Zusammenfassung

  • Der Netzausfall am 9. Oktober und der Datenbankpool-Ausfall am 10. Oktober waren getrennte Ereignisse, die über gemeinsam genutzte Abhängigkeiten die Ausführung störten.
  • Einige Läufe mit internen Fehlern blieben auf Running. Fehlerhandler und wartende Elternfunktionen erhielten keine Meldung; Kunden mussten die Läufe abbrechen oder erneut ausführen.

Dauerhafte Ausführung verspricht, dass Arbeit warten, nach einer Unterbrechung fortgesetzt und bereits abgeschlossene Schritte behalten kann. Inngests Bericht über den 9. bis 11. Oktober legt die Bedingungen offen, die hinter diesem Versprechen stehen: Wo liegt der Zustand eines Laufs? Welche Warteschlangen teilen sich einen Verarbeitungspfad? Welchen Status schreibt das System, wenn eine interne Abhängigkeit versagt? Wer erfährt, dass ein Lauf nicht selbst weiterläuft?

Inngest beschreibt zwei Vorfälle und keinen einheitlichen Ausfall über mehrere Tage. Am 9. Oktober um 21:05 UTC verlor ein Rechenzentrumsanbieter die Verbindung zwischen seinem Standort und Inngests anderen Zentren sowie den ausgehenden Internetzugang. Laut Inngest vermutete der Anbieter zunächst einen Fehler bei einer Änderung der DDoS-Schutzkonfiguration; der vollständige Bericht stand noch aus. Die Verbindung kehrte um 21:49 zurück. Am folgenden Tag verloren die beiden PgBouncer-Pools vor der primären Datenbank um 14:00 und erneut um 15:30 UTC sämtliche Datenbankverbindungen.

Die Ablaufplanung und Warteschlangenverarbeitung stockten für die meisten Konten. Eine Gegenmaßnahme stellte die Verarbeitung wieder her, verursachte aber weitere zeitweilige Verzögerungen, vor allem bei Cron-Funktionen, bis die Planung am 11. Oktober um 04:17 UTC auf die ursprünglichen Pools zurückging. Am 12. Oktober verbesserte Inngest die Gateway-Routen. Ursache und Wiederherstellung unterschieden sich bei beiden Ereignissen.

Der erste Vorfall zeigt, wie eine lokale Netzgrenze den Ausfall weitertragen kann. Inngest erklärte, den Dienst über drei Rechenzentren zu betreiben. Konten konnten an einem Standort verarbeitet werden, während ihr Laufzustand an einem anderen lag; zentrale Konto- und Konfigurationsdatenbank sowie die Verbindungspools lagen bei einem weiteren Anbieter. Nach dem Verlust der Verbindung zwischen den Standorten konnten betroffene Worker Kontodetails nicht abrufen oder Laufzustände speichern. Auch Konten an anderen Standorten waren betroffen, wenn ihr Zustand im isolierten Zentrum lag.

Wiederholt fehlschlagende Arbeit baute zudem einen großen Rückstau in einer gemeinsam genutzten Ereignispipeline auf und verzögerte Funktionen von Konten ohne direkte Abhängigkeit vom isolierten Zentrum. Konten mit eigener Ereignispipeline waren nicht betroffen. Der gemeinsame Verarbeitungspfad bestimmte somit die Reichweite über die ursprüngliche Netzabhängigkeit hinaus.

Am 10. Oktober lag die Kopplung an anderer Stelle. Laut Inngest liefen kurze Fristen für Datenbankabfragen mit der Abbruchbehandlung von Client und PgBouncer zusammen. Manche Abfragen warteten noch auf eine Pool-Verbindung, als ihre Frist ablief. Der Treiber schloss die Client-Verbindung; später führte PgBouncer die verlassene Abfrage aus und schloss die Datenbankverbindung, statt sie dem Pool zurückzugeben. Neue Verbindungen wurden einzeln geöffnet. Dadurch gingen Verbindungen schneller verloren, als sie ersetzt werden konnten.

Die Pool-Ausfälle fielen mit Cron-Last am Beginn und Ende der Stunde zusammen, die das Abfragevolumen ungefähr verdreifachte, und mit neu eingeführten Abfragen, die vor dem Wochenende massenhaft scheiterten. Ein Neustart der Pools half nicht verlässlich; eine höhere Pool-Grenze beseitigte den Engpass beim Öffnen neuer Verbindungen nicht.

Die Ausweichroute führte eine weitere Abhängigkeit ein. Der Umzug zu Pools, die der Datenbankanbieter neben der Datenbank betrieb, stellte zwischen 16:10 und 16:25 UTC die Verarbeitung wieder her. Diese Route führte jedoch durch NAT-Gateways, die einige Verbindungen still verwarfen. Eine Abfrage konnte bis zu 16 Minuten hängen, bevor sie fehlschlug; besonders sichtbar war das bei Cron-Funktionen. Inngest stellte Cron am 11. Oktober um 04:17 UTC auf die ursprünglichen Pools zurück und verbesserte die Gateway-Routen am 12. Oktober. Eine Gegenmaßnahme verändert die Topologie.

Sie kann einen Engpass entfernen und zugleich eine weniger sichtbare Zeitgrenze schaffen.

Die Zustandsänderung war die wichtigere Kontrolllücke. Inngest sagte, interne Fehler hätten die konfigurierten Wiederholungen verbraucht. Wenn ein Schritt wegen eines internen Fehlers endgültig scheiterte, blieben einige Läufe auf Running, statt auf Failed zu wechseln. Dadurch lief weder onFailure, noch erhielt eine über step.invoke wartende Elternfunktion die Fehlermeldung. Laut Bericht setzten sich diese Läufe nicht selbst fort; Kunden mussten sie abbrechen oder erneut ausführen. Ein wieder funktionierender Worker-Pool bedeutete nicht automatisch, dass jeder unterbrochene Geschäftsprozess einen Endzustand erreicht hatte.

Das ist etwas anderes als eine normale Fortsetzung. Inngests Dokumentation erklärt, dass abgeschlossene Schrittresultate bei einer Fortsetzung wiederverwendet werden können und jeder Schritt eigene Wiederholungen hat. Der im Vorfallbericht beschriebene Replay startet dagegen den Lauf erneut von vorn. Bereits abgeschlossene Schritte können dadurch wieder ausgeführt werden. Es gibt keinen Beleg, dass dabei eine Zahlung, Nachricht oder Datenbankänderung doppelt erfolgte. Wer einen Lauf wiederholt, muss aber den Trace prüfen und feststellen, ob die Wiederholung sicher ist.

Inngests Idempotenzdokumentation weist darauf hin, dass ein externer Dienst eine Aktion annehmen kann, bevor die Orchestrierung das Ergebnis speichert; ein neuer Versuch könnte denselben Aufruf dann wiederholen. Ein Checkpoint hält internen Fortschritt fest, garantiert aber nicht für sich allein genau eine externe Wirkung.

Inngest meldete bereits ausgelieferte Korrekturen: Abfragen, die noch auf eine Pool-Verbindung warten, werden nicht mehr mit dem Client abgebrochen; ein endgültiger interner Fehler markiert den Lauf als fehlgeschlagen; kann der Zustand gerade nicht gelesen werden, bleibt die Arbeit in der Warteschlange und wird fortgesetzt, sobald der Zustand wieder verfügbar ist. Auch Gateway-Routing und Statusseitenmeldungen wurden verbessert. Die größere Architekturänderung, die Konsolidierung auf ein Rechenzentrum, war noch im Gange. Der Bericht beschreibt weder die fertige Topologie noch deren unabhängige Notfallwiederherstellung.

Quellen