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 di Lambda Managed Instances
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 differenze importanti 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), vedere Comprensione del ciclo di vita 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 si differenzia da Lambda (impostazione predefinita) in diversi modi chiave:
Fase di init
Durante la fase di inizializzazione, Lambda esegue le seguenti operazioni:
-
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)
-
Codice di inizializzazione della funzione Run (codice esterno al gestore)
-
Attendi che almeno un runtime worker segnali la disponibilità chiamando
/runtime/invocation/next
La fase di inizializzazione è 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 ed elabora le chiamate non appena arrivano senza bloccarsi tra una chiamata e l'altra.
Elaborazione parallela. È possibile eseguire più chiamate 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 scade una chiamata, Lambda contrassegna quella chiamata specifica come fallita ma non interrompe le 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 chiamata 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 dei Runtime Worker. Se un processo di runtime worker si blocca, l'ambiente di esecuzione continua a funzionare con i restanti lavoratori sani.
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 errori. Invece, i contenitori non integri vengono chiusi e sostituiti con altri nuovi.
Richiama i timeout
Quando scade una singola chiamata, 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 la chiamata è scaduta. Le altre chiamate simultanee nell'ambiente di esecuzione continuano l'elaborazione normalmente.
Comportamento di ripetizione
Quando scade una chiamata:
-
Richiamazioni sincrone: il chiamante riceve l'errore di timeout ed è responsabile del nuovo tentativo.
-
Richiamazioni asincrone: Lambda riprova in base alla politica di nuovi tentativi della funzione (impostazione predefinita: 2 tentativi). Una volta esauriti tutti i tentativi, l'evento viene inviato alla coda di lettere non scritte configurata o all'eventuale destinazione in caso di errore.
-
Mappature delle origini degli eventi: il comportamento dei nuovi tentativi dipende dalla configurazione dell'origine dell'evento (ad esempio, dimensione del batch, divisione in due parti in caso di errore, numero massimo di tentativi). Il batch può essere ritentato o inviato a una destinazione in caso di errore in base alle politiche di riprova.
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 operazione completata dal codice dopo il timeout viene effettivamente persa 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 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 collaterali possono ancora verificarsi dopo che Lambda ha già comunicato al chiamante che la chiamata non è riuscita. Ad esempio, il gestore scrive un record su DynamoDB, quindi il timeout si attiva e Lambda restituisce un errore di timeout al chiamante, ma il codice è ancora in esecuzione e procede all'invio di una notifica SNS. Il chiamante riprova la chiamata, che scrive nuovamente il record e invia nuovamente la notifica. Ora hai dati e notifiche duplicati, e non c'è modo semplice per capire quali provenivano dalla chiamata «fallita» che era ancora in esecuzione in background.
Gestione dei timeout nel codice
Utilizzate l'oggetto contestuale 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 ogni elemento impiega circa 500 ms per l'elaborazione, imposta il buffer su almeno 500 ms più il margine.
Per esempi di gestione del timeout specifici per una lingua, consulta la sezione relativa al contesto della richiesta di ciascuna pagina di runtime:
