Étendre Apigee dans plusieurs régions

Cette page s'applique à Apigee, mais pas à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

Vous pouvez étendre une organisation Apigee à plusieurs régions. L'expansion multirégionale permet les améliorations dans les domaines suivants :

Haute disponibilité : en cas de défaillance d'une région, le trafic peut toujours être diffusé par les régions restantes, ce qui augmente la disponibilité globale de vos API.
Haute capacité: des régions supplémentaires fournissent une capacité supplémentaire pour diffuser votre trafic d'API, et offrent une capacité supplémentaire en cas de pic de trafic inattendu, sans augmenter la pression sur un seul environnement, ce qui augmente la capacité globale de vos API.
Faible latence: des régions supplémentaires peuvent réduire la latence de transaction globale pour les clients en diffusant leurs requêtes dans une région géographiquement plus proche.

Ce document explique comment ajouter Apigee à une nouvelle région et comment supprimer Apigee d'une région.

Ajouter Apigee à une nouvelle région

Vous pouvez avoir une instance d'exécution par région. Par conséquent, pour ajouter une nouvelle région, vous devez créer une instance entièrement nouvelle dans cette région.

Le processus général d'ajout d'une nouvelle région est le suivant :

Vérifiez que votre réseau d'appairage dispose d'une plage d'adresses IP appropriée, comme décrit dans la section Prérequis. Assurez-vous également que votre compte peut accepter une nouvelle région, comme décrit dans la section Limites.
Définir des variables d'environnement
Créer un trousseau de clés et une clé
Réserver une nouvelle plage d'adresses
Créer une instance
Associer des environnements à la nouvelle instance
Configurer le routage

Toutes ces étapes sont décrites plus en détail dans les sections suivantes.

Prérequis

Vérifiez que votre réseau dispose de plages d'adresses IP /22 et /28 sans chevauchement, en plus des plages utilisées par d'autres régions.

Limites

Par défaut, votre organisation initiale est généralement créée avec une seule région. Lorsque vous décidez de créer une deuxième région (ou une autre région), notez que vous ne pouvez l'ajouter que si vos droits de licence vous y autorisent. Si vous le souhaitez, vous pouvez acheter un pack d'organisation.

Si vous disposez d'un modèle de tarification par abonnement, vous devrez peut-être acheter des unités organisationnelles supplémentaires pour autoriser l'expansion dans plusieurs régions. Pour en savoir plus, consultez Droits d'abonnement.
Si vous disposez d'un modèle de paiement à l'usage, l'expansion dans plusieurs régions entraîne des coûts supplémentaires, comme expliqué dans la section Ajouter des régions pour le paiement à l'usage.
Les comptes d'évaluation sont limités à une région et ne peuvent pas être étendus à une deuxième région.

Pour en savoir plus, consultez la section Présentation du paiement à l'usage.

Aucune organisation ne peut posséder plus de 10 régions (11 pour les environnements hybrides).

Définir des variables d'environnement

Nous vous recommandons de définir les variables d'environnement suivantes pour assurer la cohérence entre les différentes commandes utilisées tout au long de cette documentation.

export NEW_REGION_LOCATION="NEW_REGION_LOCATION"
export NEW_INSTANCE_NAME="NEW_INSTANCE_NAME"
export NETWORK_NAME"=NETWORK_NAME"
export DISK_KEY_RING_NAME="YOUR_DISK_KEY_RING_NAME"
export DISK_KEY_NAME="YOUR_DISK_KEY_NAME"
export PROJECT_ID=YOUR_PROJECT_ID
export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

Où :

NEW_REGION_LOCATION est l'emplacement physique de votre nouvelle instance. Les valeurs valides sont toutes les régions Compute Engine. Pour en savoir plus, consultez la page Régions et zones. Exemple : us-west1
NEW_INSTANCE_NAME est le nom de la nouvelle région. Il doit être unique dans votre organisation. Par exemple, my-instance-2.
NETWORK_NAME est le nom du réseau d'appairage de votre organisation. Par exemple, my-network. Consultez la section Configurer la mise en réseau des services.
DISK_KEY_RING_NAME correspond au nom du trousseau de clés de disque.
DISK_KEY_NAME correspond au nom du trousseau de disques.
AUTH définit l'en-tête Authentication avec un jeton de support. Vous utiliserez cet en-tête lors de l'appel des API Apigee. Notez que le jeton expire après un certain temps. Si c'est le cas, il vous suffit de le générer à nouveau en exécutant la même commande. Pour en savoir plus, consultez la page de référence sur la commande print-access-token.
PROJECT_ID est votre ID de projet cloud.
PROJECT_NUMBER est le numéro de projet de votre projet Cloud.

Créer un trousseau de clés et une clé

Chaque région nécessite sa propre clé de chiffrement de disque pour le réseau. Nous vous recommandons également de créer un trousseau de clés distinct pour la nouvelle région. Vous n'avez pas besoin de créer une nouvelle clé de chiffrement de base de données, car toutes les instances d'une organisation partagent la même clé.

Pour en savoir plus, consultez la section À propos des clés de chiffrement Apigee.

Pour créer un trousseau de clés et une clé de chiffrement de disque :

Créez un trousseau de clés de disque à l'aide de la commande gcloud :

gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

Vérifiez que le trousseau de clés du disque est défini sur le même emplacement que l'instance. Chaque instance et chaque trousseau de clés doit avoir son propre emplacement.

gcloud kms keyrings list \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keyrings describe $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

Créez une clé de disque à l'aide de la commande kms keys create. Exemple :

gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

La clé peut être référencée par son chemin d'accès de clé. Vous pouvez l'obtenir à l'aide de la commande suivante :

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

Le chemin d'accès de la clé se présente comme suit :

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

Accordez à l'agent de service Apigee l'accès à la nouvelle clé en exécutant la commande gcloud kms keys add-iam-policy-binding. Exemple :

gcloud kms keys add-iam-policy-binding $DISK_KEY_NAME \
  --location $NEW_REGION_LOCATION \
  --keyring $DISK_KEY_RING_NAME \
  --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com \
  --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
  --project $PROJECT_ID

Vérifiez que la clé est liée à l'agent de service Apigee.

gcloud kms keys get-iam-policy $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keys describe $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

Réserver une nouvelle plage d'adresses

Réservez des adresses IP pour la plage d'adresses de votre réseau d'appairage. Pour plus d'informations et des considérations importantes, consultez également la section Comprendre les plages d'appairage.

Créez les variables d'environnement suivantes :
```
NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME
```
Où :
- NEW_RANGE_NAME_22 est le nom de la plage d'adresses IP de longueur CIDR /22 que vous allez créer. Vous pouvez donner le nom que vous voulez à la plage. Par exemple : google-svcs-new_22.
- NEW_RANGE_NAME_28 correspond au nom de la plage d'adresses IP de longueur CIDR /28 que vous allez créer. Vous pouvez donner le nom que vous voulez à la plage. Par exemple : google-svcs-new_28.
- NETWORK_NAME est le nom de la ressource réseau dans laquelle les adresses doivent être réservées.
  Google crée un réseau par défaut (nommé default) pour chaque nouveau projet afin que vous puissiez l'utiliser. Toutefois, Google ne recommande d'utiliser le réseau par défaut que pour effectuer des tests.
  
  Remarque : Nous vous déconseillons d'utiliser default, sauf si vous testez ce processus de configuration. Vous ne devez pas utiliser une organisation avec un réseau par défaut en production.

Créez une plage d'adresses IP réseau avec une longueur CIDR de /22 :

gcloud compute addresses create $NEW_RANGE_NAME_22 \
  --global \
  --prefix-length=22 \
  --description="Peering range for Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

En cas de réussite, gcloud renvoie la réponse suivante :

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs-new].

Validez l'adresse de calcul créée :

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

gcloud compute addresses describe $NEW_RANGE_NAME_22 \
  --global \
  --project=$PROJECT_ID

Une fois que vous avez créé une plage d'adresses IP, les adresses sont associées au projet jusqu'à leur publication.

Créez une plage d'adresses IP réseau avec une longueur CIDR de /28 : Cette plage est obligatoire. Elle est utilisée par Apigee à des fins de dépannage et ne peut être ni personnalisée ni modifiée.

gcloud compute addresses create $NEW_RANGE_NAME_28 \
  --global \
  --prefix-length=28 \
  --description="Peering range for supporting Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

Validez l'adresse de calcul créée :

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

 gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID

Obtenez les noms des plages d'appairage :

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

Ajoutez les plages nouvellement réservées à votre réseau appairé avec la commande suivante, où $NEW_RANGE_NAME_22 et $NEW_RANGE_NAME_28 sont les nouveaux noms de plages, et ORIGINAL_RANGE_NAME_1 et ORIGINAL_RANGE_NAME_n sont les noms de plage d'appairage réservée renvoyés dans la commande précédente :
```
gcloud services vpc-peerings update --service=servicenetworking.googleapis.com \
  --network=$NETWORK_NAME \
  --ranges=$NEW_RANGE_NAME_22,$NEW_RANGE_NAME_28,ORIGINAL_RANGE_NAME_1,ORIGINAL_RANGE_NAME_n \
  --project=$PROJECT_ID
```

Validez les modifications de l'appairage vpc qui ont été mises à jour:

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

Créez une instance.

Créez une instance pour la région à l'aide de l'API Instances.

Avec appairage de VPC

Si Apigee a été configuré pour utiliser l'appairage de VPC, utilisez cet appel d'API pour créer l'instance :

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$NEW_INSTANCE_NAME"'",
    "location":"'"$NEW_REGION_LOCATION"'",
    "diskEncryptionKeyName":"KEY_PATH",
    "ipRange":"IP_ADDRESS_1/28, IP_ADDRESS_2/22"  # OPTIONAL
  }'

Où :

KEY_PATH correspond au chemin d'accès de la clé de chiffrement de disque que vous avez créée dans la section Créer un trousseau de clés et une clé.
IP_ADDRESS_* correspond aux adresses IP CIDR des plages CIDR /22 et /28 utilisées pour créer l'instance Apigee. Notez que ipRange est facultatif. Si vous ne fournissez pas ce champ, Apigee demande automatiquement un bloc CIDR /22 et /28 disponible à Service Networking. Voir aussi API des instances Apigee.

Cette requête peut prendre jusqu'à 20 minutes, car Apigee doit créer et lancer un nouveau cluster Kubernetes, installer les ressources Apigee sur ce cluster et configurer l'équilibrage de charge.

Sans appairage de VPC

Si Apigee n'est pas configuré pour utiliser l'appairage de VPC, utilisez cet appel d'API pour créer l'instance :

curl -X POST -H "$AUTH" \
  -H "Content-Type:application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$INSTANCE_NAME"'",
    "location":"'"$RUNTIME_LOCATION"'",
    "diskEncryptionKeyName":"'"KEY_PATH"'",
    "consumerAcceptList":[ARRAY_OF_PROJECT_IDS]
  }'

Où :

KEY_PATH correspond au chemin d'accès de la clé de chiffrement de disque que vous avez créée dans la section Créer un trousseau de clés et une clé. Voir aussi API des instances Apigee.
consumerAcceptList(Facultatif) Spécifie une liste d'ID de projet Google Cloud pouvant se connecter en privé au rattachement de service du VPC Apigee. Le rattachement de service est une entité utilisée avec Private Service Connect de Google Cloud pour permettre aux producteurs de services (dans ce cas, Apigee) d'exposer des services aux consommateurs (dans ce cas, un ou plusieurs projets Cloud que vous possédez). Par défaut, nous utilisons le projet Cloud qui est déjà associé à votre organisation Apigee. Par exemple : "consumerAcceptList": ["project1", "project2", "project3"]

Cette requête peut prendre jusqu'à 20 minutes, car Apigee doit créer et lancer un nouveau cluster Kubernetes, installer les ressources Apigee sur ce cluster et configurer l'équilibrage de charge.

Localiser le chemin d'accès de la clé

Vous pouvez l'obtenir à l'aide de la commande suivante :

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

Le chemin d'accès de la clé se présente comme suit :

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

timer L'opération de création d'instance prend environ 30 minutes.

Pour vérifier l'état de votre requête de création d'instance d'exécution, exécutez la commande suivante. Lorsque l'état est ACTIF, vous pouvez passer à l'étape suivante.

curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME"

Pour en savoir plus sur la création d'une instance d'exécution, y compris obtenir des informations supplémentaires sur le contexte et le dépannage, consultez la section Étape 5 : Créez une instance d'exécution Apigee.

Associer des environnements à la nouvelle instance

Une fois l'instance créée, vous devez lui associer des environnements. Sinon, elle ne peut pas répondre aux requêtes API.

Les environnements sont partagés entre les instances. Par conséquent, vous devriez associer des environnements existants à la nouvelle région. Vous ne définissez pas de nouveaux environnements pour la nouvelle région. Si vous définissez un nouvel environnement pour la nouvelle région qui diffuse le trafic via les mêmes chemins de base pour les mêmes hôtes que votre environnement d'origine, vos appels d'exécution peuvent renvoyer des erreurs HTTP 503.

Lorsque vous ajoutez des environnements à une nouvelle région, vous n'avez pas besoin de les associer à des groupes d'environnements. Ils sont déjà associés à leurs groupes. Il vous suffit d'associer les environnements à la nouvelle instance.

Pour associer vos environnements à la nouvelle région, utilisez l'API Instances Attachment comme indiqué dans l'exemple suivant :

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME/attachments \
  -d '{
    "environment":"ENVIRONMENT_NAME"
  }'

Pour obtenir la liste de vos environnements, procédez comme suit :

curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/environments"

Vous devez associer chaque environnement avec un appel distinct à l'API Instances Attachment. Vous ne pouvez pas associer plusieurs environnements dans un seul appel.

Configurer le routage

Vous pouvez configurer le routage réseau dans la nouvelle région à l'aide d'une configuration basée sur un groupe d'instances géré (MIG) ou sur Private Service Connect (PSC).

Configurer le routage PSC

La procédure suivante explique comment configurer le routage dans la nouvelle région en utilisant PSC.

Présentation

La figure suivante montre l'architecture de haut niveau Northbound pour l'architecture PSC multirégionale :

Schéma de routage PSC multirégional

Figure 1 : Architecture multirégionale Northbound avec PSC

Comme le montre la figure 1, vous allez créer dans votre projet un groupe de points de terminaison du réseau (NEG, "Network Endpoint Group") qui communique avec un rattachement de service situé dans la région où se trouve la nouvelle instance Apigee. Les NEG Apigee de toutes les régions sont connectés au service de backend de votre équilibreur de charge externe global Apigee de production.

(Facultatif) Effectuer un test avec un équilibreur de charge temporaire

Avant de continuer, vous souhaiterez peut-être tester la nouvelle instance en configurant un équilibreur de charge (LB) temporaire et un NEG pour communiquer avec Apigee dans votre nouvelle région. Après avoir envoyé le trafic de l'API avec succès vers l'équilibreur de charge de test, vous pouvez supprimer l'équilibreur de charge temporaire et connecter le NEG au service de backend de votre équilibreur de charge Apigee de production.

Pour tester la nouvelle instance, procédez comme suit :

Suivez toutes les étapes de Routage externe (PSC) de l'Étape 8 : Configurer le routage pour provisionner un équilibreur de charge global parallèle dans la nouvelle région. Ces étapes incluent la création d'un NEG et son ajout au service de backend d'un LB temporaire.
Testez un proxy d'API à partir d'un client externe. Consultez la page Déployer un exemple de proxy pour effectuer un test avec un routage externe.
Lorsque vous avez terminé les tests, supprimez l'équilibreur de charge temporaire. Notez qu'il n'est pas nécessaire de supprimer le NEG. Vous pouvez le réutiliser, comme expliqué ci-dessous. Consultez la section <aclass='external' l10n-attrs-original-order="href,class" l10n-encrypted-href="8B2NcPbn4YT9OnY1wVRBc4ejOGtbg0yHKIEfrt909xVY1lbZgR+V+y8N3ExnKpzZ">Nettoyer une configuration d'équilibrage de charge.</aclass='external'>

Créer un groupe de points de terminaison du réseau pour la nouvelle région

Suivez ces étapes pour créer et configurer un équilibreur de charge avec un groupe de points de terminaison du réseau (NEG, "Network Endpoint Group") pour la nouvelle région :

Créez un NEG :
Remarque : Si vous n'avez pas supprimé le NEG que vous avez créé lors des tests, vous pouvez choisir de le réutiliser. Dans ce cas, ignorez cette étape et passez à l'étape 2.
1. Récupérez le rattachement de service à partir de l'instance que vous avez créée précédemment :
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
  Dans l'exemple de résultat suivant, la valeur serviceAttachment est indiquée en gras :
```
{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.82.192.2",
      "port": "443",
      "createdAt": "1645731488019",
      "lastModifiedAt": "1646504754219",
      "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-7-0-20220228-190814",
      "ipRange": "10.82.192.0/22,10.82.196.0/28",
      "consumerAcceptList": [
        "875609189304"
      ],
      "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
    }
  ]
}
```
  Remarque : L'ID du projet que vous avez utilisé pour créer votre organisation Apigee apparaît toujours dans la liste consumerAcceptList. Dans l'exemple de résultat présenté ci-dessus, il s'agit du seul projet de la liste.
2. Créez un NEG qui pointe vers le rattachement de service obtenu à partir du corps de réponse de l'instance à l'étape précédente.
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=TARGET_SERVICE \
  --region=$NEW_REGION_LOCATION \
  --network=NETWORK_NAME \
  --subnet=SUBNET_NAME \
  --project=PROJECT_ID
```
  Remplacez les éléments suivants :
  - NEG_NAME : nom du groupe de points de terminaison du réseau.
  - TARGET_SERVICE : rattachement de service auquel vous souhaitez vous connecter. Par exemple : projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
  - NETWORK_NAME (facultatif) : nom du réseau dans lequel le NEG est créé. Si vous omettez ce paramètre, le réseau de projet default est utilisé.
  - SUBNET_NAME : nom du sous-réseau utilisé pour la connectivité privée au producteur. La taille du sous-réseau peut être faible : le NEG PSC n'a besoin que d'une adresse IP du sous-réseau. Pour Apigee, un seul NEG PSC est nécessaire par région. Le sous-réseau peut être partagé et utilisé par des VM ou d'autres entités. Si aucun sous-réseau n'est spécifié, les points de terminaison du réseau peuvent appartenir à n'importe quel sous-réseau de la région dans laquelle le groupe de points de terminaison du réseau est créé.
    REMARQUE : Si vous spécifiez le paramètre --network, vous devez également spécifier --subnet.
  - PROJECT_ID : projet Cloud déjà associé à votre organisation Apigee, ou projet Cloud inclus dans consumerAcceptlist lors de la création de l'instance d'exécution Apigee.
Obtenez le nom du service de backend pour votre équilibreur de charge Apigee de production :
```
gcloud compute backend-services list --project=$PROJECT_ID
```
Ajoutez le NEG en tant que backend au service de backend :
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --network-endpoint-group-region=$NEW_REGION_LOCATION \
  --global --project=$PROJECT_ID
```
Remplacez les éléments suivants :
- BACKEND_SERVICE_NAME : nom du service de backend.
- NEG_NAME : nom du groupe de points de terminaison du réseau.
(Facultatif) Vous pouvez définir une règle de trafic de détection des anomalies sur le service de backend pour gérer automatiquement les scénarios de basculement. Pour en savoir plus, lisez les informations ci-après :

Tester la configuration finale

Appelez un proxy d'API. Consultez la section Déployer un exemple de proxy.

Configurer le routage du MIG

Les étapes suivantes expliquent comment configurer le routage dans la nouvelle région en utilisant un groupe d'instances géré (MIG).

Présentation

La figure suivante montre l'architecture Northbound de haut niveau pour les applications multi-régionales utilisant des groupes d'instances gérés (MIG) :

Schéma de l'architecture Northbound pour l'architecture PSC multirégionale

Figure 2 : Architecture multirégionale Northbound avec MIG

Comme le montre la figure 2, vous allez créer un MIG dans votre projet afin de communiquer avec un équilibreur de charge déployé dans la région où réside la nouvelle instance Apigee. Les proxys de MIG de toutes les régions sont connectés au backend de l'équilibreur de charge externe global Apigee de production.

(Facultatif) Effectuer un test avec un équilibreur de charge temporaire

Avant de continuer, vous souhaiterez peut-être tester la nouvelle instance en configurant un équilibreur de charge temporaire et un MIG afin de communiquer avec Apigee dans votre nouvelle région. Après avoir envoyé le trafic de l'API avec succès vers l'équilibreur de charge de test, vous pouvez supprimer l'équilibreur de charge temporaire et connecter le MIG au service de backend de votre équilibreur de charge Apigee de production.

Pour tester la nouvelle instance, procédez comme suit :

Suivez toutes les étapes de Routage externe (MIG) de l'Étape 8 : Configurer le routage pour provisionner un équilibreur de charge global parallèle dans la nouvelle région.
Testez un proxy d'API à partir d'un client externe. Consultez la page Déployer un exemple de proxy pour effectuer un test avec un routage externe.
Lorsque vous avez terminé les tests, supprimez l'équilibreur de charge temporaire. Notez qu'il n'est pas nécessaire de supprimer le MIG. Vous pouvez le réutiliser, comme expliqué ci-dessous. Consultez la section <aclass='external' l10n-attrs-original-order="href,class" l10n-encrypted-href="8B2NcPbn4YT9OnY1wVRBc4ejOGtbg0yHKIEfrt909xVY1lbZgR+V+y8N3ExnKpzZ">Nettoyer une configuration d'équilibrage de charge.</aclass='external'>

Créer un groupe d'instances géré (MIG) pour la nouvelle région

Pour créer et configurer un MIG pour la nouvelle région, procédez comme suit :

Activez l'accès privé à Google pour un sous-réseau de votre réseau VPC.

Pour activer l'accès privé à Google pour un sous-réseau de votre réseau VPC, suivez la procédure décrite dans la section Activer l'accès privé à Google.
Configurez des variables d'environnement :

Les instructions de cette section utilisent des variables d'environnement pour faire référence à des chaînes utilisées de manière répétée. Nous vous recommandons de les définir avant de continuer :
```
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=YOUR_VPC_NAME       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=YOUR_SUBNET_NAME     # Private Google Access must be enabled for this subnet
NEW_REGION_LOCATION=YOUR_NEW_REGION      # The same region as your new Apigee runtime instance
APIGEE_ENDPOINT=APIGEE_INSTANCE_IP        # See the tip below for details on getting this IP address value
```
Conseil : Pour obtenir l'adresse IP d'instance Apigee appropriée, utilisez l'API Instances, comme le montre l'exemple suivant :
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
Apigee répond avec des informations détaillées sur l'instance, par exemple :
```
{
  "instances": [
    {
      "name": "my-runtime-instance",
      "location": "us-west1",
      "host": "10.16.0.2",
      "port": "443"
    },
    ...
  ]
}
```
L'adresse IP de l'instance, que vous pouvez attribuer à la variable d'environnement $APIGEE_ENDPOINT, correspond à la valeur du champ host. Dans cet exemple, la valeur est 10.16.0.2.

Dans une installation multirégionale, l'appel d'API renvoie les détails de l'instance pour chaque emplacement régional.
Créez un groupe d'instances géré. Au cours de cette étape, vous allez créer et configurer un groupe d'instances géré.
Remarque : Si vous n'avez pas supprimé le MIG que vous avez créé lors des tests, vous pouvez choisir de le réutiliser. Dans ce cas, ignorez cette étape et passez à l'étape 3.
1. Créez un modèle d'instance en exécutant la commande suivante.
```
gcloud compute instance-templates create $MIG_NAME \
  --project $PROJECT_ID \
  --region $NEW_REGION_LOCATION \
  --network $VPC_NAME \
  --subnet $VPC_SUBNET \
  --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
  --machine-type e2-medium --image-family debian-10 \
  --image-project debian-cloud --boot-disk-size 20GB \
  --no-address \
  --metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh
```
  Comme vous pouvez le voir avec cette commande, les machines sont de type e2-medium. Elle exécute Debian 10 et dispose de 20 Go d'espace disque. Le script startup-script.sh configure le groupe d'instances géré pour acheminer le trafic entrant de l'équilibreur de charge vers l'instance Apigee.
2. Créez un groupe d'instances géré en exécutant la commande suivante :
```
gcloud compute instance-groups managed create $MIG_NAME \
  --project $PROJECT_ID --base-instance-name apigee-mig \
  --size 2 --template $MIG_NAME --region $NEW_REGION_LOCATION
```
3. Configurez l'autoscaling pour le groupe en exécutant la commande suivante :
  Remarque : Un MIG régional avec des instances e2-medium peut accepter un maximum de 6 Gbit/s. Si cela ne suffit pas à vos besoins en débit, envisagez de redimensionner la VM et/ou d'augmenter le nombre d'instances dupliquées.
```
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --max-num-replicas 3 \
  --target-cpu-utilization 0.75 --cool-down-period 90
```
4. Pour définir un port nommé, exécutez la commande suivante :
```
gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
```
Obtenez le nom du service de backend pour votre équilibreur de charge Apigee de production :
```
gcloud compute backend-services list --project=$PROJECT_ID
```

Ajoutez le groupe d'instances géré à votre service de backend à l'aide de la commande suivante :

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --project $PROJECT_ID --instance-group $MIG_NAME \
  --instance-group-region $NEW_REGION_LOCATION \
  --balancing-mode UTILIZATION --max-utilization 0.8 --global

Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

Tester la configuration finale

Appelez un proxy d'API. Consultez la section Déployer un exemple de proxy.

Ajouter des régions

L'ajout de plusieurs régions à un environnement Apigee peut offrir une haute disponibilité, une plus grande capacité et une latence plus faible pour vos API. Un déploiement multirégional permet une haute disponibilité, car le basculement manuel n'est pas nécessaire dans la mesure où l'équilibreur de charge externe vérifie l'état de chaque région. Une capacité plus élevée est fournie lorsque plusieurs régions diffusent les mêmes API en même temps. En outre, si vos clients API se trouvent dans plusieurs régions, la diffusion de votre API à partir d'une région plus proche de vos clients permet de réduire la latence et d'améliorer les performances.

Exemple : un déploiement multirégional améliore la disponibilité, la capacité et la latence

Dans un déploiement multirégional actif-actif, le trafic est diffusé depuis deux régions simultanément. Ajoutez un service de backend pour le groupe d'instances géré de chaque région au même équilibreur de charge HTTPS externe (XLB), comme expliqué à l'étape 8e(3) sous l'onglet Routage externe (MIG) de la section Étape 8 : Configurer le routage. Pour en savoir plus, consultez également la section Créer un groupe d'instances géré (MIG) pour la nouvelle région.

Pour chaque requête, l'équilibreur de charge externe choisit la région la plus proche du client, sauf si le nombre de requêtes dépasse la limite définie pour un backend particulier. Pour en savoir plus sur la manière dont les équilibreurs de charge externes acheminent le trafic, consultez la page Optimiser la capacité des applications avec l'équilibrage de charge global.

Ajouter des régions pour le paiement à l'usage

Le modèle de tarification à l'usage vous permet de définir le nombre minimal de nœuds de la passerelle Apigee pour un environnement. Ainsi, vous êtes sûr d'avoir des régions qui s'exécutent toujours avec une capacité supplémentaire pour prendre en charge immédiatement le trafic de basculement en cas de défaillance d'une région.

Définir le nombre minimal de nœuds de la passerelle Apigee

Si vous êtes en mesure de diffuser l'intégralité de votre trafic d'API normal sur deux régions actives, chacune avec quatre nœuds de passerelle Apigee, chaque région doit comporter au moins huit nœuds. Cela permet de prendre en charge immédiatement la perte d'une région. Consultez la section À propos des nœuds Apigee pour savoir comment déterminer le nombre de nœuds dont vous avez besoin pour gérer votre trafic d'API. Notez que le nombre minimal de nœuds est défini par environnement, mais appliqué par région. Par exemple, si vous définissez le nombre minimal sur 8, chaque région contiendra au moins huit nœuds.

Coût

Dans l'exemple ci-dessus, le coût d'exécution d'au moins 16 nœuds de passerelle Apigee (8 nœuds x 2 régions) vous est facturé. Le coût peut augmenter à mesure que le nombre de nœuds augmente automatiquement pour gérer le trafic supplémentaire, jusqu'à atteindre le nombre maximal.

Supprimer Apigee d'une région

Pour mettre hors service une instance Apigee de diffusion du trafic d'API, procédez comme suit pour garantir un service ininterrompu (zéro temps d'arrêt pour vos API) :

Activez le drainage de connexion sur le service de backend. Le drainage de connexion est un processus qui garantit que, lorsqu'un backend est supprimé du service de backend, les requêtes en cours se voient accorder un délai suffisant pour être traitées.
Si Cloud DNS a été configuré pour acheminer le trafic vers cette région Apigee via la règle de routage à répétition alternée pondérée, supprimez cette configuration DNS, comme décrit dans la section Gérer les règles de routage DNS et les vérifications d'état.
Dissociez le backend du MIG du service de backend. Avec le drainage de connexion, vous vous assurez que l'instance Apigee ne reçoit pas de nouveau trafic, mais autorise les requêtes en cours de transfert.
Supprimez l'instance Apigee et le MIG correspondant. Consultez la section Supprimer une instance.