Am 3. und 4. Juni kam es bei PagerDutys Benachrichtigungspipeline zu zwei großen SEV-1-Ausfällen. Am 3. führte der Ausfall zu einer Phase schlechter Leistung, die zu einigen verzögerten Benachrichtigungen führte. Am 4. war der Ausfall noch schwerwiegender. Um den Ausfall zu beheben, wurden die laufenden Daten aus dem System gelöscht, was zu einer fehlgeschlagenen Benachrichtigungsübermittlung, der Nichtannahme eingehender Ereignisse von unserer Integrations-API und einer erheblichen Anzahl verzögerter Benachrichtigungen führte.

Wir möchten uns bei allen unseren Kunden entschuldigen, die von diesem Ausfall betroffen waren. Dies war ein sehr ernstes Problem und wir ergreifen Maßnahmen, um einen Ausfall dieses Ausmaßes in Zukunft zu verhindern.

Was ist passiert?

Unsere Benachrichtigungspipeline basiert auf einem NoSQL-Datenspeicher namens Cassandra. Dieser Open-Source-, verteilte, hochverfügbare und dezentrale Datenspeicher betreibt einige der beliebtesten Websites/Dienste im Internet. Cassandra hat sich auch als kompliziertes System erwiesen, das schwierig zu verwalten und richtig abzustimmen ist.

Am 3. Juni nahm der Reparaturprozess auf einem der Knoten in unserem Cassandra-Cluster den Normalbetrieb auf. Dieser Cassandra-Reparaturprozess im Hintergrund, der dazu dient, die Konsistenz der gespeicherten Daten im gesamten Cluster sicherzustellen, belastet Cassandra erheblich. Dies wirkte sich auf die Leistung unseres Datenspeichers aus. Der Reparaturprozess in Kombination mit der zu diesem Zeitpunkt zusätzlich hohen Arbeitslast versetzte den Cassandra-Cluster in einen stark beeinträchtigten Zustand.

Um die Situation zu beheben, verringerte unser Team die Belastung des Clusters. In diesem Zusammenhang wurde der Reparaturprozess gestoppt. Dadurch wurde der Vorfall vorübergehend behoben, der Cluster schwankte jedoch sechs Stunden lang zwischen stabilen und instabilen Phasen. Anschließend haben wir die Kommunikation zwischen einigen Knoten unterbrochen, um den Cluster zu stabilisieren. Schließlich wurde der normale Betrieb wieder aufgenommen.

Während dieses Ausfalls war die Benachrichtigungs-Pipeline von PagerDuty soweit beeinträchtigt, dass etwa 3 % der an unsere Integrations-API gesendeten Ereignisse nicht empfangen werden konnten und eine kleine Anzahl von Benachrichtigungen (ein Bruchteil von 1 %) verspätet zugestellt wurde.

Am 4. Juni startete unser Team den am 3. verschobenen Reparaturvorgang manuell neu. Obwohl der Reparaturvorgang eine erhebliche Menge optionaler Systemlast deaktivierte, führte er letztendlich wieder zum Systemausfall vom Vortag. Leider war dieser nachfolgende Ausfall viel schädlicher: Während dieses Ausfalls konnten wir 14,9 % der an unsere Integrations-API gesendeten Ereignisse nicht empfangen, während 27,5 % der Benachrichtigungen überhaupt nicht zugestellt wurden und 60,9 % der Benachrichtigungen mehr als 5 Minuten verzögert waren.

Zunächst versuchten wir, unseren Prozess vom Vortag zu reproduzieren, um Cassandra zu stabilisieren, aber diese Bemühungen führten nicht zum gleichen Ergebnis. Nach mehreren weiteren Versuchen, die Leistung der Benachrichtigungspipeline zu stabilisieren, wurde entschieden, eine drastische Maßnahme zu ergreifen, um die Kontrolle über die Pipeline zurückzuerlangen: einen „Werksreset“, bei dem alle laufenden Daten in der Benachrichtigungspipeline gelöscht wurden. Dadurch konnte das Team den Dienst schrittweise wiederherstellen, was zur Stabilisierung der Pipeline und einer Rückkehr zum regulären Betrieb führte. Cassandra erholte sich nach dem „Reset“ sofort, obwohl einige unserer nachgelagerten Systeme manuelle Eingriffe erforderten, um ihre Daten mit dem neuen „leeren Blatt“ in Einklang zu bringen.

Obwohl unsere Systeme jetzt voll funktionsfähig sind, führen wir noch immer eine Ursachenanalyse durch, da wir verstehen müssen, warum unsere Stabilisierungsansätze nicht funktioniert haben. Grundsätzlich wissen wir jedoch, dass wir unterdimensioniert waren und dass wir den Cluster für zu viele verschiedene Dienste mit unterschiedlichen Last- und Nutzungsmustern gemeinsam genutzt haben.

Was machen wir?

Unsere oberste Priorität ist es, sicherzustellen, dass ein solcher Ausfall unsere Kunden nicht noch einmal betrifft. Wir bei PagerDuty nehmen Zuverlässigkeit unglaublich ernst und werden Projekte priorisieren, die dazu beitragen, unser System in Zukunft stabiler zu machen. Hier sind einige der Änderungen, die wir vornehmen werden, um zu verhindern, dass sich Ausfälle dieser Art erneut ereignen:

• Vertikale Skalierung der vorhandenen Cassandra-Knoten (größere, schnellere Server)

• Einrichten mehrerer Cassandra-Cluster und Verteilen unserer Workloads auf diese

• Festlegung von Systemlastschwellenwerten, bei denen wir in Zukunft unsere vorhandenen Cassandra-Cluster proaktiv horizontal skalieren werden

• Aktualisieren Sie die aktuellen und neuen Cluster auf eine neuere Version von Cassandra.

• Implementieren Sie weitere Lastabwurftechniken, die uns helfen, Cassandra bei hoher Last zu kontrollieren

• Holen Sie sich zusätzliche Cassandra-Expertise ins Haus

Eine letzte Sache muss noch erwähnt werden: Wir hatten uns bereits entschieden, einige der oben genannten Maßnahmen zu ergreifen, da uns kürzlich ähnliche Probleme aufgefallen waren. Einige unserer geplanten Verbesserungen hatten wir bereits umgesetzt, aber leider hatten wir uns entschieden, die restlichen Verbesserungen in einer Reihenfolge durchzuführen, die hauptsächlich auf Effizienz basierte: Wir hatten uns entschieden, das Cassandra-Versionsupgrade vor der vertikalen + horizontalen Skalierung durchzuführen. Leider lief uns die Zeit davon. Es ist nun offensichtlich, dass die Skalierung zuerst erfolgen musste, und seit dem 4. haben wir die vertikale Skalierung bereits abgeschlossen und sind mitten in der Aufteilung unserer Cassandra-Cluster basierend auf Arbeitslast und Nutzung.

Wenn Sie Fragen oder Bedenken haben, senden Sie uns eine E-Mail an support@pagerduty.com .