Visibility timeout, DLQ e long polling

Quando un consumatore riceve un messaggio da SQS, il messaggio viene nascosto a tutti gli altri consumatori per un periodo chiamato visibility timeout. Durante questo intervallo, il consumatore elabora il messaggio e poi lo elimina. Se il consumatore si arresta in modo anomalo o non termina in tempo, il visibility timeout scade e il messaggio diventa nuovamente visibile, consentendo a un altro consumatore di prelevarlo. Questo è il meccanismo fondamentale alla base della garanzia di consegna almeno una volta di SQS.

Il visibility timeout predefinito è di 30 secondi. Può essere impostato da 0 secondi fino a 12 ore. Lo imposti in modo che superi comodamente il tempo massimo previsto per l'elaborazione: se l'elaborazione richiede fino a 2 minuti, imposti il timeout su almeno 3-4 minuti. È inoltre possibile modificare il timeout per ogni receipt utilizzando change-message-visibility, una funzione utile quando un consumatore rileva di aver bisogno di più tempo per completare l'elaborazione di uno specifico messaggio.

Impostare il timeout troppo breve fa ricomparire i messaggi prima che il consumatore abbia terminato, causando un'elaborazione duplicata. Impostarlo troppo lungo impedisce a un altro consumatore di prelevare un messaggio se quello originale si arresta senza segnalarlo (ad esempio, in caso di arresto anomalo di un'istanza EC2 senza una chiusura corretta). Il timeout ottimale è leggermente superiore al tempo di elaborazione del 99° percentile, ma abbastanza breve da consentire un recupero rapido dagli errori dei consumatori. Monitori la metrica CloudWatch ApproximateNumberOfMessagesNotVisible per individuare i problemi relativi al timeout.

Una Dead-Letter Queue (DLQ) è una coda SQS separata in cui vengono inviati i messaggi dopo un numero configurabile di tentativi di elaborazione falliti (il maxReceiveCount). Quando il numero di ricezioni di un messaggio supera maxReceiveCount, SQS lo sposta automaticamente nella DLQ. Le DLQ impediscono ai messaggi problematici (messaggi che falliscono sempre) di bloccare indefinitamente la coda. I messaggi nella DLQ possono essere esaminati, sottoposti a debug e riprocessati dopo aver corretto il bug di elaborazione.

Una DLQ è semplicemente una normale coda SQS (Standard per una coda di origine Standard, FIFO per una coda di origine FIFO). Nella coda di origine si configura la Redrive Policy per specificare quale coda utilizzare come DLQ e la soglia maxReceiveCount. Si assicuri che il periodo di conservazione della DLQ sia più lungo di quello della coda di origine: i messaggi arrivano nella DLQ in ritardo e occorre avere tempo per analizzarli prima che scadano.

Imposti un allarme CloudWatch sulla metrica ApproximateNumberOfMessagesVisible della DLQ. Qualsiasi messaggio che arriva nella DLQ indica un errore di elaborazione che richiede attenzione. Configuri l'allarme in modo che attivi una notifica SNS per avvisare immediatamente l'ingegnere reperibile. Consideri ogni messaggio nella DLQ come un bug da analizzare: i messaggi DLQ non devono accumularsi senza essere rilevati. Dopo aver corretto il bug, utilizzi DLQ Redrive per reinviare i messaggi alla coda di origine e rielaborarli.

Dopo aver corretto il bug che ha causato gli errori di elaborazione, utilizzi SQS DLQ Redrive per spostare i messaggi dalla DLQ alla coda di origine e rielaborarli. La console offre una funzione di redrive integrata. È possibile filtrare in base agli attributi dei messaggi per riprodurre solo messaggi specifici. In alternativa, può scrivere una funzione Lambda che esegua il polling della DLQ e inoltri i messaggi alla coda di origine se è necessaria una logica di filtraggio personalizzata.

Per impostazione predefinita, SQS utilizza il short polling: una chiamata receive-message campiona un sottoinsieme casuale di server e restituisce immediatamente una risposta, anche se non sono disponibili messaggi. Questo genera molte risposte vuote e spreca chiamate API. Il long polling attende fino a 20 secondi l'arrivo di un messaggio prima di restituire una risposta vuota. Il long polling riduce significativamente i costi (con meno chiamate API) e la latenza (il messaggio viene ricevuto appena arriva, fino a 20 secondi prima rispetto al ciclo di polling successivo).

Abiliti il long polling a livello di coda (si applica a tutte le chiamate di ricezione) oppure per singola richiesta. Per la maggior parte delle applicazioni, è consigliata la configurazione a livello di coda con ReceiveMessageWaitTimeSeconds impostato su 20. Quando Lambda utilizza SQS come origine degli eventi, usa automaticamente il long polling. Per i consumatori basati su EC2, imposti WaitTimeSeconds nella chiamata receive-message.

I messaggi SQS possono contenere attributi del messaggio, ovvero coppie chiave-valore di metadati separate dal corpo del messaggio. Gli attributi hanno un tipo (String, Number, Binary) e un valore. Quando SQS è sottoscritto a un topic SNS, è possibile utilizzare le policy di filtro delle sottoscrizioni SNS applicate agli attributi dei messaggi per instradare solo i messaggi pertinenti a ciascuna coda. Senza filtraggio, ogni sottoscrittore SQS riceve ogni pubblicazione SNS, indipendentemente dal contenuto.

Una Delay Queue rende ogni nuovo messaggio invisibile per un periodo di ritardo compreso tra 0 e 15 minuti dopo l'invio. È utile per i workflow in cui un consumatore non deve elaborare immediatamente un messaggio, ad esempio quando deve prima attendere il completamento di un processo dipendente. È inoltre possibile impostare un ritardo per singolo messaggio utilizzando DelaySeconds nella chiamata di invio, sostituendo il ritardo configurato a livello di coda. Nota: le code di ritardo non sono disponibili per le code FIFO.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che: Visibility Timeout nasconde un messaggio agli altri consumer durante l'elaborazione, consentendo una consegna almeno una volta con ridistribuzione automatica se il consumer non riesce a elaborarlo; le Dead-Letter Queues raccolgono i messaggi che continuano a non riuscire per facilitare il debug e il replay dopo la correzione del bug; il Long Polling (con un'attesa fino a 20 secondi) riduce i costi delle API e la latenza rispetto allo short polling. Ora esploreremo gli argomenti SNS e l'architettura fan-out.