Trucchi e suggerimenti
Questo documento descrive le best practice per la progettazione, l'implementazione, il test e il deployment di Cloud Run functions.
Correttezza
Questa sezione descrive le best practice generali per la progettazione e l'implementazione di Cloud Run functions.
Scrivere funzioni idempotenti
Le funzioni devono produrre lo stesso risultato anche se vengono chiamate più volte. In questo modo puoi riprovare a eseguire un'invocazione se quella precedente non va a buon fine nel corso del codice. Per ulteriori informazioni, consulta Riprovare le funzioni basate su eventi.
Assicurati che le funzioni HTTP inviino una risposta HTTP
Se la funzione è attivata tramite HTTP, ricordati di inviare una risposta HTTP, come mostrato di seguito. In caso contrario, la funzione potrebbe essere eseguita fino al timeout. In questo caso, ti verrà addebitato l'intero tempo di attesa. I timeout possono anche causare un comportamento imprevedibile o avviamenti a freddo nelle chiamate successive, con conseguente comportamento imprevedibile o latenza aggiuntiva.
Non avviare attività in background
L'attività in background è qualsiasi evento che si verifica dopo il termine della funzione.
Una chiamata alla funzione termina quando la funzione restituisce o indica in altro modo il completamento, ad esempio chiamando l'argomento callback
nelle funzioni basate su eventi di Node.js. Qualsiasi codice eseguito dopo l'interruzione controllata non può accedere alla CPU e non farà alcun progresso.
Inoltre, quando viene eseguita un'invocazione successiva nello stesso ambiente, la tua attività in background riprende, interferendo con la nuova invocazione. Ciò può portare a comportamenti imprevisti ed errori difficili da diagnosticare. L'accesso alla rete al termine di una funzione di solito comporta la reimpostazione delle connessioni (codice di errore ECONNRESET
).
Spesso le attività in background possono essere rilevate nei log delle singole invocazioni, trovandovi tutto ciò che viene registrato dopo la riga che indica il termine dell'invocazione. A volte l'attività in background può essere nascosta più in profondità nel codice, soprattutto quando sono presenti operazioni asincrone come callback o timer. Controlla il codice per assicurarti che tutte le operazioni asincrone vengano completate prima di terminare la funzione.
Eliminare sempre i file temporanei
Lo spazio di archiviazione del disco locale nella directory temporanea è un file system in memoria. I file che scrivi consumano la memoria disponibile per la tua funzione e a volte rimangono tra le chiamate. Se non elimini esplicitamente questi file, potresti incorrere in un errore di esaurimento della memoria e in un successivo avvio a freddo.
Puoi visualizzare la memoria utilizzata da una singola funzione selezionandola nell'elenco delle funzioni nella console Google Cloud e scegliendo il grafico Utilizzo della memoria.
Se hai bisogno di accedere a uno spazio di archiviazione a lungo termine, ti consigliamo di utilizzare i montaggi dei volumi Cloud Run con Cloud Storage o i volumi NFS.
Puoi ridurre i requisiti di memoria durante l'elaborazione di file di grandi dimensioni utilizzando la pipeline. Ad esempio, puoi elaborare un file su Cloud Storage creando uno stream di lettura, facendolo passare attraverso un processo basato su stream e scrivendo lo stream di output direttamente su Cloud Storage.
Framework di Functions
Per assicurarti che le stesse dipendenze vengano installate in modo coerente in tutti gli ambienti, ti consigliamo di includere la libreria Functions Framework nel tuo gestore pacchetti e di bloccare la dipendenza a una versione specifica di Functions Framework.
A tale scopo, includi la versione che preferisci nel file di blocco pertinente (ad esempio package-lock.json
per Node.js o requirements.txt
per Python).
Se Functions Framework non è elencato esplicitamente come dipendenza, verrà aggiunto automaticamente durante il processo di compilazione utilizzando la versione più recente disponibile.
Strumenti
Questa sezione fornisce linee guida su come utilizzare gli strumenti per implementare, testare e interagire con le funzioni Cloud Run.
Sviluppo locale
Il deployment delle funzioni richiede un po' di tempo, quindi spesso è più veloce testare il codice della funzione localmente.
Segnalazione degli errori
Nei linguaggi che utilizzano la gestione delle eccezioni, non lanciare eccezioni non rilevate, perché forzano gli avvii a freddo nelle invocazioni future. Per informazioni su come segnalare correttamente gli errori, consulta la guida di Error Reporting.
Non uscire manualmente
L'uscita manuale può causare comportamenti imprevisti. Utilizza invece le seguenti espressioni idiomatiche specifiche per lingua:
Non utilizzare process.exit()
. Le funzioni HTTP devono inviare una risposta con res.status(200).send(message)
e le funzioni basate sugli eventi usciranno al loro ritorno (implicitamente o esplicitamente).
Non utilizzare sys.exit()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi usciranno una volta
che avranno restituito un valore (implicitamente o esplicitamente).
Non utilizzare os.Exit()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi usciranno una volta
che avranno restituito un valore (implicitamente o esplicitamente).
Non utilizzare System.exit()
. Le funzioni HTTP devono inviare una risposta con response.getWriter().write(message)
e le funzioni basate sugli eventi usciranno al loro ritorno (implicitamente o esplicitamente).
Non utilizzare System.Environment.Exit()
. Le funzioni HTTP devono inviare una risposta con context.Response.WriteAsync(message)
e le funzioni basate sugli eventi usciranno al loro ritorno (implicitamente o esplicitamente).
Non utilizzare exit()
o abort()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi usciranno una volta
che avranno restituito un valore (implicitamente o esplicitamente).
Non utilizzare exit()
o die()
. Le funzioni HTTP devono restituire esplicitamente
una risposta come stringa e le funzioni basate su eventi usciranno una volta
che avranno restituito un valore (implicitamente o esplicitamente).
Utilizzare SendGrid per inviare email
Le funzioni Cloud Run non consentono connessioni in uscita sulla porta 25, pertanto non puoi effettuare connessioni non sicure a un server SMTP. Il modo consigliato per inviare email è utilizzare un servizio di terze parti come SendGrid. Puoi trovare altre opzioni per l'invio di email nel tutorial Invio di email da un'istanza per Google Compute Engine.
Prestazioni
Questa sezione descrive le best practice per ottimizzare il rendimento.
Evita una concorrenza ridotta
Poiché gli avvii completi sono costosi, la possibilità di riutilizzare le istanze avviate di recente durante un picco è un'ottima ottimizzazione per gestire il carico. La limitazione della concorrenza limita il modo in cui è possibile utilizzare le istanze esistenti, con un conseguente aumento degli avvii a freddo.
L'aumento della concorrenza contribuisce a rimandare più richieste per istanza, facilitando la gestione degli picchi di carico. Nota: la concorrenza delle funzioni di 1ª generazione è limitata a 1. Ti consigliamo di eseguire la migrazione a Cloud Run Functions.Utilizza le dipendenze in modo oculato
Poiché le funzioni sono senza stato, l'ambiente di esecuzione viene spesso inizializzato da zero (durante quello che viene chiamato avvio a freddo). Quando si verifica un avvio a freddo, viene valutato il contesto globale della funzione.
Se le funzioni importano moduli, il tempo di caricamento di questi moduli può aumentare la latenza di chiamata durante un avvio a freddo. Puoi ridurre questa latenza, nonché il tempo necessario per eseguire il deployment della funzione, caricando correttamente le dipendenze e non caricando quelle che la funzione non utilizza.
Utilizza le variabili globali per riutilizzare gli oggetti nelle chiamate future
Non è garantito che lo stato di una funzione Cloud Run verrà conservato per le chiamate future. Tuttavia, Cloud Run Functions spesso ricicla l'ambiente di esecuzione di un'invocazione precedente. Se dichiari una variabile in ambito globale, il suo valore può essere riutilizzato nelle chiamate successive senza dover essere ricalcolato.
In questo modo puoi memorizzare nella cache gli oggetti che potrebbero essere costosi da ricreare a ogni chiamata della funzione. Spostare questi oggetti dal corpo della funzione all'ambito globale può comportare miglioramenti significativi del rendimento. L'esempio seguente crea un oggetto pesante una sola volta per istanza di funzione e lo condivide tra tutte le chiamate di funzione che raggiungono l'istanza specificata:
È particolarmente importante memorizzare nella cache le connessioni di rete, i riferimenti alle librerie e gli oggetti client dell'API a livello globale. Per esempi, consulta Ottimizzare il networking.
Riduci gli avvii a freddo impostando un numero minimo di istanze
Per impostazione predefinita, le funzioni Cloud Run adattano il numero di istanze in base al numero di richieste in entrata. Puoi modificare questo comportamento predefinito impostando un numero minimo di istanze che le funzioni Cloud Run devono mantenere pronte per gestire le richieste. L'impostazione di un numero minimo di istanze riduce gli avvii a freddo della tua applicazione. Se la tua applicazione è sensibile alla latenza, ti consigliamo di impostare un numero minimo di istanze e di completare l'inizializzazione al momento del caricamento.
Per scoprire come impostare un numero minimo di istanze, consulta Utilizzare le istanze minime.
Note sull'avvio a freddo e sull'inizializzazione
L'inizializzazione globale avviene al momento del caricamento. In caso contrario, la prima richiesta dovrebbe completare l'inizializzazione e caricare i moduli, con una conseguente latenza più elevata.
Tuttavia, l'inizializzazione globale influisce anche sugli avvii a freddo. Per ridurre al minimo questo impatto, inizializza solo ciò che è necessario per la prima richiesta, in modo da mantenere la latenza della prima richiesta il più bassa possibile.
Questo è particolarmente importante se hai configurato le istanze minime come descritto sopra per una funzione sensibile alla latenza. In questo scenario, il completamento dell'inizializzazione al momento del caricamento e la memorizzazione nella cache dei dati utili assicurano che la prima richiesta non debba essere eseguita e venga eseguita con bassa latenza.
Se inizializzi le variabili a livello globale, a seconda del linguaggio, i tempi di inizializzazione lunghi possono comportare due comportamenti: - per alcune combinazioni di linguaggi e librerie asincrone, il framework di funzioni può essere eseguito in modo asincrono e restituire immediatamente, causando il proseguimento dell'esecuzione del codice in background, il che potrebbe causare problemi come la mancata possibilità di accedere alla CPU. Per evitare ciò, devi bloccare l'inizializzazione del modulo come descritto di seguito. In questo modo, le richieste non vengono inviate finché l'inizializzazione non è completata. - d'altra parte, se l'inizializzazione è sincrona, il tempo di inizializzazione lungo causerà avvii a freddo più lunghi, il che potrebbe essere un problema soprattutto con le funzioni a bassa concorrenza durante i picchi di carico.
Esempio di preriscaldamento di una libreria Node.js asincrona
Node.js con Firestore è un esempio di libreria Node.js asincrona. Per usufruire di min_instances, il codice seguente completa il caricamento e l'inizializzazione al momento del caricamento, bloccandosi sul caricamento del modulo.
Viene utilizzato TLA, il che significa che è richiesto ES6, utilizzando un'estensione .mjs
per il codice node.js o aggiungendo type: module
al file package.json.
{ "main": "main.js", "type": "module", "dependencies": { "@google-cloud/firestore": "^7.10.0", "@google-cloud/functions-framework": "^3.4.5" } }
import Firestore from '@google-cloud/firestore'; import * as functions from '@google-cloud/functions-framework'; const firestore = new Firestore({preferRest: true}); // Pre-warm firestore connection pool, and preload our global config // document in cache. In order to ensure no other request comes in, // block the module loading with a synchronous global request: const config = await firestore.collection('collection').doc('config').get(); functions.http('fetch', (req, res) => { // Do something with config and firestore client, which are now preloaded // and will execute at lower latency. });
Esempi di inizializzazione globale
Le funzioni PHP non possono conservare le variabili tra le richieste. Il campione di ambiti riportato sopra utilizza il caricamento lento per memorizzare nella cache i valori delle variabili globali in un file.
Questo è particolarmente importante se definisci più funzioni in un unico file e le funzioni diverse utilizzano variabili diverse. A meno che non utilizzi l'inizializzazione dinamica, potresti sprecare risorse per variabili inizializzate, ma mai utilizzate.
Risorse aggiuntive
Scopri di più sull'ottimizzazione del rendimento nel video "Google Cloud Performance Atlas" Tempo di avvio a freddo delle funzioni Cloud Run.