Utilizzo di Lambda con Amazon SQS - AWS Lambda

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

Utilizzo di Lambda con Amazon SQS

È possibile utilizzare una funzione Lambda per elaborare i messaggi in una coda Amazon Simple Queue Service (Amazon SQS). Lambda supporta sia code standard che code first-in, first-out (FIFO) per gli strumenti di mappatura dell'origine degli eventi. Puoi anche utilizzare la modalità provisioned per allocare risorse di polling dedicate per le mappature delle sorgenti degli eventi Amazon SQS. La funzione Lambda e la coda Amazon SQS devono trovarsi nella Regione AWS stessa posizione, anche se possono trovarsi in posizioni diverse. Account AWS

Durante l'elaborazione di messaggi Amazon SQS, è necessario implementare una logica di risposta batch parziale per evitare che i messaggi elaborati correttamente vengano ritentati quando alcuni messaggi di un batch falliscono. L'utilità Batch Processor di Powertools AWS Lambda semplifica questa implementazione gestendo automaticamente la logica di risposta batch parziale, riducendo i tempi di sviluppo e migliorando l'affidabilità.

Informazioni sul comportamento di polling e batch per gli strumenti di mappatura dell'origine degli eventi di Amazon SQS

Con gli strumenti di mappatura dell'origine degli eventi di Amazon SQS, Lambda esegue il polling della coda e richiama la funzione in modo sincrono con un evento. Ogni evento può contenere un batch di più messaggi dalla coda. Lambda riceve questi eventi un batch alla volta e richiama la funzione una volta per ogni batch. Quando la funzione elabora correttamente un batch, Lambda elimina i relativi messaggi dalla coda.

Quando Lambda legge un batch, i messaggi rimangono nella coda ma vengono nascosti per la durata del timeout visibilità della coda. Se la funzione elabora correttamente tutti i messaggi nel batch, Lambda elimina i messaggi dalla coda. Per impostazione predefinita, se la funzione rileva un errore durante l'elaborazione di un batch, una volta scaduto il timeout di visibilità tutti i messaggi in quel batch diventeranno nuovamente visibili nella coda. Per questo motivo, il codice della funzione deve riuscire a elaborare lo stesso messaggio più volte, senza intoppi indesiderati.

avvertimento

Gli strumenti di mappatura dell'origine degli eventi elaborano ogni evento almeno una volta e può verificarsi un'elaborazione duplicata dei record. Per evitare potenziali problemi legati agli eventi duplicati, ti consigliamo vivamente di rendere idempotente il codice della funzione. Per ulteriori informazioni, consulta Come posso rendere idempotente la mia funzione Lambda nel Knowledge Center. AWS

Per impedire a Lambda di elaborare un messaggio più volte, puoi configurare la mappatura dell'origine degli eventi per includere gli errori degli elementi in batch nella risposta della funzione oppure puoi utilizzare l'DeleteMessageAPI per rimuovere i messaggi dalla coda man mano che la funzione Lambda li elabora correttamente.

Per ulteriori informazioni sui parametri di configurazione supportati da Lambda per gli strumenti di mappatura dell'origine degli eventi di SQS, consulta Creazione di uno strumento di mappatura dell'origine degli eventi SQS.

Utilizzo della modalità provisioning con le mappature delle sorgenti degli eventi di Amazon SQS

Per i carichi di lavoro in cui è necessario ottimizzare il throughput dello strumento di mappatura dell'origine degli eventi, è possibile utilizzare la modalità provisioning. In modalità provisioning, vengono definiti i limiti minimi e massimi per la quantità di poller di eventi assegnati. Questi poller di eventi con provisioning sono dedicati allo strumento di mappatura dell'origine degli eventi e possono gestire picchi di messaggi imprevisti tramite un dimensionamento automatico reattivo. La mappatura delle sorgenti di eventi di Amazon SQS configurata con la modalità Provisioned è 3 volte più veloce (fino a 1.000 richiami simultanei al minuto) e supporta una contemporaneità 16 volte superiore (fino a 20.000 richiami simultanei) rispetto alla funzionalità di mappatura delle sorgenti di eventi di Amazon SQS predefinita. Ti consigliamo di utilizzare la modalità provisioned per i carichi di lavoro basati su eventi di Amazon SQS che hanno requisiti prestazionali rigorosi, come le società di servizi finanziari che elaborano i feed di dati di mercato, le piattaforme di e-commerce che forniscono consigli personalizzati in tempo reale e le società di gioco che gestiscono le interazioni tra giocatori dal vivo. L'utilizzo della modalità provisioning comporta costi aggiuntivi. Per i prezzi dettagliati, consulta la pagina dei prezzi.AWS Lambda

Ogni event poller in modalità provisioned può gestire fino all'1% MB/s del throughput, fino a 10 chiamate simultanee o fino a 10 chiamate API di polling di Amazon SQS al secondo. L'intervallo di valori accettati per il numero minimo di event poller (MinimumPollers) è compreso tra 2 e 200, con il valore predefinito di 2. L'intervallo di valori accettati per il numero massimo di event poller (MaximumPollers) è compreso tra 2 e 2.000, con il valore predefinito di 200. MaximumPollers deve essere maggiore o uguale a. MinimumPollers

Determinazione dei sondaggi di eventi richiesti

Per stimare il numero di event poller necessari per garantire prestazioni ottimali di elaborazione dei messaggi quando si utilizza la modalità provisioned per SQS ESM, raccogli le seguenti metriche per la tua applicazione: eventi SQS di picco al secondo che richiedono un'elaborazione a bassa latenza, dimensione media del payload degli eventi SQS, durata media della funzione Lambda e dimensione del batch configurato.

Innanzitutto puoi stimare il numero di eventi SQS al secondo (EPS) supportati da un event poller per il tuo carico di lavoro utilizzando la seguente formula:

EPS per event poller = minimum( ceiling(1024 / average event size in KB), ceiling(10 / average function duration in seconds) * batch size, min(100, 10 * batch size) )

Quindi, puoi calcolare il numero minimo di poller richiesti utilizzando la formula seguente. Questo calcolo garantisce la disponibilità di una capacità sufficiente per gestire i requisiti di traffico di picco.

Required event pollers = (Peak number of events per second in Queue) / EPS per event poller

Prendiamo in considerazione un carico di lavoro con una dimensione del batch predefinita di 10, una dimensione media degli eventi di 3 KB, una durata media della funzione di 100 ms e un requisito per gestire 1.000 eventi al secondo. In questo scenario, ogni event poller supporterà circa 100 eventi al secondo (EPS). Pertanto, è necessario impostare un numero minimo di poller su 10 per gestire adeguatamente i requisiti di traffico di picco. Se il carico di lavoro ha le stesse caratteristiche ma la durata media della funzione è di 1 secondo, ogni poller supporterà solo 10 EPS, il che richiede la configurazione di almeno 100 poller per supportare 1.000 eventi al secondo a bassa latenza.

Ti consigliamo di utilizzare una dimensione batch predefinita pari o superiore a 10 per massimizzare l'efficienza dei poller di eventi in modalità provisioned. Le dimensioni dei batch più elevate consentono a ciascun poller di elaborare più eventi per chiamata, migliorando la produttività e l'efficienza in termini di costi. Quando pianificate la capacità dei poller del vostro evento, tenete conto dei potenziali picchi di traffico e valutate la possibilità di impostare il valore MinimumPollers leggermente più alto del minimo calcolato per fornire un buffer. Inoltre, monitora le caratteristiche del carico di lavoro nel tempo, poiché le modifiche alla dimensione dei messaggi, alla durata delle funzioni o ai modelli di traffico potrebbero richiedere modifiche alla configurazione del poller degli eventi per mantenere prestazioni ed efficienza dei costi ottimali. Per una pianificazione precisa della capacità, consigliamo di testare il carico di lavoro specifico per determinare l'EPS effettivo che ogni event poller può generare.

Configurazione della modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS

Puoi configurare la modalità di provisioning per la mappatura delle sorgenti degli eventi Amazon SQS utilizzando la console o l'API Lambda.

Per configurare la modalità di provisioning per una mappatura delle sorgenti di eventi Amazon SQS esistente (console)
  1. Aprire la pagina Funzioni della console Lambda.

  2. Scegli la funzione con la mappatura delle sorgenti degli eventi di Amazon SQS per cui desideri configurare la modalità di provisioning.

  3. Scegli la scheda Configurazione, quindi scegli Trigger.

  4. Scegli la mappatura delle sorgenti degli eventi Amazon SQS per cui desideri configurare la modalità di provisioning, quindi scegli Modifica.

  5. In Configurazione dello strumento di mappatura dell'origine degli eventi, scegli Configura la modalità provisioning.

    • Per Minimum event poller, inserisci un valore compreso tra 2 e 200. Se non si specifica un valore, Lambda sceglie un valore predefinito pari a 2.

    • Per Maximum event poller, inserisci un valore compreso tra 2 e 2.000. Questo valore deve essere maggiore o uguale al valore specificato in Numero minimo di poller di eventi. Se non si specifica un valore, Lambda assegna il valore predefinito 200.

  6. Scegli Save (Salva).

È possibile configurare la modalità di provisioning a livello di codice utilizzando l'ProvisionedPollerConfigoggetto in. EventSourceMappingConfiguration Ad esempio, il seguente comando UpdateEventSourceMapping CLI configura un MinimumPollers valore di 5 e un MaximumPollers valore di 100.

aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

Dopo aver configurato la modalità provisioning, puoi osservare l'utilizzo dei poller di eventi per il tuo carico di lavoro monitorando il parametro ProvisionedPollers. Per ulteriori informazioni, consulta Metriche di mappatura della fonte degli eventi.

Per disabilitare la modalità provisioning e tornare alla modalità predefinita (su richiesta), puoi utilizzare il seguente comando CLIUpdateEventSourceMapping:

aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{}'
Nota

La modalità provisioned non può essere utilizzata insieme all'impostazione della massima concorrenza. Quando si utilizza la modalità provisioned, è possibile controllare la massima concorrenza mediante il numero massimo di sondaggi di eventi.

Per ulteriori informazioni sulla configurazione della modalità provisioned, vedere. Creazione e configurazione di uno strumento di mappatura dell'origine degli eventi Amazon SQS

Esempio di evento con messaggio di coda standard

Esempio Evento messaggio Amazon SQS (coda standard)
{ "Records": [ { "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d", "receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082649183", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082649185" }, "messageAttributes": { "myAttribute": { "stringValue": "myValue", "stringListValues": [], "binaryListValues": [], "dataType": "String" } }, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" }, { "messageId": "2e1424d4-f796-459a-8184-9c92662be6da", "receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1545082650636", "SenderId": "AIDAIENQZJOLO23YVJ4VO", "ApproximateFirstReceiveTimestamp": "1545082650649" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue", "awsRegion": "us-east-2" } ] }

Per impostazione predefinita, Lambda eseguirà il polling di un massimo di 10 messaggi contemporaneamente nella coda e invierà il batch alla funzione. Per evitare di richiamare la funzione con un piccolo numero di record, è possibile configurare l'origine eventi per memorizzare nel buffer i record per un massimo di 5 minuti definendo un periodo di batch. Prima di richiamare la funzione, Lambda continua a eseguire il polling dei messaggi dalla coda standard fino alla scadenza del periodo di batch, al raggiungimento della quota della dimensione del payload di richiesta o al raggiungimento della dimensione massima per la configurazione di un batch.

Se stai utilizzando un periodo di batch e la tua coda SQS contiene un traffico molto basso, Lambda potrebbe attendere fino a 20 secondi prima di richiamare la tua funzione. Lo stesso vale anche se imposti un periodo di batch inferiore a 20 secondi.

Nota

In Java, potresti riscontrare errori di puntatore null durante la deserializzazione di JSON. Ciò potrebbe essere dovuto al modo in cui "Records" e "eventSourceARN" vengono convertiti dal mappatore di oggetti JSON.

Esempio di evento di messaggio di coda FIFO

Per le code FIFO, i record contengono attributi aggiuntivi correlati alla deduplicazione e al sequenziamento.

Esempio Evento messaggio Amazon SQS (coda FIFO)
{ "Records": [ { "messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5", "receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...", "body": "Test message.", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1573251510774", "SequenceNumber": "18849496460467696128", "MessageGroupId": "1", "SenderId": "AIDAIO23YVJENQZJOL4VO", "MessageDeduplicationId": "1", "ApproximateFirstReceiveTimestamp": "1573251510774" }, "messageAttributes": {}, "md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo", "awsRegion": "us-east-2" } ] }