Cloud Functions è regionale, il che significa che l'infrastruttura che esegue la funzione si trova in regioni specifiche ed è gestita da Google in modo da 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 prendere in considerazione la posizione di 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 può 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, consulta Energia a zero emissioni di CO2 per le regioni Google Cloud.
Prezzi di Livello 1
Cloud Functions è disponibile nelle seguenti regioni con prezzi di Livello 1:
| Regione | Località | Versioni dei prodotti supportate | Emissioni di CO2 |
|---|---|---|---|
asia-east1 |
Taiwan | 1ª gen., 2ª gen. | |
asia-east2 |
Hong Kong | Solo 1ª gen. | |
asia-northeast1 |
Tokyo | 1ª gen., 2ª gen. | |
asia-northeast2 |
Osaka | 1ª gen., 2ª gen. | |
europe-north1 |
Finlandia | Solo 2ª gen. | energy_savings_leaf |
europe-southwest1 |
Madrid | Solo 2ª gen. | |
europe-west1 |
Belgio | 1ª gen., 2ª gen. | 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ª gen., 2ª gen. | energy_savings_leaf |
us-east1 |
Carolina del Sud | 1ª gen., 2ª gen. | |
us-east4 |
Virginia del Nord | 1ª gen., 2ª gen. | |
us-east5 |
Columbus | Solo 2ª gen. | |
us-south1 |
Dallas | Solo 2ª gen. | |
us-west1 |
Oregon | 1ª gen., 2ª gen. | energy_savings_leaf |
Prezzi di Livello 2
Cloud Functions è disponibile nelle seguenti regioni con prezzi di Livello 2:
| Regione | Località | Versioni dei prodotti supportate | Emissioni di CO2 |
|---|---|---|---|
asia-east2 |
Hong Kong | Solo 2ª gen. | |
asia-northeast3 |
Seul | 1ª gen., 2ª gen. | |
asia-southeast1 |
Singapore | 1ª gen., 2ª gen. | |
asia-southeast2 |
Giacarta | 1ª gen., 2ª gen. | |
asia-south1 |
Mumbai | Solo 2ª gen. | |
asia-south2 |
Delhi, India | Solo 2ª gen. | |
australia-southeast1 |
Sydney | 1ª gen., 2ª gen. | |
australia-southeast2 |
Melbourne | Solo 2ª gen. | |
europe-central2 |
Varsavia | 1ª gen., 2ª gen. | |
europe-west2 |
Londra | Solo 2ª gen. | |
europe-west3 |
Francoforte | 1ª gen., 2ª gen. | energy_savings_leaf |
europe-west6 |
Zurigo | 1ª gen., 2ª gen. | 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ª gen., 2ª gen. | energy_savings_leaf |
northamerica-northeast2 |
Toronto | Solo 2ª gen. | energy_savings_leaf |
southamerica-east1 |
San Paolo | 1ª gen., 2ª gen. | energy_savings_leaf |
southamerica-west1 |
Santiago, Cile | Solo 2ª gen. | |
us-west2 |
Los Angeles | 1ª gen., 2ª gen. | |
us-west3 |
Salt Lake City | 1ª gen., 2ª gen. | |
us-west4 |
Las Vegas | 1ª gen., 2ª gen. |
Le funzioni in una determinata regione di un determinato progetto devono avere nomi univoci (non sensibili alle maiuscole), ma le funzioni in più regioni o in più progetti possono condividere lo stesso nome.
Best practice per la specifica di una regione
Per impostazione predefinita, le funzioni vengono eseguite nella regione us-central1. Tieni presente che questa regione può 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
consigli riportati in questa sezione per ogni tipo di attivatore della funzione.
Per impostare la regione in cui viene eseguita una funzione, imposta il parametro region nella
definizione della funzione come mostrato:
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 inoltre presente che, quando specifichi una regione per molti tipi di attivatori in background, devi specificare anche il filtro evento corretto. Nell'esempio precedente, è Cloud Firestore document
che emette l'evento. Per un trigger Cloud Storage, il filtro eventi potrebbe essere bucket; per un trigger Pub/Sub, sarà topic e così via.
Per saperne di più sulla modifica della 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 sulla regione di destinazione o sulla più vicina a quella in cui si trovano la maggior parte dei clienti previsti, quindi di modificare la funzione originale per reindirizzare la relativa richiesta HTTP alla nuova funzione (che può 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 clienti non gestiscono bene i reindirizzamenti, puoi eseguire il proxy della 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 us-central1.
Per impostare le regioni sul client, specifica la regione desiderata all'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 invio di 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 eseguire nuovamente il deployment nella nuova regione con lo stesso attivatore evento e rimuovere la vecchia funzione dopo aver verificato che la nuova funzione riceva correttamente il traffico. Durante questa transizione, entrambe le funzioni riceveranno eventi. Consulta modificare la regione di una funzione per la sequenza consigliata di comandi per modificare le regioni delle funzioni.
Se la tua funzione non è attualmente idempotente o se la sua idempotenza non si estende oltre la regione, ti consigliamo di implementare prima l'idempotenza prima di spostare la funzione.
I consigli per le regioni ottimali variano in base al tipo di trigger evento:
| Tipo di trigger | Consiglio per la regione |
|---|---|
| Cloud Firestore | Regione più vicina alla posizione dell'istanza Cloud Firestore (vedi la sezione successiva) |
| Realtime Database | Sempre us-central1 |
| Cloud Storage | 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 che avresti se avessi una funzione attivata da una di queste risorse. In caso contrario, utilizza la regione predefinita us-central1.
Le funzioni collegate a Firebase Hosting possono trovarsi in qualsiasi regione, ma consulta la panoramica dell'hosting serverless per ricevere consigli. |
Selezionare le regioni in base alle località Cloud Firestore e Cloud Storage
Le regioni disponibili per le funzioni non corrispondono sempre esattamente alle regioni disponibili per il database Cloud Firestore e i bucket Cloud Storage.
Tieni presente che se la funzione e la risorsa (istanza di database o Cloud Storage bucket) si trovano in località diverse, potresti notare una maggiore latenza e un aumento dei costi di fatturazione.
Ecco una mappatura delle regioni con le funzioni supportate più vicine per Cloud Firestore e Cloud Storage, per i casi in cui la stessa regione non sia 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 |