Partager via

Déployer une instance Gestion des API Azure sur plusieurs régions Azure

  • Article

S’APPLIQUE À : premium

Le service Gestion des API Azure prend en charge le déploiement multirégion, ce qui permet aux éditeurs d’API d’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.

Quand vous ajoutez une région, vous configurez ceci :

  • Nombre d’unités d’échelle que la région va héberger.

  • Zones de disponibilité facultatives, si la région concernée les prend en charge.

  • Paramètres de réseau virtuel dans la région ajoutée, si la mise en réseau est configurée dans la ou les régions existantes.

Important

La fonctionnalité permettant le stockage de données client dans une seule région n’est actuellement disponible que dans la région Asie Sud-Est (Singapour) de la zone géographique Asie-Pacifique. Pour toutes les autres régions, les données client sont stockées dans Zone géographique.

À propos du déploiement multirégion

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

Prérequis

  • Si vous n’avez pas créé d’instance de service Gestion des API, consultez Créer une instance de service Gestion des API. Sélectionnez le niveau de service Premium.
  • Si votre instance Gestion des API est déployée dans un réseau virtuel, vérifiez que vous configurez un réseau virtuel et un sous-réseau à l’emplacement que vous prévoyez d’ajouter, et dans le même abonnement. Consultez les prérequis du réseau virtuel.

Déployer le service Gestion des API sur une région supplémentaire

  1. Dans le portail Azure, accédez à votre service Gestion des API, puis sélectionnez Emplacements dans le menu gauche.
  2. Sélectionnez + Ajouter dans la barre supérieure.
  3. Sélectionnez l’emplacement ajouté dans la liste déroulante.
  4. Sélectionnez le nombre d’ Unités d’échelle dans l’emplacement.
  5. Sélectionnez éventuellement une ou plusieurs zones de disponibilité.
  6. Si l’instance Gestion des API est déployée dans un réseau virtuel, configurez les paramètres du réseau virtuel dans l’emplacement, y compris le réseau virtuel, le sous-réseau et l’adresse IP publique (si des zones de disponibilité sont activées).
  7. Sélectionnez Ajouter pour confirmer.
  8. Répétez cette procédure jusqu’à ce que vous configuriez tous les emplacements.
  9. Sélectionnez Enregistrer dans la barre supérieure pour démarrer le processus de déploiement.

Supprimer une région du service Gestion des API

  1. Dans le portail Azure, accédez à votre service Gestion des API, puis sélectionnez Emplacements dans le menu gauche.
  2. Pour l’emplacement à supprimer, sélectionnez le menu contextuel à l’aide du bouton ... situé à l’extrême droite du tableau. Sélectionnez Supprimer.
  3. Confirmez la suppression, puis sélectionnez Enregistrer pour appliquer les modifications.

Acheminer les appels d’API à des services back-end régionaux

Par défaut, chaque API achemine les demandes vers une URL de service principal unique. Même si vous avez configuré des passerelles Gestion des API Azure dans diverses régions, la passerelle API va toujours transférer les requêtes au même service back-end, qui est déployé dans une seule région. Dans ce cas, le gain de performances ne proviendra que des réponses mises en cache au sein de Gestion des API Azure dans une région propre à la requête. Contacter le back-end dans le monde entier pourra toujours entraîner une latence élevée.

Pour tirer pleinement parti de la distribution géographique de votre système, vous devez disposer de services back-end déployés dans les mêmes régions que les instances Gestion des API Azure. Ensuite, à l’aide de stratégies et de la propriété @(context.Deployment.Region), vous pouvez acheminer le trafic vers des instances locales de votre serveur principal.

  1. Accédez à votre instance Gestion des API Azure et cliquez sur API dans le menu gauche.

  2. Sélectionnez l’API souhaitée.

  3. Sélectionnez Éditeur de Code dans la liste déroulante Traitement entrant.

    Éditeur de code API

  4. Utilisez le set-backend combiné avec les stratégies choose conditionnelles pour construire une stratégie de routage appropriée dans la section <inbound> </inbound> du fichier.

    Par exemple, le fichier XML suivant fonctionnerait pour les régions USA Ouest et Asie Est :

    <policies>
    <inbound>
        <base />
        <choose>
            <when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                <set-backend-service base-url="http://contoso-backend-us.com/" />
            </when>
            <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
                <set-backend-service base-url="http://contoso-backend-asia.com/" />
            </when>
            <otherwise>
                <set-backend-service base-url="http://contoso-backend-other.com/" />
            </otherwise>
        </choose>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Utiliser Traffic Manager pour le routage vers les back-ends régionaux

Vous pouvez également proposer des services back-end avec Azure Traffic Manager, diriger les appels d’API vers Traffic Manager et le laisser résoudre le routage automatiquement.

  • Pour la distribution et le basculement du trafic, nous vous recommandons d’utiliser Traffic Manager avec la méthode de routage Géographique. Nous vous déconseillons d’utiliser Traffic Manager avec la méthode Routage pondéré avec les back-ends Gestion des API.

  • Pour le contrôle du trafic pendant les opérations de maintenance, nous vous recommandons d’utiliser la méthode de routage Prioritaire.

Utiliser le routage personnalisé vers des passerelles régionales du service Gestion des API

Le service Gestion des API route les demandes vers une passerelle régionale selon la plus faible latence. Même s’il n’est pas possible de remplacer ce paramètre dans le service Gestion des API, vous pouvez utiliser votre propre Traffic Manager avec des règles de routage personnalisées.

  1. Créez votre propre Azure Traffic Manager.
  2. Si vous utilisez un domaine personnalisé, utilisez-le avec Traffic Manager plutôt qu’avec le service Gestion des API.
  3. Configurez les points de terminaison régionaux du service Gestion des API dans Traffic Manager. Les points de terminaison régionaux suivent le modèle d’URL https://<service-name>-<region>-01.regional.azure-api.net, par exemple https://contoso-westus2-01.regional.azure-api.net.
  4. Configurez les points de terminaison d’état régionaux du service Gestion des API dans Traffic Manager. Les points de terminaison d’état régionaux suivent le modèle d’URL https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, par exemple https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.
  5. Spécifiez la méthode de routage de Traffic Manager.

Désactiver le routage vers une passerelle régionale

Dans certains cas, vous devrez peut-être désactiver temporairement le routage vers l’une des passerelles régionales. Par exemple :

  • Après l’ajout d’une nouvelle région, pour la maintenir désactivée pendant que vous configurez et testez le service back-end régional
  • Pendant la maintenance régulière du back-end dans une région
  • Pour rediriger le trafic vers d’autres régions lors d’un exercice de récupération d’urgence planifié qui simule une région indisponible, ou au cours d’une défaillance régionale

Pour désactiver le routage vers une passerelle régionale dans votre instance de Gestion des API, mettez à jour la valeur de propriété de disableGateway la passerelle sur true. Vous pouvez définir la valeur à l’aide de l’API REST Créer ou mettre à jour le service, de la commande az apim update dans Azure CLI, de l’applet de commande set-azapimanagement Azure PowerShell ou d’autres outils Azure.

Remarque

Vous pouvez uniquement désactiver le routage vers une passerelle régionale lorsque vous utilisez le routage par défaut de Gestion des API, et non pas lorsque vous utilisez une solution de routage personnalisée.

Pour désactiver une passerelle régionale à l’aide d’Azure CLI :

  1. Utilisez la commande az apim show pour afficher les emplacements, l’état de la passerelle et les URL régionales configurées pour l’instance Gestion des API.

    az apim show --name contoso --resource-group apim-hello-world-resource \
    --query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
    --output table

    Exemple de sortie :

    Location    Disabled    Url
----------  ----------  ------------------------------------------------------------
West US 2   True        https://contoso-westus2-01.regional.azure-api.net
West Europe True        https://contoso-westeurope-01.regional.azure-api.net

  2. Utilisez la commande az apim update pour désactiver la passerelle dans un emplacement disponible, tel que USA Ouest 2.

    az apim update --name contoso --resource-group apim-hello-world-resource \
--set additionalLocations[location="West US 2"].disableGateway=true

    Cette mise à jour peut prendre quelques minutes.

  3. Vérifiez que le trafic dirigé vers l’URL de la passerelle régionale est redirigé vers une autre région.

Pour restaurer le routage vers la passerelle régionale, définissez la valeur de disableGateway sur false.

Réseau virtuel

Cette section fournit des considérations relatives aux déploiements multirégions quand l’instance Gestion des API est injectée dans un réseau virtuel.

  • Configurez chaque réseau régional de façon indépendante. Les exigences de connectivité, comme les règles de groupe de sécurité réseau d’un réseau virtuel dans une région ajoutée, sont généralement les mêmes que celles nécessaires à un réseau dans la région primaire.
  • Les réseaux virtuels n’ont pas besoin d’être appairés dans les différentes régions.

Important

Quand elle est configurée en mode réseau virtuel interne, chaque passerelle régionale doit également disposer d’une connectivité sortante sur le port 1433 vers la base de données Azure SQL configurée pour votre instance Gestion des API, qui se trouve seulement dans la région primaire. Assurez-vous d’autoriser la connectivité au nom de domaine complet ou à l’adresse IP de cette base de données Azure SQL dans les itinéraires ou les règles de pare-feu configurés pour les réseaux dans vos régions secondaires. L’étiquette de service Azure SQL ne peut pas être utilisée dans ce scénario. Pour trouver le nom de la base de données Azure SQL dans la région primaire, accédez à la page Réseau>État du réseau de votre instance Gestion des API dans le portail.

Adresses IP

  • Une adresse IP virtuelle publique est créée dans chaque région ajoutée avec un réseau virtuel. Pour les réseaux virtuels en mode externe ou en mode interne, cette adresse IP publique est utilisée pour le trafic de gestion sur le port 3443.

    • Mode Réseau virtuel externe : Les adresses IP publiques sont également nécessaires pour router le trafic HTTP public vers les passerelles API.

    • Mode Réseau virtuel interne : Une adresse IP privée est également créée dans chaque région ajoutée avec un réseau virtuel. Utilisez ces adresses pour vous connecter au sein du réseau aux points de terminaison Gestion des API dans les régions primaires et secondaires.

Routage

  • Mode Réseau virtuel externe : Le routage du trafic HTTP public vers les passerelles régionales est automatiquement géré, de la même façon que pour une instance Gestion des API non mise en réseau.

  • Mode Réseau virtuel interne : Le trafic HTTP privé n’est pas routé ni équilibré en charge vers les passerelles régionales par défaut. Les utilisateurs sont propriétaires du routage et se chargent d’apporter leur propre solution pour gérer le routage et l’équilibrage de charge privé dans toutes les régions.

Étapes suivantes