Lad os starte med at fortælle, hvad 4 9’s præcist betyder:
Fire nier er 4,38 minutters nedetid pr. måned eller 52,56 minutter pr. år.
Det er sandsynligvis mere end acceptabelt for næsten alle tjenester på internettet, ikke alle, men næsten alle. Så hvis din e-mail er nede i 4 minutter hver måned, er det ikke verdens undergang. Jeg mener, du ville sandsynligvis ikke engang bemærke det. Når du går hen for at tjekke Twitter for at se, om det kun er dig eller ej, ville den være oppe igen.
Typisk for at få en god oppetid tænker vi på at tilføje redundans og replikering, så hvis en server går ned, har du allerede andre kørende, som straks tager over. Problemet med denne fremgangsmåde er, at det er kompliceret og dyrt. Du har brug for flere servere, normalt 3 eller flere for både din app og din database, plus du skal bruge en load balancer foran. Og så skal du administrere/overvåge alle disse maskiner.
Og med den nye Microservices-trend, hvor folk splitter deres apps op i mindre services, skal du gentage disse komplicerede opsætninger for hver service.
Hvis du bygger en Microservice, er det bedre, jo mindre “ting” du skal bruge for at køre den. Du ønsker ikke at skulle opsætte en ny replikeret database, hver gang du vil smide et lille API sammen, vel? Jeg vil være superproduktiv, jeg vil være i stand til at lave en service hurtigt uden at skulle beskæftige mig med alle de komplicerede, tidsspilde ops ting.
Så jeg kom til at tænke, “hvad nu, hvis der er en måde at være… pålidelig nok?” Jeg mener, hvor mange af de ting, du bygger, har faktisk brug for at være meget tilgængelige? Hvor mange tjenester har ikke råd til at være nede i et par minutter her og der eller miste en lille smule data en gang i mellem på grund af en fatal serverfejl?
Mit gæt er, at der ikke er mange tjenester, der ikke har råd til at miste en meget lille mængde data og have et par minutters nedetid om året. Selv hvis du arkitekterer helvede ud af din tjeneste, vil du sandsynligvis stadig have nedetid alligevel af en eller anden grund. Så hvorfor ikke bare holde det simpelt.
Først nogle tal: Lad os sige, at en AWS EC2-instans i gennemsnit fejler hver sjette måned. Jeg tror, at det er meget mindre end det i dag, men ingen ved det rigtig, så vi er konservative. Det giver os ca. 26,5 minutter til at genoprette appen hvert halve år, mens vi stadig har 4 9’s oppetid.
Her er hvordan du kan få 4 9’s på en enkelt maskine.
Skridt 1) Start server, implementer app og skift DNS-script
Den første ting vi har brug for er et simpelt script, der kan starte en ny instans, starte appen (Docker gør det nemt) og ændre DNS til at pege på den nye instans. Jeg vil ikke gå i detaljer med dette trin i dette indlæg, men hvis du kan lave et one liner script, der kan udføre disse trin, er du god. Service fails: run script.
Stræk 2) Database med automatisk backup og automatisk genopretning
Hvis du kan sikre, at du har meget nylige backups af din database, og at disse er gemt på et let tilgængeligt sted som S3, kan du lave en app, der kan genoprette sig selv, når den starter op. Brug af en indlejret database gør alting enklere, da du kun behøver at distribuere en enkelt ting: din app.
Jeg har brugt BoltDB meget på det seneste, mest fordi jeg skriver meget i Go, og Bolt er en simpel indlejret database, der er tilgængelig i en Go-pakke, som du bruger som enhver anden afhængighed. Så du behøver ikke at køre en separat database, som du opretter forbindelse til og skal beskæftige dig med at holde den kørende. Du bruger bare biblioteket, og dataene skrives til din lokale disk.
Nu er det også problemet med Bolt, at dataene kun er på din lokale maskine sammen med din app. Hvis maskinen fejler, mister du alle dine data.
Men hvad med at lave en backup hvert minut eller 2? Og være i stand til automatisk at gendanne fra denne backup, når appen starter op?
Jeg har oprettet en lib, der gør netop dette, kaldet Bolt Backup, og blot ved at ændre BoltDb initialiseringslinjen, vil den automatisk tage backup af din database til S3, og endnu bedre, når du starter appen, vil den gendanne fra den seneste backup.
Du kan nemt teste dette ved at tilføje data til din Bolt-database, dræbe din app, slette Bolt-datafilen og derefter genstarte din app. Den vil fortsætte, hvor den slap, uanset hvor du starter din app igen.
Her er en eksempelapp, der bruger dette, som du kan prøve: https://github.com/treeder/bolt-backup/tree/master/example
Slutning
Med de enkle koncepter ovenfor kan du gendanne din app på mindre end 26 minutter og dermed opnå 4 9’ere eller bedre oppetid. Bare sørg for, at det hele er automatiseret med et launch script og automatisk database recovery som det ovenfor nævnte Bolt Backup bibliotek.
Værdien af enkelhed kan nogle gange gå tabt, når vi bliver helt begejstrede for “web scale”, men ofte kan du spare dig selv for en masse tid og sorg, hvis du holder tingene enkle. Og en masse penge.