Visibility Timeout, DLQ und Long Polling

Wenn ein Konsument eine Nachricht von SQS empfängt, wird die Nachricht für einen Zeitraum, der als Visibility Timeout bezeichnet wird, vor allen anderen Konsumenten verborgen. Während dieses Zeitraums verarbeitet der Konsument die Nachricht und löscht sie anschließend. Wenn der Konsument abstürzt oder nicht rechtzeitig fertig wird, läuft der Visibility Timeout ab und die Nachricht wird wieder sichtbar, sodass ein anderer Konsument sie übernehmen kann. Dies ist der zentrale Mechanismus hinter der SQS-Garantie der Zustellung mindestens einmal.

Der standardmäßige Visibility Timeout beträgt 30 Sekunden. Er kann auf einen Wert zwischen 0 Sekunden und 12 Stunden gesetzt werden. Legen Sie ihn so fest, dass er die maximal erwartete Verarbeitungszeit komfortabel überschreitet. Wenn die Verarbeitung bis zu 2 Minuten dauert, sollte der Timeout beispielsweise mindestens 3–4 Minuten betragen. Sie können den Timeout auch für einen einzelnen Receipt mit change-message-visibility ändern. Das ist nützlich, wenn ein Konsument erkennt, dass er für die Verarbeitung einer bestimmten Nachricht mehr Zeit benötigt.

Wird der Timeout zu kurz eingestellt, werden Nachrichten erneut sichtbar, bevor der Konsument die Verarbeitung abgeschlossen hat, was zu einer doppelten Verarbeitung führt. Ein zu langer Timeout verzögert die Übernahme einer Nachricht durch einen anderen Konsumenten, wenn der ursprüngliche Konsument unbemerkt ausfällt (z. B. durch den Absturz einer EC2-Instanz ohne ordnungsgemäße Bereinigung). Der optimale Timeout liegt etwas über Ihrer Verarbeitungszeit am 99. Perzentil, sollte aber kurz genug sein, um sich schnell von Ausfällen eines Konsumenten zu erholen. Überwachen Sie die CloudWatch-Metrik ApproximateNumberOfMessagesNotVisible, um Timeout-Probleme zu erkennen.

Eine Dead-Letter-Warteschlange (DLQ) ist eine separate SQS-Warteschlange, in die Nachrichten verschoben werden, nachdem ihre Verarbeitung eine konfigurierbare Anzahl von Malen fehlgeschlagen ist (der Wert maxReceiveCount). Sobald der Empfangszähler einer Nachricht maxReceiveCount überschreitet, verschiebt SQS sie automatisch in die DLQ. DLQs verhindern, dass sogenannte Poison-Pill-Nachrichten (Nachrichten, deren Verarbeitung immer fehlschlägt) die Warteschlange unbegrenzt blockieren. Nachrichten in der DLQ können untersucht, debuggt und nach der Behebung des Verarbeitungsfehlers erneut verarbeitet werden.

Eine DLQ ist lediglich eine reguläre SQS-Warteschlange (Standard für eine Standard-Quellwarteschlange, FIFO für eine FIFO-Quellwarteschlange). Sie konfigurieren die Redrive Policy der Quellwarteschlange, um festzulegen, welche Warteschlange als DLQ dient und welcher maxReceiveCount-Schwellenwert gilt. Stellen Sie sicher, dass die Aufbewahrungsdauer der DLQ länger ist als die Aufbewahrungsdauer der Quellwarteschlange. Nachrichten treffen verspätet in der DLQ ein, und Sie benötigen Zeit für die Untersuchung, bevor sie ablaufen.

Richten Sie für die Metrik ApproximateNumberOfMessagesVisible der DLQ einen CloudWatch-Alarm ein. Jede Nachricht, die in der DLQ eintrifft, weist auf einen Verarbeitungsfehler hin, der Aufmerksamkeit erfordert. Konfigurieren Sie den Alarm so, dass er eine SNS-Benachrichtigung auslöst, die den diensthabenden Engineer sofort alarmiert. Behandeln Sie jede DLQ-Nachricht als Fehler, der untersucht werden muss – DLQ-Nachrichten sollten sich nicht unbemerkt ansammeln. Verwenden Sie nach der Fehlerbehebung DLQ Redrive, um Nachrichten zur erneuten Verarbeitung zurück in die Quellwarteschlange zu senden.

Nachdem Sie den Fehler behoben haben, der die Verarbeitungsfehler verursacht hat, verwenden Sie SQS DLQ Redrive, um Nachrichten aus der DLQ zurück in die Quellwarteschlange zu verschieben und erneut zu verarbeiten. Die Konsole bietet dafür eine integrierte Redrive-Funktion. Sie können nach Nachrichtenattributen filtern, um nur bestimmte Nachrichten erneut abzuspielen. Alternativ können Sie eine Lambda-Funktion schreiben, die die DLQ abfragt und Nachrichten zurück an die Quellwarteschlange weiterleitet, wenn Sie eine benutzerdefinierte Filterlogik benötigen.

Standardmäßig verwendet SQS Short Polling: Ein Aufruf von receive-message fragt eine zufällige Teilmenge der Server ab und gibt sofort eine Antwort zurück – selbst wenn keine Nachrichten verfügbar sind. Dadurch entstehen viele leere Antworten und API-Aufrufe werden unnötig verbraucht. Long Polling wartet bis zu 20 Sekunden auf das Eintreffen einer Nachricht, bevor eine leere Antwort zurückgegeben wird. Long Polling senkt die Kosten erheblich (durch weniger API-Aufrufe) und verringert die Latenz (eine Nachricht wird empfangen, sobald sie eintrifft, bis zu 20 Sekunden früher als im nächsten Abfragezyklus).

Aktivieren Sie Long Polling auf Ebene der Warteschlange (gilt für alle Empfangsaufrufe) oder pro Anfrage. Die Konfiguration auf Warteschlangenebene mit einem Wert von 20 für ReceiveMessageWaitTimeSeconds wird für die meisten Anwendungen empfohlen. Wenn Lambda SQS als Ereignisquelle verwendet, wird Long Polling automatisch eingesetzt. Legen Sie bei Konsumenten auf EC2-Basis WaitTimeSeconds im Aufruf von receive-message fest.

SQS-Nachrichten können Nachrichtenattribute enthalten – Metadaten in Form von Schlüssel-Wert-Paaren, die vom Nachrichteninhalt getrennt sind. Attribute verfügen über einen Typ (String, Number, Binary) und einen Wert. Wenn SQS ein SNS-Thema abonniert, können Sie auf Nachrichtenattribute angewendete SNS-Abonnementfilterrichtlinien verwenden, um nur relevante Nachrichten an die jeweilige Warteschlange weiterzuleiten. Ohne Filterung empfängt jeder SQS-Abonnent jede SNS-Veröffentlichung unabhängig von deren Inhalt.

Eine Delay Queue macht jede neue Nachricht nach dem Senden für einen Verzögerungszeitraum von 0 bis 15 Minuten unsichtbar. Das ist nützlich für Workflows, in denen ein Konsument eine Nachricht nicht sofort verarbeiten soll – beispielsweise, wenn zunächst der Abschluss eines abhängigen Prozesses abgewartet werden muss. Sie können mithilfe von DelaySeconds im Sendeaufruf auch eine Verzögerung pro Nachricht festlegen, die die Verzögerung auf Warteschlangenebene überschreibt. Hinweis: Verzögerungswarteschlangen sind für FIFO-Warteschlangen nicht verfügbar.

Testen Sie Ihr Verständnis der Konzepte für AWS Solutions Architect (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Das Visibility Timeout blendet eine Nachricht während der Verarbeitung für andere Consumer aus und ermöglicht dadurch eine Zustellung mindestens einmal mit automatischer erneuter Zustellung, wenn der Consumer ausfällt. Dead-Letter Queues erfassen wiederholt fehlschlagende Nachrichten zum Debuggen und erneuten Abspielen, nachdem der Fehler behoben wurde. Long Polling (bis zu 20 Sekunden Wartezeit) reduziert im Vergleich zu Short Polling API-Kosten und Latenz. Als Nächstes sehen wir uns SNS topics und die Fan-out-Architektur an.