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

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é, si cette région la prend en charge. Par défaut, Gestion des API configure automatiquement les zones de disponibilité pour la région ajoutée, ce qui est recommandé. Vous pouvez également configurer manuellement des zones de disponibilité pour la région ajoutée.
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.

Important

Les modifications apportées à l’infrastructure de votre service Gestion des API (telles que la configuration de domaines personnalisés, l’ajout de certificats d’autorité de certification, la mise à l’échelle, la configuration du réseau virtuel, les modifications de zone de disponibilité et les ajouts de régions) peuvent prendre 15 minutes ou plus, en fonction du niveau de service et de la taille du déploiement. Attendez-vous à des temps plus longs pour une instance avec un plus grand nombre d’unités d’échelle ou de configuration multirégion. Les modifications propagées apportées à Gestion des API sont exécutées avec soin pour préserver la capacité et la disponibilité.

Pendant la mise à jour du service, d’autres modifications de l’infrastructure de service ne peuvent pas être apportées. Toutefois, vous pouvez configurer des API, des produits, des stratégies et des paramètres utilisateur. Le service n’aura pas de temps d’arrêt de passerelle et Gestion des API continuera à traiter les demandes d’API sans interruption (sauf dans le niveau Développeur).

À 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.
Si elles sont configurées, les politiques de limitation de débit et de limitation de débit par clé comptabilisent les appels séparément à chaque passerelle régionale du déploiement. Les stratégies n’agrègent pas toutes les données d’appel pour l’instance. De même, les stratégies azure-openai-token-limit et llm-token-limit comptent l’utilisation des jetons séparément à chaque passerelle régionale dans le déploiement.

Prérequis

Comprenez soigneusement toutes les exigences et considérations relatives à l’activation du déploiement multirégion dans Gestion des API.
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

Dans le portail Azure, accédez à votre service Gestion des API, puis sélectionnez Emplacements dans le menu gauche.
Sélectionnez + Ajouter dans la barre supérieure.
Sélectionnez l’emplacement ajouté dans la liste déroulante.
Sélectionnez le nombre d’ Unités d’échelle dans l’emplacement.
Si la région prend en charge les zones de disponibilité, laissez le paramètre automatique (recommandé) ou sélectionnez éventuellement une ou plusieurs zones. Si vous sélectionnez des zones spécifiques, le nombre d’unités que vous sélectionnez doit être réparti uniformément entre les zones de disponibilité. Par exemple, si vous sélectionnez trois unités, vous devez sélectionner trois zones afin que chaque zone héberge une unité.
Si l’instance Gestion des API est déployée dans un réseau virtuel, configurez les paramètres de réseau virtuel à l’emplacement, y compris le réseau virtuel, le sous-réseau et l’adresse IP publique.
Sélectionnez Ajouter pour confirmer.
Répétez cette procédure jusqu’à ce que vous configuriez tous les emplacements.
Sélectionnez Enregistrer dans la barre supérieure pour démarrer le processus de déploiement.

Supprimer une région de service Gestion des API

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

Acheminer les appels d’API vers les services principaux régionaux

Par défaut, chaque API achemine les demandes vers une URL de service principal unique. Même si vous configurez des passerelles Gestion des API dans différentes régions, la passerelle d’API transfère toujours les requêtes au même service back-end, qui est déployé dans une seule région. Dans ce cas, les performances améliorées proviennent uniquement des réponses mises en cache dans Gestion des API dans une région spécifique à la requête. Le fait de contacter le serveur principal à travers le monde peut encore entraîner une latence élevée.

Pour tirer parti de la distribution géographique de votre système, vous devez déployer des services back-end dans les mêmes régions que les instances gestion des API. Ensuite, en utilisant des stratégies et la @(context.Deployment.Region) propriété, vous pouvez router le trafic vers des instances locales de votre back-end.

Accédez à votre instance Gestion des API et sélectionnez LES API dans le menu de gauche.
Sélectionnez l’API souhaitée.
Sous l’onglet Création , dans la section Traitement entrant , sélectionnez Éditeur de code.

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 fronter vos services back-end avec Azure Traffic Manager, diriger les appels d’API vers Traffic Manager et le laisser résoudre automatiquement le routage.

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 les passerelles régionales d'API Management

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.

Créez votre propre Traffic Manager.
Si vous utilisez un domaine personnalisé, utilisez-le avec Traffic Manager au lieu du service Gestion des API.
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.
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.
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 avoir ajouté une nouvelle région, pour la conserver désactivée pendant que vous configurez et testez le service principal 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 de création ou de mise à jour du service , de la commande az apim update dans Azure CLI, de l’applet de commande Azure PowerShell set-azapimanagement ou d’autres outils Azure.

Important

Vous pouvez uniquement définir la propriété pour désactiver le disableGateway routage vers une passerelle régionale lorsque vous utilisez le routage par défaut dans Gestion des API, et non une solution de routage personnalisée.
Vous ne pouvez pas définir la propriété pour désactiver le disableGateway routage vers une passerelle régionale lorsque l’instance Gestion des API est déployée dans un réseau virtuel en mode interne. Dans ce cas, vous devez gérer le routage et l’équilibrage de charge entre plusieurs régions vous-même.

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

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

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
```
La mise à jour peut prendre quelques minutes.
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é, telles que les règles de groupe de sécurité réseau requises pour un réseau virtuel dans une région ajoutée, sont généralement identiques aux exigences d’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

Lorsque vous configurez votre instance Gestion des API pour utiliser le mode de 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 uniquement dans la région primaire . Vérifiez que vous autorisez la connectivité au nom de domaine complet (FQDN) ou à l’adresse IP de cette base de données Azure SQL dans les itinéraires ou règles de pare-feu que vous configurez pour les réseaux de vos régions secondaires ; Le point de terminaison de service Azure SQL ne peut pas être utilisé 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 de réseau virtuel externe : Les adresses IP publiques sont également requises pour acheminer le trafic HTTP public vers les passerelles d’API.
- Mode de 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 de réseau virtuel externe : Le routage du trafic HTTP public vers les passerelles régionales est géré automatiquement, de la même façon que pour une instance de gestion des API sans réseau.
Mode de réseau virtuel interne : Le trafic HTTP privé n’est pas routé ou é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.

En savoir plus sur la fiabilité dans Gestion des API
En savoir plus sur l’activation de la prise en charge des zones de disponibilité pour une instance Gestion des API.
Pour plus d’informations sur les réseaux virtuels et Gestion des API, consultez :

Rétroaction

Cette page vous a-t-elle été utile ?

Last updated on 2025-09-19

Partager via

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

À propos du déploiement multirégion

Prérequis

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

Supprimer une région de service Gestion des API

Acheminer les appels d’API vers les services principaux régionaux

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

Utiliser le routage personnalisé vers les passerelles régionales d'API Management

Désactiver le routage vers une passerelle régionale

Réseau virtuel

Adresses IP

Routage

Contenu connexe

Rétroaction

Ressources additionnelles