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.

La création d'un équilibreur de charge HTTP(S) pour prendre en charge les déploiements d'API Gateway dans plusieurs régions peut améliorer la disponibilité et réduire la latence de votre service en diffusant vos annonces à partir de plusieurs régions. Vous pouvez réduire davantage la latence et maximiser le temps d'activité grâce au routage interrégional, qui traite les requêtes depuis 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 traite les requêtes des utilisateurs à partir du 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 est indisponible ou en surcapacité, 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égional, suivez le guide de démarrage rapide de la passerelle API 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 d'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 réseau HTTP(S) 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, un 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éé lors d'une étape ultérieure. Pour obtenir des instructions détaillées, consultez l'article Utiliser des clés de sécurité gérées par Google certificats.
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 de passerelle API.

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 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 diriger les requêtes vers des services différents 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 de la requête.

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, Certificat SSL ressource 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éé à une é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'ils pointent 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 en cas d'utilisation avec DNS. Les instructions spécifiques à cette étape dépendent de votre fournisseur DNS.

Pour envoyer du trafic vers l'équilibreur de charge, l'enregistrement DNS de votre domaine (dans ce tutoriel, mon-domaine-appli) 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.
Effectuez un test pour vérifier que votre passerelle reçoit du trafic en utilisant 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'un message "Hello World". une page HTML ou 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 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 actuellement pas compatible avec les vérifications d'état. Avec la configuration de routage interrégional décrite ci-dessus, si votre passerelle ou son service 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.
Les tarifs du niveau Premium sont nécessaires pour combiner différentes régions dans une même règle de transfert. Pour plus d'informations 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 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.