Warteschlangen für Lastspitzen planen

Eine Warteschlange puffert kurzzeitige Lastspitzen, wenn Arbeit schneller eintrifft, als die Ziel-API sie zulässt. Planen Sie vom möglichen Abfluss und der fachlichen Frist aus: Lassen sich die angenommenen Vorgänge rechtzeitig abschließen? Ist der Eingang dauerhaft größer als die Abschlusskapazität, wächst die Zahl offener Fälle trotz Queue.

Eingang, Abfluss und Frist abschätzen

Schätzen Sie für einen passenden Zeitraum, wie viele Vorgänge eintreffen und wie viele Zielaufrufe ein Vorgang benötigt. Beziehen Sie Statusprüfungen und mögliche Wiederholungen ein. Vergleichen Sie den Eingang mit der unter den tatsächlichen API-Grenzen möglichen Verarbeitung. Ein zeitweiliger Überschuss muss später abgebaut werden können.

Als grobe Bilanz gilt: offene Vorgänge am Ende eines Zeitraums entsprechen den zuvor offenen plus neuen Vorgängen minus bestätigten Abschlüssen und begründeten Verwerfungen. Das ist eine Planungsrechnung, keine Durchsatzzusage. Die sichtbare Zahl von Queue-Nachrichten ist etwas anderes: Arbeit kann gerade verarbeitet, erneut zugestellt oder in einen gesonderten Fehlerweg verschoben worden sein.

Legen Sie fest, wie alt ein Fall höchstens werden darf. Prüfen Sie, ob Wartezeit, Bearbeitungszeit und mögliche Wiederholungen in diese Frist passen. GitHub empfiehlt für seine REST-API zur Vermeidung sekundärer Limits serielle Aufrufe und nennt eine Queue als mögliche Umsetzung. Für andere APIs müssen Sie deren eigene Regeln prüfen.

Schritte zur Planung von Warteschlangen für Lastspitzen

Die Begrenzung gemeinsam durchsetzen

Teilen mehrere Worker dasselbe Zielbudget, reicht ein lokales Limit pro Worker nicht. Begrenzen Sie die Summe ihrer Zielaufrufe. Stimmen Sie außerdem ab, wann ein Worker neue Nachrichten empfängt und wie lange ihre Bearbeitung dauern darf. Bei Produkten mit Sichtbarkeitsfrist oder Lock kann zu langes Bearbeiten eine erneute Zustellung auslösen.

Jede Nachricht braucht eine stabile Vorgangskennung und den für die Bearbeitung nötigen Kontext. Prüfen Sie die Größen- und Zugriffsgrenzen des gewählten Queue-Produkts. Liegen große oder sensible Daten außerhalb der Nachricht, muss die berechtigte Quelle sie beim späteren Abruf noch im benötigten Stand liefern.

Wiederholung und Aufbewahrung einplanen

Bei Amazon SQS bleibt eine empfangene Nachricht während des Visibility Timeouts vorübergehend verborgen. Wird sie nicht rechtzeitig gelöscht, kann sie erneut sichtbar werden; SQS schließt doppelte Zustellung auch während dieses Zeitraums nicht vollständig aus. Azure Service Bus empfiehlt bei verlustkritischer Verarbeitung Peek Lock und ausdrücklichen Abschluss; nach Lock-Verlust kann eine Nachricht erneut eintreffen.

Prüfen Sie die tatsächliche Aufbewahrungsfrist Ihrer Queue. Bei SQS ist die Nachrichtenaufbewahrung konfigurierbar; nach Ablauf werden verbliebene Nachrichten entfernt. Die maximale geplante Wartezeit muss innerhalb dieser Grenze liegen.

Für dauerhaft fehlschlagende Fälle braucht es einen sichtbaren gesonderten Weg. Die fachliche Bearbeitung solcher Fälle gehört in eine zugewiesene Prüfliste.

Rückstand richtig beobachten

Beobachten Sie wartende Nachrichten, gerade verarbeitete Nachrichten und das Alter des Rückstands. SQS stellt dafür CloudWatch-Metriken bereit, deren Werte teils ungefähr sind. Das Alter der ältesten Nachricht kann bei wiederholt fehlgeschlagenen Standard-Queue-Nachrichten zudem einen Teil des Problems verdecken. Queue-Metriken zeigen Betriebszustände; sie beweisen keinen fachlichen Abschluss.

Gehen Sie vor dem Einsatz eine kurze und eine längere Spitze, eine langsame Ziel-API sowie einen Worker-Ausfall durch. Halten Sie fest, wann der Rückstand abgebaut sein müsste und wer Fälle übernimmt, die zu alt werden. Die tatsächliche Kapazität lässt sich erst in der vorgesehenen Umgebung bestimmen.

Wichtige Metriken zur Überwachung von Warteschlangen