Partage via

Garantir la disponibilité et la fiabilité de Gestion des API

  • Article

S’APPLIQUE À : Premium

Cet article est une vue d’ensemble des fonctionnalités du service qui vous assurent que votre instance Gestion des API continue de traiter les requêtes d’API en cas de panne d’Azure.

Gestion des API offre les fonctionnalités suivantes pour des solutions Azure fiables et résilientes. Utilisez-les individuellement ou ensemble pour améliorer la disponibilité :

  • Zones de disponibilité : résilience aux pannes au niveau du centre de données

  • Déploiement multirégion : résilience aux pannes régionales

Remarque

Zones de disponibilité

Les zones de disponibilité Azure sont des emplacements physiquement séparés au sein d’une région Azure qui tolèrent les défaillances au niveau du centre de données. Chaque zone est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’une infrastructure réseau indépendants. Pour garantir la résilience, au moins trois zones de disponibilité distinctes sont présentes dans toutes les régions qui ont des zones de disponibilité. En savoir plus

L’activation de la redondance de zone pour une instance Gestion des API dans une région prise en charge fournit une redondance pour tous les composants de service : passerelle, plan de gestion et portail des développeurs. Azure réplique automatiquement tous les composants de service dans les zones que vous sélectionnez.

Lorsque vous activez la redondance de zone dans une région, tenez compte du nombre d’unités d’échelle Gestion des API qui doivent être distribuées. Au minimum, configurez le même nombre d’unités que le nombre de zones de disponibilité, ou un multiple de sorte que les unités soient distribuées uniformément entre les zones. Par exemple, si vous sélectionnez 3 zones de disponibilité dans une région, vous pouvez avoir 3 unités de sorte que chaque zone héberge une unité.

Remarque

Utilisez les métriques de capacité et vos propres tests pour déterminer le nombre d’unités d’échelle qui fourniront les performances de la passerelle nécessaires à vos besoins. En savoir plus sur la mise à l’échelle et la mise à niveau de votre instance de service.

Déploiement multi-régions

Avec le déploiement multirégion, vous pouvez ajouter des passerelles API régionales à une instance Gestion des API existante dans une ou plusieurs régions Azure prises en charge. Ce déploiement multirégions permet de réduire la latence de la requête telle qu’elle est perçue par les consommateurs distribués de l’API et améliore la disponibilité du service si une région est mise hors connexion.

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

  • Si vous voulez configurer un emplacement secondaire pour votre instance Gestion des API lorsqu’elle est déployée (injectée) dans un réseau virtuel, la région du réseau virtuel et du sous-réseau doit 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 Adresses IP du service Gestion des API Azure. Toutefois, si vous ajoutez une région secondaire, l’adresse IP virtuelle de la région primaire ne change pas, car chaque région a sa propre adresse IP virtuelle privée.

  • Les configurations de passerelle comme les API et les définitions de stratégie sont régulièrement synchronisées 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. Le déploiement multirégion assure la disponibilité de la passerelle API dans plusieurs régions et la disponibilité du service lorsqu’une région est hors connexion.

  • Lorsque le service API Management reçoit des requêtes HTTP publiques sur le point de terminaison Traffic Manager (il s’applique au VNET externe et aux modes non connectés au réseau d’API Management), le trafic est acheminé vers une passerelle régionale selon la latence la plus faible, ce qui peut réduire la latence rencontrée par les consommateurs d’API géographiquement distribués. En mode réseau virtuel interne, les clients doivent configurer leur propre solution pour acheminer et équilibrer la charge du trafic entre les passerelles régionales. Pour plus de détails, consultez Considérations de mise en réseau.

  • 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.

  • Si une région est hors connexion, les requêtes d’API sont automatiquement acheminées autour de la région défaillante vers la passerelle suivante la plus proche.

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

Combiner des zones de disponibilité et un déploiement multirégion

La combinaison de zones de disponibilité pour la redondance au sein d’une région et du déploiement dans plusieurs régions, pour améliorer la disponibilité de la passerelle en cas de panne régionale, contribue à améliorer la fiabilité et les performances de votre instance Gestion des API.

Exemples :

  • Utiliser des zones de disponibilité pour améliorer la résilience de la région primaire dans un déploiement multirégion

  • Distribuer des unités d’échelle entre les zones de disponibilité et les régions pour améliorer les performances des passerelles régionales

Considérations relatives au SLA

Gestion des API fournit un SLA de 99,99 % lorsque vous déployez au moins une unité dans deux ou plusieurs zones de disponibilité ou régions. Pour plus d’informations, voir la tarification.

Notes

Bien qu’Azure s’efforce continuellement de garantir la résilience la plus élevée possible dans le SLA de la plateforme cloud, vous devez définir vos propres objectifs SLA pour les autres composants de votre solution.

Disponibilité du back-end

Selon l’emplacement et la façon dont vos services principaux sont hébergés, vous devrez peut-être configurer des back-ends redondants dans différentes régions pour répondre à vos besoins de disponibilité du service. Vous pouvez également configurer les propriétés du back-end afin d'améliorer la résilience et la disponibilité de vos services principaux.

Back-ends régionaux

Vous pouvez gérer les back-ends régionaux et gérer le basculement via Gestion des API pour maintenir la disponibilité. Par exemple :

  • Dans les déploiements multirégions, utilisez des stratégies pour acheminer les requêtes via des passerelles régionales vers des back-ends régionaux.

  • Configurez des stratégies pour acheminer les requêtes de manière conditionnelle vers différents back‑ends en cas de défaillance d’un back‑end dans une région particulière.

  • Utilisez la mise en cache pour réduire les appels défaillants.

Pour plus d’informations, consultez le billet de blog sur la redondance des API back-end avec Azure API Manager.

Configurer les propriétés du back-end pour la disponibilité

Les entités back-end de gestion des API vous permettent de gérer et d'appliquer des propriétés back-end afin d'améliorer la disponibilité de ces derniers. Par exemple :

  • Distribuer et équilibrer la charge du trafic vers un pool d’URL
  • Configurer les règles de disjoncteur afin de protéger le back-end contre un trop grand nombre de demandes

Étapes suivantes