Utilisez une passerelle devant plusieurs déploiements ou instances Azure OpenAI.

Les architectures de charge de travail impliquant Azure OpenAI peuvent être aussi simples qu’une ou plusieurs applications clientes consommant directement un seul modèle de déploiement Azure OpenAI, mais toutes les charges de travail ne peuvent pas être conçues avec une telle simplicité. Des scénarios plus complexes incluent des topologies avec plusieurs clients, plusieurs déploiements Azure OpenAI et/ou plusieurs instances Azure OpenAI. Dans ces situations, l’introduction d’une passerelle devant Azure OpenAI pourrait être bénéfique pour la conception de la charge de travail.

Plusieurs instances ou modèles de déploiement Azure OpenAI répondent à des exigences spécifiques dans une architecture de charge de travail. Ils peuvent être classés dans quatre topologies clés.

• Plusieurs modèles de déploiement dans une seule instance Azure OpenAI
• Plusieurs instances Azure OpenAI dans une seule région et pour un abonnement unique
• Plusieurs instances Azure OpenAI dans une seule région à travers plusieurs abonnements
• Plusieurs instances Azure OpenAI à travers plusieurs régions

Ces topologies à elles seules ne nécessitent pas l’utilisation d’une passerelle. Le choix d’une passerelle dépend de savoir si la charge de travail bénéficie de son inclusion dans l’architecture. Cet article couvre les défis auxquels chaque topologie des quatre adresses, ainsi que les avantages et les coûts de l’inclusion d’une passerelle dans chaque topologie.

Plusieurs modèles de déploiement dans une seule instance Azure OpenAI

Détails de la topologie pour plusieurs modèles de déploiement

• modèles de déploiement Azure OpenAI : multiples
• Instances Azure OpenAI : une
• Abonnements : un
• Régions : une

Cas d’utilisation de la topologie pour plusieurs modèles de déploiement

Une topologie qui comprend une seule instance Azure OpenAI mais contient plus d’un modèle déployé simultanément prend en charge les cas d’utilisation suivants :

• Exposer différentes capacités de modèle, telles que gpt-35-turbo, gpt-4, et des modèles personnalisés ajustés

• Exposer différentes versions de modèle, telles que 0613, 1106, et des modèles personnalisés ajustés pour prendre en charge l’évolution de la charge de travail ou les déploiements bleu/vert

• Exposer différentes quotas attribués (30 000 jetons par minute (TPM), 60 000 TPM) pour prendre en charge le contrôle de la consommation à travers plusieurs clients

Introduire une passerelle pour plusieurs modèles de déploiement

L’introduction d’une passerelle dans cette topologie vise principalement à abstraire les clients de la sélection autonome d’une instance de modèle spécifique parmi les déploiements disponibles sur l’instance. Une passerelle permet un contrôle côté serveur pour diriger une demande de client vers un modèle spécifique sans avoir besoin de redéployer le code client ou de changer la configuration du client.

Une passerelle est particulièrement utile lorsque vous ne contrôlez pas le code client. Elle est également utile lorsque le déploiement de la configuration du client est plus complexe ou plus risqué que le déploiement des modifications apportées à la configuration du routage de la passerelle. Vous pouvez modifier vers quel modèle un client pointe en fonction d’une stratégie de déploiement bleu/vert de vos versions de modèle, comme dans le déploiement d’un nouveau modèle affiné ou en passant de la version X à la version X+1 du même modèle.

La passerelle peut également être utilisée comme un point d’entrée API unique, qui permet à la passerelle d’identifier le client. Elle peut alors déterminer quel modèle de déploiement est utilisé pour servir l’invite en fonction de l’identité de ce client ou d’autres informations contenues dans la requête HTTP. Par exemple, dans une solution multi-locataire, les locataires peuvent être limités à un débit spécifique, et la mise en œuvre de l’architecture consiste en un modèle de déploiement par locataire avec des quotas spécifiques. Dans ce cas, l’acheminement vers le modèle du locataire serait de la responsabilité de la passerelle en fonction des informations trouvées dans la demande HTTP.

L’utilisation d’une passerelle dans cette topologie permet le suivi de l’utilisation basée sur le client. À moins que les clients n’utilisent des principaux de service Microsoft Entra distincts, les journaux d’accès pour Azure OpenAI ne pourraient pas distinguer plusieurs clients. Avoir une passerelle devant le déploiement donne à votre charge de travail l’opportunité de suivre l’utilisation par client à travers divers modèles de déploiement disponibles pour prendre en charge des modèles de facturation ou de démonstration.

Conseils pour la topologie de plusieurs modèles de déploiement

• Alors que la passerelle est en mesure de changer complètement le modèle utilisé, par exemple gpt-35-turbo vers gpt-4, ce changement serait probablement considéré comme un changement de rupture pour le client. Ne laissez pas les nouvelles fonctionnalités fonctionnelles de la passerelle détourner l’attention de l’exécution systématique des bonnes pratiques de déploiement pour cette charge de travail.

• Cette topologie est généralement assez simple pour implémenter via azure Gestion des API stratégie au lieu d’une solution de code personnalisée.

• Pour prendre en charge l’utilisation des SDK natifs avec les spécifications des API Azure OpenAI publiées, maintenez la compatibilité de l’API avec l’API Azure OpenAI. Il s’agit d’une préoccupation plus importante lorsque votre équipe n’est pas l’auteur de tout le code client de votre charge de travail. Lors de la conception de l’API HTTP pour la passerelle, gardez à l’esprit les avantages de maintenir la compatibilité de l’API HTTP Azure OpenAI.

• Bien que cette topologie prenne en charge techniquement les informations d’identification client pass-through (jetons d’accès ou clé API) pour l’instance Azure OpenAI, envisagez sérieusement de mettre en œuvre la terminaison et le rétablissement des informations d’identification. De cette façon, le client est autorisé au niveau de la passerelle, puis la passerelle est autorisée par le contrôle d’accès basé sur les rôles (RBAC) Azure à l’instance Azure OpenAI.

• Si la passerelle est conçue pour utiliser des informations d’identification pass-through, assurez-vous que les clients ne peuvent pas contourner la passerelle ou les restrictions de modèle basées sur le client.

• Déployez votre passerelle dans la même région que l’instance Azure OpenAI.

• Déployez la passerelle dans un groupe de ressources dédié dans l’abonnement qui est distinct de l’instance Azure OpenAI. Isoler l’abonnement des back ends peut aider à conduire une approche APIOps grâce à des séparations de préoccupations.

• Déployez la passerelle dans un réseau virtuel qui contient un sous-réseau pour le point de terminaison privé Liaison privée Azure de l’instance Azure OpenAI. Appliquez des règles de groupe de sécurité réseau (NSG) à ce sous-réseau pour autoriser uniquement l’accès de la passerelle à ce point de terminaison privé. Tout autre accès au plan de données aux instances Azure OpenAI doit être interdit.

Raisons d’éviter une passerelle pour plusieurs modèles de déploiement

Si contrôler la configuration de vos clients est aussi facile ou plus facile que de contrôler l’acheminement au niveau de la passerelle, l’impact accru sur la fiabilité, la sécurité, le coût, la maintenance et les performances de la passerelle pourrait ne pas valoir la peine d’ajouter ce composant architectural supplémentaire.

De plus, certains scénarios de charge de travail pourraient bénéficier de la migration d’une approche avec plusieurs modèles de déploiement à une approche de déploiement de plusieurs instances Azure OpenAI. Par exemple, envisagez plusieurs instances Azure OpenAI si vous avez plusieurs clients qui devraient utiliser différents RBAC ou clés d’accès pour accéder à leur modèle. L’utilisation de plusieurs déploiements dans une seule instance Azure OpenAI et le traitement de la segmentation d’identité logique au niveau de la passerelle est possible, mais pourrait être excessif lorsque qu’une approche de segmentation RBAC physique est disponible en utilisant des instances Azure OpenAI distinctes.

Plusieurs instances Azure OpenAI dans une seule région et pour un abonnement unique

Détails de la topologie pour plusieurs instances dans une seule région et pour un abonnement unique

• Modèles de déploiement Azure OpenAI : un ou plusieurs
• Instances Azure OpenAI : multiples
• Abonnements : un
• Régions : une

Cas pratiques concernant la topologie pour plusieurs instances dans une seule région et pour un abonnement unique

Une topologie qui inclut plusieurs instances Azure OpenAI dans une seule région et pour un abonnement unique prend en charge les cas d’utilisation suivants:

• Permet des limites de segmentation de sécurité, telles que la clé ou les RBAC par client

• Permet un modèle de refacturation facile pour différents clients

• Permet une stratégie de basculement pour la disponibilité d’Azure OpenAI, tel qu’une panne de plateforme qui affecte une instance spécifique, une mauvaise configuration du réseau ou un déploiement supprimé accidentellement

• Permet une stratégie de basculement pour la disponibilité du quota Azure OpenAI, tel que l’appariement d’une instance basée sur le PTU et d’une instance basée sur la consommation pour le débordement

Introduire une passerelle pour plusieurs instances dans une seule région et un abonnement

Il se peut qu’un modèle ne soit pas accessible à un client pour plusieurs raisons. Ces raisons incluent des perturbations dans le service Azure OpenAI, la limitation des requêtes Azure OpenAI, ou des problèmes liés aux opérations de charge de travail comme une mauvaise configuration réseau ou la suppression involontaire d’un modèle de déploiement. Pour faire face à ces défis, vous devriez mettre en œuvre une logique de réessai et de rupture de circuit.

Cette logique pourrait être implémentée côté client ou côté serveur dans une passerelle. Implémenter la logique dans une passerelle abstrait la logique des clients, résultant en aucun code répété et un seul endroit pour tester la logique. Peu importe si vous possédez le code client ou non, ce changement peut augmenter la fiabilité de la charge de travail.

L’utilisation d’une passerelle avec plusieurs instances Azure OpenAI dans une seule région et un seul abonnement vous permet de traiter tous les backends comme des déploiements actif-actif et non pas seulement de les utiliser dans des basculements actif-passif. Vous pouvez déployer le même modèle basé sur le PTU sur plusieurs instances Azure OpenAI et utiliser la passerelle pour répartir la charge entre eux.

L’une des options dont dispose une équipe de charge de travail lors de la provision de Azure OpenAI est de décider si le modèle de facturation et de débit est basé sur le PTU ou sur la consommation. Une stratégie d’optimisation des coûts pour éviter le gaspillage à travers des PTU inutilisés est de sous-provisionner légèrement l’instance PTU et de déployer également une instance basée sur la consommation à côté. L’objectif avec cette topologie est de faire en sorte que les clients consomment d’abord tous les PTU disponibles, puis "débordent" vers le déploiement basé sur la consommation pour les dépassements. Cette forme de basculement planifié bénéficie de la même raison que celle mentionnée dans le paragraphe d’introduction de cette section : garder cette complexité hors du code client.

Lorsqu’une passerelle est impliquée, elle se trouve dans une position unique pour capturer des détails sur tous les modèles de déploiement avec lesquels les clients interagissent. Alors que chaque instance de Azure OpenAI peut capturer sa propre télémétrie, le faire au sein de la passerelle permet à l’équipe de charge de travail de publier la télémétrie et les réponses d’erreur de tous les modèles consommés dans un seul magasin pour rendre la création de tableaux de bord et d’alertes unifiée plus facile.

Conseils pour la topologie de plusieurs instances dans une seule région et un seul abonnement

• Assurez-vous que la passerelle utilise les informations Retry-After disponibles dans la réponse HTTP d’Azure OpenAI lors de la prise en charge de scénarios de basculement sur la passerelle. Utilisez ces informations faisant autorité pour contrôler l’implémentation de votre coupe-circuit. N’envoyez pas continuellement une requête à un point de terminaison qui renvoie un 429 Too Many Requests Au lieu de cela, coupez le circuit pour cette instance de modèle.

• Tenter de prédire les événements de limitation avant qu’ils ne se produisent en suivant la consommation du modèle à travers des requêtes antérieures est possible dans la passerelle, mais comporte des cas particuliers. Dans la plupart des cas, il est préférable de ne pas tenter de prédire, mais d’utiliser les codes de réponse HTTP pour orienter les futures décisions de routage.

• Lorsque vous effectuez un équilibrage de charge ou une bascule vers un autre point de terminaison, incluant le débordement de PTU vers la consommation, assurez-vous toujours que ces points de terminaison utilisent le même modèle et la même version. Par exemple, ne basculez pas de gpt-4 à gpt-35-turbo ou de la version X à la version X+1 ou ne faites pas d’équilibrage de charge entre eux. Ce changement de version peut provoquer un comportement inattendu chez les clients.

• La logique d’équilibrage de charge et de basculement peut être mise en œuvre dans les politiques de gestion des API Azure. Vous pourriez être en mesure de fournir une approche plus sophistiquée en utilisant une solution de passerelle basée sur le code, mais la gestion des API est suffisante pour ce cas pratique.

• Déployez votre passerelle dans la même région que l’instance Azure OpenAI.

• Déployez la passerelle dans un groupe de ressources dédié dans l’abonnement qui est distinct des instances Azure OpenAI. Isoler la passerelle des backends peut favoriser une approche APIOps grâce à des séparations de préoccupations.

• Regroupez tous les points de terminaison privés Liaison privée des instances Azure OpenAI dans un seul sous-réseau sur le réseau virtuel de la passerelle. Appliquez des règles NSG à ce sous-réseau pour autoriser uniquement l’accès de la passerelle à ces points de terminaison privés. Tout autre accès au plan de données aux instances Azure OpenAI doit être interdit.

• Pour simplifier la logique dans le code de routage de votre passerelle, utilisez le même nom de modèle de déploiement pour minimiser la différence entre les routes HTTP. Par exemple, le nom de modèle gpt4-v1 peut être utilisé pour toutes les instances à charge équilibrée ou de déversement, qu’elles soient basées sur la consommation ou sur les PTU.

Raisons d’éviter une passerelle pour plusieurs instances dans une seule région et un seul abonnement

Une passerelle en soi n’améliore pas la capacité à facturer différents modèles à différents clients pour cette topologie spécifique. Dans cette topologie, les clients pourraient se voir accorder l’accès à leurs propres instances Azure OpenAI dédiées, ce qui soutiendrait la capacité de votre équipe de charge de travail à effectuer une facturation ou une exposition. Ce modèle prend en charge des périmètres uniques d’identité et de réseau, donc une passerelle ne serait pas nécessairement introduite spécifiquement pour la segmentation.

Si vous avez quelques clients où vous contrôlez le code, et que les clients sont facilement mis à jour, la logique que vous devriez intégrer dans la passerelle pourrait être ajoutée directement dans le code. Envisagez d’utiliser l’approche de la passerelle pour la bascule ou l’équilibrage de charge principalement lorsque vous ne possédez pas le code client ou que la complexité est inappropriée pour que les clients la gèrent.

Plusieurs instances Azure OpenAI dans une seule région à travers plusieurs abonnements

Détails topologiques pour plusieurs instances Azure OpenAI dans une seule région à travers plusieurs abonnements

• Modèles de déploiement Azure OpenAI : un ou plusieurs
• Instances Azure OpenAI : multiples
• Abonnements: multiples
• Régions : une

Cas pratiques de topologie pour plusieurs instances Azure OpenAI dans une seule région à travers plusieurs abonnements

Une topologie qui inclut plusieurs instances Azure OpenAI dans une seule région sur plusieurs abonnements prend en charge les cas d’utilisation suivants:

• Comprend tous les cas pratiques répertoriés pour plusieurs instances Azure OpenAI dans une seule région et un abonnement unique

• Vous permet d’obtenir plus de quotas basés sur la consommation, car la limite de l’abonnement est un facteur disponible pour le modèle de consommation. Vous pouvez utiliser ce quota supplémentaire pour prendre en charge une consommation hautement concurrente.

Introduire une passerelle pour plusieurs instances dans une seule région et pour plusieurs abonnements

Les mêmes raisons qui sont abordées dans la rubrique Introduire une passerelle pour plusieurs instances dans une seule région et pour un seul abonnement s’appliquent à cette topologie.

En plus de ces raisons, l’ajout d’une passerelle dans cette topologie prend également en charge une équipe centralisée fournissant un modèle « Azure OpenAI en tant que service » pour leur organisation. Étant donné que le quota basé sur la consommation est lié à l’abonnement, une équipe centralisée qui fournit des services Azure OpenAI utilisant le modèle basé sur la consommation doit déployer des instances Azure OpenAI dans plusieurs abonnements pour obtenir le quota requis. La logique de la passerelle reste largement la même.

Conseils pour la topologie de plusieurs instances dans une seule région et pour plusieurs abonnements

• Idéalement, les abonnements devraient tous être soutenus par le même locataire Microsoft Entra pour prendre en charge la cohérence dans Azure RBAC et Azure Policy.

• Déployez votre passerelle dans la même région que l’instance Azure OpenAI.

• Déployez la passerelle dans un abonnement dédié distinct des instances Azure OpenAI. Cela aide à garantir une cohérence dans l’adressage des instances Azure OpenAI et fournit une segmentation logique des tâches entre les déploiements Azure OpenAI et leur routage.

• Lorsque vous acheminez les requêtes de votre passerelle à travers les abonnements, assurez-vous que les points de terminaison privés sont joignables. Vous pouvez utiliser le routage transitif à travers un hub vers des points de terminaison privés pour les back ends dans leurs rayons respectifs. Vous pourriez être en mesure d’exposer des points de terminaison privés pour les services Azure OpenAI directement dans l’abonnement de la passerelle en utilisant des connexions Liaison privée entre les abonnements. Les connexions Liaison privée inter-abonnements seraient préférables si votre architecture et votre organisation supportent cette approche.

Raisons d’éviter une passerelle pour plusieurs instances dans une seule région et plusieurs abonnements

Toutes les raisons d’éviter une passerelle pour plusieurs instances dans une seule région et un seul abonnement s’appliquent à cette topologie.

Plusieurs instances Azure OpenAI à travers plusieurs régions

Détails topologiques pour plusieurs instances Azure OpenAI dans plusieurs régions

• modèles de déploiement Azure OpenAI : multiples
• Instances Azure OpenAI : multiples
• Abonnements : un ou plusieurs
• Régions : Multiples

Cas pratiques de topologie pour plusieurs instances Azure OpenAI dans plusieurs régions

Une topologie comprenant plusieurs instances Azure OpenAI réparties dans deux ou plusieurs régions Azure prend en charge les cas d’utilisation suivants :

• Comprend tous les cas pratiques répertoriés pour plusieurs instances Azure OpenAI dans une même région à travers plusieurs abonnements

• Permet une stratégie de basculement pour la disponibilité du service, telle que l’utilisation de paires inter-régions

• Permet une conception de résidence des données et de conformité.

• Permet la disponibilité de modèles mixtes. Certaines régions ont différents modèles et différentes quotas disponibles pour les modèles.

Bien que techniquement différents des régions Azure, cette topologie est également applicable lorsque vous avez un modèle d’IA exposé sur différents locaux telle que sur site ou dans un autre cloud.

Introduire une passerelle pour plusieurs instances dans plusieurs régions

Pour les architectures stratégiques d’entreprise qui doivent survivre à une panne régionale complète, une passerelle globale et unifiée aide à éliminer la logique de basculement du code client. Cette mise en œuvre nécessite que la passerelle elle-même ne soit pas affectée par une panne régionale.

La répartition de la charge entre les régions n’est pas typique, mais pourrait être utilisée de manière stratégique pour combiner les quotas disponibles dans les déploiements basés sur la consommation à travers les régions. Ce scénario n’exige pas que la passerelle elle-même reste indemne d’une panne régionale, mais cela est recommandé pour une fiabilité maximale de la charge de travail.

Utiliser Azure API Management (Déploiement dans une seule région)

Dans cette topologie, Azure API Management est utilisé spécifiquement pour la technologie de passerelle. Ici, API Management est déployé dans une seule région. À partir de cette instance de passerelle, vous effectuez un équilibrage de charge actif-actif entre les régions. Les stratégies dans votre passerelle font référence à toutes les instances Azure OpenAI. La passerelle nécessite une visibilité réseau sur chaque backend à travers les régions, soit par le biais d’un appairage de réseaux virtuels inter-régions ou de points de terminaison privés. Les appels de cette passerelle vers une instance Azure OpenAI dans une autre région entraînent une plus grande latence du réseau et des frais de sortie.

Votre passerelle doit respecter les signaux de limitation et de disponibilité des instances Azure OpenAI et supprimer les backends défaillants du pool jusqu'à ce qu'il soit sûr de réintégrer l'instance Azure OpenAI défaillante ou limitée. La passerelle doit réessayer la requête actuelle contre une autre instance de backend dans le pool en cas de défaillance, avant de revenir à un retour d’erreur de passerelle. La vérification de l’état de l’intégrité de la passerelle doit signaler un état d’intégrité dégradé lorsque aucune instance de backend Azure OpenAI n’est disponible.

Parce que cette topologie introduit un point de défaillance unique, la passerelle, l’utilité de cette architecture spécifique est assez limitée. Ce modèle se prête bien à la facturation basée sur la consommation dans Azure OpenAI lorsque la prévision de l’allocation PTU pourrait s’avérer trop complexe.

Variante active-passive

Ce modèle peut également être utilisé pour fournir une approche active-passive pour gérer spécifiquement les pannes régionales d’Azure OpenAI. Dans ce mode, le trafic circule normalement de la passerelle vers l’instance Azure OpenAI dans la même région que le service de gestion d’API. Cette instance d’Azure OpenAI gérerait tout le trafic attendu sans que des pannes régionales ne se produisent. Elle pourrait être basée sur PTU ou sur la consommation, selon votre modèle de facturation préféré. En cas de panne régionale d’Azure OpenAI uniquement, la passerelle peut rediriger le trafic vers une autre région avec Azure OpenAI déjà déployé en mode consommation.

Utilisation de Azure API Management (Déploiement multi-région)

Pour améliorer la fiabilité de l’architecture précédente basée sur Azure API Management, API Management prend en charge le déploiement d’une instance dans plusieurs régions Azure. Cette option de déploiement vous donne un seul plan de contrôle, via une seule instance de gestion d’API, mais des passerelles répliquées dans les régions de votre choix. Dans cette topologie, vous déployez des composants de passerelle dans chaque région contenant des instances Azure OpenAI fournissant une architecture de passerelle actif-actif.

Les stratégies (logique de routage et de traitement des demandes) sont répliquées sur chaque passerelle individuelle. Toute la logique de stratégie doit avoir une logique conditionnelle dans la stratégie pour garantir que vous appelez des instances Azure OpenAI dans la même région que la passerelle actuelle. Pour plus d’informations, veuillez consulter la section Routage des appels API vers des services backend régionaux. Le composant passerelle nécessite ensuite une visibilité réseau uniquement sur les instances Azure OpenAI dans sa propre région, généralement via des points de terminaison privés.

API Management propose un routage global par nom de domaine entièrement qualifié (FQDN) basé sur la latence la plus faible. Utilisez cette fonctionnalité intégrée, basée sur la performance pour les déploiements de passerelles actif-actif. Cette fonctionnalité intégrée aide à la fois à améliorer les performances et à gérer une panne de passerelle régionale. En utilisant le routeur global intégré, vous soutenez également les tests de reprise après sinistre car les régions peuvent être simulées en panne en désactivant les passerelles individuelles. Assurez-vous que les clients respectent la durée de vie (TTL) sur le FQDN et ont une logique de réessai appropriée pour gérer un basculement DNS récent.

Si vous devez introduire un pare-feu d’applications web dans cette architecture, vous pouvez toujours utiliser la solution de routage FQDN intégrée comme origine de backend pour votre routeur global qui implémente le pare-feu d’applications web Azure. Le routeur global déléguerait la responsabilité du basculement à API Management. Alternativement, vous pouvez utiliser les FQDN de passerelle régionaux comme membres du pool de backends. Dans cette dernière architecture, utilisez le point de terminaison /status-0123456789abcdef intégré sur chaque passerelle régionale ou un autre point de terminaison d’API d’intégrité personnalisé pour prendre en charge le basculement régional. Si vous n’êtes pas certain, commencez par l’approche FQDN de backend à origine unique.

Cette architecture fonctionne mieux si vous pouvez traiter les régions comme entièrement disponibles ou entièrement indisponibles. Cela signifie que si soit la passerelle de gestion d’API, soit l’instance Azure OpenAI est indisponible, vous voulez que le trafic client ne soit plus routé vers la passerelle de gestion d’API dans cette région. À moins qu’une autre disposition ne soit prise, si la passerelle régionale accepte toujours le trafic alors qu’Azure OpenAI est indisponible, l’erreur doit être propagée au client. Pour éviter l’erreur client, consultez une approche améliorée dans Passerelle actif-actif + Variante passive d’Azure OpenAI actif-passif.

Si une région subit une panne de la passerelle de gestion d’API ou est signalée comme non saine, les régions restantes disponibles doivent absorber 100 % du trafic provenant de ces autres régions. Cela signifie que vous devez surdimensionner les instances Azure OpenAI basées sur PTU pour gérer le nouvel afflux de trafic ou utiliser une approche active-passive pour le basculement. Utilisez le calculateur de capacité Azure OpenAI pour la planification de la capacité.

Assurez-vous que le groupe de ressources contenant Azure API Management est situé dans le même emplacement que l’instance de gestion d’API elle-même pour réduire l’impact d’une panne régionale connexe sur votre capacité à accéder au fournisseur de ressources de vos passerelles.

Mode actif-actif + actif-passif d’Azure OpenAI

La section précédente aborde la disponibilité de la passerelle en fournissant une topologie de passerelle active-actif. Cette topologie combine la passerelle active-actif avec une topologie Azure OpenAI active-passive économique. Ajouter une logique active-passive à la passerelle pour basculer vers un déploiement Azure OpenAI basé sur la consommation à partir d’un déploiement basé sur PTU peut augmenter considérablement la fiabilité de la charge de travail. Ce modèle permet toujours aux clients d’utiliser la solution de routage FQDN intégrée de la gestion d’API pour un routage basé sur les performances.

Utilisation d’une passerelle codée sur mesure

Si vos règles de routage par passerelle sont trop complexes pour que votre équipe les considère comme raisonnables en tant que politiques de gestion d’API, vous devez déployer et gérer votre propre solution. Cette architecture doit être un déploiement multi-région de votre passerelle, avec une unité d’échelle hautement disponible par région. Vous devez préparer ces déploiements avec Azure Front Door (Anycast) ou Azure Traffic Manager (DNS), généralement en utilisant un routage basé sur la latence et des vérifications appropriées de la disponibilité de la passerelle.

Utilisez Azure Front Door si vous avez besoin d’un pare-feu d’applications web et d’un accès Internet public. Utilisez Traffic Manager si vous n’avez pas besoin d’un pare-feu d’applications web et que la durée de vie du DNS est suffisante. Lorsque vous préparez vos instances de passerelle avec Azure Front Door (ou tout proxy inverse), assurez-vous que la passerelle ne peut pas être contournée. Rendez les instances de passerelle disponibles uniquement via un point de terminaison privé lors de l’utilisation de Azure Front Door et ajoutez la validation de l’en-tête HTTP X_AZURE_FDID dans votre implémentation de passerelle.

Placez les ressources par région utilisées dans votre passerelle personnalisée dans des groupes de ressources par région. Cela réduit l’impact d’une panne régionale connexe sur votre capacité à accéder au fournisseur de ressources pour vos ressources de passerelle dans cette région.

Vous pouvez également envisager de mettre en avant votre implémentation logique de passerelle avec la gestion d’API elle-même, pour les autres avantages de la gestion d’API tels que TLS, l’authentification, la vérification de l’état d’intégrité ou l’équilibrage de charge en round-robin. Cela déplace les « problèmes d’API » hors du code personnalisé de votre passerelle, laissant votre passerelle adresser spécifiquement le routage des instances Azure OpenAI et des modèles de déploiement.

Pour la conformité en matière de résidence des données, assurez-vous que chaque frontière géopolitique dispose de son propre déploiement isolé de cette architecture et que les clients ne peuvent atteindre que leur point de terminaison autorisé.

Raisons d’éviter une passerelle pour plusieurs instances dans plusieurs régions

N’implémentez pas une passerelle unifiée à travers des régions géopolitiques lorsque la résidence des données et la conformité sont requises. Cela violerait les exigences de résidence des données. Utilisez des passerelles adressables individuellement par région et suivez les directives d’une des sections précédentes.

Si l’on ne s’attend pas à ce que les clients basculent entre les régions et que vous avez la capacité de donner à chaque client une passerelle spécifique à utiliser, utilisez plutôt plusieurs passerelles, une par région, et suivez les directives d’une des sections précédentes. Ne liez pas la disponibilité des autres régions à la région contenant votre passerelle en tant que point de défaillance unique.

N’implémentez pas une passerelle unifiée si votre modèle et sa version ne sont pas disponibles dans toutes les régions exposées par la passerelle. Les clients doivent être routés vers le même modèle et la même version de modèle. Pour les passerelles multi-régionales équilibrées et de basculement, vous devez choisir un modèle et une version de modèle communs disponibles dans toutes les régions impliquées. Pour plus d’informations, consultez Disponibilité du modèle. Si vous ne pouvez pas normaliser le modèle et la version du modèle, l’avantage de la passerelle est limité.

Recommandations générales

Quelle que soit la topologie requise par votre charge de travail, il existe quelques recommandations transversales à prendre en compte lors de la construction de votre solution de passerelle.

Interactions avec état

Lorsque les clients utilisent les fonctionnalités avec état d’Azure OpenAI, telles que l’API Assistants, vous devez configurer votre passerelle pour épingler un client à un back-end spécifique au cours de cette interaction. Pour ce faire, vous pouvez stocker les données d’instance dans un cookie. Dans ces scénarios, envisagez de renvoyer une réponse de l’API Azure OpenAI comme un 429 à un client épinglé au lieu de le rediriger vers une autre instance Azure OpenAI. Cela permet au client de gérer explicitement une indisponibilité soudaine plutôt que de la cacher et d’être dirigé vers une instance de modèle qui n’a pas d’historique.

Vérifications de l’intégrité de la passerelle

Il existe deux perspectives de contrôle de santé à prendre en compte, quelle que soit la topologie.

Si votre passerelle est basée sur le mode de rotation ou effectue strictement une bascule de disponibilité du service, vous voudrez avoir un moyen de mettre une instance (ou un modèle) Azure OpenAI hors statut de disponibilité. Azure OpenAI ne fournit aucun type de point de terminaison de vérification d’intégrité pour savoir préventivement s’il est disponible pour gérer les demandes. Vous pourriez envoyer des transitions synthétiques, mais cela consomme la capacité du modèle. À moins que vous n’ayez une autre source de signal fiable pour la disponibilité de l’instance Azure OpenAI et du modèle, votre passerelle doit probablement supposer que l’instance Azure OpenAI est active, puis gérer les codes d’état HTTP 429, 500, 503 comme un signal de mise en circuit pour les futures demandes sur cette instance ou ce modèle pendant une période donnée. Pour les situations de limitation, honorez toujours les données de l’en-tête Retry-After trouvé dans les réponses de l’API Azure OpenAI pour les codes de réponse 429 dans votre logique de mise en circuit. Si vous utilisez Azure API Management, envisagez d’utiliser la fonctionnalité de circuit breaker intégrée.

Vos clients ou votre équipe d’opérations de charge de travail peuvent souhaiter disposer d’une vérification d’intégrité exposée sur votre passerelle à des fins de routage ou d’inspection propres. Si vous utilisez API Management, le /status-0123456789abcdef par défaut peut ne pas être assez détaillé car il s’adresse principalement à l’instance de passerelle de gestion d’API, pas à vos backends. Envisagez d’ajouter une API de vérification d’intégrité dédiée qui peut renvoyer des données significatives aux clients ou aux systèmes d’observabilité sur la disponibilité de la passerelle ou des routes spécifiques dans la passerelle.

Pratiques de déploiement sécurisé

Vous pouvez utiliser des implémentations de passerelles pour orchestrer des déploiements bleu-vert de modèles mis à jour. Les modèles Azure OpenAI sont mis à jour avec de nouvelles versions de modèles et de nouveaux modèles, et vous pouvez avoir de nouveaux modèles affinés.

Après avoir testé l’impact d’un changement en préproduction, évaluez si les clients de production doivent être « basculés » vers la nouvelle version du modèle ou si le trafic doit plutôt être déplacé. Le modèle de passerelle décrit précédemment permet au back-end de déployer les deux modèles simultanément. Le déploiement simultané des modèles donne à la passerelle le pouvoir de rediriger le trafic en fonction de la pratique de déploiement sûre de l’équipe de charge de travail, à savoir le déploiement incrémentiel.

Même si vous n’utilisez pas de déploiements bleu/vert, l’approche APIOps de votre charge de travail doit être définie et suffisamment automatisée en fonction du taux de changement de vos instances de backend et de vos modèles de déploiement.

Implémentation suffisante

Beaucoup des scénarios introduits dans cet article visent à augmenter l’objectif potentiel de niveau de service (SLO) de votre charge de travail en réduisant la complexité des clients et en mettant en œuvre des techniques fiables d’autoprotection. D’autres améliorent la sécurité de la charge de travail en déplaçant les contrôles d’accès vers des modèles spécifiques loin d’Azure OpenAI. Assurez-vous que l’introduction de la passerelle ne va pas à l’encontre de ces objectifs. Comprenez les risques d’ajouter un nouveau point de défaillance unique soit par des défauts de service soit par des problèmes de configuration causés par l’homme dans la passerelle, la logique de routage complexe ou les risques d’exposer plus de modèles à des clients non autorisés que prévu.

Souveraineté des données

Les différentes approches en mode actif-actif et actif-passif doivent être évaluées du point de vue de la conformité à la résidence des données pour votre charge de travail. Beaucoup de ces modèles seraient applicables à l’architecture de votre charge de travail si les régions impliquées restent toujours dans la même limite géopolitique. Pour prendre en charge ce scénario, vous devez traiter les frontières géopolitiques comme des tampons isolés et appliquer exclusivement la gestion en mode actif-actif ou actif-passif à l’intérieur de ce tampon.

En particulier, tout routage basé sur les performances doit être examiné de près pour garantir la conformité à la souveraineté des données. Dans les scénarios de souveraineté des données, vous ne pouvez pas fournir de services à des clients d’une autre géographie tout en restant conforme. Toutes les architectures de passerelle impliquant la résidence des données doivent garantir que les clients utilisent uniquement des points de terminaison dans leur région géopolitique. Les clients doivent être bloqués d’utiliser d’autres points de terminaison de la passerelle et la passerelle elle-même ne doit pas violer la confiance du client en effectuant une demande transfrontalière. La manière la plus fiable d’implémenter cette segmentation est de construire votre architecture autour d’une passerelle entièrement indépendante et hautement disponible par région géopolitique.

Autorisation Azure OpenAI

La passerelle doit s’authentifier auprès de toutes les instances Azure OpenAI avec lesquelles elle interagit. À moins que vous n’ayez conçu la passerelle pour une authentification pass-through, la passerelle doit utiliser une identité gérée pour ses informations d’identification. Ainsi, chaque instance Azure OpenAI doit configurer le RBAC à moindre privilège pour les identités gérées des passerelles. Pour les architectures actives-actives et de basculement, assurez-vous que l’identité de la passerelle a des permissions équivalentes dans toutes les instances Azure OpenAI impliquées.

Azure Policy

La cohérence entre les modèles de déploiement et les instances Azure OpenAI est importante dans les situations actif-actif ou actif-passif. Utilisez les stratégies Azure pour aider à garantir la cohérence entre les différentes instances Azure OpenAI ou les modèles de déploiement. Si les politiques intégrées pour Azure OpenAI ne sont pas suffisantes pour garantir la cohérence entre eux, envisagez de créer ou d’utiliser des politiques personnalisées créées par la communauté.

Redondance de la passerelle

Bien que non spécifique aux multiples back-ends, l’implémentation de la passerelle de chaque région doit toujours être construite avec une redondance et être hautement disponible au sein de l’unité d’échelle. Privilégiez les régions avec des zones de disponibilité et assurez-vous que votre passerelle est répartie entre elles. Déployez plusieurs instances de la passerelle de sorte que le point de défaillance unique soit limité à une panne régionale complète, non due à la faute d’une seule instance de calcul dans votre passerelle. Pour API Management, déployez deux unités ou plus dans deux zones ou plus. Pour les implémentations de code personnalisées, déployez au moins trois instances avec une distribution optimale entre les zones de disponibilité.

Implémentations de passerelle

Azure ne propose pas de solution clé en main ni d’architecture de référence pour construire une telle passerelle. Comme mentionné dans l’article d’introduction, votre équipe de charge de travail doit construire et exploiter cette passerelle. Voici quelques exemples d’implémentations prises en charge par la communauté couvrant certains des cas d’usage mentionnés précédemment. Envisagez de référencer ces exemples GitHub lorsque vous créez votre propre preuve de concept (POC).

Implémentation	Exemple
Gestion des API Azure	Équilibre de charge intelligent pour Azure OpenAI utilisant Azure API Management - Ce référentiel GitHub contient du code de stratégie d’échantillon et des instructions pour le déployer dans votre abonnement. Mise à l’échelle d’Azure OpenAI en utilisant Azure API Management - Ce référentiel GitHub contient du code de stratégie d’échantillon et des instructions pour le débordement de PTU et de consommation. Il existe également des stratégies de gestion des API soutenues par la communauté dans le référentiel de la boîte à outils de la passerelle GenAI.
Code personnalisé	Équilibre de charge intelligent pour Azure OpenAI en utilisant Azure Container Apps Ce référentiel GitHub contient du code C# d’échantillon et des instructions pour construire le conteneur et le déployer dans votre abonnement.

Étapes suivantes

Avoir une implémentation de passerelle pour votre charge de travail offre des avantages qui vont au-delà de l’avantage de routage tactique multiple du back-end décrit dans cet article. Renseignez-vous sur les autres problèmes qu’une passerelle peut résoudre.

Ressources associées

• Azure OpenAI Service
• Passerelle API dans API Management Azure
• Stratégies de gestion de l’API Azure OpenAI