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à.
Riprova per le funzioni durevoli Lambda
Le funzioni durevoli forniscono funzionalità di riprova automatica che rendono le applicazioni resistenti ai guasti transitori. L'SDK gestisce i nuovi tentativi a due livelli: i tentativi successivi per errori della logica aziendale e i tentativi di backend per i guasti dell'infrastruttura.
Ripetimenti in fasi
Quando si verifica un'eccezione non rilevata all'interno di un passaggio, l'SDK riprova automaticamente il passaggio in base alla strategia di riprova configurata. I tentativi di fase sono operazioni controllate che consentono all'SDK di sospendere l'esecuzione e riprenderla in un secondo momento senza perdere i progressi.
Comportamento dei nuovi tentativi
La tabella seguente descrive come l'SDK gestisce le eccezioni in pochi passaggi:
| Scenario | Cosa succede | Impatto della misurazione |
|---|---|---|
| Eccezione in corso con i tentativi di nuovo tentativo rimanenti | L'SDK crea un checkpoint per il nuovo tentativo e sospende la funzione. Alla chiamata successiva, il passaggio riprova con il ritardo di backoff configurato. | 1 operazione + dimensione del payload di errore |
| Eccezione in fase senza tentativi di nuovo tentativo rimanenti | Il passaggio non riesce e genera un'eccezione. Se il codice del gestore non rileva questa eccezione, l'intera esecuzione ha esito negativo. | 1 operazione + dimensione del payload di errore |
Quando un passaggio deve essere riprovato, l'SDK verifica lo stato del tentativo ed esce dalla chiamata Lambda se nessun altro lavoro è in esecuzione. Ciò consente all'SDK di implementare ritardi di backoff senza consumare risorse di calcolo. La funzione riprende automaticamente dopo il periodo di backoff.
Configurazione delle strategie di ripetizione dei passaggi
Configura le strategie di ripetizione per controllare il modo in cui i passaggi gestiscono gli errori. È possibile specificare il numero massimo di tentativi, gli intervalli di backoff e le condizioni per riprovare. Per un riferimento completo agli helper, alle preimpostazioni e alle strategie personalizzate per i tentativi, consultate Retries nella documentazione di Durable Execution SDK.
Eccezioni al di fuori dei passaggi
Quando si verifica un'eccezione non rilevata nel codice del gestore ma al di fuori di qualsiasi passaggio, l'SDK contrassegna l'esecuzione come fallita. Ciò garantisce che gli errori nella logica dell'applicazione vengano acquisiti e segnalati correttamente.
| Scenario | Cosa succede | Impatto della misurazione |
|---|---|---|
| Eccezione nel codice del gestore al di fuori di qualsiasi passaggio | L'SDK contrassegna l'esecuzione come FALLITA e restituisce l'errore. L'eccezione non viene ritentata automaticamente. | Dimensione del payload di errore |
Per abilitare il ritentativo automatico per il codice soggetto a errori, racchiudi in un passaggio una strategia di riprova. I passaggi prevedono un nuovo tentativo automatico con backoff configurabile, mentre il codice esterno ha esito negativo immediatamente.
Riprova di richiamo
I tentativi a livello di chiamata vengono gestiti in modo diverso a seconda di come si tenta di richiamare la funzione Lambda durable. La tabella seguente descrive in che modo i diversi tipi di chiamata possono influenzare i tentativi a livello di chiamata.
| Tipo di invocazione | Cosa succede |
|---|---|
| Invocazione sincrona | Lambda non ritenta automaticamente l'invocazione in caso di errore durante l'esecuzione di una funzione durevole. I tentativi in caso di errore di richiamo dipendono dall'origine dell'invocazione sincrona. Ad esempio, utilizzando l' AWS SDK, e per impostazione predefinita vengono ritentati automaticamente. InternalFailure ThrottlingException |
| Invocazione asincrona | Se l'esecuzione di una funzione durevole fallisce (ad esempio, entra nello stato FAILED, STOPPED o TIMED_OUT), Lambda non riprova l'esecuzione. Ciò è diverso dalle funzioni Lambda standard, in cui Lambda riprova la funzione in caso di errori di chiamata asincrona. L'MaximumRetryAttemptsimpostazione per le chiamate asincrone non si applica alle esecuzioni durature. Se si configura una coda di lettere morte (DLQ) per la funzione, Lambda invia l'evento di attivazione al DLQ. |
| ESM (Event Source Mapping) | Per impostazione predefinita, Lambda riprova l'intero batch finché non ha esito positivo. Per le origini di flusso (DynamoDB e Kinesis), è possibile configurare il numero massimo di tentativi che Lambda effettua quando la funzione restituisce un errore. Vedi la mappatura delle sorgenti degli eventi in batch. Per Amazon SQS ESM, puoi configurare il numero massimo di tentativi tramite un DLQ sulla coda Amazon SQS originale. Consulta la sezione Configurazione di Amazon SQS ESM. Come best practice, potresti prendere in considerazione un DLQ a livello di funzione e Lambda invia l'evento di attivazione dell'errore al DLQ. Vedi funzione DLQ. Aggiunta di una coda DLQ |
| Trigger diretto | Dipende dal «Trigger». Ad esempio, Lambda elabora le funzioni attivate dalle notifiche di eventi di Amazon S3 in modo asincrono. Vedi Elaborare le notifiche di eventi Amazon SQS con Lambda. Lambda elabora le funzioni attivate dalle notifiche di eventi di Amazon SNS, in modo asincrono. Vedi Richiamare le funzioni Lambda con le notifiche Amazon SNS. Il comportamento di ripetizione dell'invocazione asincrona è riportato sopra nella voce della tabella «Invocazione asincrona». Se Amazon SNS non è in grado di raggiungere Lambda o il messaggio viene rifiutato, Amazon SNS riprova a intervalli crescenti per diverse ore. Per ulteriori informazioni, consulta Affidabilità |
Tentativi nel backend
I tentativi di backend si verificano quando Lambda rileva guasti all'infrastruttura, errori di runtime o quando l'SDK non è in grado di comunicare con il servizio di esecuzione durevole. Lambda riprova automaticamente questi errori per aiutare le funzioni durevoli a riprendersi da problemi transitori dell'infrastruttura.
Scenari di riprova nel backend
Lambda riprova automaticamente la funzione quando incontra i seguenti scenari:
-
Errori interni del servizio: quando Lambda o il servizio di esecuzione durevole restituiscono un errore 5xx, che indica un problema temporaneo del servizio.
-
Limitazione: quando la funzione è limitata a causa dei limiti di concorrenza o delle quote di servizio.
-
Timeout: quando l'SDK non può raggiungere il servizio di esecuzione durevole entro il periodo di timeout.
-
Errori di inizializzazione della sandbox: quando Lambda non è in grado di inizializzare l'ambiente di esecuzione.
-
Errori di runtime: quando il runtime di Lambda rileva errori esterni al codice della funzione, come errori di esaurimento della memoria o arresti anomali del processo.
-
Errori del token di checkpoint non valido: quando il token del checkpoint non è più valido, in genere a causa di modifiche allo stato del servizio.
La tabella seguente descrive come l'SDK gestisce questi scenari:
| Scenario | Cosa succede | Impatto della misurazione |
|---|---|---|
| Errore di runtime esterno a durable handler (OOM, timeout, crash) | Lambda riprova automaticamente l'invocazione. L'SDK esegue il replay dall'ultimo checkpoint, saltando i passaggi completati. | Dimensione del payload di errore + 1 operazione per tentativo |
Errore di servizio (5xx) o timeout durante la chiamata a/API CheckpointDurableExecution GetDurableExecutionState |
Lambda riprova automaticamente l'invocazione. L'SDK esegue i replay dall'ultimo checkpoint. | Dimensione del payload di errore + 1 operazione per tentativo |
Throttling (429) o token di checkpoint non valido durante la chiamata a/API CheckpointDurableExecution GetDurableExecutionState |
Lambda riprova automaticamente l'invocazione con un backoff esponenziale. L'SDK esegue i replay dall'ultimo checkpoint. | Dimensione del payload di errore + 1 operazione per tentativo |
Errore del client (4xx, tranne 429 e token non valido) quando/API CheckpointDurableExecution GetDurableExecutionState |
L'SDK contrassegna l'esecuzione come FALLITA. Non si verifica un nuovo tentativo automatico perché l'errore indica un problema permanente. | Dimensione del payload errato |
I tentativi di backend utilizzano il backoff esponenziale e continuano fino al completamento della funzione o al raggiungimento del timeout di esecuzione. Durante la riproduzione, l'SDK salta i checkpoint completati e continua l'esecuzione dall'ultima operazione riuscita, assicurando che la funzione non riesegua il lavoro completato.
Riprova le best practice
Segui queste best practice per configurare le strategie di ripetizione dei tentativi:
-
Configura strategie di ripetizione esplicite: non affidarti al comportamento predefinito dei tentativi in produzione. Configura strategie di ripetizione esplicite con il numero massimo di tentativi e intervalli di backoff appropriati per il tuo caso d'uso.
-
Usa tentativi condizionali: implementa la
shouldRetrylogica per riprovare solo gli errori transitori (limiti di frequenza, timeout) e fallire rapidamente in caso di errori permanenti (errori di convalida, non trovati). -
Imposta il numero massimo di tentativi appropriato: equilibrio tra resilienza e tempo di esecuzione. Troppi tentativi possono ritardare il rilevamento degli errori, mentre un numero insufficiente può causare errori non necessari.
-
Utilizza il backoff esponenziale: il backoff esponenziale riduce il carico sui servizi a valle e aumenta la probabilità di ripristino in caso di guasti transitori.
-
Raccogli il codice soggetto a errori in passaggi: il codice esterno non può essere ritentato automaticamente. Raccogli le chiamate API esterne, le interrogazioni al database e altre operazioni soggette a errori in fasi con strategie di ripetizione.
-
Monitora le metriche dei nuovi tentativi: tieni traccia delle operazioni di ripetizione dei tentativi e degli errori di esecuzione in Amazon CloudWatch per identificare i modelli e ottimizzare le strategie di riprova.
