Como expandir a Apigee para várias regiões

Esta página se aplica à Apigee, mas não à Apigee híbrida.

Confira a documentação da Apigee Edge.

É possível expandir uma organização da Apigee em várias regiões. A expansão multirregional permite melhorias nas seguintes áreas:

Alta disponibilidade : em caso de falha na região, o tráfego ainda pode ser atendido pelas regiões restantes, o que aumenta a disponibilidade geral das APIs.
Alta capacidade: regiões adicionais oferecem capacidade extra para atender o tráfego de API e espaço para qualquer pico inesperado de tráfego sem aumentar a pressão em um único ambiente, o aumento da capacidade geral das suas APIs.
Baixa latência: regiões adicionais podem diminuir a latência geral da transação para clientes exibindo as solicitações em uma região geograficamente mais próxima.

Neste documento, explicamos como adicionar a Apigee a uma nova região e como remover a Apigee de uma região.

Como adicionar a Apigee a uma nova região

É possível ter uma instância de ambiente de execução por região. Portanto, para adicionar uma nova região, crie uma instância totalmente nova nessa região.

O processo geral para adicionar uma nova região é o seguinte:

Verifique se há um intervalo de endereços IP apropriado na rede de peering disponível, conforme descrito em Pré-requisitos. Além disso, verifique se sua conta é compatível com uma nova região, conforme descrito em Limites.
Definir as variáveis de ambiente
Criar um novo keyring e uma nova chave
Reservar um novo intervalo de endereços
Crie uma nova instância
Anexar ambientes à nova instância
Configurar o roteamento

Cada uma dessas etapas é descrita nas seções a seguir.

Pré-requisitos

Verifique se sua rede tem /22 e /28 como intervalos de endereços IP não sobrepostos disponíveis. Ela é uma adição aos intervalos usados por outras regiões.

Limites

Por padrão, sua organização inicial costuma ser criada com uma única região. Ao decidir se você vai criar uma segunda região (ou subsequente), só será possível adicionar uma região se os direitos de licença permitirem. Também é possível comprar um pacote organizacional.

Se você tiver um modelo de preços com base em assinatura, talvez seja necessário comprar unidades organizacionais adicionais para permitir a expansão para várias regiões. Consulte Direitos de assinatura.
Se você tiver um modelo de preços de pagamento por utilização, a expansão para várias regiões terá custos extras, conforme explicado em Como adicionar regiões para pagamento por utilização.
As contas de e-mail são limitadas a uma região e não podem ser expandidas para uma segunda região.

Para mais informações, consulte Visão geral do pagamento por utilização.

Nenhuma organização pode ter mais de 10 (11 para híbridas) regiões.

Definir as variáveis de ambiente

Recomendamos que você defina as variáveis de ambiente a seguir para garantir a consistência dos comandos usados nesta documentação.

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)")

Em que:

NEW_REGION_LOCATION é o local físico da nova instância. Os valores válidos são qualquer região do Compute Engine. Para mais informações, consulte Regiões e zonas. Por exemplo, us-west1.
NEW_INSTANCE_NAME é o nome da nova região. Ele precisa ser exclusivo para sua organização. Por exemplo, my-instance-2.
NETWORK_NAME é o nome da rede de peering da organização. Por exemplo, my-network. Consulte Configurar rede de serviços.
DISK_KEY_RING_NAME é o nome do keyring da chave de disco.
DISK_KEY_NAME é um nome para o anel de disco.
AUTH define o cabeçalho Authentication com um token do portador. Você usará esse cabeçalho ao chamar as APIs da Apigee. Observe que o token expira após um certo tempo. Quando isso acontecer, basta gerar o token novamente usando o mesmo comando. Saiba mais na página de referência do comando print-access-token.
é o PROJECT_IDID do projeto do Cloud.
PROJECT_NUMBER é o número do projeto do Cloud.

Criar um novo keyring e uma nova chave

Cada região requer a própria chave de criptografia de disco para a rede. O Google recomenda que você também crie um keyring separado para a nova região. Você não precisa criar uma nova chave de criptografia de banco de dados porque todas as instâncias de uma organização compartilham a mesma chave de criptografia de banco de dados.

Para mais detalhes, consulte Sobre as chaves de criptografia da Apigee.

Para criar um novo keyring e chave de criptografia de disco:

Crie um novo keyring usando o comando gcloud:

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

Verifique se o keyring do disco está definido para o mesmo local que a instância. Cada instância e keyring têm o próprio local.

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

Crie uma nova chave de disco usando o comando kms keys create; Por exemplo:

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

A chave pode ser referenciada pelo caminho de chave. É possível ver o caminho da chave com o comando a seguir:

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

O caminho de chave é semelhante ao seguinte:

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

Conceda acesso para que o agente de serviço da Apigee use a nova chave executando o comando gcloud kms keys add-iam-policy-binding; por exemplo:

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

Verifique se a chave está vinculada ao agente de serviço da 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

Reservar um novo intervalo de endereços

Reserve endereços IP para o intervalo de endereços da sua rede de peering: Para mais informações e considerações importantes, consulte também Noções básicas sobre intervalos de peering.

Crie estas variáveis de ambiente:
```
NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
NETWORK_NAME=YOUR_NETWORK_NAME
```
Em que:
- NEW_RANGE_NAME_22 é o nome do intervalo de endereços IP com tamanho /22 do CIDR que você criará. Você dá o nome que quiser a ele; Por exemplo: google-svcs-new_22
- NEW_RANGE_NAME_28 é o nome do intervalo de endereços IP com tamanho /28 do CIDR que você criará. Você dá o nome que quiser a ele; Por exemplo: google-svcs-new_28
- NETWORK_NAME é o nome do recurso de rede em que os endereços precisam ser reservados.
  O Google cria uma rede padrão (chamada default) para cada novo projeto, para que você possa usar isso. No entanto, o Google não recomenda usar a rede padrão para qualquer finalidade que não seja teste.
  
  Observação: o Google não recomenda o uso de default, a menos que você esteja testando esse processo de configuração. Não use uma organização com uma rede padrão em produção.

Crie um intervalo de IP de rede com um comprimento 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

Em caso de sucesso, gcloud responderá com o seguinte:

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

Valide o endereço de computação criado:

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

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

Depois que você criar um intervalo de endereços IP, os endereços serão associados ao projeto até que você os libere.

Crie um intervalo de IP de rede com um comprimento CIDR de /28. Esse intervalo é obrigatório e é usado pela Apigee para solução de problemas e não pode ser personalizado ou alterado.

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

Valide o endereço de computação criado:

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

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

Consiga os nomes dos intervalos de peering:

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

Adicione os intervalos recém-reservados à sua rede de peering com o seguinte comando, em que $NEW_RANGE_NAME_22 e$NEW_RANGE_NAME_28 são os novos nomes de intervalo eORIGINAL_RANGE_NAME_1 eORIGINAL_RANGE_NAME_n são os nomes do intervalo de peering reservado retornado no comando anterior:
```
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
```

Valide as alterações de vpc-peering atualizadas:

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

Crie uma nova instância

Crie uma nova instância para a região usando as instâncias de API.

Com peering de VPC

Se a Apigee estiver configurada para usar peering de VPC, use esta chamada de API para criar a instância:

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
  }'

Em que:

KEY_PATH é o caminho da chave de criptografia de disco que você criou em Criar um novo keyring e chave.
IP_ADDRESS_* são endereços IP CIDR para os intervalos CIDR /22 e /28 usados para criar a instância da Apigee. Observe que ipRange é opcional. Se você não fornecer esse campo, a Apigee vai solicitar automaticamente um bloco CIDR /22 e /28 disponível da rede de serviços. Consulte também a API Apigee instances.

Essa solicitação pode levar até 20 minutos para ser concluída porque a Apigee precisa criar e iniciar um novo cluster do Kubernetes, instalar os recursos da Apigee nesse cluster e configurar o balanceamento de carga.

Sem peering de VPC

Se a Apigee não estiver configurada para usar peering de VPC, use esta chamada de API para criar a instância:

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]
  }'

Em que:

KEY_PATH é o caminho da chave de criptografia de disco que você criou em Criar um novo keyring e chave. Consulte também a API Apigee instances.
consumerAcceptList(Opcional) Especifica uma lista de IDs de projetos do Google Cloud que podem se conectar de forma particular ao anexo de serviços da VPC da Apigee. O anexo do serviço é uma entidade usada com o Private Service Connect do Google Cloud para permitir que os produtores de serviços (neste caso, a Apigee) exponham serviços aos consumidores (neste caso, um ou mais projetos do Cloud que pertençam a você). Por padrão, usamos o projeto do Cloud que já está associado à sua organização da Apigee. Por exemplo: "consumerAcceptList": ["project1", "project2", "project3"]

Como encontrar o caminho da chave

É possível ver o caminho da chave com o comando a seguir:

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

O caminho de chave é semelhante ao seguinte:

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

timer A operação de criação da instância leva cerca de 30 minutos para ser concluída.

Para ver o status da solicitação de criação da instância de ambiente de execução, execute o comando a seguir. Quando o estado for ACTIVE, avance para o próximo passo.

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

Para mais detalhes sobre como criar uma instância de ambiente de execução, incluindo informações extras sobre contexto e solução de problemas, consulte a Etapa 5: criar uma instância de ambiente de execução.

Anexar ambientes à nova instância

Depois de criar a instância, é necessário anexar ambientes a ela. Caso contrário, ela não poderá responder às solicitações da API.

Os ambientes são compartilhados entre instâncias. Portanto, você precisa anexar ambientes existentes à nova região. Não defina novos ambientes para a nova região. Se você definir um novo ambiente para a nova região que esteja atendendo aos mesmos caminhos de base dos mesmos hosts que o ambiente original, as chamadas de ambiente de execução poderão retornar erros HTTP 503.

Quando você preenche uma nova região com ambientes, não precisa anexar os ambientes aos grupos de ambiente: eles já estão anexados aos grupos. Você só precisa anexar os ambientes à nova instância.

Para anexar os ambientes à nova região, use a instâncias de anexo de API, como no exemplo a seguir:

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"
  }'

Para ver uma lista dos seus ambientes:

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

É necessário anexar cada ambiente com uma chamada separada às instâncias de anexo de API. Não é possível anexar mais de um ambiente em uma única chamada.

Configurar o roteamento

É possível configurar o roteamento de rede na nova região usando um grupo de instâncias gerenciadas (MIG, na sigla em inglês) ou uma configuração baseada no Private Service Connect (PSC).

Configurar o roteamento PSC

As etapas a seguir explicam como configurar o roteamento na nova região usando a PSC.

Visão geral

A figura a seguir mostra a arquitetura geral e de alto nível para o PSC multirregional:

Diagrama do encaminhamento do PSC em várias regiões.

Figura 1: arquitetura multirregional com nordeste com o PSC

Como mostrado na Figura 1, você criará um grupo de endpoints da rede (NEG, na sigla em inglês) no projeto que se comunica com um anexo de serviço na região em que a nova instância da Apigee reside. Os NEGs da Apigee para todas as regiões estão conectados ao serviço de back-end do balanceador de carga externo global da produção da Apigee.

(Opcional) Teste usando um balanceador de carga temporário

Antes de continuar, talvez você queira testar a nova instância configurando um balanceador de carga temporário (LB, na sigla em inglês) e NEG para se comunicar com a Apigee na nova região. Depois de enviar o tráfego da API ao BC de teste, é possível excluir o LB temporário e conectar o NEG ao serviço de back-end do BC de produção da Apigee.

Siga estas etapas para testar a nova instância:

Siga todas as etapas de Roteamento externo (MIG) em Etapa 8: configurar o roteamento para provisionar um balanceador de carga regional/global paralelo na nova região. Essas etapas incluem a criação de um novo NEG e a adição ao serviço de back-end de um LB temporário.
Teste um proxy de API de um cliente externo. Consulte Implantar um proxy de amostra para testar com roteamento externo.
Quando terminar os testes, exclua o balanceador de carga temporário. Não é necessário excluir o NEG. É possível reutilizá-lo, conforme explicado a seguir. Consulte <aclass='external' l10n-attrs-original-order="href,class" l10n-encrypted-href="8B2NcPbn4YT9OnY1wVRBc4ejOGtbg0yHKIEfrt909xVY1lbZgR+V+y8N3ExnKpzZ">Limpar uma configuração de balanceamento de carga</en>

Crie um grupo de endpoints da rede para a nova região

Siga as etapas abaixo para criar e configurar um balanceador de carga com um grupo de endpoints de rede (NEG, na sigla em inglês) para a nova região:

Crie um novo NEG:
Observação:se você não excluiu o NEG criado durante o teste, poderá reutilizá-lo. Nesse caso, pule esta etapa e vá para a Etapa 2.
1. Consiga o anexo de serviço da instância criada anteriormente:
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
  No exemplo de saída a seguir, o valor serviceAttachment é mostrado em negrito:
```
{
  "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"
    }
  ]
}
```
  Observação: o ID do projeto que você usou para criar a organização da Apigee sempre aparece na lista consumerAcceptList. No exemplo de saída mostrado acima, é o único projeto na lista.
2. Crie um NEG que aponte para o anexo do serviço que você recebeu do corpo de resposta da instância na etapa anterior.
```
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
```
  Substitua:
  - NEG_NAME: um nome para o grupo de endpoints da rede.
  - TARGET_SERVICE: o anexo de serviço ao qual você quer se conectar. Por exemplo: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
  - NETWORK_NAME: (opcional) nome da rede em que o NEG foi criado. Se você omitir esse parâmetro, a rede do projeto default será usada.
  - SUBNET_NAME: nome da sub-rede usada para conectividade particular com o produtor. O tamanho da sub-rede pode ser pequeno: o NEC PSC só precisa de um IP da sub-rede. Para a Apigee, apenas um NEG de PSC é necessário por região. A sub-rede pode ser compartilhada e usada por VMs ou outras entidades. Se uma sub-rede não for especificada, os endpoints de rede poderão pertencer a qualquer sub-rede na região em que o grupo de endpoints de rede é criado.
    OBSERVAÇÃO: se você especificar o parâmetro --network, especifique também --subnet.
  - PROJECT_ID O projeto do Cloud que já está associado à organização da Apigee ou um projeto do Cloud incluído no consumerAcceptlist quando a instância de ambiente de execução da Apigee foi criada.
Encontre o nome do serviço de back-end do balanceador de carga da Apigee de produção:
```
gcloud compute backend-services list --project=$PROJECT_ID
```

Adicione o NEG como o back-end ao serviço de back-end:

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

Substitua:

BACKEND_SERVICE_NAME: o nome do serviço de back-end.
NEG_NAME: o nome do grupo de endpoints da rede.

(Opcional) É possível definir uma política de tráfego de detecção de outlier no serviço de back-end para processar automaticamente os cenários de failover. Você também encontrará mais informações nos seguintes artigos:

Testar a configuração final

Chamar um proxy de API. Consulte Implantar um proxy de amostra.

Configurar roteamento de MIG

As etapas a seguir explicam como configurar o roteamento na nova região usando um grupo gerenciado de instâncias (MIG).

Visão geral

A figura a seguir mostra a arquitetura de alto nível no sentido norte para várias regiões usando grupos gerenciados de instâncias (MIGs, na sigla em inglês):

Diagrama da arquitetura para o norte do PSC multirregional.

Figura 2: arquitetura multirregional com entrega usando o MIG

Como ilustrado na Figura 2, você criará um MIG no seu projeto para se comunicar com um balanceador de carga implantado na região em que a nova instância da Apigee reside. Os proxies MIG para todas as regiões estão conectados ao back-end do balanceador de carga externo global da produção da Apigee.

(Opcional) Teste usando um balanceador de carga temporário

Antes de continuar, talvez você queira testar a nova instância configurando um balanceador de carga temporário e um MIG para se comunicar com a Apigee na sua nova região. Depois de enviar o tráfego da API ao BC de teste, é possível excluir o LB temporário e conectar o MIG ao serviço de back-end do LB de produção da Apigee.

Siga estas etapas para testar a nova instância:

Siga todas as etapas de Roteamento externo (MIG) em Etapa 8: configurar o roteamento para provisionar um balanceador de carga regional/global paralelo na nova região.
Teste um proxy de API de um cliente externo. Consulte Implantar um proxy de amostra para testar com roteamento externo.
Quando terminar os testes, exclua o balanceador de carga temporário. Você não precisa excluir o MIG. É possível reutilizá-lo, conforme explicado a seguir. Consulte <aclass='external' l10n-attrs-original-order="href,class" l10n-encrypted-href="8B2NcPbn4YT9OnY1wVRBc4ejOGtbg0yHKIEfrt909xVY1lbZgR+V+y8N3ExnKpzZ">Limpar uma configuração de balanceamento de carga</en>

Criar um grupo gerenciado de instâncias (MIG, na sigla em inglês) para a nova região

Siga estas etapas para criar e configurar um MIG para a nova região:

Ativar o Acesso privado do Google para uma sub-rede da rede VPC.

Para ativar o Acesso privado do Google para uma sub-rede de sua rede VPC, siga os passos indicados em Como ativar o Acesso privado do Google.

Configure as variáveis de ambiente:

Nas instruções desta seção, usamos variáveis de ambiente para fazer referência às strings usadas várias vezes. Recomendamos que você defina essas variáveis antes de continuar:

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

Dica: para acessar o endereço IP correto da instância da Apigee, use a API Instances, como mostra o exemplo a seguir:

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

A Apigee responde com detalhes sobre a instância. Por exemplo:

{
  "instances": [
    {
      "name": "my-runtime-instance",
      "location": "us-west1",
      "host": "10.16.0.2",
      "port": "443"
    },
    ...
  ]
}

O endereço IP da instância, que pode ser atribuído à variável de ambiente $APIGEE_ENDPOINT, é o valor do campo host. Neste exemplo, o valor é 10.16.0.2.

Em uma instalação multirregional, a chamada de API retorna detalhes da instância para cada local regional.

Crie um grupo de instâncias gerenciadas. Nesta etapa, você cria e configura um grupo gerenciado de instâncias (MIG, na sigla em inglês).
Observação:se você não excluiu o MIG criado durante o teste, poderá reutilizá-lo. Nesse caso, pule esta etapa e acesse a 3.
1. Crie um modelo de instância executando o seguinte comando:
```
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
```
  Como você vê neste comando, as máquinas são do tipo e2-medium. Elas executam o Debian 10 e têm 20 GB de disco. O script startup-script.sh configura o MIG para rotear o tráfego de entrada do balanceador de carga para a instância da Apigee.
2. Crie um grupo gerenciado de instâncias executando o seguinte comando:
```
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. Configure o escalonamento automático do grupo executando o seguinte comando:
  Observação: um MIG regional com instâncias e2-medium oferece suporte para, no máximo, 6 Gbps. Se não for suficiente para suas necessidades de processamento, cogite aumentar o tamanho da VM e/ou o número de réplicas.
```
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. Defina uma porta nomeada executando o seguinte comando:
```
gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
```
Encontre o nome do serviço de back-end do balanceador de carga da Apigee de produção:
```
gcloud compute backend-services list --project=$PROJECT_ID
```

Adicione o MIG ao serviço de back-end com o comando a seguir:

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

Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.

Testar a configuração final

Chamar um proxy de API. Consulte Implantar um proxy de amostra.

Adicionar regiões

Adicionar várias regiões a um ambiente da Apigee pode fornecer alta disponibilidade, maior capacidade e menor latência para suas APIs. Uma implantação multirregional oferece suporte a alta disponibilidade porque o failover manual não é necessário, uma vez que o XLB verificará a integridade de cada região. Uma capacidade maior é fornecida quando várias regiões atendem às mesmas APIs ao mesmo tempo. Além disso, se os clientes de API estiverem em várias regiões, disponibilizar a API em uma região mais próxima dos clientes vai ajudar a diminuir a latência e melhorar o desempenho.

Exemplo: uma implantação multirregional melhora a disponibilidade, a capacidade e a latência

Em uma implantação multirregional ativa-ativa, o tráfego é veiculado de duas regiões ao mesmo tempo. Adicione um serviço de back-end para o MIG de cada região ao mesmo balanceador de carga HTTPS externo (XLB), conforme explicado na etapa 8e(3) na guia Roteamento externo (MIG) na seção Etapa 8: configurar roteamento. Para mais informações, consulte também Criar um grupo gerenciado de instâncias (MIG, na sigla em inglês) para a nova região.

Para cada solicitação, a XLB vai escolher a região mais próxima do cliente, a menos que o número de solicitações exceda o limite definido para um back-end específico. Consulte Otimizações de capacidade do aplicativo com balanceamento de carga global para mais informações sobre como os balanceadores de carga externos encaminham o tráfego.

Adicionar regiões para pagamento por utilização

Com o modelo de preços de pagamento por utilização, é possível definir o número mínimo de nós de gateway da Apigee para um ambiente. Isso garante que as regiões sempre operem com capacidade extra para oferecer suporte imediato ao tráfego de failover, em caso de falha na região.

Como definir o número mínimo de nós de gateway da Apigee

Se for possível atender a todo o tráfego normal da API de duas regiões ativas, cada uma com quatro nós de gateway da Apigee, cada região vai precisar ter no mínimo oito nós. O objetivo é oferecer suporte imediato quando houver perda de uma região. Consulte Sobre nós da Apigee para mais informações sobre como determinar o número de nós necessários para acomodar o tráfego de APIs. O número mínimo de nós é definido por ambiente, mas aplicado por região. Neste exemplo, se você definir o mínimo de 8, cada região vai ter um mínimo de 8 nós.

Custo

No exemplo acima, você pagaria pela execução de pelo menos 16 nós de gateway da Apigee (8 nós x 2 regiões). O custo pode aumentar à medida que os números de nós aumentam automaticamente para acomodar o tráfego adicional, até o máximo.

Como remover a Apigee de uma região

Para desativar a interrupção de um tráfego de API por uma instância da Apigee, siga estas etapas para garantir o serviço ininterrupto (zero inatividade para suas APIs):

Ative a diminuição de conexão no serviço de back-end. A diminuição da conexão é um processo que garante que as solicitações atuais em andamento tenham tempo para serem concluídas quando um back-end é removido do serviço de back-end.
Se o Cloud DNS tiver sido configurado para rotear o tráfego a essa região da Apigee por meio da política de roteamento de round-robin ponderado, remova essa configuração de DNS, conforme descrito em Gerenciar políticas de roteamento e verificações de integridade de DNS
Remover o back-end do MIG do serviço de back-end. Isso garantirá que a instância da Apigee não receba novos tráfegos, mas permitirá que todas as solicitações em trânsito sejam concluídas, mesmo com a diminuição da conexão.
Excluir a instância da Apigee e o MIG correspondente. Consulte Excluir uma instância.