Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Créer des déploiements multirégionaux pour API Gateway

Ce tutoriel vous explique comment configurer un équilibreur de charge HTTP(S) pour activer les déploiements multirégionaux pour API Gateway.

Important : Vous ne pouvez pas configurer des déploiements multirégionaux pour les passerelles avec un effectiveStreamingMode de EFFECTIVE_STREAMING_MODE_ENABLED à l'aide de cette méthode, car elles sont incompatibles avec l'équilibrage de charge HTTP(S) pour API Gateway et les NEG sans serveur pendant la version Preview publique.

La création d'un équilibreur de charge HTTP(S) pour prendre en charge les déploiements multirégionaux d'API Gateway peut améliorer la disponibilité et réduire la latence de votre service en le diffusant à partir de plusieurs régions. Vous pouvez réduire davantage la latence et maximiser le temps d'activité grâce au routage multirégion, qui traite les requêtes à partir de la région disponible la plus proche de votre utilisateur.

Pour les besoins de ce tutoriel, vous allez configurer un schéma d'URL unique et non régional qui fonctionne partout dans le monde, mais qui répond aux requêtes des utilisateurs depuis le déploiement API Gateway le plus proche. Avec cette configuration, les requêtes sont idéalement acheminées vers la région qui offre une latence minimale à l'utilisateur. Si la région la plus proche n'est pas disponible ou est saturée, la requête est acheminée vers une autre région pour garantir la disponibilité.

Avant de commencer

Avant de configurer votre déploiement multirégion, suivez le guide de démarrage rapide API Gateway pour déployer un service Cloud Run et créer une passerelle pointant vers ce service.

Pour ce tutoriel, déployez votre service dans deux régions différentes. Par exemple, vous pouvez déployer deux instances API Gateway :

my-gateway-eu vers une région en Europe
my-gateway-us vers une région des États-Unis

Configurer les autorisations

Dans ce tutoriel, vous allez créer un groupe de points de terminaison du réseau (NEG) sans serveur et un équilibreur de charge HTTP(S) externe dans un projet Cloud. Cette opération nécessite un rôle de propriétaire ou d'éditeur de projet, ou les rôles IAM Compute Engine suivants :

Tâche	Rôle requis
Créer des composants d'équilibrage de charge et de mise en réseau	Administrateur réseau
Créer et modifier des NEG	Administrateur d'instances Compute
Créer et modifier des certificats SSL	Administrateur de sécurité

Créer une ressource de certificat SSL

Pour créer un équilibreur de charge HTTPS, une ressource de certificat SSL doit être ajoutée à l'interface de l'équilibreur de charge. Créez une ressource de certificat SSL à l'aide d'un certificat SSL géré par Google ou d'un certificat SSL autogéré.

Certificats gérés par Google. L'utilisation de certificats gérés par Google est recommandée, car Google Cloud obtient, gère et renouvelle automatiquement ces certificats. Pour créer un certificat géré par Google, vous devez disposer d'un domaine et d'enregistrements DNS pour ce domaine afin que le certificat soit provisionné. Si vous ne possédez pas encore de domaine, vous pouvez en obtenir un auprès de Google Domains. De plus, vous devrez mettre à jour l'enregistrement DNS A du domaine pour qu'il pointe vers l'adresse IP de l'équilibreur de charge créée lors d'une étape ultérieure. Pour obtenir des instructions détaillées, consultez Utiliser des certificats gérés par Google.
Certificats autosignés. Si vous ne souhaitez pas configurer un domaine à ce stade, vous pouvez utiliser un certificat SSL autosigné pour les tests.

Pour cet tutoriel, nous partons du principe que vous avez déjà créé une ressource de certificat SSL.

Si vous souhaitez tester ce processus sans créer de ressource de certificat SSL (ou de domaine comme requis par les certificats gérés par Google), vous pouvez toujours utiliser les instructions de cette page pour configurer un équilibreur de charge HTTP.

Créer l'équilibreur de charge HTTP ou HTTPS

Créez un NEG sans serveur pour chaque instance API Gateway.

Un groupe de points de terminaison du réseau (NEG) spécifie un groupe de points de terminaison backend pour un équilibreur de charge. Un NEG sans serveur est un backend qui pointe vers un service tel qu'API Gateway, comme illustré dans la figure suivante :

Pour créer un NEG sans serveur pour chaque instance de passerelle, exécutez la commande suivante, où :
- SERVERLESS_NEG_NAME est le nom du NEG sans serveur à créer.
- GATEWAY_ID spécifie le nom de la passerelle.
- REGION_ID correspond à la région de déploiement du NEG sans serveur (elle doit correspondre à la région de la passerelle).
```
gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID
```
Exemple :
```
gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway-eu
```
Répétez cette commande pour créer un NEG sans serveur pour la prochaine instance de passerelle, en utilisant les valeurs appropriées pour la deuxième instance de passerelle (par exemple, api-gateway-serverless-neg-us pour my-gateway-us dans la région us-central1).
Créez un service de backend pour définir la manière dont Cloud Load Balancing répartit le trafic.

La configuration de service de backend contient un ensemble de valeurs, telles que le protocole utilisé pour se connecter aux backends, divers paramètres de distribution et de session, des vérifications de l'état et des délais avant expiration, comme illustré dans la figure suivante :

Pour créer un service de backend et ajouter votre NEG sans serveur en tant que backend au service de backend, exécutez les commandes suivantes, où :
- BACKEND_SERVICE_NAME est le nom de votre service de backend.
- SERVERLESS_NEG_NAME correspond au nom du NEG sans serveur créé à l'étape précédente.
- REGION_ID correspond à la région de déploiement du NEG sans serveur (elle doit correspondre à la région de la passerelle).
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --global \ 
```
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \ 
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID
```
Exemple :
```
gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg-eu \
  --network-endpoint-group-region=europe-west1
```
Répétez cette commande pour ajouter le deuxième NEG sans serveur au service de backend, en utilisant les valeurs appropriées pour le deuxième NEG sans serveur, par exemple api-gateway-serverless-neg-us pour my-gateway-us dans la région us-central1.
Créez un mappage d'URL pour acheminer les requêtes entrantes vers le service de backend, comme illustré dans la figure suivante :

Pour créer le mappage d'URL, exécutez la commande suivante, où :
- URL_MAP_NAME est le nom du mappage d'URL à créer.
- BACKEND_SERVICE_NAME est le nom de votre service de backend.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
Exemple :
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
Cet exemple de mappage d'URL ne cible qu'un seul service de backend représentant une seule passerelle. Les règles d'hôte ou les outils de mise en correspondance des chemins d'accès ne sont donc pas nécessaires. Si vous disposez de plusieurs service de backend, vous pouvez utiliser des règles d'hôte pour acheminer les requêtes vers différents services en fonction du nom d'hôte. Utilisez des outils de mise en correspondance des chemins d'accès pour diriger les requêtes vers différents services en fonction du chemin d'accès des requêtes.

Exemple :
```
gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2 \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
```
```
gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher
```
Pour en savoir plus sur les règles d'hôte et les outils de mise en correspondance des chemins d'accès, consultez la documentation sur les mappages d'URL.
Créez un certificat SSL pour votre proxy cible, comme illustré dans la figure suivante :

Pour créer un équilibreur de charge HTTPS, une ressource de certificat SSL est requise pour le proxy cible HTTPS. Vous pouvez créer une ressource de certificat SSL à l'aide d'un certificat SSL géré par Google ou d'un certificat SSL autogéré. Nous vous recommandons d'utiliser des certificats gérés par Google.

Pour créer un certificat géré par Google, vous devez disposer d'un domaine. Si vous ne détenez pas de domaine, vous pouvez utiliser un certificat SSL autosigné pour les tests.

Pour créer une ressource de certificat SSL géré par Google, procédez comme suit :
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
Pour créer une ressource de certificat SSL autogéré, procédez comme suit :
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH
```
Créez un proxy HTTP(S) cible pour rediriger les requêtes vers votre mappage d'URL, comme illustré dans la figure suivante :

Pour créer le proxy cible, utilisez la commande suivante, où :
- TARGET_HTTP_PROXY_NAME est le nom du proxy cible à créer.
- URL_MAP_NAME est le nom du mappage d'URL créé à une étape précédente.
- (Facultatif) SSL_CERT_NAME correspond au nom du certificat SSL créé.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME
```
Exemple :
```
gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map
```
Créez une règle de transfert pour acheminer les requêtes entrantes vers le proxy, comme illustré dans la figure suivante :

Utilisez la commande suivante pour créer la règle de transfert, où :
- HTTPS_FORWARDING_RULE_NAME est le nom de la règle à créer.
- TARGET_HTTP_PROXY_NAME est le nom du proxy cible à créer.
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
Exemple :
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

Mettre à jour les enregistrements DNS avec l'adresse IP de l'équilibreur de charge

Si vous disposez d'un domaine personnalisé, cette étape est nécessaire pour configurer les paramètres DNS de votre domaine afin qu'il pointe vers la nouvelle adresse IP de votre service. Il est également requis si vous avez créé un équilibreur de charge HTTP(S) avec un certificat géré par Google (qui nécessite un domaine). Il est recommandé d'allouer et d'utiliser une adresse IP statique avec le DNS. Les instructions spécifiques pour cette étape dépendent de votre fournisseur DNS.

Pour envoyer du trafic vers l'équilibreur de charge, l'enregistrement DNS de votre domaine (my-app-domain dans ce tutoriel) doit pointer vers la ou les adresses IP de l'équilibreur de charge.

Pour trouver l'adresse IP de votre règle de transfert globale, utilisez la commande suivante :
```
gcloud compute forwarding-rules list
```
Mettez à jour l'enregistrement A ou AAAA DNS de votre domaine pour qu'il pointe vers l'adresse IP de l'équilibreur de charge. Le trafic envoyé à l'URL de domaine personnalisé existante sera ainsi acheminé via l'équilibreur de charge. La propagation de cette modification au serveur DNS peut prendre de quelques secondes à plusieurs heures.
Vérifiez que votre passerelle reçoit du trafic à l'aide de curl ou en accédant à l'URL dans votre navigateur. Exemple : none https://my-app-domain.

La réponse générée par le service Cloud Run devrait s'afficher. Par exemple, il peut s'agir d'une page HTML "Hello World" ou d'une autre réponse attendue générée directement par le service de backend. Cela signifie que votre requête transite par l'équilibreur de charge, et que le service de backend demande à l'équilibreur de charge de l'envoyer à votre passerelle.

Remarques

Avant de mettre en œuvre un déploiement multirégional d'API Gateway, tenez compte des points suivants :

API Gateway n'est pas compatible avec les vérifications de l'état. Avec la configuration de routage multirégionale décrite précédemment, si votre passerelle ou son service de backend renvoient des erreurs dans une région, mais que l'infrastructure API Gateway globale de la région est disponible et dispose de capacité, votre équilibreur de charge HTTP(S) ne redirigera pas le trafic vers d'autres régions.
Pour combiner différentes régions dans une même règle de transfert, vous devez utiliser la tarification du niveau Premium. Pour en savoir plus sur le calcul des tarifs et de l'utilisation, consultez les tarifs des niveaux de service réseau.

Bonnes pratiques

Lorsque vous utilisez la diffusion multirégionale, nous vous recommandons d'utiliser une solution de stockage de données gérée et répliquée à l'échelle mondiale, telle que Cloud Spanner, pour vous assurer que toutes les données sont gérées à l'échelle mondiale.