© astel design/Shutterstock.com
Was macht SRE eigentlich bei Neo4j Aura?

Glückliche Datenbanken


Moin, ich heiße Johannes und arbeite für Neo4j. Neo4j ist eine Firma, die eine Graphdatenbank herstellt. Graphdatenbanken sind wunderbar, um Datenmodelle abzubilden, die stark vernetzte Daten beinhalten und bei denen die Relationen der Daten eine erhebliche Rolle spielen. Um die Eigenschaften von Neo4j als Datenbank geht es in diesem Artikel allerdings nur am Rande. Es geht vielmehr um Neo4j Aura.

Bei Aura handelt es sich um das Cloud-Angebot von Neo4j, ein vollständig automatisiertes Graphdatenbank-as-a-Service-Angebot. Dem Kunden ist es hier möglich, über eine Weboberfläche ein Datenbankcluster zu konfigurieren und zu starten. Dieses Cluster wird dann von unserem Code in einem Kubernetes-Cluster in einer Public-Cloud für den Kunden betrieben.

Ich arbeite in einem der Teams, die für dieses Selfserviceprodukt verantwortlich sind, und ich möchte euch mit auf die Reise nehmen und zeigen, welche Aspekte wir in Bezug auf Site Reliability Engineering (SRE) eingeführt haben, um dieses Produkt am Laufen zu halten. Dabei werden wir speziell auf Monitoring, Alerting, Chaos Engineering, Rufbereitschaft und das Training dafür eingehen. Let’s go!

Let’s start at the beginning

Was benötigt man, um in diesem Business glückliche Kunden zu haben? „Glückliche“ Datenbanken! Aber woher weiß ich als Software-Engineer bzw. Site Reliability Engineer eigentlich, wann meine Datenbank glücklich ist? Speziell wenn es sich um ein Datenbankcluster handelt, das in einem Kubernetes-Cluster in einer Public Cloud läuft?

Wir müssen also zunächst mit der Definition einer glücklichen Datenbank anfangen. Wenn wir über glückliche Datenbankcluster sprechen, können wir hier verschiedene Kennzahlen, sogenannte Metriken, definieren. Eine solche Metrik könnte sein, ob das Cluster fehlertolerant ist. Fehlertolerant bedeutet an dieser Stelle, dass das aktuelle Cluster es ohne negative Auswirkungen verkraften könnte, dass man einen Datenbankknoten entfernt. Eine weitere Metrik könnte sein, ob das Cluster verfügbar ist. Das bedeutet, dass das Cluster zwar noch problemlos funktioniert, aber man auf keinen weiteren Datenbankknoten verzichten kann. Analog wäre die nächste Metrik, ob ein Cluster nicht mehr verfügbar ist, das Cluster also nicht mehr problemlos funktioniert.

Eine ganz andere Reihe von Metriken könnte sich auf die ausgeführten Transaktionen des Clusters beziehen, also zum Beispiel darauf, wie viele Transaktionen pro Sekunde geöffnet werden, wie viele erfolgreich abgeschlossen werden und wie viele fehlschlagen. Metriken können sich aber zum Beispiel auch auf einzelne Datenbankknoten in einem solchen Cluster beziehen, beispielsweise die Auslastung von CPU oder Festplatte eines einzelnen Datenbankknotens.

Im Endeffekt versuchen wir, so viele Metriken wie möglich zu sammeln, um den bestmöglichen Überblick zu erhalten, wie gut es den Datenbanken unserer Kunden geht. Diese Metriken fasst man dann üblicherweise in gut verständlichen Diagrammen zusammen.

An dieser Stelle sei kurz erwähnt, dass es viele Produkte gibt, die dieses Problem mit Bravour lösen, zum Beispiel Prometheus, Datadog oder Grafana. Es ist existenziell wichtig, dass man eins dieser Tools verwendet und damit die Metriken und Diagramme an einem zentralen Ort zusammenfasst und leicht zugänglich macht. Wenn jemand nachts um drei Uhr einen Alarm bzw. Alert erhält, dass eine Datenbank nicht glücklich ist, dann muss es für diese Person einfach sein, an die entsprechenden Informationen zu gelangen.

Man muss Metriken aber auch interpretieren

Aber da sind wir auch schon beim nächsten Punkt. Wann soll jemand einen Alert erhalten, der die Person womöglich nachts um drei Uhr aufweckt?

Lasst uns Abbildung 1 betrachten. Dort sind verschiedene Diagramme zu sehen. Die Diagramme haben unterschiedliche Wichtigkeiten und spielen unterschiedliche Rollen. Im oberen Bereich sind zum Beispiel die CPU-Auslastungen aller Datenbanken zu sehen. Der eigentlich spannende Teil dieser Abbildung ist allerdings der Bereich SLI. SLI bedeutet Service Level Indicator. Hier werden Metriken angezeigt, die Hinweise über den Zustand des Systems bzw. der Datenbankencluster geben. So sehen wir hier ein Diagramm, das anzeigt, wenn ein Datenbankcluster die bereits erwähnte Fehlertoleranz verliert. Weiterhin sehen wir ein Diagramm, das die Verfügbarkeit der Datenbankcluster widerspiegelt.

unterstein_sre_1.tif_fmt1.jpgAbb. 1: Beispielhafte Metriken in Datadog

Wenn man sich jetzt diese Diagramme genau anschaut, wird...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang