Vorfall in US-East durch erschöpfte Redis-Verbindungen

Kevin van Zonneveld

Mitgründer · Amsterdam, Niederlande · Bio anzeigen

Am 3. September 2025 (US-East) kam es zu erhöhten Queue-Zeiten und phasenweise zu stockender Jobverarbeitung, weil die Redis-Verbindungen erschöpft waren. Noch am selben Tag wurde die Lage durch einen Hotpatch und Konfigurationsänderungen stabilisiert. Dieser Beitrag erklärt, was passiert ist, wie wir das Problem entschärft haben und was wir tun, um eine Wiederholung zu verhindern.

Zusammenfassung

Ein interner Service-Endpunkt verursachte bei starker Beanspruchung ein Leck von Redis-Verbindungen. Ein Kunde löste einen ungewöhnlich großen Schwall von Anfragen an diesen Endpunkt aus. Obwohl unser Traffic Shaper den Schwall auf eine Backup-Queue isolierte, übertrug das Verbindungsleck den Druck auf gemeinsam genutzte Redis-Server. Sobald die Server ihre Verbindungslimits erreichten, wurden legitime Worker und API-Pfade in der Region ausgebremst, was zu langsamen Queues und zeitweise stockenden Jobs führte. Wir haben einen Hotpatch ausgerollt, um geleakte Verbindungen zu schließen, und die Limits angepasst; danach lief die Verarbeitung wieder normal.

Auswirkungen

• Zeitraum: 3. September 2025
  • 12:00 UTC: Langsames Encoding in US-East mit vielen Queues
  • 19:50 UTC: Erhöhte Queue-Zeiten und zu viele wartende Verbindungen beobachtet
  • 21:24 UTC: Systeme stabilisiert; Ursachenanalyse fortgesetzt
  • 23:06 UTC: Ursache identifiziert und Hotpatch ausgerollt; Wiederherstellung bestätigt
• Region: us-east-1
• Auswirkungen für Nutzer:
  • Höhere Queue-Zeiten als normal für Assemblies
  • In einigen Fällen stockende Jobs, wenn Redis-Server weitere Verbindungen ablehnten
  • Webhooks/Notifications und einige API-Interaktionen in der Region verzögerten sich

Ursache

• Ein Codepfad in einem stark frequentierten internen Endpunkt schloss Redis-Verbindungen unter bestimmten Fehlerbedingungen nicht zuverlässig.
• Eine einzelne Kundenlast beanspruchte diesen Endpunkt unbeabsichtigt übermäßig, erhöhte dadurch die Verbindungsfluktuation und legte das Leck offen.
• Schließlich waren die Verbindungslimits der Redis-Server erschöpft, sodass neue Verbindungen von legitimen Workern und API-Knoten blockiert wurden.

Begünstigende Faktoren:

• Gemeinsam genutzte Redis-Pools vergrößerten den Wirkungsradius, sobald die Verbindungslimits erreicht waren.
• Bestehende Dashboards zeigten das Verbindungsleck nicht an, weil die Metriken des Erfolgspfads gesund waren, die Verbindungserfassung auf dem Fehlerpfad jedoch nicht.

Erkennung

Wir haben das Problem über Alerts zur Queue-Latenz und Anomalien bei den Worker-Heartbeats erkannt. Unsere Engineers brachten Spitzen bei connected_clients in Redis, steigende Verbindungsfluktuation und Fehler vom Typ ECONNREFUSED/max clients reached auf den betroffenen Servern in Zusammenhang.

Behebung und Wiederherstellung

• Traffic der verursachenden Last wurde bereits verlangsamt in eine isolierte Backup-Queue geleitet, was die Auswirkungen begrenzte, aber nicht beseitigte.
• Wir haben die Redis-Verbindungslimits vorübergehend angehoben, um während der Diagnose Luft zu schaffen.
• Wir haben einen Hotpatch ausgeliefert, der sicherstellt, dass Verbindungen beim betreffenden Endpunkt sowohl auf Erfolgs- als auch auf Fehlerpfaden immer freigegeben werden.
• Wir haben betroffene Prozesse neu gestartet, um geleakte Verbindungen abzubauen, und den Normalbetrieb überprüft.

Um 21:24 UTC stabilisierten sich die Systeme. Um 23:06 UTC wurde das Leck bestätigt und der Hotpatch flottenweit ausgerollt. Seitdem laufen die Systeme stabil.

Kundenkommunikation

Während des gesamten Vorfalls haben wir Updates auf unserer Statusseite veröffentlicht und betroffene Kunden kontaktiert. Nach der Behebung haben wir empfohlen, ein Assembly Replay zu versuchen, um andernfalls verlorene Ergebnisse wiederherzustellen, sofern die Eingabedateien noch verfügbar waren.

Unsere nächsten Schritte

• SLOs und Dashboards für Verbindungslecks ergänzen, die den Verbindungslebenszyklus auf Erfolgs- und Fehlerpfaden verfolgen.
• Verbindungsbudgets pro Endpunkt und Circuit Breaker einführen, um Lecks einzudämmen.
• Redis-Client-Pooling mit strikten Timeouts und lintbaren Blöcken (finally) rund um die Verbindungsaufnahme stärken.
• Kritische Redis-Rollen (Queues, Locks, Metadaten) auf getrennte Pools mit eigenen Limits aufteilen.
• Rate Limiting am betroffenen Endpunkt verschärfen, mit Backpressure, die die Leistung kontrolliert reduziert.
• Chaos-Tests ergänzen, die teilweise Redis-Ausfälle und Verbindungsfluten simulieren.

Wenn Sie betroffen waren

Führen Sie kritische Jobs nach Möglichkeit erneut aus. Wenn Ihre Eingabedateien noch verfügbar sind, können Sie eine fehlgeschlagene Assembly über unsere API erneut ausführen, siehe Assembly Replay durchführen. Wenn Sie Hilfe dabei benötigen, betroffene Jobs zu identifizieren, wenden Sie sich bitte an den Support, wir unterstützen Sie gern.

Update 4. September 2025

Einen Tag später kam es zu einem weiteren Vorfall. Wir hatten zwar eine Leckquelle erfolgreich geschlossen, doch es stellte sich heraus, dass es noch eine zweite gab. Diesmal konnten wir sie früher erkennen und das Problem innerhalb einer Stunde entschärfen.

Wir haben zusätzliche Härtungsmaßnahmen abgeschlossen, um die Wahrscheinlichkeit einer Wiederholung zu senken. Wir haben gezielte Rate Limits für den betroffenen Endpunkt ergänzt, die Verbindungshygiene in allen Codepfaden verbessert, die Fehler behandeln, und einige Redis-Zuständigkeiten auf separate Pools mit klareren Limits aufgeteilt. Zusammen verkleinern diese Änderungen den Wirkungsradius und machen das System bei schubweisen Lasten widerstandsfähiger.

Außerdem haben wir Monitoring und Alerting erweitert, um Frühsignale in den Blick zu nehmen, etwa ungewöhnliche Verbindungsfluktuation und Druck in den Queues, damit wir schneller reagieren können, wenn ähnliche Muster auftreten. Diese Verbesserungen sind jetzt in US-East aktiv und werden vorsorglich auf weitere Regionen ausgerollt.

Abschluss

Wir bedauern die Störung aufrichtig. Zuverlässigkeit hat für uns oberste Priorität, und am 3. September haben wir unsere eigenen Standards in US-East nicht erfüllt. Die oben genannten Fixes sind bereits in Umsetzung, und wir melden uns erneut, falls es weitere wesentliche Änderungen gibt.