Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Comprendere l'ambiente di esecuzione delle istanze gestite Lambda
Le istanze gestite Lambda forniscono un modello di distribuzione alternativo che esegue il codice funzionale su istanze Amazon EC2 di proprietà del cliente mentre Lambda gestisce gli aspetti operativi. L'ambiente di esecuzione per le istanze gestite presenta diverse importanti differenze rispetto alle funzioni Lambda (predefinite), in particolare nel modo in cui gestisce le chiamate simultanee e gestisce i cicli di vita dei container.
Nota: per informazioni sull'ambiente di esecuzione Lambda (predefinito), consulta Understanding the Lifecycle dell'ambiente di esecuzione Lambda.
Ciclo di vita dell'ambiente di esecuzione
Il ciclo di vita di un ambiente di esecuzione delle funzioni Lambda Managed Instances è diverso da Lambda (predefinito) in diversi modi chiave:
Fase di init
Durante la fase di avvio, Lambda esegue i seguenti passaggi:
-
Inizializza e registra tutte le estensioni
-
Avvia il punto di ingresso del runtime. Il runtime genera il numero configurato di runtime worker (l'implementazione dipende dal runtime)
-
Esegui il codice di inizializzazione della funzione (codice esterno al gestore)
-
Attendi che almeno un runtime worker segnali la disponibilità chiamando
/runtime/invocation/next
La fase Init è considerata completa quando le estensioni sono state inizializzate e almeno un runtime worker è stato chiamato. /runtime/invocation/next La funzione è quindi pronta per elaborare le chiamate.
Nota
Per le funzioni Lambda Managed Instances, l'inizializzazione può richiedere fino a 15 minuti. Il timeout è il massimo di 130 secondi o il timeout della funzione configurata (fino a 900 secondi).
Invoca fase
La fase Invoke per le funzioni Lambda Managed Instances presenta diverse caratteristiche uniche:
Funzionamento continuo. A differenza di Lambda (impostazione predefinita), l'ambiente di esecuzione rimane continuamente attivo, elaborando le chiamate man mano che arrivano senza bloccarsi tra una chiamata e l'altra.
Elaborazione parallela. È possibile eseguire più invocazioni contemporaneamente all'interno dello stesso ambiente di esecuzione, ciascuna gestita da un runtime worker diverso.
Timeout indipendenti. Il timeout configurato della funzione si applica a ogni singola chiamata. Quando una chiamata scade, Lambda contrassegna quella specifica invocazione come fallita ma non interrompe altre chiamate in esecuzione né termina l'ambiente di esecuzione.
Gestione della contropressione. Se tutti i runtime worker sono impegnati nell'elaborazione delle chiamate, le nuove richieste di richiamo vengono rifiutate fino a quando un worker non diventa disponibile.
Gestione e ripristino degli errori
La gestione degli errori negli ambienti di esecuzione delle funzioni Lambda Managed Instances è diversa da Lambda (impostazione predefinita):
Errori del runtime worker. Se un processo di runtime worker si blocca, l'ambiente di esecuzione continua a funzionare con i lavoratori sani rimanenti.
L'estensione si blocca. Se un processo di estensione si blocca durante l'inizializzazione o l'operazione, l'intero ambiente di esecuzione viene contrassegnato come non integro e viene terminato. Lambda crea un nuovo ambiente di esecuzione per sostituirlo.
No reset/repair A differenza di Lambda (impostazione predefinita), le istanze gestite non tentano di reimpostare e reinizializzare l'ambiente di esecuzione dopo gli errori. Invece, i contenitori non integri vengono terminati e sostituiti con contenitori nuovi.
Richiama i timeout
Quando una singola chiamata scade, Lambda restituisce al chiamante un Task timed out after <timeout> seconds errore con lo stato di errore di funzione. Tuttavia, Lambda Managed Instances non termina forzatamente il codice, ma continua a funzionare nell'ambiente di esecuzione. In qualità di sviluppatore di funzioni, sei responsabile del rilevamento e della gestione del timeout.
L'oggetto context espone il tempo rimanente per l'invocazione. Un valore zero o negativo indica che l'invocazione è scaduta. Le altre chiamate simultanee nell'ambiente di esecuzione continuano a essere elaborate normalmente.
Comportamento di ripetizione
Quando scade il timeout di una chiamata:
-
Chiamate sincrone: il chiamante riceve l'errore di timeout ed è responsabile del nuovo tentativo.
-
Chiamate asincrone: Lambda riprova in base alla politica di ripetizione della funzione (impostazione predefinita: 2 tentativi). Una volta esauriti tutti i tentativi, l'evento viene inviato alla coda di lettere morte configurata o alla destinazione in caso di errore, se presente.
-
Mappature dell'origine degli eventi: il comportamento dei tentativi dipende dalla configurazione dell'origine dell'evento (ad esempio, dimensione del batch, bisezione in base all'errore, numero massimo di tentativi di ripetizione). Il batch può essere ritentato o inviato a una destinazione in caso di errore in base alle politiche relative ai nuovi tentativi.
Cosa succede se non gestisci il timeout
Se il codice non controlla il tempo rimanente e interrompe l'esecuzione:
-
L'invocazione è già contrassegnata come fallita. Lambda ha già restituito un errore di timeout al chiamante: qualsiasi lavoro completato dal codice dopo il timeout viene effettivamente perso dal punto di vista del chiamante.
-
Le risorse rimangono consumate. Il codice continua a occupare uno slot di runtime worker, riducendo la concorrenza disponibile per le nuove chiamate su quell'istanza.
-
Comportamento non deterministico. Il codice non si interrompe quando scatta il timeout, ma continua a funzionare in background. Ciò significa che gli effetti indesiderati possono ancora verificarsi dopo che Lambda ha già comunicato al chiamante che l'invocazione è fallita.
Ad esempio, il gestore scrive un record su DynamoDB, quindi si attiva il timeout e Lambda restituisce un errore di timeout al chiamante, ma il codice è ancora in esecuzione e procede con l'invio di una notifica SNS. Il chiamante riprova l'invocazione, che scrive nuovamente il record e invia nuovamente la notifica. Ora hai dati e notifiche duplicati e non c'è un modo semplice per stabilire quali provenissero dalla chiamata «fallita» ancora in esecuzione in background.
Gestione dei timeout nel codice
Usa l'oggetto context per controllare il tempo rimanente e interrompere l'elaborazione prima del timeout. Configura un buffer in base alla durata prevista della prossima unità di lavoro: ad esempio, se l'elaborazione di ogni elemento richiede circa 500 ms, imposta il buffer su almeno 500 ms più il margine.
Per esempi di gestione dei timeout specifici per lingua, consulta la sezione relativa al contesto della richiesta di ciascuna pagina di runtime:
