Am 25. März kam es bei PagerDuty über einen Zeitraum von drei Stunden zu zeitweiligen Leistungseinbußen, die unsere Kunden auf verschiedene Weise beeinträchtigten. Während der Leistungseinbußen konnte PagerDuty 2,5 % der Versuche, Ereignisse an unsere Integrationsendpunkte zu senden, nicht annehmen, und bei 11,0 % der Benachrichtigungen kam es zu einer Verzögerung bei der Zustellung – anstatt innerhalb von fünf Minuten nach dem auslösenden Ereignis einzutreten, wurden sie bis zu fünfundzwanzig Minuten nach dem auslösenden Ereignis gesendet.

Wir nehmen Zuverlässigkeit sehr ernst. Ein Ausfall dieser Größenordnung und die damit verbundenen Auswirkungen auf unsere Kunden sind inakzeptabel. Wir entschuldigen uns bei allen betroffenen Kunden und arbeiten daran, sicherzustellen, dass die zugrunde liegenden Ursachen PagerDuty -Kunden nie wieder betreffen.

Was ist passiert?

Ein Großteil der PagerDuty Benachrichtigungspipeline basiert auf Cassandra, einem verteilten NoSQL-Datenspeicher. Wir verwenden Cassandra aufgrund seiner hervorragenden Haltbarkeits- und Verfügbarkeitseigenschaften und es funktioniert für uns hervorragend. Da wir einen größeren Teil der Benachrichtigungspipeline auf Cassandra umgestellt haben, hat sich die Arbeitslast auf unserem Cassandra-Cluster erhöht, einschließlich der Dauerlast und einer Vielzahl von geplanten Jobs im Batch-Stil mit Spitzenlast.

Am 25. März war der Cassandra-Cluster einer höheren als üblichen Arbeitslast durch mehrere separate Back-End-Dienste ausgesetzt, war aber immer noch innerhalb der Kapazität. Einige geplante Jobs übten dann jedoch erhebliche, stoßweise Arbeitslasten auf den Cassandra-Cluster aus, wodurch mehrere Cassandra-Clusterknoten überlastet wurden. Die überlasteten Cassandra-Knoten reagierten, indem sie verschiedene in die Warteschlange gestellte Anfragen stornierten, was zu Verarbeitungsfehlern bei internen Clients führte.

Anforderungsfehler sind nicht unerwartet, viele unserer internen Clients verfügen über eine Wiederholungslogik bei Fehlern, um vorübergehende Fehler zu überbrücken. Angesichts der Überlastung von Cassandra waren diese Wiederholungsversuche jedoch kontraproduktiv, da viele der abgebrochenen Anforderungen sofort wiederholt wurden – was dazu führte, dass die Überlastungsperiode länger als nötig dauerte, da die Wiederholungsversuche mit der Zeit nachließen.

Zusammenfassend lässt sich sagen, dass erhebliche Schwankungen in unserer Cassandra-Arbeitslast die Verarbeitungskapazität des Clusters überstiegen und es infolgedessen zu Ausfällen kam. Darüber hinaus dauerte es aufgrund der Client-Wiederholungslogik viel länger, bis die Arbeitslast abgebaut wurde, was die Dauer der Dienstunterbrechung verlängerte.

Was wir dagegen tun

Selbst bei hervorragender Überwachung und Warnfunktion sind stoßweise Arbeitslasten gefährlich: Bis ihre Auswirkungen messbar sind, ist der Schaden möglicherweise bereits angerichtet. Stattdessen sollte eine Gesamtarbeitslast mit geringer Variabilität angestrebt werden. Vor diesem Hintergrund haben wir unsere geplanten Jobs neu ausbalanciert, sodass sie zeitlich verteilt sind, um ihre Überschneidungen zu minimieren. Darüber hinaus reduzieren wir die Intensität unserer geplanten Jobs, sodass jeder Job eine viel gleichmäßigere und vorhersehbarere Last aufweist, auch wenn diese über einen längeren Zeitraum angewendet wird.

Auch wenn unsere Datensätze bereits logisch getrennt sind, ist es immer noch problematisch, einen einzigen gemeinsamen Cassandra-Cluster für die gesamte Benachrichtigungspipeline zu haben. Abgesehen davon, dass die kombinierte Arbeitslast mehrerer Systeme schwer zu modellieren und genau vorherzusagen ist, bedeutet dies auch, dass eine Überlastung mehrere Systeme beeinträchtigen kann. Um diesen Überlastungs-Welleneffekt zu reduzieren, werden wir verwandte Systeme isolieren, um separate Cassandra-Cluster zu verwenden. Dadurch wird die Möglichkeit ausgeschlossen, dass sich Systeme über Cassandra gegenseitig stören.

Unsere Richtlinien zur Fehlererkennung und zum Wiederholungsversuch müssen ebenfalls neu ausbalanciert werden, damit sie Überlastungsszenarien besser berücksichtigen und eine Drosselung und Lastableitung ermöglichen.

Schließlich müssen wir unser Fehlertestprogramm erweitern, um Überlastungsszenarien sowohl innerhalb unserer Failure Friday-Sitzungen als auch darüber hinaus einzuschließen.

Wir nehmen jeden Ausfall, der unsere Kunden betrifft, ernst und werden die oben genannten (und noch viele weitere) Schritte unternehmen, um PagerDuty noch zuverlässiger zu machen. Wenn Sie Fragen oder Kommentare haben, lassen Sie es uns bitte wissen.