Locais do Cloud Functions

O Cloud Functions é regional , o que significa que a infraestrutura que executa seu Cloud Function está localizada em regiões específicas e é gerenciada pelo Google para estar disponível de forma redundante em todas as zonas dessas regiões .

Ao selecionar em quais regiões executar suas funções, suas principais considerações devem ser a latência e a disponibilidade. Geralmente, você pode selecionar regiões próximas aos seus usuários, mas também deve considerar a localização de outros produtos e serviços que seu aplicativo usa. O uso de serviços em várias regiões pode afetar a latência do seu aplicativo, bem como os preços .

Regiões suportadas

Nas listas desta secção, o ícone energy_ savings_leaf indica que a eletricidade para esta região é produzida com baixas emissões de carbono. Para obter mais informações, consulte Energia livre de carbono para regiões do Google Cloud .

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

• asia-east1 (Taiwan)
• asia-east2 (Hong Kong) apenas 1ª geração
• asia-northeast1 (Tóquio)
• asia-northeast2 (Osaka)
• europe-north1 (Finlândia) energy_ savings_leaf apenas 2ª geração
• europe-west1 (Bélgica) energy_ savings_leaf
• europe-west2 (Londres) apenas 1ª geração
• us-central1 (Iowa) energy_ savings_leaf
• us-east1 (Carolina do Sul)
• us-east4 (Norte da Virgínia)
• us-west1 (Oregon) energy_ savings_leaf

O Cloud Functions está disponível nas seguintes regiões com preços de nível 2 :

• asia-east2 (Hong Kong) apenas 2ª geração
• asia-northeast3 (Seul)
• asia-southeast1 (Cingapura)
• asia-southeast2 (Jacarta)
• asia-south1 (Mumbai) apenas 2ª geração
• australia-southeast1 (Sydney)
• australia-southeast2 (Melbourne) apenas 2ª geração
• europe-central2 (Varsóvia)
• europe-west2 (Londres) apenas 2ª geração
• europe-west3 (Frankfurt)
• europe-west6 (Zurique) energy_ savings_leaf
• northamerica-northeast1 (Montreal) energy_ savings_leaf
• northamerica-northeast2 (Toronto) energy_ savings_leaf somente 2ª geração
• southamerica-east1 (São Paulo) energy_ savings_leaf
• southamerica-west1 (Santiago, Chile) somente 2ª geração
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

As funções em uma determinada região em um determinado projeto devem ter nomes exclusivos (sem distinção entre maiúsculas e minúsculas), mas as funções entre regiões ou entre projetos podem compartilhar o mesmo nome.

Melhores práticas para especificar uma região

Por padrão, as funções são executadas na região us-central1 . Observe que isso pode ser diferente da região de uma fonte de evento, como um bucket do Cloud Storage. Se precisar especificar a região onde uma função é executada, siga as recomendações nesta seção para cada tipo de gatilho de função.

Para definir a região onde uma função é executada, defina o parâmetro region na definição da função conforme mostrado:

exports.firestoreAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

Você pode especificar diversas regiões passando diversas sequências de regiões separadas por vírgula em region . Observe também que, ao especificar uma região para muitos tipos de acionadores em segundo plano, você precisará especificar o filtro de eventos correto junto com a região. No exemplo acima, este é o document do Cloud Firestore que emite o evento. Para um acionador do Cloud Storage, o filtro de evento pode ser bucket ; para um gatilho do Pub/Sub, seria topic e assim por diante.

Consulte alterar a região de uma função para obter mais informações sobre como alterar a região de uma função que lida com o tráfego de produção.

Funções HTTP e que podem ser chamadas pelo cliente

Para funções HTTP e que podem ser chamadas, recomendamos que você primeiro defina sua função para a região de destino, ou mais próxima de onde os clientes mais esperados estão localizados, e então altere sua função original para redirecionar sua solicitação HTTP para a nova função (eles podem ter o mesmo nome). Se os clientes da sua função HTTP suportam redirecionamentos, você pode simplesmente alterar sua função original para retornar um status de redirecionamento HTTP (301) junto com o URL da sua nova função. Se seus clientes não lidam bem com redirecionamentos, você pode 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 função. A etapa final é garantir que todos os clientes estejam chamando a nova função.

Seleção de localização do lado do cliente para funções que podem ser chamadas

Em relação à função que pode ser chamada, as configurações que podem ser chamadas pelo cliente devem seguir as mesmas diretrizes das funções HTTP. O cliente também pode especificar uma região, e deverá fazê-lo se a função for executada em qualquer região diferente de us-central1 .

Para definir regiões no cliente, especifique a região desejada na inicialização:

lazy var functions = Functions.functions(region:"europe-west1")

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];

var functions = firebase.app().functions('europe-west1');

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");

Funções de fundo

As funções de segundo plano adotam uma semântica de entrega de eventos pelo menos uma vez, o que significa que, em algumas circunstâncias, elas podem receber eventos duplicados. Portanto, você deve implementar funções para serem idempotentes . Se sua função já for idempotente, você poderá 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 esta transição, ambas as funções receberão eventos. Consulte alterar a região de uma função para obter a sequência recomendada de comandos para alterar as regiões das funções.

Se a sua função não for atualmente idempotente ou se sua idempotência não se estender além da região, recomendamos que você primeiro implemente a idempotência antes de mover a função.

As recomendações de região ideal diferem de acordo com o tipo de acionador de evento:

Seleção de regiões com base nos locais do Cloud Firestore e do Cloud Storage

As regiões disponíveis para funções nem sempre correspondem exatamente às regiões disponíveis para seu banco de dados do Cloud Firestore e seus buckets do Cloud Storage.

Observe que se sua função e seu recurso (instância de banco de dados ou intervalo do Cloud Storage) estiverem em locais diferentes, você poderá enfrentar aumento na latência e nos custos de faturamento .

Aqui está um mapeamento das regiões com suporte de funções mais próximas para Cloud Firestore e Cloud Storage, para casos em que a mesma região não é compatível: