Partager via

Meilleures pratiques en matière d’architecture pour Gestion des API Azure

Gestion des API Azure est une plateforme de gestion et une passerelle pour les API dans tous les environnements, notamment hybrides et multiclouds. En tant que solution PaaS (Platform as a Service), Gestion des API permet de prendre en charge le cycle de vie de l’API de votre charge de travail.

Cet article part du principe que, en tant qu’architecte, vous avez examiné l’arbre de décision integration services et choisi gestion des API comme service d’intégration pour votre charge de travail. Les conseils fournis dans cet article proposent des recommandations architecturales alignées sur les principes des piliers du Framework Well-Architected.

Important

Comment utiliser ce guide

Chaque section dispose d’une liste de contrôle de conception qui présente des domaines d’intérêt architecturaux, ainsi que des stratégies de conception localisées dans l’étendue technologique.

Sont également incluses les recommandations relatives aux fonctionnalités technologiques qui peuvent aider à matérialiser ces stratégies. Les recommandations ne représentent pas une liste exhaustive de toutes les configurations disponibles pour gestion des API ou les serveurs d’API principaux de votre charge de travail. Il s’agit plutôt de recommandations clés associées aux perspectives de conception. Utilisez les recommandations pour créer votre preuve de concept ou pour optimiser vos environnements existants.

Architecture fondamentale qui illustre les recommandations clés : architecture de zone d’atterrissage gestion des API.

La portée de la technologie

Cette révision se concentre sur les décisions liées à la ressource Azure suivante :

  • Gestion des API Azure

L’étendue de ce guide est le service Gestion des API, principalement le composant de passerelle (plan de données), qui proxies les demandes d’API des applications clientes vers les API principales hébergées sur différentes plateformes ou emplacements intersite. L’architecture de la charge de travail doit tenir compte du plan de contrôle Gestion des API et des composants associés, tels que les applications clientes qui accèdent à la passerelle et les API principales qui traitent les demandes routées. Il intègre également la prise en charge des services Azure, notamment la mise en réseau, la surveillance, la gestion des identités et d’autres fonctionnalités.

Ce guide ne couvre pas le Centre des API Azure. Il traite des rubriques au niveau de l’API, car elles sont liées à Gestion des API au lieu de fournir une perspective bien conçue sur les considérations relatives à la conception des API.

Remarque

Toutes les recommandations ne s’appliquent pas à tous les niveaux de service de gestion des API. De nombreuses recommandations de ce guide se concentrent sur les niveaux Standard v2 et Premium classique de Gestion des API, qui sont les niveaux de production recommandés pour la plupart des charges de travail d’entreprise.

Important

Le niveau Premium v2 avec les fonctionnalités d’entreprise est en préversion. Pour déterminer si votre conception doit s’appuyer sur des fonctionnalités d’accès anticipé ou des fonctionnalités en disponibilité générale, évaluez vos chronologies de conception et d’implémentation par rapport aux informations disponibles sur les chemins de migration et de mise en production de Premium v2.

Fiabilité

L'objectif du pilier Fiabilité est de fournir une fonctionnalité continue en construisant suffisamment de résilience et la capacité de récupérer rapidement en cas de défaillance.

principes de conception de fiabilité fournir une stratégie de conception de haut niveau appliquée pour les composants individuels, les flux système et le système dans son ensemble.

Liste de contrôle de conception

Commencez votre stratégie de conception basée sur la checklist de revue de conception pour la fiabilité. Déterminez sa pertinence pour vos besoins métier tout en gardant à l’esprit les niveaux et fonctionnalités de Gestion des API et ses dépendances. Étendez la stratégie pour inclure davantage d’approches en fonction des besoins.

  • Évaluez les fonctionnalités de passerelle pour la fiabilité et la redondance : Déterminez le niveau gestion des API et les fonctionnalités nécessaires pour répondre aux exigences de fiabilité de la charge de travail pour chaque environnement.

    Évaluez les fonctionnalités de redondance de passerelle, notamment les zones de disponibilité, plusieurs unités de passerelle, plusieurs régions et espaces de travail. Ces fonctionnalités sont toutes prises en charge dans le niveau Premium. Le niveau Développeur, qui n’inclut pas de contrat de niveau de service (SLA), n’est pas adapté aux charges de travail de production. Tenez compte des compromis liés à l’adoption de fonctionnalités telles que la mise en cache externe qui peuvent introduire des points de défaillance potentiels et des goulots d’étranglement des performances.

  • Passez en revue les fonctionnalités d’observabilité : Tenez compte des fonctionnalités d’observabilité du service, notamment les journaux et métriques Azure Monitor, Application Insights, les analyses intégrées et les diagnostics intégrés. Utilisez ces fonctionnalités pour surveiller les signaux de fiabilité de votre charge de travail.

    Par exemple, envisagez d’utiliser des alertes Azure Monitor pour vous informer des problèmes potentiels liés à la passerelle Gestion des API ou à ses dépendances.

  • Passez en revue les stratégies de mise à l’échelle : Définissez des critères pour effectuer un scale-out de la passerelle en ajoutant des unités pour maintenir la fiabilité du service. Déterminez s’il faut effectuer une mise à l’échelle en fonction des demandes, des exceptions ou des deux. Évaluez l’impact de la mise à l’échelle du composant de passerelle sur d’autres composants de la charge de travail. Par exemple, son effet sur l’espace d’adressage réseau et les fonctionnalités de mise à l’échelle des back-ends.

  • Isoler les charges de travail critiques : Déterminez si l’isolation de calcul est nécessaire pour répondre aux exigences de charge de travail, telles que la souveraineté des données ou l’optimisation des performances, dans vos API. Utilisez des passerelles dédiées pour les API critiques et les passerelles partagées pour les API moins critiques.

    Choisissez une approche d’isolation, comme l’utilisation d’une passerelle d’espace de travail dédiée ou d’une instance de gestion des API distincte. Pour plusieurs instances, gardez les environnements synchronisés dans le cadre de vos pratiques de déploiement sécurisées.

  • Alignement de l’objectif de niveau de service (SLO) : Prenez en compte l’étendue du SLA de la passerelle lorsque vous définissez les SLO de votre charge de travail. Le service fournit son propre contrat SLA, mais vous devez également tenir compte de la fiabilité prévue d’autres composants de charge de travail, tels que les back-ends de l’API.

  • Résoudre les erreurs principales : Planifiez les erreurs principales attendues et inattendues. Testez les expériences clientes dans ces scénarios. Évaluez les stratégies de passerelle pour améliorer la résilience et améliorer l’expérience client. Concentrez-vous sur les quotas, les limites de débit, les stratégies de nouvelle tentative, les disjoncteurs back-end, l’équilibrage de charge et la gestion des exceptions comme documentés dans vos spécifications d’API.

  • Définir des stratégies de test : Utilisez une solution de test telle qu’Azure Load Testing à partir de votre réseau pour refléter les charges de travail de production réelles. Ne vous fiez pas au débit publié ou à d’autres estimations qui peuvent ne pas s’appliquer à votre charge de travail.

  • Plan de reprise après sinistre (DR) : Examinez les options de sauvegarde et de restauration de l'infrastructure de la passerelle et des API. Les fonctionnalités de sauvegarde et de restauration intégrées peuvent être utiles dans certains scénarios. Toutefois, les options gérées par le client, telles que les outils APIOps et l’infrastructure en tant que solutions de code (IaC) peuvent également être prises en compte. Développez des stratégies pour gérer d’autres données système, y compris les abonnements utilisateur.

Recommandations

Ces recommandations de fiabilité peuvent s’appliquer au service lui-même ou au trafic qui transite par les API et leurs stratégies. Les indicateurs (Service) ou API indiquent si une recommandation cible le service ou les API.

Recommandation Avantage
(Service) Activez la redondance de zone dans le niveau Premium et disposez d’un minimum de trois unités déployées.

Dans cette configuration, dans des conditions de fonctionnement normales, toutes les unités d’échelle de toutes les zones configurées sont actives et servent le trafic de passerelle.

Dans un scénario actif-actif, prévoyez de prendre en charge l'extension de capacité dans les zones actives restantes pour gérer le trafic que les unités avaient antérieurement traité dans la zone défaillante.		 La résilience est assurée pendant une panne de centre de données au sein d’une région. Pendant une perte complète du centre de données, le trafic d’API continue de transiter par les unités restantes déployées dans d’autres zones.
(Service) Activez le scale-out automatique en fonction des demandes de trafic.

Dans les déploiements multirégions, les régions secondaires ne disposent pas de fonctionnalités automatiques de scale-out ou de scale-in. Vous devez implémenter une fonction personnalisée ou une application logique qui s’active en réponse aux alertes de métrique Azure Monitor pour gérer les ajustements unitaires en fonction de la demande.		 Des ressources suffisantes sont garanties pour répondre à la demande des clients d’API, ce qui empêche les défaillances en raison d’une capacité insuffisante.
(Service) Utilisez une topologie multirégion pour prendre en charge la résilience contre une défaillance régionale complète.

Cette approche vous oblige à vous coordonner avec d’autres composants de votre charge de travail et à comprendre leurs caractéristiques de basculement planifiées. Dans tous les scénarios actif-actif, envisagez de prendre en charge le scale-out dans les régions actives restantes pour gérer le trafic que la région désormais inactive a traité au départ.

Assurez-vous que votre topologie multirégion s’aligne sur toutes les exigences de conformité pour les données en transit ou les données en résidence du cache.		 Une résilience robuste est fournie lors d’une panne régionale complète, ce qui permet de garantir un trafic d’API ininterrompu par le biais d’unités déployées dans d’autres régions.
(Service) Isoler les API non liées avec des espaces de travail ou des instances de gestion des API supplémentaires. L’impact des défaillances causées par une mauvaise configuration ou des pannes est réduit en séparant les API entre différentes instances de calcul.
(API) Testez soigneusement les expressions de stratégie et la logique et associez-les à des techniques de gestion des erreurs résilientes dans les stratégies de gestion des API. L'expérience client est améliorée en empêchant les nouvelles sources de défaillances à la passerelle et en fournissant une dégradation maîtrisée ou une gestion sécurisée des pannes transitoires.
(Service &API) Collecter les métriques de fiabilité.

Les métriques de fiabilité d’API classiques sont les suivantes :

- Limites de taux et violations des quotas.
- Taux d’erreur basé sur les codes d’état HTTP.
- Écarts de taux de requête par rapport à la ligne de base.
- Contrôles d’intégrité, y compris l’intégrité des dépendances.		 Les écarts du comportement attendu et des lignes de base passées sont identifiés. Ces données peuvent être utilisées pour tracer les causes racines, telles que le comportement de l’utilisateur modifié, les interférences des opérations de routine, les impacts inattendus des nouvelles fonctionnalités ou les erreurs non planifiées dans la charge de travail.
(Service et API) Utilisez les fonctionnalités intégrées de sauvegarde et de restauration de la Gestion des API dans le cadre de votre playbook de récupération d’urgence. Compléter ces fonctionnalités avec vos artefacts IaC et vos processus APIOps pour une solution robuste qui peut gérer différents scénarios, notamment la coordination de la récupération avec les dépendances et les back-ends. La continuité de l’activité est assurée en autorisant la récupération de la passerelle d’API et la restauration des API définies après une perte complète du système.

Sécurité

L'objectif du pilier Sécurité est de fournir des garanties de confidentialité, d'intégrité et de disponibilité à la charge de travail.

Les principes de conception de sécurité fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs en appliquant des approches à la conception technique pour protéger la passerelle Gestion des API.

Remarque

La liste de contrôle et les recommandations de cette section se concentrent sur la sécurisation de la ressource de passerelle Gestion des API. La sécurisation des API elles-mêmes n’est traitée que brièvement. Pour plus d’informations, consultez Atténuer la sécurité des API OWASP top 10 dans Gestion des API.

Liste de contrôle de conception

Démarrez votre stratégie de conception à partir de la checklist de révision de conception pour la sécurité, et identifiez les vulnérabilités ainsi que les mesures de contrôle pour améliorer la posture de sécurité. Étendez la stratégie pour inclure davantage d’approches en fonction des besoins.

  • Établissez une base de référence de sécurité : Passez en revue la base de référence de sécurité pour Gestion des API et incorporez les mesures applicables dans votre base de référence.

  • Protégez le pipeline de déploiement : Identifiez les individus et les rôles de contrôle d’accès en fonction du rôle requis pour gérer la plateforme de services, l’intégration continue et les pipelines de déploiement continu (CI/CD) et les API individuelles. Assurez-vous que seules les personnes autorisées ont accès à la gestion du service et de ses API.

  • Évaluez la sensibilité des données : Si des données sensibles transitent par des requêtes et des réponses d’API dans la passerelle Gestion des API, assurez-vous de sa protection tout au long de son cycle de vie. Comptez des exigences de protection des données variables dans différentes régions. Évaluez les fonctionnalités de service telles que plusieurs régions pour isoler des données spécifiques. Vérifiez également si votre stratégie de mise en cache s’aligne sur ces exigences d’isolation.

  • Développez des stratégies de segmentation sur des passerelles partagées : Si votre instance Gestion des API héberge des API pour plusieurs équipes de charge de travail, utilisez des espaces de travail pour séparer les rôles, les réseaux et éventuellement les passerelles. Cette approche garantit que chaque équipe dispose d’un accès et d’un contrôle appropriés sur les API qu’elle gère tout en limitant l’accès aux API d’autres équipes.

  • Considérez les contrôles réseau : Identifiez les exigences et les options permettant d’isoler ou de filtrer le trafic de passerelle entrante et sortante à l’aide de réseaux virtuels. Déterminez si l’accès à la passerelle peut être restreint via Azure Private Link ou si l’accès public à la passerelle est nécessaire. Déterminez si l’architecture doit inclure un pare-feu d’applications web, tel qu’Azure Web Application Firewall dans Azure Application Gateway ou Azure Front Door, pour obtenir l’isolation réseau requise et filtrer le trafic réseau.

  • Prenez en compte les fonctionnalités d’authentification et d’autorisation de l’API : Évaluez l’utilisation de fournisseurs d’identité tels que l’ID Microsoft Entra, qui inclut des groupes intégrés ou l’ID externe Microsoft Entra pour écranr les demandes de passerelle et activer l’autorisation OAuth pour les API principales.

  • Chiffrer le trafic réseau : Identifiez les versions de protocole TLS (Transport Layer Security) les plus sécurisées et les chiffrements que vos charges de travail peuvent prendre en charge. Ne nécessite pas de versions TLS non sécurisées. Utilisez TLS 1.3 quand il est pris en charge par vos clients.

  • Effectuez une modélisation des menaces sur Gestion des API et réduisez sa surface d’exposition : Déterminez si des composants de gestion des API spécifiques, tels que l’API de gestion directe ou l’accès public au portail des développeurs, peuvent être désactivés, restreints ou supprimés.

  • Identifiez les secrets requis par les charges de travail : L’opération de passerelle peut nécessiter des certificats, des clés API ou d’autres valeurs secrètes. Passez en revue les exigences et les fonctionnalités d’Azure Key Vault pour stocker des secrets et des certificats. Vous pouvez également consulter les fonctionnalités intégrées de gestion des API, telles que les valeurs nommées et les certificats managés.

Recommandations

Ces recommandations de sécurité peuvent s’appliquer au service lui-même ou au trafic qui transite par les API et leurs stratégies. Les indicateurs (Service) ou API indiquent si une recommandation cible le service ou les API.

Recommandation Avantage
(Service) Désactivez l’API de gestion directe, qui est déconseillée. Utilisez Azure Resource Manager comme plan de contrôle. La surface du service est réduite en supprimant un point d’accès au plan de contrôle.
(Service) Limitez l’exposition de la passerelle en fonction exclusivement de l’endroit où les clients légitimes se connectent.

- Utilisez l’injection de réseau virtuel sans adresse IP publique lorsque tous les clients peuvent router le trafic via un réseau virtuel. Utilisez un groupe de sécurité réseau (NSG) pour restreindre davantage le trafic aux adresses IP d’origine du client attendues.

- Utilisez l’intégration de réseau virtuel à Application Gateway ou Azure Front Door si un trafic doit provenir d’Internet. Configurez le groupe de sécurité réseau pour accepter uniquement le trafic à partir du point d’entrée unique.		 La confidentialité du trafic réseau est protégée en limitant l’exposition aux plages d’adresses IP sources censées contenir des clients légitimes. Ces restrictions bloquent l’accès à partir de sources qui ne doivent pas initier de communication client légitime. Limiter l’exposition aux sources de trafic légitimes améliore la confidentialité, l’intégrité et la disponibilité du service.
(Service) Désactivez le portail des développeurs s’il n’est pas utilisé. Si le portail est en cours d’utilisation, désactivez l’expérience d’inscription, désactivez l’accès anonyme et limitez l’accès aux emplacements réseau approuvés uniquement. La surface du service et la possibilité de mauvaise configuration ou de négligence sont réduites.
(Service) Définissez explicitement les versions, protocoles et chiffrements TLS les plus étroits pris en charge pour vos clients et vos back-ends. Les versions et les chiffrements pris en charge sont réduits uniquement aux options prises en charge par les clients et les back-ends. Cette approche permet de s’assurer que les connexions hiérarchisent les connexions de niveau supérieur possibles pour la confidentialité.
(Service) Stockez des certificats personnalisés dans Key Vault. La fonctionnalité de gestion des certificats est fournie en utilisant Key Vault, qui prend en charge la rotation de routines et vérifie l’accès aux certificats.
(Service) Les back-ends doivent accepter uniquement le trafic des passerelles API et bloquer tout autre trafic. Le trafic malveillant ne peut pas contourner les problèmes de sécurité et autres problèmes transversaux déchargés sur la passerelle.
(Service) Pour les instances gestion des API qui hébergent des API pour plusieurs équipes ou charges de travail segmentées, vous devez concevoir une stratégie d’isolation de contrôle d’accès robuste. Utilisez des espaces de travail ou implémentez un processus APIOps rigoureux pour atteindre cette stratégie.

Teams ne doit avoir accès qu’aux API qu’ils possèdent. Ils ne doivent pas avoir accès à d’autres API qui peuvent être hébergées dans la même instance.		 Le déplacement latéral par les attaquants d’une API compromise définie dans d’autres API non liées est réduit.
(API) Stockez les secrets dans Key Vault et exposez-les à des stratégies par le biais de valeurs nommées. N’utilisez pas Key Vault pour stocker des non-secrets. Utilisez des propriétés de valeur nommées directement pour ces valeurs. La rotation des secrets est encouragée au travers d’un plan de gestion unique dans Key Vault, similaire à l’approche utilisée pour les certificats. Ce processus garantit que la gestion des API est mise à jour en conséquence. Les valeurs nommées garantissent également une expérience cohérente de configuration de stratégies pour les secrets et les non-secrets. Tous les accès secrets sont également audités dans Key Vault pour fournir un historique d’accès. Le stockage des secrets uniquement dans Key Vault réduit la dépendance vis-à-vis de Key Vault et ne transforme pas Key Vault en service de configuration d’application.
(API) Utilisez différentes identités managées affectées par l’utilisateur pour différentes API à l’aide de la stratégie d’identité managée par l’authentification . Chaque API est activée pour avoir une identité indépendante, qui prend en charge les objectifs de segmentation par le biais d’un accès au privilège minimum pour chaque API. Il offre également une meilleure auditabilité dans les systèmes back-end.
(API) Si possible, demandez aux clients de s’authentifier auprès des flux OAuth 2.0 au lieu d’utiliser uniquement des clés prépartagées, y compris des clés d’abonnement ou des certificats clients. L’identification des clients à des fins d’audit est améliorée, la rotation des clés est éliminée et la charge des clients pour protéger les secrets est réduite par rapport à l’utilisation de clés prépartage.
(API) Supprimez les en-têtes HTTP des réponses d’API à l’aide de la stratégie set-header qui peut exposer les détails de l’implémentation. Le coût pour les attaquants augmente avec la conservation des informations d’implémentation.
(API) N’utilisez pas le suivi d’API en production. Les données sensibles ne peuvent pas être exposées dans les traces de requête.
(API) Utilisez Defender pour les API. Des insights, des recommandations et une détection des menaces sont fournis pour la sécurité des API.
(API) Protégez les ressources principales en déléguant les vérifications de sécurité de clé dans la stratégie d’API, telles que validate-jwt, ip-filter, validate-headers, validate-content. La quantité de trafic nonlegitimate qui atteint les services principaux est réduite en effectuant des vérifications de sécurité sur la passerelle. Cette approche de déchargement permet de protéger l’intégrité et la disponibilité de ces ressources.
(API) Appliquez des pratiques de cycle de vie de développement de sécurité (SDL) aux modifications de stratégie d’API de la même façon que vous appliquez des modifications proposées au code d’application dans votre charge de travail. Les stratégies s’exécutent avec une vue hautement privilégiée du trafic d’API. Le contournement des protections principales pour la confidentialité, l’intégrité et la disponibilité par une passerelle d’API compromise est empêché.
(Service &API) Utilisez des identités managées pour les dépendances de service et d’API. Les connexions à Key Vault, Azure Event Hubs et d’autres dépendances, telles que les certificats et les valeurs nommées, sont établies sans compter sur des secrets prépartagés.
(Service & API) Connectez-vous aux dépendances telles que Key Vault, Event Hubs et back-ends via des connexions réseau privées lorsque cela est possible. La confidentialité du trafic est protégée en n’exposant pas le trafic au-delà du réseau privé.
(Service &API) Le trafic client qui cible les API exposées sur Internet doit d’abord passer par un pare-feu d’applications web, tel que le pare-feu d’applications web, avant d’atteindre la gestion des API. De plus, protégez les points de terminaison publics à l’aide d’Azure DDoS Protection. La quantité de trafic nonlegitimate qui atteint la passerelle et les services principaux est réduite en effectuant des vérifications de sécurité avec un pare-feu d’applications web. La réduction de ce trafic permet de protéger l’intégrité et la disponibilité de ces ressources.
(Service &API) Évaluez et activez tous les contrôles de conformité réglementaire Azure Policy pertinents pour votre charge de travail. L’instance Gestion des API s’aligne sur la posture souhaitée et reste alignée à mesure que la charge de travail évolue en ayant des stratégies de sécurité en place.

Optimisation des coûts

L’optimisation des coûts se concentre sur la détection des modèles de dépense, la hiérarchisation des investissements dans les domaines critiques et l’optimisation dans d’autres pour répondre au budget de l’organisation tout en répondant aux besoins de l’entreprise.

Les principes de conception de l’optimisation des coûts fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs et faire des compromis si nécessaire dans la conception technique liée à la gestion des API et à son environnement.

Liste de contrôle de conception

  • Considérez le modèle de coût gestion des API : Utilisez la calculatrice de prix Azure avec les avantages et critères du compte de votre organisation pour le contrat SLA et l’extensibilité afin de développer des estimations de coûts précises d’utilisation d’un niveau de service Gestion des API. Déterminez si un modèle de rétrofacturation est nécessaire et la façon de le calculer en fonction des métriques, balises et jetons.

    Le modèle de coût de service est principalement influencé par le niveau de service, le nombre d’unités et le nombre de passerelles. Évaluez les coûts supplémentaires associés à la maintenance d’une unité de réserve ou à l’implémentation d’une configuration de récupération d’urgence active-passive.

    Si vous implémentez des espaces de travail, évaluez les coûts liés à l’utilisation de passerelles d’espace de travail distinctes par rapport aux passerelles d’espace de travail partagées pour répondre aux exigences de flux d’API distinctes des différentes équipes ou parties prenantes de l’API.

  • Estimer les coûts de mise à l’échelle : Développez des critères de mise à l’échelle pour maintenir une utilisation élevée des ressources de passerelle. Évaluez les coûts de base dans un environnement de préproduction et effectuez des tests pour modéliser les coûts de scale-out en fonction du trafic de charge de travail prévu.

    Concevez une stratégie d’atténuation pour empêcher l’utilisation abusive de vos passerelles, ce qui peut entraîner une mise à l’échelle coûteuse au-delà de l’utilisation prédicée.

  • Évaluez les configurations et stratégies de service : Les fonctionnalités telles que la limite de débit et la concurrence limite peuvent être utilisées comme techniques d’optimisation des coûts pour gérer les chargements de demandes.

  • Optimiser le positionnement de la logique : Déterminez si les serveurs principaux sont plus rentables pour la logique de traitement ou si la passerelle doit gérer l’utilisation des ressources. La passerelle est un composant fort pour l’implémentation de préoccupations croisées, mais elle peut exécuter des fonctions excessives dans certains scénarios. Identifiez les tâches de traitement des demandes lourdes de ressources effectuées par la passerelle et déterminez si le déplacement de cette logique vers des serveurs principaux peut réduire les coûts.

Recommandations

Ces recommandations d’optimisation des coûts peuvent s’appliquer au service lui-même ou au trafic qui transite par les API et leurs stratégies. Les indicateurs (Service) ou API indiquent si une recommandation cible le service ou les API.

Recommandation Avantage
(Service) Utilisez le niveau le moins coûteux qui prend en charge les exigences de votre charge de travail. Par exemple, choisissez un niveau Standard au lieu d’un niveau Premium si votre charge de travail ne bénéficie pas des fonctionnalités ajoutées d’une manière qui justifie le retour sur investissement (ROI). L’achat de fonctionnalités inutilisées ou sous-utilisées est évité.
(Service) Utilisez des niveaux de non-production ou une infrastructure temporaire dans des environnements inférieurs, tels que des environnements de développement, des déploiements de preuve de concept et des activités de modélisation des coûts initiales. Les coûts de ressources sont économisés pour les environnements qui peuvent rester utiles sans répliquer entièrement la configuration exacte ou les exigences de disponibilité de la production.
(Service) Effectuez un scale-in lorsque la demande diminue. Configurez des règles de mise à l’échelle automatique ou d’autres processus automatisés pour réduire les unités lorsque la capacité de passerelle tombe en dessous des seuils définis. Les coûts inutiles sont réduits en alignant la capacité sur la demande.
(Service) Calculez les avantages des coûts d’un modèle fédéré pour la gestion des API à l’aide d’espaces de travail pour servir les API tout en fournissant également une isolation d’équipe. La surface de déploiement et de gestion est réduite. Cette approche vise à réaliser des économies d’échelle à partir du temps et des achats de ressources.
(Service) Désactive les espaces de travail lorsqu’ils ne sont plus utilisés. Les dépenses sur les ressources inutilisées sont évitées.
(Service) Utilisez le cache intégré si les données mises en cache de votre charge de travail correspondent aux contraintes du cache intégré dans votre niveau. Les coûts liés à l’achat et à la maintenance d’un cache compatible Redis externe sont évités.
(Service) Bloquer le trafic malveillant avant d’atteindre la passerelle à l’aide de contrôles réseau, de protection DDoS et de pare-feu d’applications web. Des niveaux spécifiques de gestion des API entraînent des frais en fonction du nombre d’opérations de requête HTTP traitées par la passerelle. Par conséquent, le trafic indésirable, tel que les demandes générées par un bot, peut augmenter les coûts.

Évaluez le coût du mécanisme de blocage par rapport au coût estimé de la réduction de l’opération HTTP pour déterminer si cette approche a un retour sur investissement.		 Les frais encourus en raison d’opérations HTTP excessives malveillantes ou gênantes sur la passerelle sont réduits.
(API) Optimisez les expressions de stratégie et le traitement et le code pour éviter une utilisation excessive des ressources de calcul, telles que le processeur, la mise en réseau ou la mémoire. Le déploiement inutile d'unités supplémentaires pour accroître la capacité des stratégies et du code non optimisés est évité.
(API) Évaluez le coût du placement logique entre votre passerelle, votre back-end ou votre point d’entrée public, tel qu’Azure Front Door. Le même traitement peut souvent se produire à l’une de ces couches, chacun avec ses propres compromis. Toutefois, certaines couches peuvent offrir des économies en raison de la capacité inutilisée disponible à ce niveau. Par exemple, la logique de mise en cache initialement implémentée dans le serveur principal peut être plus rentable au niveau de la passerelle à l’aide du cache intégré. Cette approche réduit la surcharge de réseau et de calcul supplémentaires sur les services principaux. La charge sur les ressources à coût élevé est réduite en plaçant les fonctionnalités dans la couche la plus rentable. Cette approche déplace les charges de travail vers des couches qui ont une capacité de rechange ou des options de calcul à moindre coût.

Excellence opérationnelle

L’excellence opérationnelle se concentre principalement sur les procédures liées aux pratiques de développement , à l’observabilité et à la gestion des mises en production.

Les principes de conception d’excellence opérationnelle fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs pour les besoins opérationnels de la charge de travail.

Démarrez votre stratégie de conception en fonction de la liste de contrôle de révision de conception pour l’excellence opérationnelle pour définir des processus d’observabilité, de test et de déploiement liés à gestion des API.

Liste de contrôle de conception

  • Passez en revue les connaissances et compétences clés nécessaires pour exploiter le service : Les domaines incluent le cycle de vie des API, les processus DevOps, la mise en réseau et la connectivité, la surveillance et l’observabilité, ainsi que le développement logiciel. Cette approche englobe la configuration de stratégie, les tests unitaires et la création de pipelines CI/CD.

  • Tenez compte des besoins de documentation : Les organisations doivent s’engager à documenter les processus pour la configuration au niveau du service et au niveau de l’API, les opérations de cycle de vie et les différents modèles d’accès pour les équipes d’API.

  • Évaluez les outils standard pour prendre en charge les opérations de service. Par exemple, adoptez des méthodes APIOps , telles que GitOps et CI/CD, pour publier des API et gérer des configurations d’API. Utilisez les outils IaC pour les modifications de configuration au niveau du service. Concevez des artefacts réutilisables qui peuvent passer en toute transparence des environnements de développement à la production. Envisagez l’intégration d’un linter tel que Specter, auto-géré ou intégré à un service Azure tel qu’Azure API Center, dans des pipelines d’approbation d’API.

  • Déterminez les métriques et journaux opérationnels clés : Passez en revue les métriques de production. Ces métriques incluent la capacité de passerelle, l’utilisation du processeur, l’utilisation de la mémoire et le nombre de requêtes. Passez en revue les journaux et les outils d’observabilité tels qu’Azure Monitor et Application Insights. Déterminez les stratégies et les outils nécessaires pour gérer efficacement de grands volumes de données d’observation dans les environnements de production. Déterminez les requêtes qui fournissent des insights actionnables pour l’opérateur de passerelle et les parties prenantes qui surveillent des API hébergées spécifiques.

  • Planifiez des tests réguliers des charges de travail de production à l’aide de tests de charge.

  • Identifiez les tâches opérationnelles au-delà des processus CI/CD ou IaC qui nécessitent une automatisation. Planifiez l’automatisation dans des domaines tels que la gestion des sources de stratégie gestion des API, les stratégies Azure et des configurations spécifiques du portail des développeurs.

Recommandations

Ces recommandations d’excellence opérationnelle peuvent s’appliquer au service lui-même ou au trafic qui transite par les API et leurs stratégies. Les indicateurs (Service) ou API indiquent si une recommandation cible le service ou les API.

Recommandation Avantage
(Service) Configurez les journaux de diagnostic des ressources Azure pour le service de gestion des API. Les journaux générés par la plateforme sont disponibles pour rechercher des opérations de routine, des besoins à la demande ou des scénarios urgents, tels que des audits de sécurité.
(Service) Utilisez Azure Event Grid pour l’automatisation en fonction des événements significatifs que votre instance Gestion des API déclenche, tels que APICreated. Les tâches d’automatisation ou de notification peuvent être générées autour des événements de cycle de vie clés qui se produisent dans l’instance Gestion des API.
(Service) Évitez d’utiliser une passerelle auto-hébergée si une unité de passerelle hébergée par Microsoft fonctionne dans votre scénario. Les tâches d’automatisation ou de notification peuvent être générées autour des événements de cycle de vie clés qui se produisent dans l’instance Gestion des API.
(Service) Appliquez toutes les stratégies Azure Policy intégrées qui vous aident à régir votre instance et à la limiter pour s’aligner sur les exigences de charge de travail, y compris les exigences de sécurité. Par exemple, utilisez des stratégies de refus pour empêcher l’exposition des API via HTTP ou pour empêcher l’activation de l’API REST de gestion directe. Utilisez des stratégies d’audit si les stratégies de refus ne sont pas disponibles ou créez des stratégies de refus personnalisées s’il est important pour votre charge de travail. L’instance Gestion des API s’aligne sur la conception et reste alignée à mesure que la charge de travail évolue.
(Service) Familiarisez-vous avec la fonctionnalité Diagnostiquer et résoudre les problèmes dans le portail Azure.

Utilisez le panneau État du réseau dans le portail pour résoudre les problèmes de connectivité réseau.		 Les personnes d’ingénierie de fiabilité de site peuvent identifier et résoudre les problèmes de performances de passerelle, de disponibilité des services et de connectivité réseau dans tous les environnements.
(API) Utilisez Event Hubs pour gérer les flux de journaux ou d’événements à partir d’appels d’API qui nécessitent des réactions quasiment en temps réel ou des opérations en fenêtres à court terme. La disponibilité en temps quasi réel des entrées de journal est fournie. Le délai d’ingestion des données de journal qui se produit lors de la connexion à Azure Monitor dans les API est évité.
(API) Encouragez l’utilisation du suivi des API dans le développement pour aider les développeurs à comprendre l’implémentation de leur stratégie. La productivité des développeurs est optimisée en fournissant des informations sur l’implémentation des stratégies au sein d’une API. Sans cette fonctionnalité, les développeurs doivent introduire des hacks dans l’implémentation de stratégie pour obtenir des insights.
(API) Définissez toujours les back-ends à l’aide de la fonctionnalité back-end de Gestion des API. Référencez ces back-ends par ID dans la stratégie en utilisant set-backend-service. Les back-ends à charge équilibrée doivent être définis comme pool de back-ends. Les modifications de connexion back-end s’appliquent à toutes les API qui utilisent le back-end sans nécessiter de mises à jour du code de stratégie individuel. Le risque de configurations incorrectes ou de modifications de stratégie d’API ignorées est réduit et les scénarios dans lesquels plusieurs API partagent le même back-end sont adaptés par le biais de cette couche d’abstraction de configuration.
(API) Concevez l’approche de contrôle de version de vos API pour s’aligner sur les fonctionnalités de contrôle de version et de révision de Gestion des API. Facteurz cette approche dans vos opérations de déploiement d’API. Une stratégie de contrôle de version d’API prise en charge par Gestion des API est utilisée pour tirer parti des fonctionnalités intégrées au lieu de créer des solutions personnalisées.
(Service &API) Définissez un processus opérationnel cohérent et durable pour l’ajout, la modification et la suppression d’API. Déterminez s’il faut gérer cette expérience manuellement via le portail ou l’implémenter via un processus APIOps. Préférez utiliser une approche basée sur IaC au lieu d’une approche basée sur le portail.

La représentation de la gestion des API dans l’API Resource Manager se compose de nombreuses ressources enfants, d'où l'importance d’adopter une approche en couches pour la gestion basée sur IaC de cette collection de ressources.		 Les spécifications des API et leurs implémentations de passerelle sont intégrées aux processus de contrôle des modifications de la charge de travail. Cette approche empêche la gestion des modifications apportées aux API principales différemment de la façon dont elles sont exposées aux clients d’API via la passerelle.

Efficacité des performances

L'efficacité des performances consiste à maintenir l'expérience de l'utilisateur même en cas d'augmentation de la charge en gérant la capacité. La stratégie inclut la mise à l’échelle des ressources, l’identification et l’optimisation des goulots d’étranglement potentiels et l’optimisation des performances maximales.

Les principes de conception Performance Efficiency fournissent une stratégie de conception de haut niveau pour atteindre ces objectifs de capacité par rapport à l’utilisation attendue.

Démarrez votre stratégie de conception en fonction de la liste de vérification de la révision de conception pour l’Efficacité de la Performance afin de définir une référence basée sur les indicateurs clés de performance pour la gestion des API.

Liste de contrôle de conception

  • Définissez des cibles de performances : Les métriques clés permettant d’évaluer les performances de la passerelle Gestion des API incluent des métriques de capacité, telles que les pourcentages d’utilisation du processeur et de la mémoire pour l’infrastructure de passerelle, la durée de la demande et le débit des requêtes. Dans les déploiements multirégions, définissez des cibles de performances pour chaque région. Le client doit définir des seuils de mise à l’échelle appropriés en fonction des modèles de trafic, des charges de travail d’API et des temps de mise à l’échelle.

  • Collecter des données de performances : Passez en revue les fonctionnalités d’analytique intégrée, de métriques Azure Monitor, de journaux Azure Monitor, d’Application Insights et d’Event Hubs pour collecter et analyser les performances à différents niveaux de granularité.

  • Passez en revue comment identifier les problèmes de performances en direct : Les indicateurs de problèmes de performances actives incluent la disponibilité du service Azure, les erreurs de réponse HTTP et les erreurs générées dans la section Diagnostiquer et résoudre les problèmes dans le portail. Résolvez les problèmes de performances et de disponibilité à l’aide d’Application Insights, de requêtes Kusto et de recommandations à partir des diagnostics de gestion des API dans le portail Azure.

  • Performances des tests : Testez les performances dans des conditions de production à l’aide de tests de charge.

  • Évaluez les services adjacents susceptibles d’améliorer les performances : Les stratégies de mise en cache ou un cache externe peuvent améliorer les performances des opérations d’API spécifiques. Azure Front Door et Application Gateway sont des choix courants pour le déchargement TLS.

  • Passez en revue les limites et contraintes documentées :Gestion des API a des limites et des contraintes. Passez en revue les contraintes documentées et comparez-les aux exigences de votre charge de travail pour voir si vous devez concevoir une solution qui évite ces contraintes.

Recommandations

Ces recommandations d’efficacité des performances peuvent s’appliquer au service lui-même ou au trafic qui transite par les API et leurs stratégies. Les indicateurs (Service) ou API indiquent si une recommandation cible le service ou les API.

Recommandation Avantage
(Service) Adapter de façon dynamique pour répondre à la demande. Configurez des règles de mise à l’échelle automatique ou d’autres processus automatisés pour ajuster les unités de passerelle en fonction d’une capacité d’utilisation cible. L’élasticité est obtenue en fonction de l’utilisation simultanée, ce qui empêche l’épuisement des ressources des unités actuellement déployées ou l’allocation excessive de capacité.
(API) Réduisez les tâches de traitement coûteuses, telles que la génération de tailles de charge utile mises en mémoire tampon volumineuse, à l’aide de la stratégie de validation de contenu sur les corps de requêtes volumineux ou en conservant un grand nombre de WebSockets actifs. La charge sur les unités d’échelle est réduite, ce qui leur permet de traiter simultanément plus de demandes avant de devoir effectuer un scale-out.
(Service &API) Collectez les métriques de performances.

Les métriques courantes de performances de l’API sont les suivantes :

- Temps de traitement des demandes pour la passerelle elle-même et pour l’opération complète.
- Métriques d’utilisation des ressources d’unité de passerelle.
- Mesures de débit telles que les requêtes par seconde ou mégabits par seconde.
- Taux de correspondance dans le cache.		 Les performances réelles sont mesurées par rapport aux cibles de la charge de travail.
(Service &API) Définissez un pourcentage d’échantillonnage pour Application Insights qui offre une visibilité suffisante sans affecter les performances. Les besoins en données d’observabilité sont satisfaits sans affecter les performances globales.
(Service &API) Évaluez l’impact sur les performances du placement de la logique entre votre passerelle, votre back-end ou votre point d’entrée public, tel qu’Azure Front Door. Les mêmes tâches de traitement peuvent souvent se produire à l’une de ces couches, avec des compromis de performances et des limitations dans les opportunités d’optimisation pour chacun d’eux. Si une tâche, telle qu’une stratégie d’API de gestion des API, introduit trop de latence, déterminez si cette tâche peut s’exécuter ailleurs de manière plus optimisée. Les tâches qui ajoutent la latence aux API sont exécutées sur le calcul optimisé pour répondre aux exigences de charge de travail.

Stratégies Azure

Azure fournit un ensemble complet de stratégies intégrées liées à gestion des API et à ses dépendances. Certaines des recommandations précédentes peuvent être auditées via Azure Policy. Par exemple, vous pouvez vérifier si :

  • La passerelle est configurée pour la redondance de zone.
  • Les contrôles réseau appropriés sont en place pour la passerelle Gestion des API, comme le déploiement dans un réseau virtuel.
  • Les points de terminaison de configuration de service ne sont pas accessibles à tous.
  • L’API REST gestion directe est désactivée.

Pour une gouvernance complète, passez en revue les définitions intégrées d’Azure Policy et d’autres stratégies susceptibles d’affecter la sécurité de la passerelle Gestion des API.

Recommandations d’Azure Advisor

Azure Advisor est un consultant cloud personnalisé qui vous aide à suivre les meilleures pratiques pour optimiser vos déploiements Azure.

Pour plus d’informations, consultez Azure Advisor.

Advisor peut également exposer d’autres recommandations dans votre système de production, telles que :

  • Échec de l’utilisation requise de tailles de clés JWT longues dans la stratégie validate-jwt.
  • Vous avez utilisé une version héritée de l’API Resource Manager pour déployer la ressource.
  • Les jetons de clé API sont proches de leur date d’expiration.
  • Échec dans une opération de rotation de certificat.

Compromis

Vous devrez peut-être faire des compromis de conception si vous utilisez les approches dans les listes de contrôle des piliers. Voici quelques exemples d’avantages et d’inconvénients.

Haute disponibilité par le biais de la redondance et de l’isolation

  • Haute disponibilité : L’ajout d’une redondance à une architecture affecte les coûts. Par exemple, l’approvisionnement d’au moins trois unités pour éviter les pannes zonales peut ne pas être financièrement réalisable pour votre charge de travail. Les coûts augmentent davantage avec une architecture multirégion, qui nécessite au moins six unités, ou trois unités par région. Une configuration multirégion ajoute également des coûts opérationnels pour coordonner les déploiements sécurisés, la mise à l’échelle fiable et la coordination du basculement avec les back-ends.

  • Isolement : L’isolation des charges de travail entre les espaces de travail ou les instances Gestion des API ajoute une complexité opérationnelle, car elle inclut la gestion d’un système multilocataire qui a une isolation de calcul.

Adapter pour répondre à la demande

  • Lorsque vous effectuez automatiquement un scale-out pour répondre à la demande des clients bien comportés, ces coûts sont déjà pris en compte dans vos modèles de coûts. Toutefois, cette fonctionnalité de mise à l’échelle permet également au service de gérer le trafic contre les nuisances et le trafic malveillant.

  • L’atténuation du trafic non souhaité entraîne des coûts. L’ajout de services comme un pare-feu d’applications web et la protection DDoS augmentent les dépenses. La mise à l’échelle de votre service pour gérer le trafic augmente les coûts en raison d’unités ajoutées. La définition de limites de mise à l’échelle supérieures peut limiter les dépenses, mais peut entraîner des problèmes de fiabilité pour les utilisateurs légitimes si le trafic malveillant ou dangereux surcharge votre API.

Approche fédérée et distribuée

Une décision fondamentale dans Gestion des API consiste à colocaliser des charges de travail disparates au sein d’une seule instance gestion des API ou à isoler les charges de travail entre plusieurs instances dans une topologie entièrement autonome.

Les espaces de travail Gestion des API permettent une opération efficace en tant que plateforme de colocation mutualisée pour plusieurs équipes d’API. Les modèles tarifaires hiérarchisé sont conçus pour permettre le partage des coûts de service entre tous les locataires qui utilisent les passerelles. Toutefois, comme toutes les plateformes de colocalisation, les pannes ou les mauvaises configurations peuvent entraîner des effets généralisés sur les charges de travail non liées qui partagent la même infrastructure.

Modèle entièrement distribué, où chaque équipe de charge de travail gère ses propres instances, introduit des coûts duplicatifs et une redondance dans les opérations de routine. Toutefois, il fournit une atténuation inhérente du rayon d’explosion pour la fiabilité, la sécurité et les incidents liés aux performances.

Étapes suivantes

La gestion des API est souvent combinée aux services suivants. Veillez à consulter leurs guides de service ou documentation produit si votre charge de travail inclut les services suivants.

Les articles suivants illustrent certaines des recommandations présentées dans cet article.