Failover: perfecționismul și... lenea ne distrug

Vara, atât activitatea de cumpărare, cât și intensitatea schimbărilor în infrastructura proiectelor web scad în mod tradițional, ne spune căpitanul Obvious. Pur și simplu pentru că chiar și specialiștii IT pleacă uneori în vacanță. Și CTO de asemenea. Este cu atât mai dificil pentru cei care rămân în funcție, dar nu acesta este ideea acum: poate de aceea vara este cea mai bună perioadă pentru a te gândi încet la schema de rezervare existentă și a întocmi un plan pentru a o îmbunătăți. Și experiența lui Yegor Andreev din AdminDivision, despre care a vorbit la conferință Zi de uptime.

Există mai multe capcane în care puteți cădea atunci când construiți site-uri de rezervă. Și este absolut imposibil să fii prins în ele. Și ceea ce ne strică în toate acestea, ca și în multe alte lucruri, este perfecționismul și... lenea. Încercăm să facem totul, totul, totul perfect, dar nu trebuie să o facem perfect! Trebuie doar să faci anumite lucruri, dar să le faci corect, să le completezi astfel încât să funcționeze corect.

Failover-ul nu este un fel de distracție; acesta este un lucru care ar trebui să facă exact un lucru - reduce timpul de nefuncționare, astfel încât serviciul, compania, să piardă mai puțini bani. Și în toate modalitățile de rezervare, vă sugerez să vă gândiți în următorul context: unde sunt banii?

Failover: perfecționismul și... lenea ne distrug

Prima capcană: atunci când construim sisteme mari, fiabile și ne angajăm în redundanță, reducem numărul de accidente. Aceasta este o concepție greșită teribilă. Când ne angajăm în redundanță, este probabil să creștem numărul de accidente. Și dacă facem totul corect, atunci împreună vom reduce timpul de nefuncționare. Vor fi mai multe accidente, dar vor avea loc la costuri mai mici. Ce este o rezervare? - aceasta este o complicație a sistemului. Orice complicație este rea: avem mai multe roți dințate, mai multe roți dințate, într-un cuvânt, mai multe elemente - și, prin urmare, o șansă mai mare de avarie. Și chiar se vor rupe. Și se vor rupe mai des. Un exemplu simplu: să presupunem că avem un site web cu PHP și MySQL. Și trebuie rezervat urgent.

Shtosh (c) Luăm al doilea site, construim un sistem identic... Complexitatea devine de două ori mai mare - avem două entități. De asemenea, lansăm o anumită logică pentru transferul datelor de la un site la altul - adică replicarea datelor, copierea datelor statice și așa mai departe. Deci, logica de replicare este de obicei foarte complexă și, prin urmare, complexitatea totală a sistemului poate fi nu de 2, ci de 3, 5, 10 ori mai mare.

A doua capcană: când construim sisteme complexe cu adevărat mari, fantezim despre ceea ce vrem să obținem în final. Voila: vrem să obținem un sistem super-fiabil, care să funcționeze fără niciun timp de nefuncționare, să comute într-o jumătate de secundă (sau mai bine zis, instantaneu) și începem să transformăm visele în realitate. Dar există și o nuanță aici: cu cât timpul de comutare dorit este mai scurt, cu atât logica sistemului devine mai complexă. Cu cât trebuie să facem această logică mai complex, cu atât sistemul se va defecta mai des. Și poți ajunge într-o situație foarte neplăcută: încercăm din toate puterile să reducem timpul de nefuncționare, dar de fapt facem totul mai complicat, iar când ceva nu merge bine, timpul de nefuncționare va ajunge să fie mai lung. Aici te surprinzi adesea cu gândul: ei bine... ar fi bine să nu faci rezervare. Ar fi mai bine dacă ar funcționa singur și cu timpi de nefuncționare ușor de înțeles.

Cum poți lupta cu asta? Trebuie să încetăm să ne mințim pe noi înșine, să încetăm să ne linguim că vom construi acum o navă spațială aici, dar să înțelegem în mod adecvat cât de mult poate dura proiectul. Și pentru acest timp maxim, vom alege ce metode vom folosi efectiv pentru a crește fiabilitatea sistemului nostru.

Failover: perfecționismul și... lenea ne distrug

E timpul pentru „povești din w”... din viață, desigur.

Exemplul numărul unu

Imaginați-vă un site web pentru cărți de vizită pentru Uzina de laminare a țevilor nr. 1 din orașul N. Scrie cu litere mari - Uzina de laminare a țevilor nr. 1. Chiar dedesubt este sloganul: „Țevile noastre sunt cele mai rotunde țevi din N”. Și mai jos este numărul de telefon al CEO-ului și numele lui. Înțelegem că trebuie să faceți o rezervare - acesta este un lucru foarte important! Să începem să ne dăm seama în ce constă. Html-statics - adică câteva imagini în care directorul general, de fapt, discută despre un fel de următoarea afacere la masa din baie cu partenerul său. Începem să ne gândim la timpul de nefuncționare. Îmi vine în minte: trebuie să stai acolo cinci minute, nu mai mult. Și atunci apare întrebarea: câte vânzări au fost de pe acest site al nostru în general? Cât-cât? Ce înseamnă „zero”? Și asta înseamnă: pentru că generalul a făcut toate cele patru tranzacții anul trecut la aceeași masă, cu aceleași oameni cu care merg la baie și stau la masă. Și înțelegem că, chiar dacă site-ul rămâne o zi, nu se va întâmpla nimic groaznic.

Pe baza informațiilor introductive, există o zi pentru a ridica această poveste. Să începem să ne gândim la o schemă de redundanță. Și alegem cea mai ideală schemă de redundanță pentru acest exemplu: nu folosim redundanța. Toată chestia asta poate fi ridicată de orice administrator într-o jumătate de oră cu pauze de fum. Instalați un server web, adăugați fișiere - asta este. O sa mearga. Nu trebuie să fii cu ochii pe nimic, nu trebuie să acorzi o atenție deosebită la nimic. Adică, concluzia din exemplul numărul unu este destul de evidentă: serviciile care nu trebuie rezervate nu trebuie rezervate.

Failover: perfecționismul și... lenea ne distrug

Exemplul numărul doi

Blogul companiei: oameni special instruiți scriu știri acolo, am participat la așa și așa expoziție, dar am lansat un alt produs nou și așa mai departe. Să presupunem că acesta este PHP standard cu WordPress, o bază de date mică și puțin static. Desigur, îmi vine din nou în minte că nu ar trebui să te întinzi în niciun caz - „nu mai mult de cinci minute!” Asta este tot. Dar să ne gândim mai departe. Ce face acest blog? Oamenii vin acolo de la Yandex, de la Google pe baza unor interogări, organic. Grozav. Vânzările au vreo legătură cu asta? Bobotează: nu chiar. Traficul publicitar merge către site-ul principal, care se află pe o altă mașină. Să începem să ne gândim la o schemă de rezervare. Într-un sens bun, trebuie crescut în câteva ore și ar fi bine să ne pregătim pentru asta. Ar fi rezonabil să luați o mașină dintr-un alt centru de date, să rulați mediul pe ea, adică un server web, PHP, WordPress, MySQL, și să o lăsați acolo. În momentul în care înțelegem că totul este stricat, trebuie să facem două lucruri - să lansăm depozitul mysql la 50 de metri, acesta va zbura acolo într-un minut și să lansăm un anumit număr de imagini din backup acolo. Nici asta nu este acolo pentru Dumnezeu știe cât timp. Astfel, într-o jumătate de oră se ridică toată treaba. Fără replicare, sau Dumnezeu să mă ierte, failover automat. Concluzie: ceea ce putem lansa rapid dintr-o copie de rezervă nu trebuie să fie copiat de rezervă.

Failover: perfecționismul și... lenea ne distrug

Exemplul numărul trei, mai complicat

Magazin online. PhP cu inima deschisă este puțin modificat, mysql cu o bază solidă. Destul de mult static (la urma urmei, magazinul online are imagini frumoase HD și toate chestiile astea), Redis pentru sesiune și Elasticsearch pentru căutare. Începem să ne gândim la timpul de nefuncționare. Și aici, desigur, este evident că un magazin online nu poate sta întins fără durere o zi. La urma urmei, cu cât zace mai mult, cu atât pierdem mai mulți bani. Merită să grăbiți. Cât costă? Cred că dacă ne întindem o oră, nimeni nu va înnebuni. Da, vom pierde ceva, dar dacă începem să muncim din greu, se va înrăutăți. Definim o schemă de timp de nefuncționare permis pe oră.

Cum pot fi rezervate toate acestea? Ai nevoie de o mașină în orice caz: o oră de timp este destul de puțin. Mysql: aici avem deja nevoie de replicare, replicare live, pentru că într-o oră cel mai probabil 100 GB nu vor fi adăugați în dump. Statica, poze: din nou, intr-o ora 500 GB s-ar putea sa nu aiba timp sa fie adaugati. Prin urmare, este mai bine să copiați imaginile imediat. Redis: aici lucrurile devin interesante. În Redis, sesiunile sunt stocate - nu putem pur și simplu să-l luăm și să îl îngropăm. Pentru că acest lucru nu va fi foarte bine: toți utilizatorii vor fi deconectați, coșurile lor vor fi golite și așa mai departe. Oamenii vor fi forțați să-și introducă din nou numele de utilizator și parola, iar mulți oameni s-ar putea să se desprindă și să nu finalizeze achiziția. Din nou, conversiile vor scădea. Pe de altă parte, Redis este direct actualizat, probabil că nici ultimii utilizatori conectați nu sunt necesari. Și un compromis bun este să luați Redis și să-l restaurați dintr-o copie de rezervă de ieri sau, dacă o faceți în fiecare oră, de acum o oră. Din fericire, restaurarea acestuia dintr-o copie de rezervă înseamnă copierea unui fișier. Și cea mai interesantă poveste este Elasticsearch. Cine a preluat vreodată replicarea MySQL? Cine a preluat vreodată replicarea Elasticsearch? Și pentru cine a funcționat în mod normal după? Ce vreau să spun este că vedem o anumită entitate în sistemul nostru. Pare a fi util - dar este complex.
Complex în sensul că colegii noștri ingineri nu au experiență de lucru cu el. Sau există o experiență negativă. Sau înțelegem că aceasta este încă o tehnologie destul de nouă, cu nuanțe sau cruzime. Ne gândim... La naiba, elasticul este și sănătos, durează și mult să-l refac dintr-un backup, ce să fac? Înțelegem că elasticul în cazul nostru este folosit pentru căutare. Cum vinde magazinul nostru online? Mergem la marketeri și întrebăm de unde vin oamenii. Ei răspund: „90% de la Yandex Market vin direct pe cardul produsului”. Și fie îl cumpără, fie nu. Prin urmare, căutarea este necesară pentru 10% dintre utilizatori. Și păstrarea replicării elastice, în special între diferite centre de date din zone diferite, are într-adevăr o mulțime de nuanțe. Care iesire? Luăm elastic dintr-un site rezervat și nu facem nimic cu el. Dacă chestiunea va dura, probabil că o vom ridica într-o zi, dar acest lucru nu este sigur. De fapt, concluzia este aceeași, plus sau minus: noi, din nou, nu rezervăm servicii care nu afectează banii. Pentru a menține schema mai simplă.

Failover: perfecționismul și... lenea ne distrug

Exemplul numărul patru, chiar mai dificil

Integrator: vânzarea de flori, apelarea unui taxi, vânzarea mărfurilor, în general, orice. Un lucru serios care funcționează 24/7 pentru un număr mare de utilizatori. Cu o stivă interesantă cu drepturi depline, unde există baze interesante, soluții, încărcătură mare și, cel mai important, doare să stai culcat mai mult de 5 minute. Nu numai și nu atât pentru că oamenii nu vor cumpăra, ci pentru că oamenii vor vedea că acest lucru nu funcționează, se vor supăra și s-ar putea să nu se mai întoarcă deloc.

BINE. Cinci minute. Ce vom face în privința asta? În acest caz, noi, ca și adulții, folosim toți banii pentru a construi un adevărat site de rezervă, cu replicarea tuturor, și poate chiar automatizăm trecerea la acest site cât mai mult posibil. Și în plus, trebuie să vă amintiți să faceți un lucru important: de fapt, scrieți regulamentul de comutare. Reglementările, chiar dacă ai totul automatizat, pot fi foarte simple. Din seria „execuți un script ansible”, „faceți clic pe așa sau pe o casetă de selectare pe ruta 53” și așa mai departe - dar aceasta trebuie să fie un fel de listă exactă de acțiuni.

Și totul pare clar. Schimbarea replicării este o sarcină trivială, sau se va schimba singură. Rescrierea unui nume de domeniu în DNS este din aceeași serie. Problema este că atunci când un astfel de proiect eșuează, începe panica și chiar și cei mai puternici administratori cu barbă pot fi susceptibili la el. Fără instrucțiuni clare „deschide terminalul, vino aici, adresa serverului nostru este încă așa”, este dificil să respecti timpul limită de 5 minute alocat pentru resuscitare. Ei bine, în plus, atunci când folosim aceste reglementări, este ușor să înregistrăm unele modificări în infrastructură, de exemplu, și să schimbăm regulamentele în consecință.
Ei bine, dacă sistemul de rezervare este foarte complex și la un moment dat am făcut o greșeală, atunci ne putem distruge site-ul de rezervă și, în plus, putem transforma datele într-un dovleac pe ambele site-uri - acest lucru va fi complet trist.

Failover: perfecționismul și... lenea ne distrug

Exemplul numărul cinci, hardcore complet

Un serviciu internațional cu sute de milioane de utilizatori din întreaga lume. Toate fusurile orare există, încărcare mare la viteză maximă, nu te poți întinde deloc. Un minut - și va fi trist. Ce să fac? Rezervați, din nou, conform programului complet. Am făcut tot ce am vorbit în exemplul anterior și puțin mai mult. O lume ideală, iar infrastructura noastră este conformă tuturor conceptelor devopilor IaaC. Adică, totul este în git și doar apăsați butonul.

Ce lipsește? Unu - exerciții. Este imposibil fără ei. Se pare că totul este perfect la noi, în general avem totul sub control. Apăsăm butonul, totul se întâmplă. Chiar dacă așa este - și înțelegem că nu se întâmplă așa - sistemul nostru interacționează cu alte sisteme. De exemplu, acesta este dns de la ruta 53, stocare s3, integrare cu unele api. Nu vom putea prevedea totul în acest experiment speculativ. Și până când nu tragem efectiv comutatorul, nu vom ști dacă va funcționa sau nu.

Failover: perfecționismul și... lenea ne distrug

Probabil asta e tot. Nu fi leneș și nu exagera. Și să fie timpul de funcționare cu tine!

Sursa: www.habr.com

Adauga un comentariu