Partager via

Utiliser Gestion des API Azure dans une solution multilocataire

  • Article

Gestion des API Azure est une passerelle API complète et un proxy inverse pour les API. Ce service offre de nombreuses fonctionnalités, notamment la mise en cache, la simulation de réponses et un portail des développeurs, particulièrement utiles pour les applications axées sur les API. 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 de multilocation. Envisagez d’utiliser des espaces de travail, qui vous permettent de partager une instance Gestion des API entre plusieurs équipes disposant de niveaux d’accès différents.

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 vous utilisez Gestion des API varie peu, quel que soit le modèle 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 des back-ends monolocataires Instance partagée avec un back-end multilocataire partagé Instance pour chaque locataire
Nombre de locataires pris en charge Divers Pratiquement illimité Un pour chaque instance.
Cost Faible Faible Plus grand
Complexité du déploiement Faible : une seule instance à gérer pour chaque empreinte Faible : une seule instance à gérer pour chaque empreinte Élevée : plusieurs instances à gérer
Complexité de la configuration d’acheminement Élevée Faible Faible
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 volumineuse avec une couche Application partagée Empreintes de déploiement propres 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 back-end 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 Gestion des API avec les noms d’hôte back-end pour chaque locataire ou d’avoir un autre moyen de mapper 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 back-end du locataire. Toutefois, l’ampleur de cette surcharge de performances dépend de la façon dont vous concevez une telle recherche.

Application back-end 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 obtenir une mise à l’échelle pratiquement illimitée avec cette méthode. 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 cas, vous pouvez déployer une instance Gestion des API pour chaque locataire. Nous vous recommandons cette méthode uniquement si vous avez un petit nombre de locataires ou si vous avez des exigences de conformité strictes qui vous empêchent de partager une infrastructure entre plusieurs 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 Gestion des API, vous devez prendre en compte les limites du service, y compris les limites qui peuvent concerner le nombre d’instances Gestion des API au sein d’un abonnement Azure ou d’une région.

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 propres au locataire que vous déployez déjà.

Fonctionnalités de Gestion des API prenant en charge l’architecture multilocataire

Le service Gestion des API utilise des stratégies pour permettre une certaine 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. Voici quelques exemples de méthodes qui 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 considérer en tant qu’identificateur du locataire. De même, dans l’URL entrante https://tenant1.contoso.com/products, vous pouvez extraire le sous-domaine, tenant1. Pour utiliser cette méthode, envisagez d’analyser le chemin d’accès ou la chaîne de requête à l’aide 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 méthode, il suffit de lire 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 jeton JWT émis par votre fournisseur d’identité. Pour utiliser cette méthode, 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 méthode, vous pouvez créer une logique de mappage de locataire personnalisé pour mapper un identificateur de locataire logique à une URL spécifique ou pour obtenir des informations supplémentaires sur un locataire. Pour utiliser cette méthode, utilisez la stratégie send-request.

    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 stratégies 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 ayant un impact sur la recherche back-end.

Valeurs nommées

Le service 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 vérifié que tenantId est adapté à la requête.

En incluant l’identificateur, vous réduisez le risque de faire référence par inadvertance à la valeur d’un autre locataire ou d’être manipulé pour faire référence à la valeur d’un autre locataire 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. Tenez compte des types d’informations d’identification que vous devez prendre en charge et d’où elles doivent être validées. 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 l’article Authentification et autorisation des API dans le service Gestion des API Azure.

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 ne constitue pas à elle seule une forme d’authentification forte, mais elle est utile pour d’autres scénarios, tels que le suivi de l’utilisation des API par un locataire.

Acheminer des requêtes vers des back-ends propres 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 back-ends peuvent se trouver dans différentes empreintes de déploiement, ou bien dans des applications différentes au sein d’une même empreinte. Pour personnaliser le routage d’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.

En incluant l’identificateur, vous réduisez le risque de faire référence par inadvertance à la valeur d’un autre locataire ou d’être manipulé pour faire référence à la valeur d’un autre locataire lorsque vous traitez une requête pour un autre locataire.

Domaines personnalisés

Utilisez Gestion des API 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 Gestion des API avec un service comme 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 en utilisant un seul nom de domaine. Si l’URL d’origine du client inclut des informations sur le 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 les 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 de débit peuvent vous aider à atténuer le problème de voisin bruyant. 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 propres à chaque locataire, envisagez d’utiliser la stratégie quota pour appliquer un quota à chaque abonnement. Vous pouvez également utiliser la stratégie quota-by-key pour appliquer des quotas à l’aide de toute autre clé de limite de débit, telle qu’un identificateur de locataire que vous avez obtenu à partir de l’URL de requête, ou un jeton JWT.

Monétisation

La documentation Gestion des API fournit des conseils détaillés sur la monétisation des API, notamment 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 certaine capacité, qui correspond aux ressources disponibles pour traiter vos requêtes. 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. Réfléchissez attentivement à la planification de la capacité et prévoyez de mettre à l’échelle la capacité de votre instance si vous constatez une augmentation de votre utilisation. 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 une instance du service Gestion des API Azure et la mettre à l’échelle.

Déploiements multirégions

Le service Gestion des API prend en charge les déploiements multirégions, ce qui signifie que vous pouvez déployer une seule ressource de 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.

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

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Principaux auteurs :

Autre contributeur :

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

Étapes suivantes

Consultez les approches architecturales pour l’intégration dans les solutions multilocataires.