Località di Cloud Functions

Cloud Functions è regionale, il che significa che l'infrastruttura che esegue la tua 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 regioni vicine ai tuoi utenti, ma devi anche considerare la posizione degli altri prodotti e servizi utilizzati dalla tua app. L'utilizzo di servizi in più regioni può influire sulla latenza della tua app, nonché sui prezzi.

Per impostazione predefinita, le funzioni vengono eseguite nella regione us-central1. Tieni presente che questa regione potrebbe essere diversa da quella di un'origine evento, ad esempio un bucket Cloud Storage. Scopri come specificare la regione in cui viene eseguita una funzione più avanti in questa pagina.

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 ulteriori informazioni, vedi Energia senza emissioni di CO2 per le regioni Google Cloud.

Prezzi di Livello 1

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

Regione	Località	Versioni del prodotto supportate	Emissioni di CO2
africa-south1	Johannesburg	Solo 2ª gen.
asia-east1	Taiwan	1ª generazione., 2ª generazione.
asia-east2	Hong Kong	Solo 1ª gen.
asia-northeast1	Tokyo	1ª generazione., 2ª generazione.
asia-northeast2	Osaka	1ª generazione., 2ª generazione.
europe-north1	Finlandia	Solo 2ª gen.	energy_savings_leaf
europe-southwest1	Madrid	Solo 2ª gen.
europe-west1	Belgio	1ª generazione., 2ª generazione.	energy_savings_leaf
europe-west4	Paesi Bassi	Solo 2ª gen.
europe-west8	Milano	Solo 2ª gen.
europe-west9	Parigi	Solo 2ª gen.	energy_savings_leaf
me-west1	Tel Aviv	Solo 2ª gen.
europe-west2	Londra	Solo 1ª gen.
us-central1	Iowa	1ª generazione., 2ª generazione.	energy_savings_leaf
us-east1	Carolina del Sud	1ª generazione., 2ª generazione.
us-east4	Virginia del Nord	1ª generazione., 2ª generazione.
us-east5	Columbus	Solo 2ª gen.
us-south1	Dallas	Solo 2ª gen.
us-west1	Oregon	1ª generazione., 2ª generazione.	energy_savings_leaf

Prezzi di Livello 2

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

Regione	Località	Versioni del prodotto supportate	Emissioni di CO2
asia-east2	Hong Kong	Solo 2ª gen.
asia-northeast3	Seul	1ª generazione., 2ª generazione.
asia-southeast1	Singapore	1ª generazione., 2ª generazione.
asia-southeast2	Giacarta	1ª generazione., 2ª generazione.
asia-south1	Mumbai	Solo 2ª gen.
asia-south2	Delhi, India	Solo 2ª gen.
australia-southeast1	Sydney	1ª generazione., 2ª generazione.
australia-southeast2	Melbourne	Solo 2ª gen.
europe-central2	Varsavia	1ª generazione., 2ª generazione.
europe-west2	Londra	Solo 2ª gen.
europe-west3	Francoforte	1ª generazione., 2ª generazione.	energy_savings_leaf
europe-west6	Zurigo	1ª generazione., 2ª generazione.	energy_savings_leaf
europe-west10	Berlino	Solo 2ª gen.
europe-west12	Torino	Solo 2ª gen.
me-central1	Doha	Solo 2ª gen.
me-central2	Dammam	Solo 2ª gen.
northamerica-northeast1	Montreal	1ª generazione., 2ª generazione.	energy_savings_leaf
northamerica-northeast2	Toronto	Solo 2ª gen.	energy_savings_leaf
southamerica-east1	San Paolo	1ª generazione., 2ª generazione.	energy_savings_leaf
southamerica-west1	Santiago, Cile	Solo 2ª gen.
us-west2	Los Angeles	1ª generazione., 2ª generazione.
us-west3	Salt Lake City	1ª generazione., 2ª generazione.
us-west4	Las Vegas	1ª generazione., 2ª generazione.

Le funzioni in una determinata regione di un determinato progetto devono avere nomi univoci (senza distinzione tra maiuscole e minuscole), ma le funzioni in regioni o progetti diversi possono condividere lo stesso nome.

Best practice per specificare una regione

Per impostazione predefinita, le funzioni vengono eseguite nella regione us-central1. Tieni presente che questa regione potrebbe essere diversa da quella di un'origine evento, ad esempio un bucket Cloud Storage. Se devi specificare la regione in cui viene eseguita una funzione, segui i suggerimenti in questa sezione per ogni tipo di trigger della funzione.

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

Node.js

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

Python

# 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 inoltre che, quando specifichi una regione per molti tipi di attivatori in background, devi specificare il filtro eventi corretto insieme alla regione. Nell'esempio riportato sopra, si tratta di Cloud Firestore document che genera l'evento. Per un trigger Cloud Storage il filtro 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 chiamabili, ti consigliamo di impostare prima la funzione sulla regione di destinazione o su quella più vicina a dove si trovano la maggior parte dei clienti previsti, quindi di modificare la funzione originale per reindirizzare la richiesta HTTP alla nuova funzione (possono avere lo stesso nome). Se i client della tua 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 tuoi client non gestiscono bene i reindirizzamenti, puoi proxy 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 chiamabili

Per quanto riguarda la funzione chiamabile, le configurazioni chiamabili dal client devono seguire le stesse linee guida delle funzioni HTTP. Il cliente può anche specificare una regione e deve farlo se la funzione viene eseguita in una regione diversa da us-central1.

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

Swift

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

Objective-C

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

Web

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

Android

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

C++

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

Unity

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 funzioni idempotenti. Se la tua funzione è già idempotente, puoi eseguirne nuovamente il deployment nella nuova regione con lo stesso trigger di eventi e rimuovere la vecchia funzione dopo aver verificato che la nuova funzione riceve correttamente il traffico. Durante questa transizione, entrambe le funzioni riceveranno eventi. Consulta Modificare la regione di una funzione per la sequenza di comandi consigliata per modificare le regioni delle funzioni.

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

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

Tipo di trigger	Consiglio sulla regione
Cloud Firestore	La regione più vicina alla posizione dell'istanza Cloud Firestore (vedi la sezione successiva)
Realtime Database	Sempre us-central1
Cloud Storage	La regione più vicina alla posizione del bucket Cloud Storage (vedi la sezione successiva)
Altro	Se interagisci con un'istanza Realtime Database, un'istanza Cloud Firestore o un bucket Cloud Storage all'interno della funzione, la regione consigliata è la stessa di una funzione attivata da una di queste risorse. In caso contrario, utilizza la regione predefinita us-central1. Le funzioni connesse a Firebase Hosting possono trovarsi in qualsiasi regione, ma consulta la panoramica di hosting serverless per i consigli.

Selezione delle regioni in base alle località Cloud Firestore e Cloud Storage

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

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

Ecco una mappatura delle regioni più vicine supportate dalle funzioni per Cloud Firestore e Cloud Storage, per i casi in cui la stessa regione non è supportata:

Regione/Più regioni per Cloud Firestore e Cloud Storage	Regione più vicina per le funzioni
nam5 o us-central (più regioni)	us-central1
eur3 o europe-west (più regioni)	europe-west1
europe-west4 (Paesi Bassi)	europe-west1
asia-south1 (Mumbai)	asia-east2
asia-south2 (Delhi)	asia-east2
australia-southeast2 (Melbourne)	australia-southeast1