Să începem cu ceea ce înseamnă exact 4 9’s:

Cele 4 9’s înseamnă 4,38 minute de timp de nefuncționare pe lună, sau 52,56 minute pe an.

Ceasta este probabil mai mult decât acceptabil pentru aproape toate serviciile de pe internet, nu toate, dar aproape toate. Deci e-mailul tău este indisponibil timp de 4 minute în fiecare lună, nu este sfârșitul lumii. Adică, probabil că nici nu ați observa. În momentul în care v-ați fi dus să verificați Twitter pentru a vedea dacă sunteți doar dvs. sau nu, ar fi fost din nou în funcțiune.

În mod normal, pentru a obține un timp de funcționare bun, ne gândim să adăugăm redundanță și replicare, astfel încât, dacă un server cedează, aveți altele care rulează deja și care preiau imediat. Problema cu această abordare este că este complicată și costisitoare. Aveți nevoie de mai multe servere, de obicei 3 sau mai multe, atât pentru aplicație, cât și pentru baza de date, plus că veți avea nevoie de un load balancer în fața acestora. Și apoi trebuie să gestionați/monitorizați toate aceste mașini.

Și cu noua tendință Microservicii, în care oamenii își despart aplicațiile în servicii mai mici, trebuie să repetați aceste configurații complicate pentru fiecare serviciu.

Dacă construiți un Microserviciu, cu cât mai puține „chestii” sunt necesare pentru a-l rula, cu atât mai bine. Nu vreți să trebuiască să mergeți să configurați o nouă bază de date replicată de fiecare dată când vreți să puneți la cale un mic API, nu-i așa? Vreau să fiu super productiv, vreau să pot realiza un serviciu rapid, fără a fi nevoit să mă ocup de toate chestiile complicate și care fac să pierd timp cu operațiile.

Așa că m-am gândit: „Ei bine, dacă există o modalitate de a fi… suficient de fiabil?” Adică, câte dintre lucrurile pe care le construiești trebuie să fie de fapt foarte disponibile? Câte servicii nu-și pot permite să nu funcționeze câteva minute pe ici pe colo sau să piardă o cantitate mică de date din când în când din cauza unei defecțiuni fatale a serverului?

Pensia mea este că nu sunt multe servicii care nu-și pot permite să piardă o cantitate foarte mică de date și să aibă câteva minute de indisponibilitate pe an. Chiar dacă îți arhitectezi al naibii de bine serviciul, probabil că vei avea oricum timpii morți din anumite motive. Așa că de ce să nu o facem simplu.

În primul rând, câteva cifre: să spunem că, în medie, o instanță AWS EC2 se defectează la fiecare șase luni. Cred că este mult mai puțin decât atât în zilele noastre, dar nimeni nu știe cu adevărat, așa că vom fi conservatori. Asta ne oferă aproximativ 26,5 minute pentru a recupera aplicația la fiecare șase luni, având în același timp un timp de funcționare de 4 9.

Iată cum puteți obține 4 9 pe o singură mașină.

Pasul 1) Lansați serverul, implementați aplicația și schimbați scriptul DNS

Primul lucru de care avem nevoie este un script simplu care poate lansa o nouă instanță, poate porni aplicația (Docker face acest lucru ușor) și poate schimba DNS pentru a indica noua instanță. Nu voi intra în detalii despre acest pas în această postare, dar dacă puteți face un script one liner care poate face acești pași, sunteți buni. Service fails: run script.

Pasul 2) Baza de date cu backup automat și recuperare automată

Dacă vă puteți asigura că aveți copii de rezervă foarte recente ale bazei de date și că acestea sunt stocate într-o locație ușor accesibilă, cum ar fi S3, atunci puteți crea o aplicație care se poate recupera singură atunci când pornește. Utilizarea unei baze de date încorporate face totul mai simplu, deoarece trebuie să implementați un singur lucru: aplicația dumneavoastră.

Am folosit BoltDB foarte mult în ultima vreme, mai ales pentru că scriu mult în Go și Bolt este o bază de date încorporată simplă, disponibilă într-un pachet Go pe care îl utilizați ca orice altă dependență. Astfel, nu trebuie să rulați o bază de date separată la care să vă conectați și să vă ocupați de menținerea ei în funcțiune. Pur și simplu folosiți biblioteca și datele sunt scrise pe discul local.

Acum, aceasta este și problema cu Bolt, datele se află doar pe mașina locală alături de aplicația dvs. Dacă mașina cedează, îți pierzi toate datele.

Bine, ce-ar fi să faci o copie de rezervă la fiecare minut sau 2? Și să puteți recupera automat din acea copie de rezervă atunci când aplicația pornește?

Am creat o bibliotecă care face exact acest lucru, numită Bolt Backup și doar prin modificarea liniei de inițializare BoltDb, aceasta va face automat o copie de rezervă a bazei de date pe S3 și, mai bine, atunci când porniți aplicația, aceasta va recupera din cea mai recentă copie de rezervă.

Puteți testa cu ușurință acest lucru adăugând date în baza de date Bolt, oprind aplicația, ștergând fișierul de date Bolt, apoi repornind aplicația. Aceasta va continua de unde a rămas, indiferent de locul în care vă porniți din nou aplicația.

Iată o aplicație de exemplu care folosește acest lucru și pe care o puteți încerca: https://github.com/treeder/bolt-backup/tree/master/example

Concluzie

Cu ajutorul conceptelor simple de mai sus, vă puteți recupera aplicația în mai puțin de 26 de minute și, prin urmare, puteți obține un timp de funcționare de 4 9 sau mai bun. Doar asigurați-vă că totul este automatizat cu un script de lansare și o recuperare automată a bazei de date, cum ar fi biblioteca Bolt Backup menționată mai sus.

Valoarea simplității poate fi uneori pierdută atunci când ne entuziasmăm cu privire la „scara web”, dar, de multe ori, vă puteți economisi mult timp și suferință dacă păstrați lucrurile simple. Și o mulțime de bani.