Laten we beginnen met wat 4 9’s precies betekent:

Vier negens is 4,38 minuten downtime per maand, of 52,56 minuten per jaar.

Dat is waarschijnlijk meer dan acceptabel voor bijna alle diensten op het internet, niet alle, maar wel bijna alle. Dus als je e-mail er elke maand 4 minuten uit ligt, is dat niet het einde van de wereld. Ik bedoel, je zou het waarschijnlijk niet eens merken. Tegen de tijd dat je Twitter gaat checken om te zien of het aan jou ligt of niet, zou het weer in de lucht zijn.

Typisch om een goede uptime te krijgen, denken we aan het toevoegen van redundantie en replicatie, zodat als een server faalt, je al anderen hebt draaien die het onmiddellijk overnemen. Het probleem met deze aanpak is dat het ingewikkeld en duur is. Je hebt meerdere servers nodig, meestal 3 of meer voor zowel je app als je database, plus je hebt er een load balancer voor nodig. En dan moet je al die machines beheren/monitoren.

En met de nieuwe Microservices-trend, waarbij mensen hun apps opsplitsen in kleinere services, moet je deze ingewikkelde setups voor elke service herhalen.

Als je een Microservice bouwt, hoe minder “spullen” je nodig hebt om het te laten draaien, hoe beter. Je wilt toch niet elke keer een nieuwe gerepliceerde database opzetten als je een kleine API in elkaar wilt flansen? Ik wil super productief zijn, ik wil snel een dienst kunnen draaien zonder me bezig te hoeven houden met al die ingewikkelde, tijdverspillende ops dingen.

Dus begon ik te denken, “nou, wat als er een manier is om… betrouwbaar genoeg te zijn?” Ik bedoel, hoeveel van de dingen die je bouwt moeten werkelijk zeer beschikbaar zijn? Hoeveel diensten kunnen het zich niet veroorloven om hier en daar een paar minuten down te zijn of eens in de blauwe maan een klein beetje data te verliezen door een fatale serverstoring?

Mijn gok is dat er niet veel diensten zijn die het zich niet kunnen veroorloven om een zeer kleine hoeveelheid data te verliezen en een paar minuten downtime per jaar te hebben. Zelfs als je je dienst zo goed mogelijk architect, zul je waarschijnlijk toch downtime hebben om wat voor reden dan ook. Dus waarom houden we het niet gewoon simpel.

Eerst wat getallen: laten we zeggen dat gemiddeld een AWS EC2 instance elke zes maanden uitvalt. Ik denk dat het tegenwoordig een stuk minder is, maar niemand weet het echt, dus we zullen conservatief zijn. Dat geeft ons ongeveer 26,5 minuten om de app elke zes maanden te herstellen, terwijl we nog steeds 4 9’s uptime hebben.

Hier is hoe je 4 9’s op een enkele machine kunt krijgen.

Stap 1) Start server, implementeer app en verander DNS Script

Het eerste wat we nodig hebben is een eenvoudig script dat een nieuwe instantie kan lanceren, de app kan starten (Docker maakt dit gemakkelijk) en DNS kan veranderen om naar de nieuwe instantie te wijzen. Ik ga niet in detail treden over deze stap in deze post, maar als je een one liner script kunt maken dat deze stappen kan doen, dan zit je goed. Service fails: run script.

Step 2) Database met Auto Backup en Auto Recover

Als je ervoor kunt zorgen dat je zeer recente back-ups van je database hebt en die zijn opgeslagen op een gemakkelijk toegankelijke locatie zoals S3, dan kun je een app maken die zichzelf kan herstellen als hij opstart. Het gebruik van een embedded database maakt alles eenvoudiger, omdat je maar één ding hoeft te implementeren: je app.

Ik gebruik BoltDB de laatste tijd veel, vooral omdat ik veel Go schrijf en Bolt een eenvoudige embedded database is die beschikbaar is in een Go-pakket dat je gebruikt als elke andere afhankelijkheid. Dus je hoeft geen aparte database te draaien waar je verbinding mee maakt en je hoeft je niet bezig te houden met het draaiende houden ervan. Je gebruikt gewoon de bibliotheek en de gegevens worden naar je lokale schijf geschreven.

Nou dat is ook het probleem met Bolt, de gegevens staan alleen op je lokale machine naast je app. Als de machine uitvalt, ben je al je gegevens kwijt.

Wat dacht je ervan om elke minuut of 2 een backup te maken? En automatisch herstellen van die back-up wanneer de app opstart?

Ik heb een lib gemaakt die precies dit doet, genaamd Bolt Backup en door alleen de BoltDb initialisatieregel te veranderen, maakt deze automatisch een back-up van je database naar S3 en nog beter, wanneer je de app start, herstelt deze zich van de meest recente back-up.

Je kunt dit eenvoudig testen door gegevens aan je Bolt-database toe te voegen, je app te stoppen, het Bolt-gegevensbestand te verwijderen en vervolgens je app opnieuw op te starten. De app gaat verder waar hij was gebleven, ongeacht waar je je app opnieuw opstart.

Hier is een voorbeeld-app die dit gebruikt en die je kunt proberen: https://github.com/treeder/bolt-backup/tree/master/example

Conclusie

Met de bovenstaande eenvoudige concepten kunt u uw app in minder dan 26 minuten herstellen en dus 4 9’s of beter aan uptime bereiken. Zorg er alleen voor dat het allemaal geautomatiseerd is met een lanceringsscript en automatisch databaseherstel zoals de Bolt Backup-bibliotheek die hierboven is genoemd.

De waarde van eenvoud kan soms verloren gaan wanneer we allemaal enthousiast raken over “webschaal”, maar vaak kun je jezelf een hoop tijd en verdriet besparen als je de dingen eenvoudig houdt. En een hoop geld.