Le service Azure OpenAI expose des API HTTP qui permettent à vos applications d’effectuer des intégrations ou des complétions en utilisant les grands modèles de langage (LLMs) d’OpenAI. Les applications intelligentes appellent ces API HTTP directement à partir de clients ou d’orchestrateurs. Les exemples de clients incluent le code d’interface utilisateur de chat et les pipelines de traitement de données personnalisés. Les exemples d’orchestrateurs incluent LangChain, Semantic Kernel et les flux d'invite Azure Machine Learning. Lorsque votre charge de travail se connecte à une ou plusieurs instances Azure OpenAI, vous devez décider si ces consommateurs se connectent directement ou via une passerelle API à proxy inverse.
Consultez ce guide pour comprendre les principaux défis dans les cinq piliers du Cadre Azure Well-Architected que vous rencontrerez si la conception de votre charge de travail inclut un accès direct de vos consommateurs aux API de plan de données Azure OpenAI. Découvrez ensuite comment l’introduction d’une passerelle dans votre architecture peut contribuer à résoudre ces problèmes d’accès direct, tout en introduisant de nouveaux défis. Cet article décrit le modèle architectural, mais pas la manière de mettre en œuvre la passerelle.
Étant donné qu’une passerelle peut être utilisée pour résoudre des scénarios spécifiques qui ne sont pas forcément présents dans toutes les charges de travail, veillez à consulter les conseils relatifs aux scénarios spécifiques, qui examinent plus en détail ce cas d’utilisation spécifique d’une passerelle.
Principaux défis
Sans passerelle API ou sans la possibilité d’ajouter une logique aux API HTTP Azure OpenAI, le client doit gérer la logique du client API, qui comprend des mécanismes de relance ou des coupe-circuits. Cette situation peut s’avérer difficile dans les scénarios où vous ne contrôlez pas directement le code client, ou lorsque le code est limité à une utilisation spécifique du SDK. Plusieurs clients ou plusieurs instances et déploiements Azure OpenAI présentent d’autres défis, tels que la coordination des déploiements sûrs et l’observabilité.
Cette section fournit des exemples de défis architecturaux clés spécifiques auxquels vous pourriez être confronté si votre architecture ne prend en charge que l’accès direct à Azure OpenAI à partir des consommateurs. Les défis sont organisés en utilisant les piliers du Cadre Azure Well-Architected.
Défis de fiabilité
La fiabilité de la charge de travail dépend de plusieurs facteurs, notamment sa capacité d’auto-préservation et d’auto-récupération, souvent mise en œuvre à travers des mécanismes de réplication et de basculement. Sans passerelle, tous les problèmes de fiabilité doivent être traités exclusivement en utilisant la logique du client et les fonctionnalités du service Azure OpenAI. La fiabilité de la charge de travail est compromise lorsqu’il n’y a pas suffisamment de contrôle de fiabilité disponible dans l’une ou l’autre de ces deux surfaces.
Redondance : basculer entre plusieurs instances Azure OpenAI en fonction de la disponibilité du service est une responsabilité du client que vous devez contrôler via la configuration et la logique personnalisée.
Expansion pour gérer les pics : basculer vers des instances Azure OpenAI avec capacité lorsqu’elles sont limitées est une autre responsabilité du client que vous devez contrôler via la configuration et la logique personnalisée. La mise à jour de multiples configurations de clients pour de nouvelles instances Azure OpenAI présente un risque plus important et pose des problèmes de délais. Il en va de même pour la mise à jour du code client pour implémenter des changements de logique, tels que diriger les demandes de faible priorité vers une file d’attente pendant les périodes de forte demande.
Équilibrage de la charge ou limitation : Les API Azure OpenAI limitent les requêtes en renvoyant un code de réponse d’erreur HTTP 429 aux requêtes qui dépassent le nombre de tokens par minute (TPM) ou de requêtes par minute (RPM) dans le modèle de paiement à l’utilisation. Les API Azure OpenAI étranglent également les requêtes qui dépassent la capacité des unités de débit provisionnées (PTU) pour le modèle de facturation préprovisionné. La gestion d’une logique appropriée de back-off et de réessai est laissée exclusivement aux implémentations client.
Défis de sécurité
Les contrôles de sécurité doivent contribuer à protéger la confidentialité, l’intégrité et la disponibilité de la charge de travail. Sans passerelle, toutes les préoccupations en matière de sécurité doivent être traitées exclusivement dans la logique du client et les fonctionnalités du service Azure OpenAI. Les exigences de charge de travail peuvent exiger plus que ce qui est disponible pour la segmentation client, le contrôle client ou les fonctionnalités de sécurité du service pour une communication directe.
Gestion des identités - étendue d’authentification : Les API de plan de données exposées par Azure OpenAI peuvent être sécurisées de deux manières, clé API ou contrôle d’accès basé sur les rôles Azure (RBAC). Dans les deux cas, l’authentification se fait au niveau de l’instance Azure OpenAI, et non au niveau du déploiement individuel, ce qui introduit une complexité pour fournir un accès au moindre privilège et une segmentation de l’identité pour des modèles de déploiement spécifiques.
Gestion des identités - fournisseurs d’identités : Les clients qui ne peuvent pas utiliser les identités situées dans le locataire Microsoft Entra qui soutient l’instance Azure OpenAI doivent partager une seule clé API d’accès complet. Les clés API ont une utilité limitée en matière de sécurité et posent des problèmes lorsque plusieurs clients sont impliqués et qu’ils partagent tous la même identité.
Sécurité du réseau : selon l’emplacement du client par rapport à vos instances Azure OpenAI, l’accès Internet public aux modèles de langage peut être nécessaire.
Souveraineté des données : la souveraineté des données dans le contexte d’Azure OpenAI fait référence aux exigences légales et réglementaires liées au stockage et au traitement des données dans les limites géographiques d’un pays ou d’une région spécifique. Votre charge de travail doit garantir une affinité régionale afin que les clients puissent se conformer aux lois sur la résidence et la souveraineté des données. Ce processus implique plusieurs déploiements d’Azure OpenAI.
Les défis liés à l’optimisation des coûts
Les charges de travail bénéficient lorsque les architectures minimisent le gaspillage et maximisent l’utilité. Une modélisation et une surveillance des coûts solides sont une exigence importante pour toute charge de travail. Sans une passerelle, l’utilisation du PTU ou le suivi des coûts par client peuvent être réalisés de manière autoritaire exclusivement en agrégeant la télémétrie d’utilisation des instances Azure OpenAI.
Suivi des coûts : la capacité de fournir une perspective financière sur l’utilisation d’Azure OpenAI est limitée aux données agrégées à partir de la télémétrie d’utilisation des instances Azure OpenAI. Lorsque vous devez procéder à une facturation ou à une rétrocession, vous devez attribuer cette télémétrie d'utilisation à divers clients dans différents départements ou même à des clients dans le cadre de scénarios multilocataires.
Utilisation du débit provisionné : votre charge de travail souhaite éviter le gaspillage en utilisant pleinement le débit provisionné pour lequel vous avez payé. Cela signifie que les clients doivent être fiables et coordonnés pour utiliser des modèles de déploiement basés sur le PTU avant de déborder vers des déploiements basés sur la consommation.
Les défis liés à l’excellence opérationnelle
Sans passerelle, l’observabilité, le contrôle des changements et les processus de développement sont limités à ce qui est fourni par la communication directe entre le client et le serveur.
Contrôle des quotas : les clients reçoivent des codes de réponse 429 directement d’Azure OpenAI lorsque les API HTTP sont limitées. Les opérateurs de charge de travail sont chargés de veiller à ce qu’un quota suffisant soit disponible pour une utilisation légitime et à ce que les clients qui se comportent mal ne consomment pas en excès. Lorsque votre charge de travail consiste en plusieurs modèles de déploiement, il peut être difficile de visualiser l’utilisation et la disponibilité des quotas.
Surveillance et observabilité : Les mesures par défaut d’Azure OpenAI sont disponibles via Azure Monitor. Cependant, la disponibilité des données s’accompagne d’un temps de latence et ne permet pas une surveillance en temps réel.
Pratiques de déploiement sûres : Votre processus LLMOps nécessite une coordination entre les clients et les modèles déployés dans Azure OpenAI. Pour les approches de déploiement avancées, telles que blue-green ou canary, la logique doit être gérée côté client.
Les défis liés à l’efficacité des performances
Sans passerelle, votre charge de travail fait peser sur les clients la responsabilité de bien se comporter individuellement et de se comporter équitablement avec les autres clients face à une capacité limitée.
Optimisation des performances - trafic prioritaire : prioriser les demandes des clients afin que les clients à haute priorité aient un accès préférentiel sur les clients à faible priorité nécessiterait une coordination étendue et probablement intenable entre clients. Certains travaux bénéficieraient d’avoir des demandes de faible priorité mises en file d’attente pour s’exécuter lorsque l’utilisation du modèle est faible.
Optimisation des performances - conformité des clients : Pour partager la capacité, les clients doivent faire preuve d’un comportement approprié. C’est le cas, par exemple, lorsque les clients s’assurent que
max_tokensetbest_ofsont réglés sur des valeurs approuvées. Sans une passerelle, vous devrez faire confiance aux clients pour agir dans le meilleur intérêt de préserver la capacité de votre instance Azure OpenAI.Minimiser la latence : bien que la latence réseau soit généralement un petit composant du flux global de demandes de suggestion et de complétion, s’assurer que les clients sont dirigés vers un point de terminaison réseau et un modèle proche d’eux pourrait être bénéfique. Sans passerelle, les clients devraient choisir eux-mêmes les points de terminaison de modèle de déploiement à utiliser et les informations d’identification nécessaires pour cette API de plan de données Azure OpenAI spécifique.
Solution
Figure 1 : Architecture conceptuelle d’accès à Azure OpenAI via une passerelle
Pour relever les nombreux défis énumérés dans la section Défis clés, vous pouvez injecter une passerelle de proxy inverse pour découpler l’application intelligente d’Azure OpenAI. Ce délestage de la passerelle vous permet de déplacer la responsabilité, la complexité et l’observabilité des clients et vous donne l’occasion d’augmenter Azure OpenAI en fournissant d’autres capacités qui ne sont pas intégrées. Quelques exemples :
Possibilité de mettre en œuvre l’authentification fédérée.
La capacité de contrôler la pression sur les modèles en limitant les taux.
Surveillance transversale et entre modèles.
Capacité d’introduire une agrégation de passerelle et un acheminement avancé vers plusieurs services tels que l’acheminement de messages à faible priorité vers une file d’attente pour un nivellement de charge basé sur la file d’attente ou vers le calcul pour effectuer des tâches.
Équilibrage de charge utilisant la surveillance de l’état du point de terminaison d’intégrité pour router uniquement vers les points de terminaison d’intégrité en ouvrant/fermant le circuit sur des modèles de déploiement indisponibles ou surchargés.
Pour certains scénarios spécifiques, il existe davantage de conseils qui concernent directement une passerelle API et les instances Azure OpenAI. Ces scénarios sont répertoriés dans la section Étape suivante.
À propos de l’installation
Lorsque vous introduisez un nouveau composant dans votre architecture, vous devez évaluer les nouveaux compromis introduits. Lorsque vous injectez une passerelle API entre vos clients et le plan de données Azure OpenAI pour résoudre l’un des défis essentiels, vous introduisez de nouvelles considérations dans votre architecture. Évaluez attentivement si l’impact sur la charge de travail à travers ces considérations architecturales justifie la valeur ajoutée ou l’utilité de la passerelle.
Fiabilité
La fiabilité garantit que votre application respecte les engagements que vous avez pris envers vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.
La solution de passerelle peut introduire un point de défaillance unique. Cette défaillance peut avoir son origine dans la disponibilité du service de la plateforme de la passerelle, les interruptions dues aux déploiements de code ou de configuration, ou même la mauvaise configuration des points de terminaison API critiques dans votre passerelle. Assurez-vous de concevoir votre implémentation pour répondre aux exigences de disponibilité de votre charge de travail. Tenez compte des capacités de résilience et de tolérance aux pannes dans l’implémentation en incluant la passerelle dans l’analyse du mode de défaillance de la charge de travail.
Votre solution peut nécessiter des capacités de routage global si votre architecture nécessite des instances Azure OpenAI dans plusieurs régions. Cette situation peut compliquer davantage la topologie par la gestion de noms de domaine pleinement qualifiés supplémentaires, de certificats TLS et de composants de routage plus globaux.
Important
Ne mettez pas en œuvre une passerelle si cela risque de compromettre la capacité de votre charge de travail à atteindre les objectifs de niveau de service (SLO) convenus.
Sécurité
Lorsque vous considérez comment une passerelle API bénéficie à votre architecture, utilisez la liste de contrôle de conception pour la sécurité pour évaluer votre conception. Vous devez prendre en compte les considérations de sécurité, telles que les suivantes :
L’empreinte de la charge de travail est augmentée avec l’ajout de la passerelle. Cette augmentation de l’empreinte apporte des considérations supplémentaires en matière de gestion des identités et des accès (IAM) des ressources Azure, des efforts de renforcement accrus, et plus encore.
La passerelle peut agir comme une transition de frontière réseau entre l’espace réseau client et l’espace réseau privé Azure OpenAI. Même si la passerelle rend privé un point de terminaison Azure OpenAI qui faisait auparavant face à Internet grâce à l’utilisation d'une liaison privée Azure, il devient le nouveau point d’entrée et doit être sécurisé de manière adéquate.
Une passerelle est dans une position unique pour voir les données de requête brutes et les réponses formulées du modèle de langage, qui pourraient inclure des données confidentielles provenant de l’une ou l’autre source. La conformité des données et le champ d’application de la réglementation s’étendent désormais à cet autre composant.
Une passerelle peut étendre la portée de l’autorisation et de l’authentification client au-delà de l’authentification par Microsoft Entra ID et clé API, potentiellement à travers plusieurs fournisseurs d’identité (IdP).
La souveraineté des données doit être prise en compte dans votre mise en œuvre pour les implémentations multirégionales. Assurez-vous que votre logique de calcul de passerelle et de routage respecte les exigences de souveraineté imposées à votre charge de travail.
Important
N’implémentez pas une passerelle si cela laisse votre charge de travail incapable de protéger la confidentialité, l’intégrité ou la disponibilité de celle-ci ou des données de ses utilisateurs.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.
Toutes les passerelles API mises en œuvre ont des coûts d’exécution qui doivent être budgétisés et pris en compte. Ces coûts augmentent généralement avec les fonctionnalités visant à garantir la fiabilité, la sécurité et les performances de la passerelle elle-même, ainsi qu’avec les coûts opérationnels introduits par la gestion de l’APIOps ajoutée. Ces coûts supplémentaires doivent être mesurés par rapport à la nouvelle valeur délivrée par le système avec la passerelle. Vous voulez atteindre un point où les nouvelles capacités introduites par l’utilisation d’une passerelle l’emportent sur le coût de mise en œuvre et de maintenance de la passerelle. En fonction de la relation de votre charge de travail avec ses utilisateurs, vous pourriez être en mesure de facturer l’utilisation.
Excellence opérationnelle
Lorsque vous considérez comment une passerelle API bénéficie à votre architecture, utilisez la liste de contrôle de conception pour l’excellence opérationnelle pour évaluer votre conception. Vous devez prendre en compte des considérations d’excellence opérationnelle telles que les suivantes :
La passerelle elle-même doit être surveillée par la solution de surveillance de votre charge de travail et éventuellement par les clients. Cela signifie que le calcul et les opérations de la passerelle doivent être inclus dans la modélisation de l’intégrité de votre charge de travail.
Vos pratiques de déploiement sûr doivent maintenant aborder le déploiement de l’infrastructure de passerelle API et le code ou la configuration du routage de la passerelle. Votre solution d’automatisation de l’infrastructure et d’infrastructure en tant que code (IaC) doit prendre en compte la manière de traiter votre passerelle comme une ressource à longue durée de vie dans la charge de travail.
Vous devez construire ou étendre votre approche APIOps pour couvrir les API exposées dans la passerelle.
Efficacité des performances
Lorsque vous considérez comment une passerelle API bénéficie à votre architecture, utilisez la liste de contrôle de conception pour l’efficacité des performances pour évaluer votre conception. Vous devez tenir compte de considérations liées à l’efficacité des performances, telles que les suivantes :
Le service de passerelle peut introduire un goulot d’étranglement de débit. Assurez-vous que la passerelle a des performances adéquates pour gérer la charge complète concurrente et peut facilement s’adapter à vos attentes de croissance. Veillez à l’élasticité de la solution afin que la passerelle puisse réduire l’offre, ou diminuer l’échelle, lorsque la demande est faible, comme dans le cas d’une utilisation pendant les jours ouvrables.
Le service de passerelle doit effectuer un traitement par requête et introduit une latence supplémentaire par invocation de l’API. Vous devez optimiser votre logique de routage pour maintenir des performances élevées.
Dans la plupart des cas, la passerelle devrait être géographiquement proche à la fois des utilisateurs et des instances Azure OpenAI pour réduire la latence. Bien que la latence du réseau ne représente généralement qu’un faible pourcentage du temps dans l’ensemble des appels d’API aux modèles de langage, elle peut constituer un facteur concurrentiel pour votre charge de travail.
Évaluez l’impact de la passerelle sur les fonctionnalités d’Azure OpenAI, telles que les réponses en continu ou l’épinglage d’instances pour les interactions avec état, comme l’API Assistants.
Important
Ne mettez pas en œuvre une passerelle si cela rend impossible la réalisation des objectifs de performance négociés ou si cela compromet d’autres compromis.
Options d’implémentation
Azure n’offre pas de solution clé en main conçue spécifiquement pour proxyer l’API HTTP d’Azure OpenAI ou d’autres API d’inférence de modèle de langage personnalisées. Mais il existe tout de même plusieurs options à mettre en œuvre par votre équipe de charge de travail, comme une passerelle dans Azure.
Utiliser Gestion des API Azure
Azure API Management est un service géré par la plate-forme conçu pour décharger les préoccupations transversales des API basées sur HTTP. Il est piloté par configuration et prend en charge la personnalisation grâce à son système de stratégies de traitement des demandes entrantes et sortantes. Il prend en charge des répliques hautement disponibles, redondantes par zone, et même multi-régions à travers un seul plan de contrôle.
La plupart de la logique de routage et de traitement des demandes de la passerelle doit être implémentée dans le système de stratégies de l’API Management. Vous pouvez combiner des stratégies intégrées, telles que Limiter l’utilisation des tokens Azure OpenAI API ou Émettre des métriques pour la consommation des tokens Azure OpenAI, et vos propres politiques personnalisées. Quelques exemples de politiques personnalisées et de scénarios peuvent être trouvés dans le référentiel communautaire GitHub du toolkit de passerelle de gestion des API.
Utilisez le Guide de service du cadre bien construit pour la gestion des API lors de la conception d’une solution impliquant Azure API Management.
L’utilisation d’Azure API Management pour votre implémentation de passerelle est généralement l’approche privilégiée pour construire et exploiter une passerelle Azure OpenAI. Cette solution est privilégiée car le service est une offre de plateforme en tant que service (PaaS) avec de riches capacités intégrées, une haute disponibilité et des options de mise en réseau. Il dispose également d’approches APIOps robustes pour gérer vos API d’achèvement.
utiliser du code personnalisé.
L’approche du code personnalisé exige qu’une équipe de développement logiciel crée une solution codée personnalisée et la déploie sur une plateforme d’application Azure de son choix. La création d’une solution auto-gérée pour gérer la logique de passerelle peut convenir aux équipes de charge de travail compétentes dans la gestion du code de réseau et de routage.
La charge de travail peut généralement utiliser le compute qui leur est familier, comme l’hébergement du code de la passerelle sur Azure App Service, Azure Container Apps ou Azure Kubernetes Service.
Les déploiements de code personnalisé peuvent également être frontalisés avec API Management lorsque API Management est utilisé exclusivement pour ses capacités de passerelle API HTTP de base entre vos clients et votre code personnalisé. Ainsi, votre code personnalisé s’interface exclusivement avec vos API HTTP Azure OpenAI sur la base de la logique commerciale nécessaire.
L’utilisation d’une technologie de passerelle non Microsoft, c’est-à-dire d’un produit ou d’un service qui n’est pas fourni de manière native par Azure, peut être considérée comme faisant partie de cette approche.
Exemple d’architecture
Figure 2 : Exemple d’architecture d’accès à Azure OpenAI via une passerelle basée sur Azure API Management
Étapes suivantes
Découvrez un scénario spécifique où le déploiement d’une passerelle entre une application intelligente et les déploiements Azure OpenAI est utilisé pour répondre aux besoins de charge de travail :
- Équilibrage de charge ou basculement entre plusieurs instances de backend
- Authentification et autorisation personnalisées pour les applications clientes
Découvrez les moyens de mettre en œuvre la journalisation et la surveillance pour les modèles Azure OpenAI.
Ressources associées
- Azure OpenAI Service
- Passerelle API dans API Management Azure
- Accélérateur de zone d’atterrissage de gestion des API couvrant des scénarios d’IA générative
- Kit de ressources de passerelle de gestion des API