Låt oss börja med vad 4 9:s betyder exakt:
Fyra nior är 4,38 minuters driftsstopp per månad, eller 52,56 minuter per år.
Det är troligen mer än godtagbart för nästan alla tjänster på Internet, inte alla, men nästan alla. Så om din e-post är nere i 4 minuter varje månad är det inte världens undergång. Jag menar, du skulle förmodligen inte ens märka det. När du sedan kollar Twitter för att se om det bara är du eller inte så är den uppe igen.
Typiskt för att få en bra drifttid tänker vi på att lägga till redundans och replikering så att om en server går sönder så har du redan andra igång som genast tar över. Problemet med detta tillvägagångssätt är att det är komplicerat och dyrt. Du behöver flera servrar, vanligtvis tre eller fler för både din app och din databas, plus att du behöver en lastutjämnare framför den. Och sedan måste du hantera/övervaka alla dessa maskiner.
Och med den nya Microservices-trenden där folk delar upp sina appar i mindre tjänster måste du upprepa dessa komplicerade inställningar för varje tjänst.
Om du bygger en Microservice, ju mindre ”saker” du behöver för att köra den, desto bättre. Du vill inte behöva konfigurera en ny replikerad databas varje gång du vill sätta ihop ett litet API, eller hur? Jag vill vara superproduktiv, jag vill kunna skapa en tjänst snabbt utan att behöva ta itu med alla komplicerade, tidskrävande operatörsgrejer.
Så jag började tänka: ”Tänk om det finns ett sätt att vara… tillräckligt tillförlitlig?”. Jag menar, hur många av de saker du bygger behöver egentligen vara mycket tillgängliga? Hur många tjänster har inte råd att vara nere i några minuter här och där eller förlora en liten bit data en gång i månaden på grund av ett allvarligt serverfel?
Min gissning är att det inte finns så många tjänster som inte har råd att förlora en mycket liten mängd data och ha några minuters driftsstopp per år. Även om du arkitekterar din tjänst till hundra procent kommer du förmodligen ändå att ha nedtid ändå av någon anledning. Så varför inte hålla det enkelt.
Först några siffror: Låt oss säga att en AWS EC2-instans i genomsnitt går sönder var sjätte månad. Jag tror att det är mycket mindre än så nuförtiden, men ingen vet riktigt så vi är konservativa. Det ger oss ungefär 26,5 minuter för att återställa appen var sjätte månad samtidigt som vi fortfarande har 4 9:or i drifttid.
Här är hur du kan få 4 9:or på en enda maskin.
Steg 1) Starta server, distribuera appen och ändra DNS-skriptet
Det första vi behöver är ett enkelt skript som kan starta en ny instans, starta appen (Docker gör det här enkelt) och ändra DNS så att den pekar på den nya instansen. Jag kommer inte att gå in i detalj på detta steg i det här inlägget, men om du kan göra ett one liner-skript som kan göra dessa steg är du bra. Service fails: run script.
Steg 2) Databas med automatisk säkerhetskopiering och automatisk återställning
Om du kan se till att du har mycket färska säkerhetskopior av din databas och att dessa sparas på en lättillgänglig plats som S3 kan du skapa en app som kan återställa sig själv när den startar. Att använda en inbäddad databas gör allting enklare eftersom du bara behöver distribuera en enda sak: din app.
Jag har använt BoltDB en hel del på sistone, mest för att jag skriver mycket Go och Bolt är en enkel inbäddad databas som finns i ett Go-paket som du använder som alla andra beroenden. Du behöver alltså inte köra en separat databas som du ansluter till och måste ta hand om att hålla den igång. Du använder bara biblioteket och data skrivs till din lokala disk.
Det är också problemet med Bolt, data finns bara på din lokala maskin tillsammans med din app. Om maskinen går sönder förlorar du alla dina data.
Vad sägs om att göra en säkerhetskopiering varannan eller varannan minut? Och kunna automatiskt återställa från den backupen när appen startar?
Jag har skapat en lib som gör just detta, kallad Bolt Backup och bara genom att ändra BoltDb-initialiseringsraden kommer den automatiskt att säkerhetskopiera din databas till S3 och ännu bättre, när du startar appen kommer den att återställa från den senaste backupen.
Du kan enkelt testa det här genom att lägga till data till din Bolt-databas, avsluta appen, ta bort Bolt-datafilen och sedan starta om din app. Den kommer att fortsätta där den slutade, oavsett var du startar din app igen.
Här är en exempelapp som använder detta och som du kan prova: https://github.com/treeder/bolt-backup/tree/master/example
Slutsats
Med de enkla koncepten ovan kan du återställa din app på mindre än 26 minuter och därmed uppnå 4 9:or eller bättre i drifttid. Se bara till att allt är automatiserat med ett lanseringsskript och automatisk databasåterställning som biblioteket Bolt Backup som nämns ovan.
Värdet av enkelhet kan ibland gå förlorat när vi blir helt upphetsade över ”webbskala”, men ofta kan du spara dig själv mycket tid och sorg om du håller saker och ting enkla. Och mycket pengar.