Località di Cloud Functions

Cloud Functions è regionale, il che significa che l'infrastruttura che esegue la funzione si trova in regioni specifiche ed è gestita da Google per essere disponibile in modo ridondante in tutte le zone all'interno di queste regioni.

Quando selezioni le regioni in cui eseguire le funzioni, le considerazioni principali devono essere la latenza e la disponibilità. In genere puoi selezionare le regioni vicine ai tuoi utenti, ma devi anche considerare la posizione degli altri prodotti e servizi utilizzati dall'app. L'utilizzo di servizi in più regioni può influire sulla latenza dell'app, nonché sui prezzi.

Per impostazione predefinita, l'interfaccia a riga di comando di Firebase esegue il deployment delle funzioni in una regione in base alla configurazione del progetto. Per le funzioni basate su eventi, in genere esegue il deployment in una regione nell'origine dati di attivazione (ad esempio un database Cloud Firestore o Cloud Storage bucket) e, come fallback, esegue il deployment in us-central1.

Dopo il deployment, puoi verificare la regione nella console Firebase o eseguendo firebase functions:list. Se vuoi che la funzione venga eseguita in un altra regione, puoi modificarla.

Aree geografiche supportate

Negli elenchi di questa sezione, l'icona energy_savings_leaf indica che l'elettricità per questa regione viene prodotta con basse emissioni di carbonio. Per saperne di più, consulta Energia a zero emissioni di carbonio per le regioni Google Cloud.

Prezzi del livello 1

Cloud Functions è disponibile nelle seguenti regioni con prezzi del livello 1:

Prezzi del livello 2

Cloud Functions è disponibile nelle seguenti regioni con prezzi del livello 2:

Le funzioni in una determinata regione di un progetto specifico devono avere nomi univoci (non sensibili alle maiuscole), ma le funzioni in regioni o progetti diversi possono condividere lo stesso nome.

Best practice per specificare una regione

Per impostazione predefinita, l'interfaccia a riga di comando di Firebase esegue il deployment delle funzioni in una regione in base alla configurazione del progetto. Per le funzioni basate su eventi, in genere esegue il deployment in una regione nell'origine dati di attivazione (ad esempio un database Cloud Firestore o Cloud Storage bucket) e, come fallback, esegue il deployment in us-central1.

Ti consigliamo di impostare regioni specifiche anziché affidarti alle impostazioni predefinite di Firebase, che potrebbero cambiare nel tempo. Quando imposti le regioni, segui i consigli riportati in questa sezione per ogni tipo di trigger.

Per impostare la regione in cui viene eseguita una funzione, imposta il parametro region nella definizione della funzione come mostrato di seguito:

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

Puoi specificare più regioni passando più stringhe di regioni separate da virgole in region. Tieni presente che, quando specifichi una regione per molti tipi di trigger in background, dovrai specificare il filtro di eventi corretto insieme alla regione. Nell'esempio precedente, si tratta del Cloud Firestore document che emette l'evento. Per un trigger Cloud Storage, il filtro di eventi potrebbe essere bucket; per un trigger Pub/Sub sarebbe topic e così via.

Per saperne di più su come modificare la regione di una funzione che gestisce il traffico di produzione, consulta Modificare la regione di una funzione.

Funzioni HTTP e richiamabili dal client

Per le funzioni HTTP e richiamabili, ti consigliamo di impostare prima la funzione nella regione di destinazione o nella regione più vicina a quella in cui si trovano la maggior parte dei clienti previsti, quindi di modificare la funzione originale in modo da reindirizzare la richiesta HTTP alla nuova funzione (possono avere lo stesso nome). Se i client della funzione HTTP supportano i reindirizzamenti, puoi semplicemente modificare la funzione originale in modo che restituisca uno stato di reindirizzamento HTTP (301) insieme all'URL della nuova funzione. Se i client non gestiscono bene i reindirizzamenti, puoi delegare la richiesta dalla funzione originale alla nuova funzione avviando una nuova richiesta dalla funzione originale alla nuova funzione. Il passaggio finale consiste nell'assicurarsi che tutti i client chiamino la nuova funzione.

Selezione della località lato client per le funzioni richiamabili

Per quanto riguarda la funzione richiamabile, le configurazioni richiamabili dal client devono seguire le stesse linee guida delle funzioni HTTP. Il client può anche specificare una regione e deve farlo se la funzione viene eseguita in una regione diversa da quella predefinita del progetto.

Per impostare le regioni sul client, specifica la regione desiderata durante l'inizializzazione:

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

Funzioni in background

Le funzioni in background adottano una semantica di distribuzione degli eventi almeno una volta, il che significa che in alcune circostanze potrebbero ricevere eventi duplicati. Pertanto, devi implementare le funzioni in modo che siano idempotenti. Se la funzione è già idempotente, puoi rieseguirne il deployment nella nuova regione con lo stesso trigger di eventi e rimuovere la vecchia funzione, dopo aver verificato che quella nuova riceve correttamente il traffico. Durante questa transizione, entrambe le funzioni riceveranno eventi. Per la sequenza di comandi consigliata per modificare le regioni delle funzioni, consulta Modificare la regione di una funzione.

Se la funzione non è attualmente idempotente o la sua idempotenza non si estende oltre la regione, ti consigliamo di implementare l'idempotenza prima di spostare la funzione.

I consigli sulle regioni ottimali variano in base al tipo di trigger di eventi:

Selezionare le regioni in base alle località di Cloud Firestore e Cloud Storage

Le regioni disponibili per le funzioni non corrispondono sempre esattamente alle regioni disponibili per il Cloud Firestore database e i Cloud Storage bucket.

Tieni presente che se la funzione e la risorsa (istanza del database o Cloud Storage bucket) si trovano in località diverse, potresti notare una maggiore latenza e un aumento dei costi fatturati.

Di seguito è riportata una mappatura delle regioni supportate dalle funzioni più vicine a Cloud Firestore e Cloud Storage, nei casi in cui la stessa regione non è supportata: