PagerDuty basiert auf einer einfachen Idee: die richtigen Leute zu wecken, wenn etwas kaputt geht. Wenn ein Ereignis ausgelöst wird, benachrichtigt PagerDuty auf magische Weise die richtige Person oder das richtige Team, dass etwas nicht stimmt.

Es ist jedoch nicht so einfach sicherzustellen, dass die Nachricht unseren Weg zu Ihnen findet. Da wir Sie benachrichtigen, wenn Ihre Systeme ausfallen, sind wir stark eingeschränkt, was die Verfügbarkeit betrifft. Wenn Sie uns nicht vertrauen können, wem dann?

Wir setzen in unserer Alarmierungspipeline auf einige verteilte Technologien, da diese uns die nötige Redundanz bieten, um sicherzustellen, dass die Alarme die Benutzer erreichen. Wir haben viel Zeit darauf verwendet, unsere Infrastruktur so fehlertolerant wie möglich zu gestalten, um dauerhafte und konsistente Lese-/Schreibvorgänge in unserer kritischen Alarmierungspipeline zu gewährleisten.

Diese Pipeline beginnt mit einem Ereignisendpunkt – entweder HTTP oder E-Mail. Von dort durchläuft jedes Ereignis des Überwachungstools eines Kunden eine Pipeline separater Dienste (wie Incident Management und Benachrichtigungsmanagement) und landet schließlich beim Messaging-Dienst, der die Nutzer tatsächlich erreicht. Viele dieser Dienste basieren auf Scala und werden im Backend von Cassandra zur Datenspeicherung unterstützt. Zur Koordination nutzen wir auch andere Technologien wie Zookeeper. Diese Pipeline muss stets aktiv und fehlerfrei sein, damit wir sicherstellen können, dass die Benachrichtigungen die Nutzer erreichen.

Cassandra bei PagerDuty

Wir nutzen Cassandra seit etwa zweieinhalb Jahren in der Produktion. Im Gegensatz zu anderen Unternehmen, die Cassandra zur Unterstützung ihrer Big-Data-Aktivitäten nutzen, ist unser Datensatz relativ klein – etwa zehn Gigabyte zu jedem Zeitpunkt. Da wir Cassandra nutzen, um Ereignisse durch unsere Pipeline zu leiten, können die Daten nach dem Ende des Ereignisses aus der Pipeline gelöscht werden. Wir versuchen, unseren Datensatz so klein wie möglich zu halten.

Cluster-Konfiguration

Wir erstellen typischerweise Cluster aus fünf Cassandra-Knoten mit einem Replikationsfaktor von fünf. Diese Knoten sind auf drei Rechenzentren verteilt: zwei Knoten in einem, zwei Knoten in einem anderen und ein Knoten in einem weiteren Rechenzentrum. Wir nutzen Cassandras Quorum-Konsistenzlevel, um die benötigte Stabilität in der Pipeline zu gewährleisten. Das bedeutet, dass jeder Schreibvorgang auf die Mehrheit des Clusters, also mindestens drei der fünf Knoten, erfolgen muss.

Dieses Muster ist nicht ohne Nachteile. Jeder Vorgang erfolgt über das WAN und führt zu Latenzeinbußen zwischen den Rechenzentren. Dies widerspricht in gewisser Weise den üblichen Empfehlungen für Datenbankcluster. Da diese Latenzeinbußen jedoch nicht von Menschen verursacht werden, sind wir bereit, diesen Kompromiss angesichts der Vorteile in Kauf zu nehmen: Ereignisse gehen nicht verloren, Nachrichten werden nicht wiederholt und wir erhalten Stabilität und Verfügbarkeit für den Fall, dass ein ganzes Rechenzentrum ausfällt. Bei diesem 3-von-5-Muster wird alles in mindestens zwei Rechenzentren geschrieben.

Woher wissen wir, dass das funktioniert?

Wir führen absichtlich Fehler in unserer Infrastruktur ein, um sicherzustellen, dass im Falle eines Ausfalls alles reibungslos weiterläuft. Dazu gehört das gründliche Testen von Cassandra-Knoten in degradiertem und nicht funktionsfähigem Zustand. Weitere Informationen hierzu finden Sie in unserem Beitrag vom Freitag, der zum Scheitern verurteilt ist .

Bei PagerDuty lösen wir gerne interessante technische Probleme. Wenn Sie daran interessiert sind, unseren Cluster robuster zu machen, stellen wir derzeit für folgende Positionen ein: San Francisco Und Toronto .