Risolvi i problemi di mappatura delle sorgenti degli eventi in Lambda

I problemi in Lambda relativi alla mappatura dell'origine di un evento possono essere più complessi perché implicano il debug su più servizi. Inoltre, il comportamento dell'origine degli eventi può variare in base all'origine esatta dell'evento utilizzata. Questa sezione elenca i problemi comuni relativi alla mappatura delle sorgenti degli eventi e fornisce indicazioni su come identificarli e risolverli.

Identificazione e gestione della limitazione

In Lambda, la limitazione si verifica quando si raggiunge il limite di concorrenza della funzione o dell'account. Considera il seguente esempio, in cui esiste una funzione Lambda che legge i messaggi da una coda Amazon SQS. Questa funzione Lambda simula invocazioni di 30 secondi e ha una dimensione batch di 1. Ciò significa che la funzione elabora solo 1 messaggio ogni 30 secondi:

const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}

Con un tempo di invocazione così lungo, i messaggi iniziano ad arrivare in coda più rapidamente di quanto vengano elaborati. Se la simultaneità non riservata dell'account è 100, Lambda è scalabile fino a 100 esecuzioni simultanee, quindi si verifica una limitazione. Puoi vedere questo modello nei parametri di CloudWatch per la funzione:

I parametri di CloudWatch per la funzione non mostrano errori, ma il grafico delle esecuzioni simultanee mostra che è stata raggiunta la simultaneità massima. Di conseguenza, il grafico Limitazioni mostra la limitazione in atto.

Puoi rilevare la limitazione utilizzando gli allarmi CloudWatch e impostare un allarme ogni volta che il parametro di limitazione per una funzione è maggiore di 0. Dopo aver identificato il problema della limitazione, hai a disposizione alcune opzioni per la risoluzione:

Errori nella funzione di elaborazione

Se la funzione di elaborazione genera errori, i messaggi vengono restituiti alla coda SQS. Il servizio Lambda impedisce la scalabilità della funzione per evitare errori su larga scala. I seguenti parametri SQS in CloudWatch indicano un problema con l'elaborazione delle code:

Aumentano sia l'età dei primi messaggi che il numero di messaggi visibili, mentre nessun messaggio viene eliminato. La coda continua a crescere ma i messaggi non vengono elaborati. I parametri CloudWatch per l'elaborazione della funzione Lambda indicano anche che esiste un problema:

Il parametro numero errori è diverso da zero ed è in aumento, mentre le esecuzioni simultanee si sono ridotte e la limitazione è stata interrotta. Ciò dimostra che il servizio Lambda ha interrotto la scalabilità a causa di errori. I log CloudWatch per la funzione forniscono dettagli sul tipo di errore.

È possibile risolvere questo problema identificando la funzione che causa l'errore, quindi trovando e risolvendo l'errore. Una volta corretto l'errore e implementato il nuovo codice, i parametri di CloudWatch mostrano come viene ripristinata l'elaborazione:

Qui, il numero di errori scende a zero e la percentuale di successo torna al 100%. Il servizio Lambda ricomincia a scalare la funzione, come mostrato nel grafico delle esecuzioni simultanee.

Identificazione e gestione della contropressione

Se un produttore di eventi genera costantemente messaggi per una coda SQS più velocemente di quanto una funzione Lambda possa elaborare la gestione, si verifica una contropressione. In questo caso, il monitoraggio SQS mostra l'età del primo messaggio che cresce in modo lineare, insieme al numero approssimativo di messaggi visibili. Puoi rilevare la contropressione nelle code utilizzando gli allarmi CloudWatch.

I passaggi per risolvere la contropressione dipendono dal carico di lavoro. Se l'obiettivo principale è aumentare la capacità di elaborazione e il throughput mediante la funzione Lambda: