Partager via

Fiabilité dans Gestion des API Azure

Gestion de l'API Azure. est un service entièrement géré qui aide les organisations à publier, sécuriser, transformer, gérer et surveiller les API. En tant que service Azure, Gestion des API fournit une gamme de fonctionnalités pour prendre en charge vos exigences de fiabilité.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre la gestion des API résiliente à diverses pannes et problèmes potentiels, notamment les erreurs temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance du service. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service Gestion des API (SLA).

Vue d’ensemble de l’architecture de fiabilité

Gestion des API utilise une architecture basée sur une unité d’échelle pour fournir une redondance et une scalabilité intégrées. Lorsque vous déployez une instance Gestion des API, vous configurez une ou plusieurs unités d’échelle ou unités. Chaque unité est une représentation logique de la capacité qui contient les ressources de calcul nécessaires pour gérer les demandes d’API.

Lorsque vous configurez une instance avec deux unités ou plus, les unités disponibles fonctionnent ensemble pour traiter les demandes et fournir un équilibrage de charge automatique. Si l’une des unités devient indisponible, les unités restantes continuent de gérer le trafic, mais avec une capacité potentiellement réduite.

Pour obtenir des niveaux de fiabilité plus élevés, Gestion des API prend en charge la distribution d’unités entre les zones de disponibilité au sein d’une région et dans plusieurs régions.

Les niveaux de service Gestion des API fournissent différents niveaux de fiabilité :

  • Niveau Premium (classique) : Prend en charge plusieurs unités qui peuvent être distribuées entre les zones de disponibilité et les régions pour une résilience maximale. Dans le niveau Premium, chaque unité se compose de deux machines virtuelles qui fournissent les ressources de calcul pour gérer les demandes d’API.

  • Niveaux De base v2, Standard, Standard v2 et Premium v2 (préversion) : Tous prennent en charge plusieurs unités au sein d’un seul centre de données. Ils ne prennent pas en charge les zones de disponibilité ou les déploiements multirégions.

  • Niveau développeur : Prend en charge une seule unité et ne fournit aucune zone de disponibilité ni prise en charge multirégion. Ce niveau est conçu pour les scénarios de développement et de test. Il ne convient pas aux charges de travail de production.

  • Niveau consommation : Possède des fonctionnalités de résilience intégrées et est résiliente à une plage d’erreurs au sein d’un seul centre de données Azure. Toutefois, le niveau Consommation ne prend pas en charge les zones de disponibilité ou les déploiements multirégions. Pour comprendre la durée de fonctionnement attendue d’une instance Gestion des API de niveau Consommation, passez en revue le contrat de niveau de service (SLA).

Les unités d’une instance fonctionnent ensemble pour traiter les requêtes et équilibrer automatiquement la charge entre les unités disponibles. Si une unité devient indisponible, les unités restantes continuent de gérer le trafic, mais avec une capacité potentiellement réduite.

Remarque

Les niveaux Développeur et Premium de Gestion des API prennent en charge les passerelles auto-hébergées, que vous pouvez exécuter sur votre propre infrastructure. Lorsque vous utilisez des passerelles auto-hébergées, vous êtes chargé de les configurer pour répondre à vos exigences de fiabilité. Les passerelles auto-hébergées sont en dehors de l’étendue de cet article.

Recommandations concernant le déploiement de production

Azure Well-Architected Framework fournit des recommandations sur la fiabilité, les performances, la sécurité, le coût et les opérations. Pour comprendre comment ces domaines influencent les uns les autres et contribuent à une solution de gestion des API fiable, consultez les meilleures pratiques d’architecture pour gestion des API.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Lorsque vous utilisez Gestion des API devant une API, vous devrez peut-être réessayer les demandes qui échouent en raison d’erreurs temporaires. Pour protéger votre API back-end d’être submergée par trop de requêtes, Gestion des API fournit des stratégies de nouvelle tentative, de limite de débit et de quota. Vous pouvez également configurer des fonctionnalités d’équilibrage de charge et de disjoncteur à l’aide de ressources principales.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Gestion des API fournit deux types de prise en charge des zones de disponibilité lorsque vous déployez une instance Gestion des API Premium (classique) dans une région prise en charge :

  • Automatique: Gestion des API fournit une prise en charge automatique des zones de disponibilité lorsque vous ne spécifiez pas les zones de disponibilité à utiliser.

  • Manuelle: Gestion des API fournit une prise en charge manuelle des zones de disponibilité lorsque vous spécifiez explicitement les zones de disponibilité à utiliser.

Avec la prise en charge des zones de disponibilité, la gestion des API réplique les composants de service à travers les zones afin d'assurer une haute disponibilité. Dans la région primaire, ces composants incluent la passerelle (unités d’échelle), le plan de gestion et le portail des développeurs. Dans les régions secondaires, seules les unités de passerelle sont répliquées. Pour plus d’informations sur les régions secondaires, consultez la résilience aux défaillances à l’échelle de la région.

Prise en charge automatique de la zone de disponibilité

Vous pouvez utiliser la prise en charge automatique de la zone de disponibilité pour choisir une seule unité ou une configuration d’instance multiunit pour obtenir une redondance de zone :

  • Configuration multiunit (recommandé) : si votre instance a deux unités ou plus, gestion des API fait un meilleur effort pour répartir les unités de votre instance entre les zones de disponibilité de la région. Il n’existe aucun moyen de déterminer les zones de disponibilité dans lesquelles vos unités sont placées. Nous vous recommandons de déployer au moins deux unités, qui peuvent être réparties entre deux zones.

    Le diagramme suivant montre une instance API Management avec trois unités configurées pour la prise en charge automatique de la zone de disponibilité :

    Diagramme montrant trois unités gestion des API réparties entre les zones de disponibilité pour la prise en charge automatique des zones de disponibilité.

  • Configuration à unité unique : Si votre instance a une seule unité, les machines virtuelles sous-jacentes de l’unité sont distribuées à deux zones de disponibilité. Il n’existe aucun moyen de déterminer les zones de disponibilité dans lesquelles les machines virtuelles de l’unité sont placées.

    Diagramme montrant une unité de gestion des API unique répartie entre deux zones de disponibilité pour la prise en charge automatique des zones de disponibilité.

Prise en charge manuelle des zones de disponibilité

Si vous souhaitez sélectionner explicitement les zones de disponibilité à utiliser, vous pouvez choisir entre les configurations redondantes interzone et zonales :

  • Redondant interzone : Configurez manuellement la redondance de zone pour une instance de gestion des API dans une région prise en charge afin de fournir une redondance pour les composants de service. Lorsque vous sélectionnez deux zones de disponibilité ou plus à utiliser, Azure réplique automatiquement les composants de service dans les zones sélectionnées.

    Diagramme montrant trois unités de gestion des API distribuées entre les zones de disponibilité afin d'assurer la redondance manuelle des zones.

  • Zonal: Les composants du service Gestion des API sont déployés dans une seule zone que vous sélectionnez dans une région Azure. Toutes les unités sont placées dans la même zone de disponibilité.

    Diagramme montrant un déploiement de gestion des API zonal qui a deux unités, dans une seule zone de disponibilité.

    Important

    Épinglez-vous à une seule zone de disponibilité uniquement si la latence interzone est trop élevée pour vos besoins et après avoir vérifié que la latence ne répond pas à vos exigences. Seule, une instance zonale n'assure pas la résilience en cas de panne d'une zone de disponibilité. Pour améliorer la résilience d’un déploiement de gestion des API zonales, vous devez déployer explicitement des instances distinctes dans plusieurs zones de disponibilité et configurer le routage et le basculement du trafic.

Spécifications

  • Prise en charge de la région : Gestion des API prend en charge les zones de disponibilité pour le niveau Premium (classique) dans toutes les régions Azure qui prennent en charge les zones de disponibilité.

  • Condition requise pour le niveau : Vous devez utiliser le niveau Premium (classique) pour configurer la prise en charge des zones de disponibilité. La gestion des API ne prend actuellement pas en charge les zones de disponibilité dans les niveaux Classique Consommation, Développeur, De base et Standard, ou dans les niveaux De base v2, Standard v2 et Premium v2. Pour mettre à niveau votre instance vers le niveau Premium (classique), consultez Mettre à niveau vers le niveau Premium.

Remarque

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.

Considérations

  • Nombre d’unités pour les instances redondantes interzone : Si vous configurez manuellement la redondance de zone pour une instance, vous devez également configurer un certain nombre d’unités gestion des API qui peuvent être distribuées uniformément sur toutes vos zones de disponibilité sélectionnées. Par exemple, si vous sélectionnez deux zones, vous devez configurer au moins deux unités. Vous pouvez à la place configurer quatre unités, ou un autre multiple de deux unités. Si vous sélectionnez trois zones de disponibilité, vous devez configurer trois unités, six unités ou un autre multiple de trois unités.

    Si vous utilisez la prise en charge automatique de la zone de disponibilité, il n’est pas nécessaire d’utiliser un nombre spécifique d’unités. Les unités que vous déployez sont réparties entre les zones de disponibilité de manière optimale. Pour une redondance maximale de zone, nous vous recommandons d’utiliser au moins deux unités pour vous assurer qu’une panne de zone de disponibilité n’affecte pas votre instance.

    Pour déterminer le nombre d’unités qui fournissent vos performances de passerelle requises, utilisez les métriques de capacité et vos propres tests. Pour plus d’informations sur la mise à l’échelle et la mise à niveau de votre instance de service, consultez Mettre à niveau et mettre à l’échelle une instance gestion des API.

  • Mise à l’échelle automatique : Si vous configurez manuellement des zones de disponibilité sur une instance Gestion des API configurée avec la mise à l’échelle automatique, vous devrez peut-être ajuster vos paramètres de mise à l’échelle automatique après la configuration. Dans ce cas, le nombre d’unités gestion des API dans les règles et limites de mise à l’échelle automatique doit être un multiple du nombre de zones. Si vous utilisez la prise en charge de la zone de disponibilité automatique, vous n’avez pas besoin d’ajuster vos paramètres de mise à l’échelle automatique.

  • Exigences relatives à l’adresse IP : Lorsque vous activez la prise en charge de la zone de disponibilité sur une instance Gestion des API déployée dans un réseau virtuel externe ou interne, vous devez spécifier une ressource d’adresse IP publique pour que l’instance utilise. Dans un réseau virtuel interne, l’adresse IP publique est utilisée uniquement pour les opérations de gestion, non pas pour les requêtes API. Pour plus d’informations, consultez les adresses IP dans Gestion des API.

Coûts

Quelle que soit la configuration de votre zone de disponibilité, si vous ajoutez d’autres unités, vous entraînez davantage de coûts. Pour plus d’informations, consultez la tarification gestion des API.

Configurez la prise en charge des zones de disponibilité

Cette section explique comment configurer la prise en charge des zones de disponibilité pour votre instance Gestion des API.

Remarque

Lorsque vous sélectionnez les zones de disponibilité à utiliser, vous sélectionnez en fait la zone de disponibilité logique. Si vous déployez d’autres composants de charge de travail dans un autre abonnement Azure, ils peuvent utiliser un autre numéro de zone de disponibilité logique pour accéder à la même zone de disponibilité physique. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

  • Créez une instance Gestion des API qui prend en charge les zones de disponibilité : Lorsque vous créez une instance Gestion des API Premium (classique) dans une région qui prend en charge les zones de disponibilité, l’instance prend en charge les zones de disponibilité par défaut. Vous pouvez sélectionner la prise en charge automatique de la zone de disponibilité ou configurer manuellement la prise en charge zonale ou redondante interzone.

  • Activer ou reconfigurer la prise en charge de la zone de disponibilité : Vous pouvez modifier la configuration de la zone de disponibilité pour une instance gestion des API, notamment l’ajout de zones de disponibilité et le déplacement d’une instance zonale entre les zones de disponibilité. Pour savoir comment configurer la prise en charge des zones de disponibilité sur une instance Gestion des API, consultez Activer la prise en charge des zones de disponibilité sur les instances Gestion des API. Il n’existe aucune exigence de temps d’arrêt pour les options de configuration.

    Lorsque vous modifiez la configuration de la zone de disponibilité, les modifications peuvent prendre 15 à 45 minutes ou plus pour s’appliquer. La passerelle Gestion des API peut continuer à gérer les demandes d’API pendant ce temps.

    La modification de la configuration de la zone de disponibilité déclenche un changement d’adresse IP publique et privée.

Planification de capacité et gestion

Dans un scénario de mise hors zone, il n’existe aucune garantie que les demandes de capacité supplémentaires dans une autre zone de disponibilité réussissent. Le remplissage des unités perdues se produit sur la base du meilleur effort. Si vous avez besoin d’une capacité garantie en cas d’échec d’une zone de disponibilité, vous devez créer et configurer votre instance Gestion des API pour tenir compte de la perte d’une zone en effectuant toutes les actions suivantes :

  • Surprovisionnez les unités de votre instance Gestion des API.

  • Utilisez une configuration de zone de disponibilité automatique ou redondante.

Pour plus d’informations, consultez Gérer la capacité avec le surapprovisionnement.

Utilisez les métriques de capacité et vos propres tests pour déterminer le nombre d’unités qui fournissent vos performances de passerelle requises. Pour plus d’informations sur la mise à l’échelle et la mise à niveau de votre instance de service, consultez Mettre à niveau et mettre à l’échelle une instance gestion des API.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque les instances gestion des API sont configurées avec la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

  • Routage du trafic entre les zones : Pendant les opérations normales, le trafic est acheminé entre toutes vos unités de gestion des API disponibles dans toutes les zones de disponibilité sélectionnées.

  • Réplication des données entre les zones : Gestion des API stocke et réplique les données suivantes.

    • La configuration de la passerelle, telle que les API et les définitions de stratégie, est régulièrement synchronisée entre les zones de disponibilité que vous sélectionnez pour l’instance. La propagation des mises à jour entre les zones de disponibilité prend normalement moins de 10 secondes.

    • Données dans le cache interne, si vous utilisez le cache interne fourni par Gestion des API. Les entrées de cache sont distribuées entre les zones de disponibilité. Le cache interne est volatile et les données ne sont pas garanties d’être conservées. Envisagez d’utiliser un cache externe si vous devez conserver les données mises en cache.

    • Compteurs de limite de débit, si vous utilisez les fonctionnalités de limitation de débit que la gestion des API fournit. Les compteurs de limite de débit sont répliqués de manière asynchrone entre les zones de disponibilité que vous sélectionnez pour l’instance.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque les instances gestion des API sont configurées avec la prise en charge de la zone de disponibilité et qu’il existe une panne de zone de disponibilité.

  • Détection et réponse : La responsabilité de la détection et de la réponse dépend de la configuration de la zone de disponibilité utilisée par votre instance.

    • Automatique et à redondance de zone : Pour les instances configurées pour utiliser la prise en charge automatique de la zone de disponibilité ou configurées manuellement pour utiliser la redondance de zone, la plateforme de la gestion des API est responsable de détecter un échec dans une zone de disponibilité et d'y répondre. Vous n’avez rien à faire pour initier un failover de zone.

    • Zonal: Pour les instances configurées pour être zonales, vous devez détecter la perte d’une zone de disponibilité et lancer un basculement vers une instance secondaire que vous créez dans une autre zone de disponibilité.

  • Demandes actives : Lorsqu’une zone de disponibilité n’est pas disponible, toutes les requêtes en cours connectées à une unité gestion des API dans la zone de disponibilité défectueuse sont arrêtées et doivent être retentées.

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Perte de données attendue : Gestion des API stocke les données suivantes.

    • Les modifications de configuration de la passerelle, qui sont répliquées dans chaque zone de disponibilité sélectionnée dans un délai d’environ 10 secondes. Si une panne d’une zone de disponibilité se produit, vous risquez de perdre les modifications de configuration qui ne sont pas répliquées.

    • Données dans le cache interne, si vous utilisez la fonctionnalité de cache interne. Le cache interne est volatile et les données ne sont pas garanties d’être conservées. Lors d’une panne de zone de disponibilité, vous risquez de perdre certaines ou toutes les données mises en cache. Envisagez d’utiliser un cache externe si vous devez conserver les données mises en cache.

    • Compteurs de limite de débit, si vous utilisez la fonctionnalité de limite de débit. Pendant une panne de zone de disponibilité, les compteurs de limite de débit peuvent ne pas être à jour dans les zones survivantes.

  • Temps d’arrêt attendu : Le temps d’arrêt attendu dépend de la configuration de la zone de disponibilité utilisée par votre instance.

    • Automatique: Vous pouvez vous attendre à ce que les instances qui utilisent la prise en charge automatique de la zone de disponibilité n’aient aucun temps d’arrêt pendant une panne de zone de disponibilité. Les unités de la zone ou des zones non affectées continuent de fonctionner.

      Vous pouvez également vous attendre à ce que les instances qui utilisent la prise en charge automatique de la zone de disponibilité, mais qui ont une unité unique, n’aient aucun temps d’arrêt. Dans ce cas, Gestion des API distribue les machines virtuelles sous-jacentes de l’unité à deux zones. La machine virtuelle dans la zone non affectée continue de fonctionner.

    • Redondant interzone : Vous pouvez vous attendre à ce que les instances redondantes de zone ne subissent aucun temps d’arrêt en cas de panne de zone de disponibilité.

    • Zonal: Pour les instances zonales, lorsqu’une zone n’est pas disponible, votre instance n’est pas disponible jusqu’à ce que la zone de disponibilité récupère.

  • Réacheminement du trafic : Le comportement de réacheminement du trafic dépend de la configuration de la zone de disponibilité utilisée par votre instance.

    • Redondant automatique et interzone : Pour les instances configurées pour utiliser la prise en charge automatique de la zone de disponibilité ou qui sont configurées manuellement pour utiliser la redondance de zone, lorsqu’une zone n’est pas disponible, toutes les unités de la zone concernée ne sont pas disponibles. Vous pouvez choisir de mettre à l’échelle votre instance pour ajouter d’autres unités.

    • Zonal: Pour les instances zonales, lorsqu’une zone n’est pas disponible, votre instance n’est pas disponible. Si vous avez une instance secondaire dans une autre zone de disponibilité, vous êtes responsable de la réacheminement du trafic vers cette instance secondaire.

Récupération de la zone

Le comportement de récupération de zone dépend de la configuration de la zone de disponibilité utilisée par votre instance.

  • Automatique et redondant entre zones : Pour les instances configurées pour utiliser la prise en charge automatique de la zone de disponibilité ou configurées manuellement pour utiliser la redondance de zone, lorsque la zone de disponibilité est rétablie, Gestion des API restaure automatiquement les unités dans la zone de disponibilité et redirige le trafic entre vos unités comme d'habitude.

  • Zonal: Pour les instances zonales, vous êtes responsable de la réacheminement du trafic vers l’instance dans la zone de disponibilité d’origine après la récupération de la zone de disponibilité.

Tester les pannes de zone

Les options de test des défaillances de zone dépendent de la configuration de la zone de disponibilité utilisée par votre instance.

  • Automatique et redondant par zone : Pour les instances configurées pour utiliser le support automatique de zone de disponibilité ou configurées manuellement pour la redondance par zone, la plateforme de Gestion des API gère le routage du trafic, le basculement et la restauration après sinistre. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

  • Zonal: Pour les instances zonales, il n’existe aucun moyen de simuler une panne de la zone de disponibilité qui contient votre instance Gestion des API. Toutefois, vous pouvez configurer manuellement des passerelles en amont ou des équilibreurs de charge pour rediriger le trafic vers une autre instance dans une autre zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

Avec un déploiement multirégion, vous pouvez ajouter des passerelles d’API régionales à une instance gestion des API existante dans une ou plusieurs régions Azure prises en charge. Le déploiement multirégion permet de réduire toute latence de requête perçue par les consommateurs d’API géographiquement distribués. Un déploiement multirégion améliore également la disponibilité du service si une région est hors connexion.

Déploiement multirégion géré par Microsoft

Gestion des API prend uniquement en charge les déploiements multirégions au niveau Premium (classique). Il ne prend pas en charge les déploiements multirégions dans les niveaux Consommation, Développeur, Basic, Basic v2, Standard, Standard v2 et Premium v2 (préversion). Pour plus d'informations, consultez la section Conditions requises.

Lorsque vous ajoutez une région, vous configurez :

Spécifications

  • Prise en charge de la région : Vous pouvez créer des déploiements multirégions dans le niveau Premium (classique) avec n’importe quelle région Azure prenant en charge gestion des API. Pour voir quelles régions prennent en charge les déploiements multirégions, consultez disponibilité des produits par région.

  • Condition requise pour le niveau : Vous devez utiliser le niveau Premium (classique) pour configurer la prise en charge multirégion. Pour mettre à niveau votre instance vers le niveau Premium (classique), consultez Mettre à niveau vers le niveau Premium.

Remarque

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.

Considérations

  • Passerelle uniquement : Seul le composant de passerelle de votre instance Gestion des API est répliqué dans plusieurs régions. Le plan de gestion et le portail des développeurs de l’instance restent hébergés uniquement dans la région primaire où vous avez déployé le service à l’origine.

  • Configuration réseau requise : Si vous souhaitez configurer un emplacement secondaire pour votre instance Gestion des API lorsqu’elle est déployée (injectée) dans un réseau virtuel, le réseau virtuel et la région de sous-réseau doivent correspondre à l’emplacement secondaire que vous configurez. Si vous ajoutez, supprimez ou activez la zone de disponibilité dans la région primaire, ou si vous modifiez le sous-réseau de la région primaire, l’adresse IP virtuelle de votre instance Gestion des API change. Pour plus d’informations, consultez Modifications apportées aux adresses IP. Toutefois, si vous ajoutez une région secondaire, le VIP de la région primaire ne change pas, car chaque région possède son propre VIP privé.

  • Noms dns (Domain Name System) : La passerelle de chaque région, y compris la région primaire, a un nom DNS régional qui suit le modèle d’URL de https://<service-name>-<region>-01.regional.azure-api.net, par exemple https://contoso-westus2-01.regional.azure-api.net.

Coûts

L’ajout de régions entraîne des coûts. Pour plus d’informations, consultez la tarification gestion des API.

Configurer la prise en charge multirégion

Pour configurer la prise en charge multirégion sur une instance Gestion des API, consultez Déployer une instance Gestion des API dans plusieurs régions Azure.

Pour supprimer une région d’une instance Gestion des API, consultez Supprimer une région de service Gestion des API.

Planification de capacité et gestion

Dans un scénario de baisse de région, il n’existe aucune garantie que les demandes de capacité supplémentaires dans une autre région réussissent. Si vous avez besoin d’une capacité garantie en cas d’échec d’une région, vous devez créer et configurer votre instance Gestion des API pour prendre en compte la perte d’une région. Pour ce faire, vous pouvez surprovisionner la capacité de votre instance Gestion des API. Pour en savoir plus sur le principe de surapprovisionnement, consultez Gérer la capacité avec surprovisionnement.

Dans les déploiements multirégions, la mise à l’échelle automatique s’applique uniquement à la région primaire. Les régions secondaires nécessitent des ajustements manuels de mise à l’échelle ou des outils personnalisés que vous contrôlez.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce à quoi s’attendre lorsque les instances gestion des API sont configurées avec une prise en charge multirégion et que toutes les régions sont opérationnelles.

  • Routage du trafic entre les régions : Gestion des API achemine automatiquement les requêtes entrantes vers une passerelle régionale. Une requête est acheminée vers la passerelle régionale avec la latence la plus faible du client. Si vous devez utiliser une approche de routage différente, vous pouvez configurer votre propre Traffic Manager avec des règles de routage personnalisées. Pour plus d’informations, consultez Utiliser le routage personnalisé vers les passerelles régionales Gestion des API.

    Lorsqu’une requête atteint une passerelle régionale Gestion des API, elle est routée vers l’API back-end, sauf si une stratégie retourne une réponse directement à partir de la passerelle, telle qu’une réponse mise en cache ou un code d’erreur. Dans une solution multirégion, vous devez prendre soin d’acheminer vers une instance de l’API back-end qui répond à vos besoins en matière de performances. Pour plus d’informations, consultez Routage des appels d’API vers les services principaux régionaux.

  • Réplication des données entre les régions : La configuration de passerelle, telle que les API et les définitions de stratégie, est régulièrement synchronisée entre les régions primaires et secondaires que vous ajoutez. La propagation des mises à jour vers les passerelles régionales prend normalement moins de 10 secondes.

    Les compteurs de limite de débit et les données dans le cache interne sont spécifiques à la région. Ils ne sont donc pas répliqués entre les régions.

Comportement lors d’une défaillance de région

Cette section décrit ce qu’il faut attendre lorsque les instances gestion des API sont configurées avec une prise en charge multirégion et qu’il existe une panne dans l’une des régions que vous utilisez.

  • Détection et réponse : Gestion des API est chargée de détecter une défaillance dans une région et de basculer automatiquement vers une passerelle dans l’une des autres régions que vous configurez.

  • Demandes actives : Toutes les requêtes actives en cours de traitement dans la région défectueuse peuvent être supprimées et doivent être retentées par le client.

  • Perte de données attendue : Gestion des API ne stocke pas de données, à l’exception de la configuration, d’un cache et des compteurs de limite de débit.

    Les modifications de configuration sont répliquées dans chaque région dans un délai d’environ 10 secondes. Si une panne de votre région primaire se produit, vous risquez de perdre les modifications de configuration qui ne sont pas répliquées.

    Les compteurs de limite de débit et les données dans le cache interne sont spécifiques à la région. Ils ne sont donc pas répliqués entre les régions.

  • Période d'indisponibilité prévue : Aucune période d'indisponibilité de passerelle n'est prévue.

    Si la région primaire est hors connexion, le plan de gestion des API et le portail des développeurs deviennent indisponibles, mais les régions secondaires continuent de traiter les demandes d’API à l’aide de la configuration de passerelle la plus récente.

  • Réacheminement du trafic : Si une région est hors connexion, les demandes d’API sont automatiquement acheminées autour de la région ayant échoué vers la passerelle la plus proche suivante.

Récupération de la région

Lorsque la région primaire récupère, Gestion des API restaure automatiquement les unités de la région et redirige le trafic entre vos unités.

Tester les défaillances régionales

Pour être prêt pour les pannes de région inattendues, nous vous recommandons de tester régulièrement vos réponses aux défaillances de région. Vous pouvez simuler certains aspects d’une défaillance de région en désactivant le routage vers une passerelle régionale.

Sauvegarde et restauration

Gestion des API ne stocke pas la plupart des données d’exécution. Toutefois, vous pouvez sauvegarder votre configuration de service Gestion des API. Vous pouvez également utiliser des opérations de sauvegarde et de restauration pour répliquer des configurations de service Gestion des API entre des environnements opérationnels, par exemple, le développement et la préproduction.

Important

Dans une procédure de sauvegarde, les données d’exécution telles que les utilisateurs et les abonnements sont incluses, ce qui peut ne pas toujours être souhaitable.

La sauvegarde est prise en charge dans les niveaux Développeur, De base, Standard et Premium.

Pour plus d’informations, consultez Comment implémenter la récupération d’urgence à l’aide de la sauvegarde et de la restauration de service dans Gestion des API.

Pour la sauvegarde ou la restauration de certains composants de service ou ressources, vous pouvez également envisager des options gérées par le client, telles que les outils APIOps et des solutions d'infrastructure en tant que code (IaC).

Résilience à la maintenance du service

Gestion des API effectue des mises à niveau de service régulières et d’autres formes de maintenance.

Dans les niveaux De base, Standard et Premium (classique), vous pouvez personnaliser le moment où dans le processus de mise à jour votre instance reçoit une mise à jour. Si vous devez valider l’effet des mises à niveau sur votre charge de travail, envisagez de configurer une instance de test pour recevoir des mises à jour au début d’un cycle de mise à jour et de définir votre instance de production pour recevoir les mises à jour en retard dans le cycle. Vous pouvez également spécifier une fenêtre de maintenance, qui est l’heure du jour où vous souhaitez que l’instance applique les mises à jour de service.

Pour plus d’informations, consultez Configurer les paramètres de mise à jour de service pour vos instances gestion des API.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Lorsque vous déployez une instance Gestion des API dans plusieurs zones de disponibilité ou régions, le pourcentage de temps d’activité défini dans le contrat SLA augmente.

Le service fournit son propre contrat SLA, mais vous devez également tenir compte de la fiabilité attendue d’autres composants de charge de travail, tels que les back-ends d’API.

Contenu connexe

  • Last updated on