Locais do Cloud Functions

O Cloud Functions é regional. Isso significa que a infraestrutura que executa a função do Cloud está em uma determinada região e é gerenciada pelo Google para estar disponível de modo redundante em todas as zonas dessa região.

Ao selecionar em qual região o Cloud Functions será executado, os principais fatores a serem considerados são a latência e a disponibilidade. Geralmente, é possível selecionar a região mais próxima aos usuários do Cloud Functions, mas você também deve considerar a localização dos outros produtos e serviços do Google Cloud que seu aplicativo usa. O uso de serviços em vários locais pode afetar a latência e o preço do seu aplicativo.

O Cloud Functions está disponível nas seguintes regiões com os preços da Camada 1:

  • us-central1 (Iowa)
  • us-east1 (Carolina do Sul)
  • us-east4 (Virgínia do Norte)
  • europe-west1 (Bélgica)
  • europe-west2 (Londres)
  • asia-east2 (Hong Kong)
  • asia-northeast1 (Tóquio)
  • asia-northeast2 (Osaka)

O Cloud Functions está disponível na região a seguir com os preços da Camada 2:

  • europe-west3 (Frankfurt)
  • europe-west6 (Zurique)
  • us-west3 (Salt Lake City)
  • northamerica-northeast1 (Montreal)
  • australia-southeast1 (Sydney)
  • us-west2 (Los Angeles)
  • us-west4 (Las Vegas)
  • southamerica-east1 (São Paulo)
  • asia-south1 (Mumbai)
  • asia-southeast2 (Jacarta)
  • asia-northeast3 (Seul)

É possível implantar funções em diferentes regiões dentro de um projeto, mas depois que a região tiver sido selecionada para uma função, ela não poderá ser alterada.

É necessário que as funções em uma determinada região em um determinado projeto tenham nomes exclusivos (indiferentes a maiúsculas), mas as funções entre regiões ou entre projetos podem compartilhar o mesmo nome.

Observe que é possível recuperar o conjunto mais recente de locais programaticamente usando o método project.locations/list da API do Cloud Functions.

Como selecionar a região

É possível selecionar uma região para a função durante a implantação.

gcloud

Se estiver usando a ferramenta de linha de comando de gcloud, é possível especificar a região usando a sinalização --region. Por exemplo:

gcloud functions deploy FUNCTION_NAME --region REGION FLAGS...

Em que REGION é uma das regiões listadas acima.

No exemplo acima, FLAGS... se refere a outros argumentos passados durante a implantação da função. Para uma referência completa para o comando deploy, consulte gcloud functions deploy.

Console

Se estiver usando o Console do Cloud, é possível selecionar a região ao criar e implantar uma função.

  1. No Console do Cloud, acesse a página de visão geral do Cloud Functions.

    Acessar a página de visão geral do Cloud Functions

    Verifique se o projeto para que você ativou o Cloud Functions está selecionado.

  2. Clique em Criar função.

  3. Expanda o menu Mais.

  4. Em Região, selecione a região.

Como definir uma região padrão

É possível definir uma região padrão usando a ferramenta de linha de comando gcloud da seguinte maneira:

gcloud config set functions/region REGION

Exemplo:

gcloud config set functions/region europe-west1

Residência dos dados

O Cloud Functions oferece uma garantia de residência de dados no escopo de execução da função (Conformidade de escopo A: execução da função), em que uma determinada função fornece residência de dados para a invocação/execução da função.

Essa conformidade se aplica a funções HTTP e funções em segundo plano. Para funções em segundo plano, o Cloud Functions é compatível com residência de dados desde o momento em que o produto upstream (produto acionador) entrega o evento ao Cloud Functions. Portanto, é importante garantir que o produto upstream (como o Cloud Storage ou o Pub/Sub) seja compatível com a residência de dados.

Práticas recomendadas para alterar a região

Se você precisar alterar uma região em que uma função será implantada, siga as recomendações abaixo.

Funções HTTP

Para funções HTTP, recomendamos reimplantar a função HTTP na região de destino (ela pode ter o mesmo nome) e, em seguida, alterar a função original para redirecionar a solicitação HTTP para a nova função. Se os clientes da função HTTP derem suporte a redirecionamentos, bastará alterar a função original para retornar um status de redirecionamento HTTP (301) com o URL da nova função. Se os clientes não lidarem bem com redirecionamentos, é possível fazer proxy da solicitação da função original para a nova função iniciando uma nova solicitação da função original para a nova. O passo final é garantir que todos os clientes estejam chamando a nova função.

Funções em segundo plano

As funções de segundo plano adotam uma semântica de entrega do evento pelo menos uma vez. Isso significa que, em algumas circunstâncias, elas podem receber eventos duplicados e, portanto, precisam sempre ser implantadas para serem idempotentes. Se sua função já for idempotente, é possível simplesmente reimplantar a função na nova região com o mesmo gatilho de evento e remover a função antiga depois de verificar se a nova função está recebendo tráfego corretamente. Durante essa transição, ambas as funções receberão eventos.

Caso a função não esteja idempotente, ou a idempotência não se estenda além da região, recomendamos implementar a idempotência antes de mover a função.