Kezdjük azzal, hogy mit jelent pontosan a 4 9-es:

Négy kilences az 4,38 perc leállási idő havonta, vagy 52,56 perc évente.

Ez valószínűleg több mint elfogadható szinte minden internetes szolgáltatás esetében, nem minden, de majdnem minden. Tehát ha az e-mailje havonta 4 percet áll le, az nem a világ vége. Úgy értem, valószínűleg észre sem vennéd. Mire megnéznéd a Twittert, hogy megnézd, hogy csak te vagy-e vagy sem, már újra működne.

A jó üzemidő eléréséhez általában redundancia és replikáció hozzáadására gondolunk, így ha egy szerver meghibásodik, akkor már futnak mások, amelyek azonnal átveszik a helyét. A probléma ezzel a megközelítéssel az, hogy bonyolult és drága. Több szerverre van szükséged, általában 3 vagy több szerverre mind az alkalmazásodhoz, mind az adatbázisodhoz, plusz egy terheléskiegyenlítőre is szükséged lesz előtte. És aztán mindezeket a gépeket menedzselni/felügyelni kell.

Az új Microservices trenddel, ahol az emberek kisebb szolgáltatásokra bontják az alkalmazásaikat, ezeket a bonyolult beállításokat minden egyes szolgáltatáshoz meg kell ismételni.

Ha Microservice-t építesz, minél kevesebb “cuccra” van szükséged a futtatásához, annál jobb. Nem akarsz minden alkalommal új replikált adatbázist beállítani, amikor össze akarsz dobni egy kis API-t, ugye? Szuper produktív akarok lenni, gyorsan akarok egy szolgáltatást létrehozni anélkül, hogy bonyolult, időpazarló ops dolgokkal kellene foglalkoznom.

Ezért elgondolkodtam, “nos, mi van, ha van rá mód, hogy… elég megbízható legyen?”. Úgy értem, hány olyan dolog van, amit építesz, aminek tényleg nagymértékben elérhetőnek kell lennie? Hány szolgáltatás nem engedheti meg magának, hogy itt-ott néhány percre leálljon, vagy egyszer a kék holdban elveszítsen egy aprócska adatot egy végzetes szerverhiba miatt?

Azt gondolom, hogy nem sok olyan szolgáltatás van, amely nem engedheti meg magának, hogy elveszítsen egy nagyon kis adatmennyiséget és évente néhány perc leállást. Még ha architektúrát is építesz a szolgáltatásodból, akkor is valószínűleg valamilyen okból kifolyólag mindenképp lesz állásidő. Miért ne lehetne tehát egyszerűbbé tenni.

Először néhány szám: tegyük fel, hogy átlagosan félévente meghibásodik egy AWS EC2-példány. Szerintem manapság ennél jóval kevesebb, de ezt senki sem tudja pontosan, úgyhogy legyünk konzervatívak. Ez körülbelül 26,5 percet ad az alkalmazás helyreállítására félévente, miközben még mindig 4 9-es üzemidővel rendelkezünk.

Íme, hogyan érhetünk el 4 9-est egyetlen gépen.

1. lépés: Szerver indítása, alkalmazás telepítése és DNS-változtatás script

Az első dolog, amire szükségünk van, egy egyszerű script, amely képes elindítani egy új példányt, elindítani az alkalmazást (a Docker megkönnyíti ezt) és megváltoztatni a DNS-t, hogy az új példányra mutasson. Nem fogom részletezni ezt a lépést ebben a bejegyzésben, de ha tudsz készíteni egy egysoros szkriptet, ami képes ezeket a lépéseket elvégezni, akkor jó vagy. Service fails: run script.

2. lépés) Adatbázis automatikus biztonsági mentéssel és automatikus helyreállítással

Ha biztosítani tudod, hogy nagyon friss biztonsági mentések legyenek az adatbázisodról, és ezeket egy könnyen elérhető helyen, például az S3-on tárolod, akkor létrehozhatsz egy olyan alkalmazást, amely induláskor képes helyreállítani magát. A beágyazott adatbázis használata mindent leegyszerűsít, mivel csak egyetlen dolgot kell telepítened: az alkalmazásodat.

Az utóbbi időben sokat használom a BoltDB-t, főleg azért, mert sokat írok Go-t, és a Bolt egy egyszerű beágyazott adatbázis, ami egy Go csomagban érhető el, amit úgy használsz, mint bármely más függőséget. Így nem kell külön adatbázist futtatnod, amihez csatlakozol, és nem kell foglalkoznod a futtatásával. Csak használod a könyvtárat és az adatok a helyi lemezedre íródnak.

Most ez a probléma a Bolttal is, az adatok csak a helyi gépeden vannak az alkalmazásoddal együtt. Ha a gép meghibásodik, elveszíted az összes adatodat.

Hát mi lenne, ha percenként vagy 2 percenként csinálnál egy mentést? És képes lennél automatikusan helyreállítani a biztonsági másolatból, amikor az alkalmazás elindul?

Elkészítettem egy lib-et, ami pontosan ezt teszi, Bolt Backup néven, és csak a BoltDb inicializálási sor megváltoztatásával automatikusan biztonsági másolatot készít az adatbázisodról az S3-ra, és ami még jobb, amikor elindítod az alkalmazást, a legutóbbi biztonsági másolatból fog helyreállni.

Ezt könnyen tesztelheted, ha adatokat adsz a Bolt adatbázisodhoz, megölöd az alkalmazásod, törlöd a Bolt adatfájlt, majd újraindítod az alkalmazásod. A program ott folytatja, ahol abbahagyta, függetlenül attól, hogy hol indítod újra az alkalmazásodat.

Itt van egy ezt használó példaalkalmazás, amit kipróbálhatsz: https://github.com/treeder/bolt-backup/tree/master/example

Következtetés

A fenti egyszerű fogalmakkal kevesebb mint 26 perc alatt helyreállíthatja az alkalmazását, és így 4 9-es vagy jobb üzemidőt érhet el. Csak győződj meg róla, hogy az egészet automatizálod egy indítószkript és egy automatikus adatbázis-helyreállítás segítségével, mint a fent említett Bolt Backup könyvtár.

Az egyszerűség értéke néha elveszhet, amikor a “webes skála” miatt izgatottak leszünk, de gyakran sok időt és bánatot spórolhatsz meg magadnak, ha egyszerűen tartod a dolgokat. És sok pénzt is.