Partager via

Utiliser Gestion des API Azure dans une solution multilocataire

Gestion des API Azure est à la fois une passerelle API et un proxy inverse pour les API. Il fournit de nombreuses fonctionnalités utiles pour les applications axées sur l’API, notamment la mise en cache, la simulation de réponse et un portail de développement. Cet article récapitule certaines des principales fonctionnalités de Gestion des API qui sont utiles pour les solutions multilocataires.

Remarque

Cet article est consacré à la façon dont vous pouvez utiliser Gestion des API lorsque vous disposez de vos propres applications multilocataires qui hébergent des API pour un usage interne ou externe.

Une autre forme de multilocation consiste à fournir la passerelle Gestion des API en tant que service à d’autres équipes. Par exemple, une organisation peut avoir une instance Gestion des API partagée déployée et utilisée par plusieurs équipes d’applications. Cet article ne traite pas de cette forme d’architecture mutualisée. Envisagez d’utiliser des espaces de travail, qui vous aident à partager une instance Gestion des API avec plusieurs équipes qui peuvent avoir différents niveaux d’accès.

Modèles d’isolation

Le service Gestion des API est généralement déployé en tant que composant partagé avec une seule instance qui répond aux demandes de plusieurs locataires. Toutefois, en fonction de votre modèle de location, il existe de nombreuses façons de déployer Gestion des API. Cet article part du principe que vous déployez votre solution à l’aide d’empreintes de déploiement.

En règle générale, la façon dont la gestion des API est utilisée reste cohérente entre différents modèles d’isolation. Cette section est consacrée aux différences de coût et de complexité entre les modèles d’isolation et à la façon dont chaque méthode achemine les requêtes vers vos applications API back-end.

Considération Instance partagée avec serveurs principaux monolocataires Instance partagée avec un back-end multilocataire partagé Instance pour chaque locataire
Nombre de locataires pris en charge Plusieurs Pratiquement illimité Un pour chaque instance.
Coût Moins grand Moins grand Plus haut
Complexité du déploiement Bas. Instance unique à gérer pour chaque tampon. Bas. Instance unique à gérer pour chaque tampon. Haut. Plusieurs instances à gérer.
Complexité de la configuration d’acheminement Plus haut Moins grand Moins grand
Sensibilité aux problèmes de voisin bruyant Oui Oui Non
Isolation réseau au niveau du locataire Non Non Oui
Exemple de scénario Noms de domaine personnalisés pour chaque locataire Solution multilocataire grande avec une couche applicative partagée Empreintes de déploiement spécifiques au locataire

Modèles d’isolation d’instance partagée

Il est courant de partager une instance Gestion des API entre plusieurs locataires, car cela permet de réduire les coûts et la complexité du déploiement et de la gestion. La façon dont vous pouvez partager une instance Gestion des API dépend de la manière dont vous affectez des locataires aux applications API back-end.

Application principale monolocataire

Si vous déployez des applications back-end distinctes pour chaque locataire, vous pouvez déployer une seule instance Gestion des API et acheminer le trafic vers le back-end du locataire approprié pour chaque requête. Cette méthode implique de configurer la Gestion des API avec les noms d’hôte back-end pour chaque locataire ou de disposer d’un autre moyen pour associer une requête entrante au back-end du locataire approprié.

Étant donné qu’elle nécessite une recherche supplémentaire, cette méthode risque de ne pas pouvoir s’adapter à un grand nombre de locataires partageant une même instance Gestion des API. Il peut également y avoir une surcharge de performances lorsque vous recherchez le serveur principal du locataire. Toutefois, la taille de cette surcharge de performances dépend de la façon dont vous concevez cette recherche.

Application principale multilocataire partagée

Dans les scénarios où vos locataires partagent une même application back-end, le processus de routage Gestion des API est simplifié, car vous pouvez acheminer toutes les requêtes vers un seul back-end. Si vous utilisez des domaines génériques ou des domaines émis par un fournisseur, vous pouvez peut-être atteindre une échelle presque illimitée à l’aide de cette approche. En outre, étant donné que les requêtes n’ont pas besoin d’être mappées au back-end d’un locataire, les décisions de routage personnalisées n’ont aucun impact sur les performances.

Instance pour chaque locataire

Dans certains scénarios, vous pouvez déployer une instance de Gestion des API pour chaque locataire. Nous vous recommandons cette approche uniquement si vous avez peu de locataires ou si vous avez des exigences de conformité strictes qui vous empêchent de partager n’importe quelle infrastructure entre locataires. Par exemple, si vous déployez un réseau virtuel dédié pour chaque locataire, vous devez probablement déployer également une instance Gestion des API dédiée pour chaque locataire.

Conseil

Si votre seule raison de déployer plusieurs instances consiste à prendre en charge des utilisateurs de différentes régions géographiques, vous devriez déterminer si la fonctionnalité de déploiement multirégion du service Gestion des API répond à vos besoins.

Lorsque vous déployez une instance de Gestion des API, vous devez prendre en compte les limites de service, notamment les limites qui peuvent s’appliquer au nombre d’instances Gestion des API au sein d’un abonnement ou d’une région Azure.

Les instances monolocataires présentent généralement une configuration de routage minimale, car vous pouvez acheminer toutes les requêtes vers un seul back-end. Ce scénario ne nécessite pas de décisions de routage personnalisées. Il n’y a donc aucun impact supplémentaire sur les performances. Toutefois, le coût des ressources est généralement plus élevé que si vous déployez une instance partagée. Si vous devez déployer des instances monolocataires, déterminez si les passerelles auto-hébergées vous permettent de réutiliser des ressources de calcul spécifiques au locataire que vous déployez déjà.

Fonctionnalités Gestion des API qui prennent en charge l’architecture mutualisée

Le gestion des API utilise des politiques pour permettre la flexibilité. Vous pouvez personnaliser la façon dont les demandes sont validées, acheminées et traitées lorsque vous utilisez des stratégies. Lorsque vous concevez une solution multilocataire avec Gestion des API, vous utilisez des stratégies pour implémenter une grande partie de ses fonctionnalités.

Identifier les locataires sur les requêtes entrantes

Réfléchissez à la façon dont vous pouvez identifier le locataire approprié dans chaque requête entrante. Dans une solution multilocataire, il est important de bien comprendre quel locataire effectue chaque requête afin de retourner les données à ce locataire et pas aux autres.

Le service Gestion des API propose des abonnements que vous pouvez utiliser pour authentifier les requêtes. Ces abonnements utilisent une clé d’abonnement unique qui permet d’identifier l’abonné qui effectue la requête. Si vous choisissez d’utiliser des abonnements, réfléchissez à la façon dont vous pouvez mapper les abonnements Gestion des API à vos propres identificateurs de clients ou de locataires. Les abonnements sont étroitement intégrés au portail des développeurs. Pour la plupart des solutions, il est recommandé d’utiliser des abonnements pour identifier les locataires.

Vous pouvez également identifier le locataire à l’aide d’autres méthodes. Les exemples d’approches suivants s’exécutent dans une stratégie personnalisée que vous définissez :

  • Utilisez un composant personnalisé de l’URL, tel qu’un sous-domaine, un chemin d’accès ou une chaîne de requête. Par exemple, dans l’URL https://api.contoso.com/tenant1/products, vous pouvez extraire la première partie du chemin d’accès, tenant1, et la traiter en tant qu’identificateur de locataire. De même, dans l'URL entrante https://tenant1.contoso.com/products, vous pouvez extraire le sous-domaine, tenant1. Pour utiliser cette approche, considérez analyser le chemin d'accès ou la chaîne de requête à partir de la propriété Context.Request.Url.

  • Utilisez un en-tête de requête. Par exemple, vos applications clientes peuvent ajouter un en-tête TenantID personnalisé aux requêtes. Pour utiliser cette approche, envisagez de lire à partir de la collection Context.Request.Headers.

  • Extrayez les revendications d’un jeton web JSON (JWT). Par exemple, vous pouvez avoir une revendication personnalisée tenantId dans un JWT que votre fournisseur d’identité rencontre. Pour utiliser cette approche, utilisez la stratégie validate-jwt et définissez la propriété output-token-variable-name afin que votre définition de stratégie puisse lire les valeurs du jeton.

  • Recherchez des identificateurs de locataire de façon dynamique. Vous pouvez communiquer avec une base de données ou un service externe pendant le traitement de la requête. En adoptant cette approche, vous pouvez créer une logique de mappage de locataire personnalisée pour mapper un identificateur de locataire logique à une URL spécifique ou obtenir plus d’informations sur un locataire. Pour appliquer cette approche, utilisez la stratégie de demande d’envoi .

    Cette méthode est susceptible d’augmenter la latence de vos demandes. Pour éviter ce problème, il est judicieux d’utiliser la mise en cache pour réduire le nombre d’appels à l’API externe. Vous pouvez utiliser les politiques cache-store-value et cache-lookup-value pour implémenter une approche de mise en cache. Veillez à invalider votre cache à chaque ajout, suppression ou déplacement de locataire qui affecte la recherche en arrière-plan.

Valeurs nommées

Gestion des API prend en charge les valeurs nommées, qui sont des paramètres de configuration personnalisés que vous pouvez utiliser dans toutes vos stratégies. Par exemple, vous pouvez utiliser une valeur nommée pour stocker l’URL back-end d’un locataire, puis réutiliser cette même valeur à plusieurs emplacements dans vos stratégies. Si vous devez mettre à jour l’URL, vous pouvez le faire à un seul emplacement.

Avertissement

Dans une solution multilocataire, il est important d’être prudent lorsque vous définissez les noms de vos valeurs nommées. Si les paramètres varient entre les locataires, veillez à inclure l’identificateur du locataire dans le nom. Par exemple, vous pouvez utiliser un modèle tel que tenantId-key:value après avoir confirmé que tenantId est adapté à la requête.

Incluez l’identificateur pour réduire le risque de faire accidentellement référence à un autre locataire ou d’être manipulé à cet effet lorsque vous traitez une requête pour un autre locataire.

Authentifier les requêtes entrantes

Les requêtes d’API adressées à la passerelle Gestion des API doivent généralement être authentifiées. Le service Gestion des API propose plusieurs méthodes d’authentification des requêtes entrantes vers la passerelle, notamment OAuth 2.0 et les certificats clients. Prenez en compte les types d'identifiants que vous devez prendre en charge et où vous devez les valider. Par exemple, déterminez si la validation doit se produire dans Gestion des API, dans vos applications back-end ou dans ces deux emplacements.

Pour plus d’informations, consultez Authentification et autorisation des API dans Gestion des API.

Remarque

Si vous utilisez une clé d’abonnement ou une clé API, il est recommandé d’utiliser également une autre méthode d’authentification.

Une clé d’abonnement seule n’est pas une forme d’authentification forte. Toutefois, il est utile pour d’autres scénarios, tels que le suivi de l’utilisation de l’API d’un locataire individuel.

Acheminer vers des serveurs principaux spécifiques au locataire

Lorsque vous utilisez Gestion des API en tant que composant partagé, vous devrez peut-être acheminer les requêtes d’API entrantes vers différents back-ends propres au locataire. Ces serveurs principaux peuvent se trouver dans différentes empreintes de déploiement, ou il peut s’agir de différentes applications au sein d’une seule empreinte. Pour personnaliser le routage dans une définition de stratégie, utilisez la stratégie set-backend-service. Vous devez spécifier la nouvelle URL de base vers laquelle la requête doit être redirigée.

Mettre en cache des réponses ou d’autres données

Le service Gestion des API dispose d’une fonctionnalité de cache puissante que vous pouvez utiliser pour mettre en cache des réponses HTTP entières ou n’importe quel autre type de données. Par exemple, vous pouvez utiliser le cache pour les mappages de locataires si vous utilisez une logique personnalisée ou si vous recherchez le mappage à partir d’un service externe.

Utilisez les stratégies cache-store-value et cache-lookup-value pour implémenter une approche de mise en cache.

Avertissement

Dans une solution multilocataire, il est important d’être prudent lorsque vous définissez vos clés de cache. Si les données mises en cache peuvent varier entre les locataires, assurez-vous d’inclure l’identificateur du locataire dans la clé de cache.

Incluez l’identificateur pour réduire le risque de faire accidentellement référence à un autre locataire ou d’être manipulé à cet effet lorsque vous traitez une requête pour un autre locataire.

API de modèle de langage volumineux

Utilisez les fonctionnalités de passerelle IA dans Gestion des API lorsque vos API appellent des modèles de langage volumineux. Ces fonctionnalités vous aident à contrôler les coûts, les performances et l’isolation dans les solutions multilocataires.

Mise en cache sémantique

Si vos API se trouvent devant les modèles Azure OpenAI, envisagez d’utiliser la mise en cache sémantique dans Gestion des API pour réduire les coûts et la latence pour les invites répétées ou en double.

Pour plus d’informations, consultez les ressources suivantes :

Vous devez partitionner le cache par locataire à l’aide de l’élément vary-by afin que les invites et les réponses soient isolées du locataire pour lequel ils sont destinés. Placez la stratégie dans le lookup traitement entrant et la stratégie dans le store traitement sortant.

L’exemple suivant montre comment les entrées de cache sémantique sont partitionnées par ID d’abonnement ou clé :

<!-- inbound -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Subscription.Id)</vary-by>
   <!-- or: <vary-by>@(context.Subscription.Key)</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

L’exemple suivant partitionne le cache sémantique par revendication ou en-tête de locataire :

<!-- inbound; requires validate-jwt if using a claim -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Principal?.Claims.GetValueOrDefault("tenantId", ""))</vary-by>
   <!-- Alternative using a custom header: -->
   <!-- <vary-by>@(context.Request.Headers.GetValueOrDefault("TenantID", ""))</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

Limites basées sur des jetons pour les modèles de langage volumineux

Utilisez des limites basées sur des jetons dans la passerelle IA pour limiter l’utilisation de chaque locataire, et non seulement pour les demandes individuelles. Lorsque vous utilisez des back-ends Azure OpenAI, utilisez la stratégie azure-openai-token-limit. Pour les back-ends compatibles OpenAI ou l’API d’inférence de modèle Azure AI, utilisez la stratégie llm-token-limit. Pour plus d’informations, consultez la stratégie de limite de jetons.

Sélectionnez une clé propre au locataire, telle qu’un ID d’abonnement ou une revendication de jeton d’ID de locataire, pour vous assurer que les limites isolent efficacement chaque locataire. L’utilisation des jetons est suivie indépendamment à chaque passerelle, région ou espace de travail, et les compteurs ne sont pas agrégés dans l’ensemble de l’instance.

L’exemple suivant limite chaque locataire à 60 000 jetons par minute par abonnement :

<azure-openai-token-limit
   counter-key="@(context.Subscription.Id)"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

L’exemple suivant limite la revendication ou l’en-tête du locataire :

<!-- Using a tenant claim; requires validate-jwt earlier in the pipeline -->
<azure-openai-token-limit
   counter-key="@(context.Principal?.Claims.GetValueOrDefault(&quot;tenantId&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

<!-- Or using a custom header populated by your edge/CDN/gateway -->
<azure-openai-token-limit
   counter-key="@(context.Request.Headers.GetValueOrDefault(&quot;TenantID&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

Remarque

Vérifiez que la revendication ou l’en-tête est présente et non vide avant d’appliquer des limites pour éviter de réduire involontairement de nombreux locataires sous un seul compteur.

Domaines personnalisés

Utilisez API Management pour configurer vos propres domaines personnalisés pour la passerelle API et le portail des développeurs. Dans certains niveaux, vous pouvez configurer des domaines génériques ou plusieurs noms de domaine complets (FQDN).

Vous pouvez également utiliser la Gestion des APIs en conjonction avec un service tel que Azure Front Door. Dans ce type de configuration, Azure Front Door gère fréquemment les domaines personnalisés et les certificats TLS (Transport Layer Security) et communique avec gestion des API à l’aide d’un nom de domaine unique. Si l’URL d’origine du client inclut des informations de locataire que vous devez envoyer à l’instance Gestion des API pour un traitement ultérieur, envisagez d’utiliser l’en-tête de requête X-Forwarded-Host ou utilisez des règles Azure Front Door pour transmettre les informations en tant qu’en-tête HTTP.

Limites du taux de transfert

Il est courant d’appliquer des quotas ou des limites de débit dans une solution multilocataire. Les limites du taux de transfert peuvent vous aider à atténuer le problème d’interférence causé par les voisins. Vous pouvez également utiliser des limites de débit pour renforcer la qualité du service et pour différencier les multiples niveaux tarifaires.

Utilisez Gestion des API pour appliquer des limites de débit propres à chaque locataire. Si vous utilisez des abonnements spécifiques au locataire, envisagez d’utiliser la stratégie de quota pour appliquer un quota à chaque abonnement. Vous pouvez également utiliser la stratégie de quota par clé pour appliquer des quotas à l’aide de toute autre clé de limite de débit, telle qu’un identificateur de locataire que vous obtenez à partir de l’URL de requête ou d’un JWT.

Pour plus d’informations, consultez Les limites basées sur les jetons pour les modèles de langage volumineux.

Important

L’étendue du compteur diffère de la topologie de stratégie et de déploiement :

  • Les stratégies et rate-limit les rate-limit-by-key stratégies gèrent des compteurs distincts pour chaque réplica de passerelle. Dans les déploiements de passerelle multirégion ou d’espace de travail, chaque passerelle régionale ou d’espace de travail applique son propre compteur.

  • Les azure-openai-token-limit stratégies et llm-token-limit les stratégies effectuent également le suivi des jetons pour chaque passerelle, région ou espace de travail et ne sont pas agrégés sur l’ensemble de l’instance de service.

  • Les quota stratégies sont quota-by-key globales au niveau du service et s’appliquent dans différentes régions pour une instance spécifique.

Si vous avez besoin d’une limitation globale cohérente par locataire, préférez les quotas, appliquez des limites à une périphérie en amont qui voit tout le trafic ou routez un locataire vers une seule passerelle ou région.

Monétisation

La documentation Gestion des API fournit des conseils détaillés sur la monétisation des API, y compris un exemple d’implémentation. Les approches de monétisation combinent de nombreuses fonctionnalités de Gestion des API afin que les développeurs puissent publier une API, gérer des abonnements et facturer les utilisateurs sur la base de différents modèles de tarification.

Gestion de la capacité

Une instance Gestion des API prend en charge une quantité spécifique de capacité, qui représente les ressources disponibles pour traiter vos demandes. Lorsque vous utilisez des stratégies complexes ou déployez plus d’API dans l’instance, vous consommez plus de capacité. Vous pouvez gérer la capacité d’une instance de plusieurs façons, notamment en achetant davantage d’unités. Vous pouvez également mettre à l’échelle la capacité de votre instance de façon dynamique.

Certaines instances multilocataires peuvent consommer plus de capacité que les instances monolocataires, notamment si vous utilisez de nombreuses stratégies pour acheminer les requêtes vers différents back-ends de locataire. Envisagez la planification de la capacité avec soin et prévoyez de mettre à l’échelle la capacité de votre instance si vous voyez votre utilisation augmenter. Vous devez également tester les performances de votre solution pour anticiper vos besoins en capacité.

Pour plus d’informations sur la mise à l’échelle de gestion des API, consultez Mettre à niveau et mettre à l’échelle une instance gestion des API.

Déploiements multirégions

Gestion des API prend en charge les déploiements multirégions, ce qui signifie que vous pouvez déployer une seule ressource Gestion des API logique dans plusieurs régions Azure sans avoir à répliquer sa configuration sur des ressources distinctes. Cette fonctionnalité est particulièrement utile lorsque vous distribuez ou répliquez votre solution à l’échelle mondiale. Vous pouvez déployer efficacement une flotte d’instances Gestion des API dans plusieurs régions, ce qui permet un traitement des requêtes à faible latence et de les gérer comme une seule instance logique.

Important

Le déploiement multirégion est pris en charge uniquement dans le niveau Premium (classique). Il n’est pas disponible dans les niveaux Consommation, Développeur, Basic, Standard, Basic v2, Standard v2 ou Premium v2 (préversion). Si vous êtes sur des niveaux v2 et que vous devez déployer dans plusieurs régions, utilisez une instance distincte pour chaque région et utilisez le routage externe (par exemple, Azure Front Door) ou envisagez des passerelles auto-hébergées.

Toutefois, si vous avez besoin d’instances Gestion des API entièrement isolées, vous pouvez également choisir de déployer des ressources Gestion des API indépendantes dans différentes régions. Cette méthode permet de séparer le plan de gestion de chaque instance Gestion des API.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Principaux auteurs :

  • John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
  • Daniel Scott-Raynsford | Architecte de solution partenaire senior, solutions Enterprise Partner

Autre contributeur :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

  • Last updated on