Como criar implantações multirregionais para gateway de API

Neste tutorial, mostramos como configurar um balanceador de carga HTTP(S) para ativar implantações multirregionais no gateway de API.

A criação de um balanceador de carga HTTP(S) compatível com implantações multirregionais do gateway de API pode melhorar a disponibilidade e diminuir a latência do serviço, sendo exibido em mais de uma região. É possível minimizar ainda mais a latência e maximizar o tempo de atividade com o roteamento entre regiões, que atende a solicitações da região disponível mais próxima do usuário.

Para os fins deste tutorial, configure um único esquema de URL não regional que funciona em qualquer lugar do mundo, mas atende às solicitações do usuário da implantação do gateway de API mais próximo. Com essa configuração, as solicitações são ideais para a região que fornece latência mínima ao usuário. Caso a região mais próxima não esteja disponível ou esteja acima da capacidade, a solicitação será encaminhada para uma região diferente para garantir a disponibilidade.

Antes de começar

Antes de configurar a implantação em várias regiões, siga o Guia de início rápido do gateway de API para implantar um serviço do Cloud Run e criar um gateway que aponte para esse serviço.

Para este tutorial, implante seu serviço em duas regiões diferentes. Por exemplo, é possível implantar duas instâncias do gateway de API:

my-gateway-eu para uma região na Europa
my-gateway-us para uma região nos EUA

Configurar permissões

Neste tutorial, você criará um grupo de endpoints de rede (NEG, na sigla em inglês) sem servidor e um balanceador de carga HTTP(S) externo em um projeto do Cloud. Isso requer um papel de proprietário ou editor do projeto ou os seguintes papéis de IAM do Compute Engine:

Tarefa	Papel necessário
Criar balanceador de carga e componentes de rede	Administrador de rede
Criar e modificar NEGs	Administrador da instância do Compute
Criar e modificar certificados SSL	Administrador de segurança

Criar um recurso de certificado SSL

Para criar um balanceador de carga HTTPS, um recurso de certificado SSL precisa ser adicionado ao front-end do balanceador de carga. Crie um recurso de certificado SSL usando um certificado SSL gerenciado pelo Google ou um certificado SSL autogerenciado.

Certificados gerenciados pelo Google. O uso de certificados gerenciados pelo Google é recomendado porque o Google Cloud recebe, gerencia e renova esses certificados automaticamente. Para criar um certificado gerenciado pelo Google, você precisa ter um domínio e os registros DNS desse domínio para que o certificado seja provisionado. Se você ainda não tiver um domínio, será possível conseguir um no Google Domains. Além disso, será necessário atualizar o registro DNS A do domínio para apontar para o endereço IP do balanceador de carga criado em uma etapa posterior. Para instruções detalhadas, consulte Como usar certificados gerenciados pelo Google.
Certificados autoassinados. Se você não quiser configurar um domínio agora, use um certificado SSL autoassinado para o teste.

Este exemplo pressupõe que você já criou um recurso de certificado SSL.

Se você quiser testar esse processo sem criar um recurso de certificado SSL (ou um domínio conforme exigido pelos certificados gerenciados pelo Google), ainda será possível usar as instruções nesta página para configurar uma carga HTTP.

Criar o balanceador de carga HTTP(S)

Crie um NEG sem servidor para cada instância de gateway de API.

Um grupo de endpoints de rede (NEG) especifica um grupo de endpoints de back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um serviço como o gateway de API, conforme mostrado na figura abaixo:

Para criar um NEG sem servidor para cada instância de gateway, execute o seguinte comando, em que:
- SERVERLESS_NEG_NAME é o nome do NEG sem servidor a ser criado;
- GATEWAY_ID especifica o nome do gateway.
- REGION_ID é a região de implantação do NEG sem servidor (deve corresponder à região do gateway).
```
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
```
Exemplo:
```
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
```
Repita esse comando para criar um NEG sem servidor para a próxima instância de gateway, usando os valores apropriados para a segunda instância de gateway, por exemplo,api-gateway-serverless-neg-us para my-gateway-us na região us-central1.
Crie um serviço de back-end para definir como o Cloud Load Balancing distribui o tráfego.

A configuração do serviço de back-end contém um conjunto de valores, como o protocolo usado para se conectar a back-ends, várias configurações de distribuição e sessão, verificações de integridade e tempos limite, conforme mostrado na figura abaixo:

Para criar um serviço de back-end e adicionar o NEG sem servidor como um back-end ao serviço de back-end, execute os seguintes comandos, em que:
- BACKEND_SERVICE_NAME: o nome do seu serviço de back-end.
- SERVERLESS_NEG_NAME é o nome do NEG sem servidor criado na etapa anterior;
- REGION_ID é a região de implantação do NEG sem servidor (deve corresponder à região do gateway).
```
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
```
Exemplo:
```
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
```
Repita esse comando para adicionar o segundo NEG sem servidor ao serviço de back-end, usando os valores apropriados para o segundo NEG sem servidor, por exemplo, api-gateway-serverless-neg-us para my-gateway-us na região us-central1.
Crie um mapa de URLs para fazer o roteamento das solicitações recebidas ao serviço de back-end, conforme mostrado na figura abaixo:

Para criar o mapa de URL, execute o seguinte comando, em que:
- URL_MAP_NAME é o nome do mapa de URL a ser criado.
- BACKEND_SERVICE_NAME: o nome do seu serviço de back-end.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
Exemplo:
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
Este mapa de URL de exemplo segmenta apenas um serviço de back-end que representa um único gateway, portanto, regras de host ou correspondências de caminho não são necessárias. Se você tiver mais de um serviço de back-end, poderá usar regras de host para direcionar solicitações para serviços diferentes com base no nome do host. Use correspondências de caminho para direcionar solicitações para serviços diferentes com base no caminho da solicitação.

Exemplo:
```
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
```
Para saber mais sobre as regras de host e as correspondências de caminho, consulte a documentação Mapa de URL.
Crie um certificado SSL para seu proxy de destino, conforme mostrado na figura abaixo:

Para criar um balanceador de carga HTTPS, é necessário um recurso de certificado SSL para o proxy de destino HTTPS. É possível criar um recurso de certificado SSL usando um certificado SSL gerenciado pelo Google ou um certificado SSL autogerenciado. Recomendamos o uso de certificados gerenciados pelo Google.

Para criar um certificado gerenciado pelo Google, você precisa ter um domínio. Se você não tiver um domínio, poderá usar um certificado SSL autoassinado para testes.

Para criar um recurso de certificado SSL gerenciado pelo Google:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
Para criar um recurso de certificado SSL autogerenciado:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH
```
Crie um proxy HTTP(S) de destino para encaminhar solicitações ao mapa de URLs, conforme mostrado na figura abaixo:

Para criar o proxy de destino, use o seguinte comando, em que:
- TARGET_HTTP_PROXY_NAME é o nome do proxy de destino a ser criado;
- URL_MAP_NAME é o nome do mapa de URL criado em uma etapa anterior.
- Opcional: SSL_CERT_NAME é o nome do certificado SSL criado.
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME
```
Exemplo:
```
gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map
```
Crie uma regra de encaminhamento para encaminhar solicitações de entrada para o proxy, como mostrado na figura abaixo:

Use o comando a seguir para criar a regra de encaminhamento, em que:
- HTTPS_FORWARDING_RULE_NAME é o nome da regra a ser criada;
- TARGET_HTTP_PROXY_NAME é o nome do proxy de destino a ser criado;
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
Exemplo:
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

Atualizar registros DNS com o endereço IP do balanceador de carga

Se você tiver um domínio personalizado, esta etapa será necessária para definir as configurações de DNS do seu domínio de modo que elas apontem para o novo endereço IP do serviço. Isso também será necessário se você tiver criado um balanceador de carga HTTPS com um certificado gerenciado pelo Google (que requer um domínio). Recomenda-se alocar e usar um endereço IP estático quando usado com DNS. As instruções específicas para esta etapa dependem do seu provedor de DNS.

Para enviar tráfego ao balanceador de carga, o registro DNS do seu domínio (neste tutorial, my-app-domain) precisa apontar para os endereços IP do balanceador de carga.

Para encontrar o endereço IP da regra de encaminhamento global, use este comando:
```
gcloud compute forwarding-rules list
```
Atualize o registro DNS A ou AAAA do seu domínio para que aponte para o endereço IP do balanceador de carga, de modo que o tráfego enviado para o URL de domínio personalizado existente seja roteado por meio do balanceador de carga. O DNS pode levar alguns segundos ou várias horas para propagar essa alteração no servidor DNS.
Teste para confirmar se o gateway está recebendo tráfego usando curl ou acessando o URL no navegador. Por exemplo: https://my-app-domain

Após o teste, você verá a resposta gerada pelo serviço do Cloud Run. Por exemplo, pode ser uma página HTML "Hello World" ou outra resposta esperada gerada diretamente pelo serviço de back-end. Isso significa que a solicitação está passando pelo balanceador de carga, e o serviço de back-end está instruindo o balanceador de carga a enviá-lo para o gateway.

Considerações

Antes de implementar uma implantação multirregional do Gateway de API, considere o seguinte:

No momento, o gateway de API não é compatível com verificações de integridade. Com a configuração de roteamento entre regiões descrita acima, se o gateway ou o serviço de back-end retornar erros em uma região, mas a infraestrutura do gateway de API na região estiver disponível e tiver capacidade, o balanceador de carga HTTP(S) não direcionará o tráfego para outro local outras regiões.
Para combinar diferentes regiões em uma única regra de encaminhamento, você precisa de preços do nível Premium. Para mais informações sobre como calcular o preço e o uso, consulte Preços dos níveis de serviço de rede.

Práticas recomendadas

Ao usar a multirregião, recomendamos o uso de uma solução de armazenamento de dados gerenciados replicada globalmente, como o Cloud Spanner, para garantir que todos os dados sejam gerenciados globalmente.