Comprendere il ciclo di vita dell’ambiente di esecuzione Lambda

Gli ambienti di esecuzione Lambda supportano sia le funzioni standard (fino a 15 minuti) che le funzioni durature (fino a un anno). Sebbene entrambi condividano lo stesso ciclo di vita di base, Durable Functions aggiunge funzionalità di gestione dello stato per flussi di lavoro di lunga durata.

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.

Per Durable Functions, l'ambiente di esecuzione include componenti aggiuntivi per:

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.

Le fasi del ciclo di vita di Durable Functions includono:

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 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. Potresti notare delle lacune tra le fasi di richiamo e inizializzazione della funzione. A seconda del runtime e della configurazione della memoria della funzione, è inoltre possibile che si verifichi una latenza variabile alla prima chiamata in un ambiente di esecuzione inizializzato.

Per le funzioni che utilizzano la concorrenza su richiesta, Lambda potrebbe occasionalmente inizializzare gli ambienti di esecuzione prima delle richieste di richiamo. Quando ciò accade, potresti anche osservare un intervallo di tempo 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 log a meno che non sia abilitata la concorrenza predisposta SnapStart. Configurazione della simultaneità fornita per una funzione SnapStart e le funzioni di concorrenza predisposte emettono sempre. INIT_REPORT Per ulteriori informazioni, consulta Monitoraggio per Lambda SnapStart.

Fase di ripristino (solo Lambda) SnapStart

Quando si richiama per la prima volta una SnapStart funzione e man mano che la funzione aumenta, Lambda riprende nuovi ambienti di esecuzione dallo snapshot persistente invece di inizializzare la funzione da zero. Se disponi di un hook di runtime dopo il ripristino, il codice viene eseguito alla fine della fase Restore. Ti sarà addebitata la durata degli hook di runtime dopo il 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.

Limite di durata: la durata massima della fase Shutdown dipende dalla configurazione delle estensioni registrate:

Se il runtime o un'estensione non risponde all'evento Shutdown entro il limite, Lambda termina il processo utilizzando 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 Implementazione stateless nelle funzioni.

Quando la funzione viene richiamata nuovamente, Lambda disattiva 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 per eseguire 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 all'esterno del gestore principale. Infine, Lambda esegue il codice del gestore.

In questo diagramma, i primi due passaggi di download del codice e configurazione dell'ambiente vengono spesso definiti «avvio a freddo». Questo tempo ti viene addebitato e questo aggiunge latenza alla durata complessiva della chiamata.

Al termine dell'invocazione, l'ambiente di esecuzione viene bloccato. Per migliorare la gestione e le prestazioni delle risorse, Lambda mantiene 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 è chiamato «avvio a caldo».

Le partenze 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 simultaneità fornita è la soluzione consigliata 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 concorrenza prevista pari a 6 ha 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, che si trova all'esterno del gestore principale. Questo codice viene spesso utilizzato per importare librerie e dipendenze, impostare configurazioni e inizializzare le 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 lambda_handler venga eseguita durante la fase di invocazione.

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 maggior contributo alla latenza prima dell'esecuzione della funzione proviene dal codice di inizializzazione. Questo codice viene eseguito quando viene creato un nuovo ambiente di esecuzione per la prima volta. 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. Queste sono singolarmente più piccole e ognuna ha meno codice di inizializzazione.

È importante che le funzioni importino solo le librerie e le dipendenze di cui hanno bisogno. Ad esempio, se utilizzi Amazon DynamoDB solo nell' AWS SDK, puoi richiedere un singolo servizio 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ù invocazioni allo stesso ambiente di esecuzione. Tuttavia, potreste avere un numero elevato di oggetti che vengono utilizzati solo in determinati percorsi di esecuzione della funzione. In questo caso, puoi caricare lentamente le variabili nell'ambito globale per ridurre la durata dell'inizializzazione statica.

Evitate 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.