Esta página foi traduzida pela API Cloud Translation.

Criar implementações multirregionais para o API Gateway

Este tutorial mostra como configurar um balanceador de carga HTTP(S) para ativar implementações em várias regiões para o API Gateway.

A criação de um balanceador de carga HTTP(S) para suportar implementações multirregião do API Gateway pode melhorar a disponibilidade e diminuir a latência do seu serviço através da publicação a partir de mais de uma região. Pode minimizar ainda mais a latência e maximizar o tempo de atividade com o encaminhamento entre regiões, que serve pedidos da região disponível mais próxima do utilizador.

Para os fins deste tutorial, vai configurar um esquema de URL único e não regional que funciona em qualquer parte do mundo, mas que processa os pedidos dos utilizadores a partir da implementação do API Gateway mais próxima. Com esta configuração, os pedidos são encaminhados idealmente para a região que oferece a latência mínima ao utilizador. Caso a região mais próxima esteja indisponível ou com capacidade excessiva, o pedido é encaminhado para uma região diferente para garantir a disponibilidade.

Antes de começar

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

Para este tutorial, implemente o seu serviço em duas regiões diferentes. Por exemplo, pode implementar duas instâncias do API Gateway:

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

Configure autorizações

Neste tutorial, vai criar um grupo de pontos finais de rede (NEG) sem servidor e um balanceador de carga HTTP(S) externo num projeto da Google Cloud. Isto requer a função de proprietário ou editor do projeto, ou as seguintes funções IAM do Compute Engine:

Tarefa	Função necessária
Crie um balanceador de carga e componentes de rede	Administrador da rede
Crie e modifique NEGs	Administrador de instâncias do Compute
Crie e modifique certificados SSL	Administrador de segurança

Crie um recurso de certificado SSL

Para criar um balanceador de carga HTTPS, tem de adicionar um recurso de certificado SSL ao front-end do balanceador de carga. Crie um recurso de certificado SSL usando um certificado SSL gerido pela Google ou um certificado SSL autogerido.

Certificados geridos pela Google. Recomendamos a utilização de certificados geridos pela Google porque Google Cloud obtém, gere e renova estes certificados automaticamente. Para criar um certificado gerido pela Google, tem de ter um domínio e os registos de DNS desse domínio para que o certificado seja aprovisionado. Se ainda não tiver um domínio, pode obtê-lo no Google Domains. Além disso, tem de atualizar o registo A de DNS do domínio para apontar para o endereço IP do equilibrador de carga criado num passo posterior. Para instruções detalhadas, consulte o artigo Usar certificados geridos pela Google.
Certificados autoassinados. Se não quiser configurar um domínio neste momento, pode usar um certificado SSL autoassinado para testes.

Este tutorial pressupõe que já criou um recurso de certificado SSL.

Se quiser testar este processo sem criar um recurso de certificado SSL (ou um domínio, conforme exigido pelos certificados geridos pela Google), pode continuar a usar as instruções nesta página para configurar um balanceador de carga HTTP.

Crie o balanceador de carga HTTP(S)

Crie um NEG sem servidor para cada instância do API Gateway.

Um grupo de pontos finais da rede (NEG) especifica um grupo de pontos finais de back-end para um balanceador de carga. Um NEG sem servidor é um back-end que aponta para um serviço como o API Gateway, 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 criar.
- GATEWAY_ID especifica o nome da gateway.
- REGION_ID é a região de implementaçã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
```
Por 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 este comando para criar um NEG sem servidor para a próxima instância do gateway, usando os valores adequados para a segunda instância do 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 estabelecer ligação aos back-ends, várias definições de distribuição e de sessão, verificações de estado e limites de tempo, conforme mostrado na figura abaixo:

Para criar um serviço de back-end e adicionar o seu NEG sem servidor como 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 no passo anterior.
- REGION_ID é a região de implementaçã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
```
Por 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 este comando para adicionar o segundo NEG sem servidor ao serviço de back-end, usando os valores adequados 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 encaminhar pedidos recebidos para o serviço de back-end, conforme mostrado na figura abaixo:

Para criar o mapa de URLs, execute o seguinte comando, em que:
- URL_MAP_NAME é o nome do mapa de URLs a criar.
- 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
```
Por exemplo:
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
Este mapa de URLs de exemplo segmenta apenas um serviço de back-end que representa um único gateway, pelo que não são necessárias regras de anfitrião nem correspondências de caminhos. Se tiver mais do que um serviço de back-end, pode usar regras de anfitrião para direcionar pedidos para diferentes serviços com base no nome do anfitrião. Use correspondências de caminhos para direcionar pedidos para diferentes serviços com base no caminho do pedido.

Por 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 anfitrião e os correspondentes de caminhos, consulte a documentação do mapa de URLs.
Crie um certificado SSL para o 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 HTTPS de destino. Pode criar um recurso de certificado SSL usando um certificado SSL gerido pela Google ou um certificado SSL autogerido. Recomendamos a utilização de certificados geridos pela Google.

Para criar um certificado gerido pela Google, tem de ter um domínio. Se não tiver um domínio, pode usar um certificado SSL autoassinado para testes.

Para criar um recurso de certificado SSL gerido pela Google:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN
```
Para criar um recurso de certificado SSL autogerido:
```
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 pedidos para o seu 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 criar.
- URL_MAP_NAME é o nome do mapa de URLs criado num passo 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
```
Por 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 os pedidos recebidos para o proxy, conforme mostrado na figura abaixo:

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

Atualize os registos de DNS com o endereço IP do balanceador de carga

Se tiver um domínio personalizado, este passo é necessário para configurar as definições de DNS do seu domínio de modo a apontarem para o novo endereço IP do seu serviço. Também é necessário se tiver criado um balanceador de carga HTTP(S) com um certificado gerido pela Google (que requer um domínio). A atribuição e a utilização de um endereço IP estático são recomendadas quando usadas com o DNS. As instruções específicas para este passo dependem do seu fornecedor de DNS.

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

Para encontrar o endereço IP da sua regra de encaminhamento global, use este comando:
```
gcloud compute forwarding-rules list
```
Atualize o registo DNS A ou AAAA do seu domínio para apontar para o endereço IP do balanceador de carga, de modo que o tráfego enviado para o URL do domínio personalizado existente seja encaminhado através do balanceador de carga. O DNS pode demorar apenas alguns segundos ou até várias horas a propagar esta alteração ao servidor DNS.
Teste para confirmar que o gateway está a receber tráfego através de curl ou visitando o URL no navegador. Por exemplo: https://my-app-domain

Após o teste, deve ver a resposta gerada pelo serviço Cloud Run. Por exemplo, pode ser uma página HTML "Hello World" ou outra resposta esperada gerada diretamente pelo serviço de back-end. Isto significa que o seu pedido está a passar pelo balanceador de carga e que o serviço de back-end está a instruir o balanceador de carga para o enviar para a sua gateway.

Considerações

Antes de implementar uma implementação multirregião do gateway da API, considere o seguinte:

Atualmente, o API Gateway não suporta verificações de estado. Com a configuração de encaminhamento entre regiões descrita acima, se o gateway ou o respetivo serviço de back-end devolver erros numa região, mas a infraestrutura geral do API Gateway na região estiver disponível e tiver capacidade, o balanceador de carga HTTP(S) não redireciona o tráfego para outras regiões.
A combinação de diferentes regiões numa única regra de encaminhamento requer os preços do nível Premium. Para mais informações sobre o cálculo dos preços e da utilização, consulte os preços dos níveis de serviço de rede.

Práticas recomendadas

Quando usar o serviço multirregião, recomendamos que use uma solução de armazenamento de dados gerida replicada globalmente, como o Cloud Spanner, para garantir que todos os dados são geridos globalmente.