Cette page a été traduite par l'API Cloud Translation.

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

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

Créer 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 depuis plusieurs régions. Vous pouvez réduire davantage la latence et maximiser la disponibilité grâce au routage interrégional, qui diffuse 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, non régional, qui fonctionne partout dans le monde, mais qui répond aux requêtes des utilisateurs à partir du déploiement d'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 est indisponible ou dépasse sa capacité, la requête est acheminée vers une autre région pour assurer la disponibilité.

Avant de commencer

Avant de configurer votre déploiement multirégional, suivez le guide de démarrage rapide d'API Gateway pour déployer un service Cloud Run et créer une passerelle qui pointe 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 vous. 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 devez mettre à jour l'enregistrement DNS A du domaine pour qu'il pointe vers l'adresse IP de l'équilibreur de charge créée à 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(S)

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 ci-dessous :

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 est 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 façon dont Cloud Load Balancing répartit le trafic.

La configuration du service de backend contient un ensemble de valeurs, telles que le protocole utilisé pour se connecter aux backends, divers paramètres de répartition et de gestion des sessions, les vérifications d'état et les délais avant expiration, comme illustré à la figure ci-dessous :

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 est le nom du NEG sans serveur créé à l'étape précédente.
- REGION_ID est 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é à la figure ci-dessous :

Pour créer le mappage d'URL, exécutez la commande suivante, où :
- URL_MAP_NAME correspond au 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. Vous n'avez donc pas besoin de règles d'hôte ni d'outils de mise en correspondance des chemins d'accès. 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 de chemins d'accès, consultez la documentation sur le mappage d'URL.
Créez un certificat SSL pour votre proxy cible, comme illustré dans la figure ci-dessous :

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 acheminer les requêtes vers votre mappage d'URL, comme illustré dans la figure ci-dessous :

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éé à l'étape précédente.
- Facultatif : SSL_CERT_NAME est le 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 ci-dessous :

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. Elle est également obligatoire si vous avez créé un équilibreur de charge HTTP(S) avec un certificat géré par Google (qui requiert un domaine). Il est recommandé d'allouer et d'utiliser une adresse IP statique lorsque vous utilisez le DNS. Les instructions spécifiques à cette étape dépendent de votre fournisseur DNS.

Pour envoyer du trafic à l'équilibreur de charge, l'enregistrement DNS de votre domaine (dans ce tutoriel, "mon-domaine-d'application") 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 DNS A ou AAAA de votre domaine pour qu'il pointe vers l'adresse IP de l'équilibreur de charge afin que le trafic envoyé vers l'URL de domaine personnalisé existant soit acheminé via l'équilibreur de charge. La propagation de cette modification au serveur DNS peut prendre aussi peu que quelques secondes ou 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 : https://my-app-domain.

Lors des tests, vous devriez voir la réponse générée par le service Cloud Run. Il peut s'agir, par exemple, 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 passe par l'équilibreur de charge, et que le service de backend lui demande 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 actuellement pas compatible avec les vérifications de l'état. Avec la configuration de routage interrégional décrite ci-dessus, si votre passerelle ou son service de backend renvoie des erreurs dans une région, mais que l'infrastructure API Gateway globale de la région est disponible et dispose de la capacité nécessaire, votre équilibreur de charge HTTP(S) ne redirigera pas le trafic vers d'autres régions.
La combinaison de différentes régions dans une même règle de transfert nécessite le niveau Premium. Pour en savoir plus sur le calcul des tarifs et de l'utilisation, consultez la page 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 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.