Comprendere il ciclo di vita dell'ambiente di esecuzione Lambda

Lambda richiama la funzione in un ambiente di esecuzione, che fornisce un ambiente di runtime sicuro e isolato. L'ambiente di esecuzione gestisce le risorse necessarie per eseguire la funzione. L'ambiente di esecuzione fornisce inoltre il supporto del ciclo di vita per il runtime della funzione e per tutte le estensioni esterne associate alla funzione.

Il runtime della funzione comunica con Lambda e usa l'API Runtime. Le estensioni comunicano con Lambda utilizzando le API estensioni. Le estensioni possono anche ricevere messaggi di log e altra telemetria dalla funzione tramite l'API di telemetria.

Quando si crea la funzione Lambda, si specificano le informazioni di configurazione, ad esempio la quantità di memoria disponibile e il tempo massimo di esecuzione consentito per la funzione. Lambda utilizza queste informazioni per impostare l'ambiente di esecuzione.

Il runtime della funzione e ogni estensione esterna sono processi eseguiti all'interno dell'ambiente di esecuzione. Le autorizzazioni, le risorse, le credenziali e le variabili di ambiente sono condivise tra la funzione e le estensioni.

Ciclo di vita dell'ambiente di esecuzione Lambda

Ogni fase inizia con un evento che Lambda invia al runtime e a tutte le estensioni registrate. Il runtime e ogni estensione indicano il completamento inviando una richiesta API Next. Lambda congela l'ambiente di esecuzione quando il runtime e ogni estensione sono stati completati e non ci sono eventi in sospeso.

Fase di init

Nella fase Init, Lambda esegue tre incarichi:

La fase Init termina quando il runtime e tutte le estensioni segnalano che sono pronti inviando una richiesta Next API. La fase Init è limitata a 10 secondi. Se tutte e tre le attività non vengono completate entro 10 secondi, Lambda ritenta la fase Init al momento della prima chiamata di funzione con timeout della funzione configurata.

Quando Lambda SnapStart è attivato, la fase Init si verifica quando si pubblica una versione della funzione. Lambda salva uno snapshot della memoria e dello stato del disco dell'ambiente di esecuzione inizializzato, mantiene lo snapshot crittografato e lo memorizza nella cache per l'accesso a bassa latenza. Se disponi di un hook di runtime prima del checkpoint, il codice viene eseguito alla fine della fase Init.

Quando utilizzi la simultaneità fornita, Lambda inizializza l'ambiente di esecuzione quando configuri le impostazioni del PC per una funzione. Lambda, inoltre, garantisce che gli ambienti di esecuzione inizializzati siano sempre disponibili prima delle invocazioni. Potrebbero verificarsi lacune tra l'invocazione della funzione e le fasi di inizializzazione. A seconda del runtime della funzione e della configurazione della memoria, può anche verificarsi una latenza delle variabili nella prima invocazione in un ambiente di esecuzione inizializzato.

Per le funzioni che utilizzano la simultaneità on demand, Lambda può inizializzare occasionalmente gli ambienti di esecuzione prima delle richieste di invocazione. Quando ciò si verifica, puoi riscontrare una lacuna temporale tra le fasi di inizializzazione e invocazione della funzione. È preferibile non acquisire dipendenza da questo comportamento.

Errori durante la fase di inizializzazione

Se una funzione si arresta in modo anomalo o si verifica un timeout durante la fase Init, Lambda emette informazioni sull'errore nel log INIT_REPORT.

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout

INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash

Se la Init fase ha esito positivo, Lambda non emette il INIT_REPORT registro a meno che non SnapStartsia abilitata la concorrenza fornita. SnapStart e le funzioni di concorrenza predisposte vengono sempre emesse. INIT_REPORT Per ulteriori informazioni, consulta Monitoraggio per Lambda SnapStart.

Fase di ripristino (solo Lambda SnapStart )

Quando richiami una SnapStartfunzione per la prima volta e man mano che la funzione aumenta, Lambda riprende i nuovi ambienti di esecuzione dall'istantanea persistente invece di inizializzare la funzione da zero. Se disponi di un hook di runtime post-ripristino, il codice viene eseguito alla fine della fase. Restore Ti viene addebitata la durata degli hook di runtime post-ripristino. Il runtime deve essere caricato e gli hook di runtime dopo il ripristino devono essere completati entro il limite di timeout (10 secondi). Altrimenti, otterrai un. SnapStartTimeoutException Al termine della fase Restore, Lambda chiama il gestore della funzione (Invoca fase).

Errori durante la fase di ripristino

Se la fase Restore fallisce, Lambda emette informazioni sull'errore nel log RESTORE_REPORT.

RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout

RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError

Per ulteriori informazioni sul log RESTORE_REPORT, consulta la pagina Monitoraggio per Lambda SnapStart.

Invoca fase

Quando una funzione Lambda viene richiamata in risposta a una richiesta API Next, Lambda invia un evento Invoke al runtime e a ogni estensione.

L'impostazione di timeout della funzione limita la durata dell'intera fase Invoke. Ad esempio, se si imposta il timeout della funzione come 360 secondi, la funzione e tutte le estensioni devono essere completate entro 360 secondi. Si noti che non esiste una fase post-richiamo indipendente. La durata è la somma di tutto il tempo di chiamata (runtime + estensioni) e non viene calcolata fino a quando la funzione e tutte le estensioni non hanno terminato l'esecuzione.

La fase di richiamo termina dopo il runtime e tutte le estensioni segnalano che vengono eseguite inviando una richiesta Next API.

Errori durante la fase di richiamo

Se la funzione Lambda si arresta in modo anomalo o si verifica un timeout durante la fase Invoke, Lambda reimposta l'ambiente di esecuzione. Il diagramma seguente mostra il comportamento dell'ambiente di esecuzione Lambda in caso di errore di invocazione:

Nel diagramma precedente:

Fase di arresto

Quando Lambda sta per chiudere il runtime, invia un evento Shutdown a ciascuna estensione esterna registrata. Le estensioni possono utilizzare questo tempo per le attività di pulizia finali. L'evento Shutdown è una risposta a una richiesta API Next.

Durata: L'intera fase Shutdown è limitata a 2 secondi. Se il runtime o qualsiasi estensione non risponde, Lambda lo termina tramite un segnale (SIGKILL).

Dopo che la funzione e tutte le estensioni sono state completate, Lambda mantiene l'ambiente di esecuzione per qualche tempo in previsione di un'altra chiamata di funzione. Tuttavia, Lambda termina gli ambienti di esecuzione ogni poche ore per consentire gli aggiornamenti e la manutenzione del runtime, anche per le funzioni che vengono richiamate continuamente. Non si deve dare per scontato che l'ambiente di esecuzione persista all'infinito. Per ulteriori informazioni, consulta Implementa l'apolidia nelle funzioni.

Quando la funzione viene richiamata di nuovo, Lambda scongela l'ambiente per il riutilizzo. Il riutilizzo dell'ambiente di esecuzione ha le seguenti implicazioni:

Avvii a freddo e latenza

Quando Lambda riceve una richiesta di esecuzione di una funzione tramite l'API Lambda, il servizio prepara innanzitutto un ambiente di esecuzione. Durante questa fase di inizializzazione, il servizio scarica il codice, avvia l'ambiente ed esegue qualsiasi codice di inizializzazione al di fuori del gestore principale. Infine, Lambda esegue il codice del gestore.

In questo diagramma, i primi due passaggi del download del codice e della configurazione dell'ambiente vengono spesso definiti «avvio a freddo». Non ti viene addebitato alcun costo per questo periodo, ma ciò aggiunge latenza alla durata complessiva della chiamata.

Una volta completata la chiamata, l'ambiente di esecuzione viene bloccato. Per migliorare la gestione delle risorse e le prestazioni, Lambda conserva l'ambiente di esecuzione per un periodo di tempo. Durante questo periodo, se arriva un'altra richiesta per la stessa funzione, Lambda può riutilizzare l'ambiente. Questa seconda richiesta in genere termina più rapidamente, poiché l'ambiente di esecuzione è già completamente configurato. Questo procedimento è chiamato "avvio a caldo".

Gli avviamenti a freddo si verificano in genere in meno dell'1% delle invocazioni. La durata di un avvio a freddo varia da meno di 100 ms a oltre 1 secondo. In generale, gli avviamenti a freddo sono in genere più comuni nelle funzioni di sviluppo e test rispetto ai carichi di lavoro di produzione. Questo perché le funzioni di sviluppo e test vengono in genere richiamate meno frequentemente.

Riduzione degli avvii a freddo con la simultaneità fornita

Se hai bisogno di orari di inizio delle funzioni prevedibili per il tuo carico di lavoro, la soluzione consigliata è la concorrenza fornita per garantire la latenza più bassa possibile. Questa funzionalità preinizializza gli ambienti di esecuzione, riducendo gli avviamenti a freddo.

Ad esempio, una funzione con una concomitanza assegnata di 6 dispone di 6 ambienti di esecuzione preriscaldati.

Ottimizzazione dell'inizializzazione statica

L'inizializzazione statica avviene prima che il codice dell'handler inizi a essere eseguito in una funzione. Questo è il codice di inizializzazione fornito dall'utente, esterno al gestore principale. Questo codice viene spesso utilizzato per importare librerie e dipendenze, impostare configurazioni e inizializzare connessioni ad altri servizi.

Il seguente esempio in Python mostra l'importazione e la configurazione dei moduli e la creazione del client Amazon S3 durante la fase di inizializzazione, prima che la funzione venga eseguita durante l'invoke. lambda_handler

import os
import json
import cv2
import logging
import boto3

s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):

  # Handler logic...

Il principale fattore di latenza prima dell'esecuzione della funzione proviene dal codice di inizializzazione. Questo codice viene eseguito quando viene creato per la prima volta un nuovo ambiente di esecuzione. Il codice di inizializzazione non viene eseguito nuovamente se una invocazione utilizza un ambiente di esecuzione caldo. I fattori che influiscono sulla latenza del codice di inizializzazione includono:

Esistono diversi passaggi che gli sviluppatori possono adottare per ottimizzare la latenza di inizializzazione statica. Se una funzione ha molti oggetti e connessioni, potresti essere in grado di riprogettare una singola funzione in più funzioni specializzate. Questi sono singolarmente più piccoli e ciascuno ha meno codice di inizializzazione.

È importante che le funzioni importino solo le librerie e le dipendenze di cui hanno bisogno. Ad esempio, se utilizzi solo Amazon DynamoDB AWS nell'SDK, puoi richiedere un servizio individuale anziché l'intero SDK. Confronta i tre esempi seguenti:

// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')

// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')

// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)

L'inizializzazione statica è spesso anche il posto migliore per aprire connessioni al database per consentire a una funzione di riutilizzare le connessioni su più chiamate allo stesso ambiente di esecuzione. Tuttavia, è possibile che nella funzione sia presente un numero elevato di oggetti utilizzati solo in determinati percorsi di esecuzione. In questo caso, puoi caricare lentamente le variabili nell'ambito globale per ridurre la durata dell'inizializzazione statica.

Evita le variabili globali per informazioni specifiche del contesto. Se la funzione ha una variabile globale che viene utilizzata solo per la durata di una singola invocazione e viene reimpostata per l'invocazione successiva, utilizza un ambito di variabile locale per l'handler. In questo modo non solo si evitano perdite di variabili globali tra le invocazioni, ma si migliorano anche le prestazioni dell'inizializzazione statica.