Hier bei PagerDuty stehen wir vor einigen interessanten architektonischen Herausforderungen, um die Zustellung von Alarmen zu gewährleisten und unseren Kunden das höchstmögliche Maß an Zuverlässigkeit zu bieten. Wir haben in der Vergangenheit erklärt, dass Sie bei Erhalt einer 200 OK vom PagerDuty Ereignisendpunkt aus Wille werden angepiept … selbst wenn das Rechenzentrum, mit dem Sie kommuniziert haben, unmittelbar nach Ihrer Anfrage verschwindet. Um diese Garantie einzuhalten, müssen wir das Ereignis synchron in mehrere Rechenzentren schreiben. Wir verwenden Apache Cassandra um dies zu erreichen und verlassen sich daher stark auf die Mehrheit Quorum liest und schreibt.

Mit solchen Garantien haben wir einige ungewöhnliche Anforderungen an unsere Cassandra-Bereitstellungen. Eine typische Cassandra-Bereitstellung bei PagerDuty besteht aus fünf Knoten, die auf drei Rechenzentren verteilt sind, mit einem Replikationsfaktor von fünf. Diese Konfiguration funktioniert gut für hochverfügbare geo-verteilte Quorum-Lese- und Schreibvorgänge, und wir haben schon mal darüber geschrieben , aber darüber wollen wir heute nicht sprechen. Stattdessen diskutieren wir etwas etwas Interessanteres: deterministische Lese-Hotspots trotz vollkommen gleichmäßiger Datenverteilung und einheitlicher Zugriffsmuster!

Diese Boxen werden einfach heiß …

Uns ist seit einiger Zeit aufgefallen, dass Cassandra-Hosts in einem unserer Rechenzentren (AWS us-west-1) heißer laufen als der Rest. Außerdem hatten wir festgestellt, dass die Hardware in diesem Rechenzentrum etwas älter und weniger effizient war als die der anderen beiden. Das schien ziemlich eindeutig: Schwächere Hardware in diesem Rechenzentrum führte zu einer höheren Belastung im Vergleich zur etwas besseren Hardware im Rest des Rings. Einer der Hosts im Ring hat mehr Kerne als die anderen (in Linode) und ist daher am wenigsten belastet, was die Hardware-Hypothese untermauert. Hier ist ein Diagramm der 5-Minuten-Last aller Hosts in einem unserer Cassandra-Ringe:

Sie können deutlich die „stärkere“ Box unten mit der geringsten Auslastung, die „schwachen“ us-west-1-Hosts oben und die weniger schwachen us-west-2-Hosts in der Mitte erkennen. Ockhams Rasiermesser , richtig? Nicht so schnell.

Mehr Daten, mehr Transparenz

Mit der vernünftigen und soliden Hardwarehypothese fühlten wir uns wohl und sahen keinen Grund, weitere Untersuchungen durchzuführen. Es verging einige Zeit, wir wuchsen und auch unsere Cassandra-Last. Es war an der Zeit, mit der Optimierung unserer Cassandra-Operationen zu beginnen. Das Erste, was man braucht, um einen Cassandra-Cluster richtig abzustimmen, sind natürlich MEHR DATEN!

Ein Cassandra-Upgrade lieferte uns mehr Messwerte, als wir verarbeiten konnten. Wir begannen, neue Dashboards zu erstellen, um zu sehen, ob wir etwas Interessantes finden konnten. Es gab mehrere Überraschungen, aber eine ließ sich nicht erklären: Während die Schreibvorgänge gleichmäßig auf alle Knoten verteilt waren, war die Leselast asymmetrisch. Weitere Untersuchungen zeigten, dass dieses Muster bei mehreren verschiedenen Diensten mit ähnlicher Topologie vorhanden war.

Drei Hosts erhielten durchgängig mehr Lesezugriffe als die anderen beiden. Das war überraschend, da die Leselast im System symmetrisch war und bei einem Replikationsfaktor, der der Clustergröße entspricht, alles ausgeglichen sein sollte. Bei einem Blick auf die Topologie wurde deutlich, dass die am stärksten belasteten Hosts alle in us-west-1 und Linode lagen. Wenn man Linode als Ausreißer außer Acht ließ (aufgrund der größeren Anzahl an CPU-Kernen), war klar, dass die Hardwarehypothese falsch war – diese Hot Nodes waren tatsächlich stärker ausgelastet als der Rest.

Cassandra Lesevorgänge vs. Schreibvorgänge

Wir führen Quorum-Schreibvorgänge durch, aber aufgrund unseres hohen Replikationsfaktors müssen alle Knoten die Daten schreiben. Während die Koordinator benötigt nur eine Mehrheitsbestätigung, um erfolgreich zu sein, der Schreibvorgang wird trotzdem an alle weitergeleitet. Wir führen auch Quorum-Lesevorgänge durch, aber im Gegensatz zu Schreibvorgängen wird der Lesevorgang nur an die erforderliche Mindestanzahl von Knoten weitergeleitet. In unserem Fall ist diese Zahl drei … sehr verdächtig.

Der Koordinator ist für die Auswahl der Knoten verantwortlich, von denen er lesen möchte. Es stellt sich heraus, dass er die Knoten auswählt, die reagiert am schnellsten . Sicherlich bringt die etwas langsamere Hardware keine bessere Leistung, also was soll das?

RTT ist eine Sache

Da unsere Cassandra-Cluster geografisch verteilt sind, dauert die Kommunikation zwischen den Knoten etwas. Wie lange das genau dauert, hängt von Quelle und Ziel ab, da die Beziehungen nicht gleichseitig sind. Hier ist ein Diagramm, das unsere Topologie und die ungefähren Roundtrip-Latenzen zwischen ihnen zeigt:

Wenn wir für einen Moment davon ausgehen, dass alle Mitglieder hinsichtlich der Leselatenz gleich gut abschneiden, können wir beginnen, die Wahrscheinlichkeit zu berechnen, dass ein bestimmter Knoten eine Leseanforderung von einem bestimmten Koordinator erhält. Also finden wir für jeden Knoten im Ring die nächsten Nachbarn (und damit die schnellsten Antworten). Mit Labels [NEU] Wie im vorherigen Diagramm zugewiesen, können wir eine Tabelle generieren:

Anhand dieser Tabelle können wir erkennen, dass Knoten DE nur in 2/5 der Fälle Lesezugriffe erhalten, was bedeutet, dass Knoten AC letztendlich etwa 60 % mehr Lesezugriffe erhalten als ihre Gegenstücke!

Reale Leseverteilung

In der Praxis sind wir nicht allzu weit davon entfernt. Betrachtet man das Diagramm der Lesevorgänge, so führen die Knoten us-west-2 im Durchschnitt 75 Lesevorgänge/Sekunde durch, während die anderen Knoten etwa 115-120 Lesevorgänge/Sekunde aufweisen – erschreckenderweise fast 60 % mehr! Wir sehen, dass sich diese Verschiebung ein wenig ändert, wenn Routen auftauchen und sich die lokalen Leselatenzen ändern, aber selbst mit diesen Variablen bleiben wir bemerkenswert nah an den Vorhersagen der Verteilungstabelle.

Erkenntnisse und Take-Aways

Nachdem wir das alles nun verstanden haben, stellt sich natürlich die Frage: „Was können wir dagegen tun?“ Rechenzentren so zu verschieben, dass sie netzwerkmäßig gleich weit voneinander entfernt sind, wäre ein vergeblicher Versuch, da sich Internetrouten leicht ändern können. Eine ungleichmäßige Verteilung unserer Lesevorgänge, um sich stärker auf DE als Koordinatorknoten zu stützen, würde zu unnötigen Leistungseinbußen führen, da Clients in anderen Rechenzentren eine Internetroute nutzen müssten, um den Cluster zu erreichen. Leider scheint die angemessenste Reaktion darin zu bestehen, die AC-Knoten einfach zu skalieren und die Last zu absorbieren. Dies kann problematisch sein, wenn wir ein Rechenzentrum verlieren, ist aber beherrschbar, solange die übrigen für einen solchen Fall nicht unterversorgt sind.

Das war für uns eine sehr interessante Erkenntnis. Die Antwort scheint jetzt offensichtlich, aber sie dient als Beispiel dafür, wie einfach es ist, Annahmen über Ihre Systeme zu treffen, die im wirklichen Leben einfach nicht zutreffen. Es ist auch erwähnenswert, dass Dies ist kein Cassandra-spezifisches Verhalten . Jedes geografisch verteilte System, das Arbeit an Hosts mit der kürzesten Reaktionszeit verteilt, wird unter diesem Phänomen leiden. Das sollten Sie im Hinterkopf behalten, wenn Sie jemals ein System mit ähnlichen Eigenschaften bauen … hoffentlich haben wir Ihnen etwas Zeit gespart :).

Vielen Dank an alle PagerDuty Ingenieure, die sich die Zeit genommen haben, dem auf den Grund zu gehen. Ohne sie wäre dieser Blogbeitrag nicht möglich gewesen! Schauen Sie sich unbedingt unsere Vorträge vom Cassandra Summit zu diesem und anderen Themen an. Donny Nadolny Und Paul Rechsteiner .