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 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, il deployment viene in genere eseguito in una regione all'interno della regione dell'origine dati di attivazione (ad esempio un database Cloud Firestore o un bucket Cloud Storage) e, come fallback, 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 una regione diversa, puoi modificare la regione.

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 anidride carbonica. Per saperne di più, consulta Energia a zero emissioni di CO2 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 (senza distinzione tra maiuscole e minuscole), ma le funzioni in regioni o progetti diversi possono condividere lo stesso nome.

Best practice per la specifica di 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, il deployment viene in genere eseguito in una regione all'interno della regione dell'origine dati di attivazione (come un database Cloud Firestore o un bucket Cloud Storage) e, come fallback, in us-central1.

Ti consigliamo di impostare regioni specifiche anziché fare affidamento sulle impostazioni predefinite di Firebase, che potrebbero cambiare nel tempo. Quando imposti le regioni, segui i suggerimenti 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 inoltre che, quando specifichi una regione per molti tipi di trigger in background, devi specificare il filtro eventi corretto insieme alla regione. Nell'esempio precedente, si tratta di Cloud Firestore document che emette 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ù sulla modifica della regione per una funzione che gestisce il traffico di produzione, consulta Modifica 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 su quella più vicina alla posizione della 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 "at least once", il che significa che in alcune circostanze possono ricevere eventi duplicati. Pertanto, devi implementare le funzioni in modo che siano idempotenti. Se la funzione è già idempotente, puoi rifare 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. Consulta Modifica la regione di una funzione per la sequenza di comandi consigliata per modificare le regioni delle funzioni.

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 suggerimenti per la regione ottimale variano in base al tipo di trigger di evento:

Selezione delle 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 tuo database Cloud Firestore e i tuoi bucket Cloud Storage.

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

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