© Excellent backgrounds/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...

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