Ist 4 9’s gut genug? Wenn ja, dann sollten Sie das hier lesen

Fangen wir damit an, was 4 9’s genau bedeutet:

Vier Neunen sind 4,38 Minuten Ausfallzeit pro Monat oder 52,56 Minuten pro Jahr.

Das ist wahrscheinlich mehr als akzeptabel für fast alle Dienste im Internet, nicht alle, aber fast alle. Wenn Ihre E-Mail also jeden Monat 4 Minuten lang ausfällt, ist das kein Weltuntergang. Ich meine, du würdest es wahrscheinlich nicht einmal merken. Bis Sie auf Twitter nachsehen, ob es nur an Ihnen liegt oder nicht, ist es schon wieder in Betrieb.

Um eine gute Betriebszeit zu erreichen, denkt man in der Regel an Redundanz und Replikation, so dass beim Ausfall eines Servers sofort andere Server einspringen können. Das Problem bei diesem Ansatz ist, dass er kompliziert und teuer ist. Sie benötigen mehrere Server, in der Regel drei oder mehr für Ihre Anwendung und Ihre Datenbank, und zusätzlich einen Load Balancer, der dem Server vorgeschaltet ist. Und dann müssen Sie all diese Maschinen verwalten/überwachen.

Und mit dem neuen Microservices-Trend, bei dem die Leute ihre Anwendungen in kleinere Dienste aufteilen, müssen Sie diese komplizierten Setups für jeden Dienst wiederholen.

Wenn Sie einen Microservice bauen, ist es umso besser, je weniger „Zeug“ Sie brauchen, um ihn zu betreiben. Du willst doch nicht jedes Mal eine neue replizierte Datenbank einrichten, wenn du eine kleine API zusammenstellen willst, oder? Ich möchte superproduktiv sein, ich möchte einen Dienst schnell auf die Beine stellen können, ohne mich mit all den komplizierten, zeitraubenden Betriebsabläufen befassen zu müssen.

Also habe ich mir überlegt: „Was wäre, wenn es einen Weg gäbe, um… zuverlässig genug zu sein?“ Ich meine, wie viele der Dinge, die Sie bauen, müssen tatsächlich hochverfügbar sein? Wie viele Dienste können es sich nicht leisten, hier und da für ein paar Minuten auszufallen oder alle Jubeljahre einmal ein winziges Stückchen Daten durch einen fatalen Serverausfall zu verlieren?

Ich schätze, dass es nicht viele Dienste gibt, die es sich nicht leisten können, eine sehr kleine Menge an Daten zu verlieren und ein paar Minuten Ausfallzeit pro Jahr zu haben. Selbst wenn Sie Ihren Dienst mit Architekten ausstatten, werden Sie aus irgendeinem Grund wahrscheinlich immer noch Ausfallzeiten haben. Deshalb sollten Sie es einfach halten.

Zunächst ein paar Zahlen: Nehmen wir an, dass eine AWS EC2-Instanz im Durchschnitt alle sechs Monate ausfällt. Ich glaube, dass es heutzutage viel weniger ist, aber niemand weiß es wirklich, also bleiben wir konservativ. Damit haben wir etwa 26,5 Minuten Zeit, um die App alle sechs Monate wiederherzustellen und trotzdem 4 9er Betriebszeit zu haben.

So bekommen Sie 4 9er auf einer einzigen Maschine.

Schritt 1) Server starten, App bereitstellen und DNS-Skript ändern

Das erste, was wir brauchen, ist ein einfaches Skript, das eine neue Instanz starten kann, die App startet (mit Docker ist das ganz einfach) und DNS ändert, um auf die neue Instanz zu verweisen. Ich werde in diesem Beitrag nicht ins Detail gehen, aber wenn Sie ein Einzeilerskript erstellen können, das diese Schritte ausführen kann, sind Sie gut. Service fails: run script.

Schritt 2) Datenbank mit Auto-Backup und Auto-Recover

Wenn Sie sicherstellen können, dass Sie sehr aktuelle Backups Ihrer Datenbank haben und diese an einem leicht zugänglichen Ort wie S3 gespeichert sind, dann können Sie eine App erstellen, die sich selbst wiederherstellen kann, wenn sie gestartet wird. Die Verwendung einer eingebetteten Datenbank macht alles einfacher, da Sie nur eine einzige Sache bereitstellen müssen: Ihre App.

Ich habe in letzter Zeit viel mit BoltDB gearbeitet, vor allem weil ich viel mit Go schreibe und Bolt eine einfache eingebettete Datenbank ist, die in einem Go-Paket verfügbar ist, das Sie wie jede andere Abhängigkeit verwenden. Man muss also keine separate Datenbank betreiben, mit der man sich verbindet, und sich darum kümmern, dass sie läuft. Sie verwenden einfach die Bibliothek, und die Daten werden auf Ihre lokale Festplatte geschrieben.

Das ist auch das Problem mit Bolt: Die Daten befinden sich nur auf Ihrem lokalen Rechner zusammen mit Ihrer Anwendung. Wenn der Rechner ausfällt, verliert man alle Daten.

Wie wäre es, wenn man jede Minute oder 2 ein Backup macht?

Ich habe eine Lib erstellt, die genau das tut, Bolt Backup genannt, und durch Ändern der BoltDb-Initialisierungszeile wird die Datenbank automatisch in S3 gesichert, und was noch besser ist, wenn Sie die App starten, wird sie von der letzten Sicherung wiederhergestellt.

Sie können dies einfach testen, indem Sie Daten zu Ihrer Bolt-Datenbank hinzufügen, Ihre App beenden, die Bolt-Datendatei löschen und dann Ihre App neu starten. Es wird dort weitergehen, wo es aufgehört hat, egal, wo Sie Ihre App erneut starten.

Hier ist eine Beispiel-App, die dies verwendet und die Sie ausprobieren können: https://github.com/treeder/bolt-backup/tree/master/example

Schlussfolgerung

Mit den obigen einfachen Konzepten können Sie Ihre App in weniger als 26 Minuten wiederherstellen und so eine Betriebszeit von 4 9 oder mehr erreichen. Achten Sie nur darauf, dass alles mit einem Startskript und einer automatischen Datenbankwiederherstellung wie der oben erwähnten Bolt-Backup-Bibliothek automatisiert wird.

Der Wert der Einfachheit kann manchmal verloren gehen, wenn wir uns über die „Web-Skala“ aufregen, aber oft kann man sich viel Zeit und Ärger ersparen, wenn man die Dinge einfach hält. Und eine Menge Geld.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.