Istoria a făcut ca industria IT să se împartă, în mod tradițional, în două tabere condiționate: cei „pentru” și cei „împotrivă”. Subiectul disputelor poate fi absolut aleator. Ce sistem de operare este mai bun: Windows sau Linux? Să ai un smartphone cu Android sau iOS? Să stochezi totul în cloud sau să folosești unități RAID cold storage și să pui hard disk-urile într-un seif? Au dreptul dezvoltatorii PHP să fie numiți programatori? Aceste dispute sunt, uneori, de natură exclusiv existențială și nu au la bază nimic altceva în afară de un interes pur sportiv.
Așa s-a întâmplat că, odată cu apariția containerelor și a acestei dragi industrii cu Docker și, în mod simbolic, Kubernetes, au început și disputele „pentru” și „împotrivă” cu privire la utilizarea noilor oportunități în diferite domenii ale backend-ului. (De la început, să menționăm că, deși cel mai frecvent în această argumentație se va face referire la Kubernetes ca orchestrator, alegerea acestui instrument specific nu este crucială. În locul său, poți alege orice altă opțiune care ți se pare mai convenabilă și familiară.)
Și, se părea că ar fi fost o simplă dispută între două părți ale aceleași medalii. La fel de lipsită de sens și implacabilă ca eterna confruntare Windows vs Linux, în care oamenii raționali există, de fapt, undeva la mijloc. Totuși, în cazul containerizării, lucrurile nu sunt atât de simple. De obicei, în astfel de dispute nu există o parte corectă, dar în cazul „a folosi” sau „a nu folosi” containere pentru stocarea bazelor de date, totul se întoarce pe dos. Pentru că, în anumite sensuri, atât susținătorii cât și oponenții acestui tip de abordare au dreptate.
Latura Luminoasă
O scurtă descriere a argumentației Laturii Luminoase poate fi rezumată într-o frază: „Salut, 2k19 la ușă!” Sună ca un populism, fără îndoială, dar dacă ne aplecăm asupra situației în detaliu, există anumite avantaje. Acestea le vom analiza acum.
Presupunem că aveți un proiect web mare. Acesta ar fi putut fi inițial construit pe baza unei abordări de microservicii sau a ajuns la acest lucru printr-o evoluție treptată — nu este foarte important, de fapt. Ați distribuit proiectul pe microservicii separate, ați configurat orchestrarea, echilibrarea încărcăturii, scalarea. Și acum, cu o conștiință curată, savurați un mohito în hamac în timpul efectelor Habr în loc să ridicați serverele căzute. Dar trebuie să fiți consecvent în toate acțiunile. Foarte adesea, doar aplicația în sine — codul — este containerizată. Și ce mai avem în afară de cod?
Corect, datele. Inima oricărui proiect sunt datele sale: acestea pot fi o bază de date tipică — MySQL, Postgre, MongoDB, precum și stocări utilizate pentru căutare (ElasticSearch), stocări key-value pentru caching — de exemplu, redis, etc. Acum nu vom vorbi despre variantele greșite de implementare a backend-ului, când baza de date se prăbușește din cauza interogărilor prost scrise, ci vom discuta despre asigurarea redundanței acestei baze de date sub încărcătura clienților. Când containerizăm aplicația noastră și îi permitem să se scaleze liber pentru a gestiona orice număr de solicitări, acest lucru crește, în mod inevitabil, și încărcătura pe baza de date.
De fapt, canalul de acces la baza de date și serverul pe care aceasta rulează devin un gât de îndoire în backendul nostru frumos containerizat. În același timp, principalul motiv pentru virtualizarea prin containere este mobilitatea și flexibilitatea structurii, care permit organizarea distribuției încărcăturii de vârf în întreaga infrastructură disponibilă cât mai eficient posibil. Asta înseamnă că, dacă nu containerizăm și nu distribui toate elementele existente ale sistemului pe un cluster, facem o greșeală foarte serioasă.
Este mult mai logic să clusterizăm nu doar aplicația, ci și serviciile care se ocupă cu stocarea datelor. Prin clusterizarea și desfășurarea serverelor web, care operează independent și distribuie sarcinile între ele, în k8s, abordăm deja problema sincronizării datelor — de exemplu, comentariile la postări, dacă luăm ca exemplu o platformă media sau un blog. În orice caz, se creează o reprezentare a bazei de date, chiar și virtuală, ca ExternalService în cadrul cluster-ului. Problema este că baza de date însă nu este încă clusterizată — serverele web desfășurate în kubernete iau informații despre modificări din baza noastră statică de producție, care rulează separat.
Simțiți un truc? Folosim k8s sau Swarm pentru a distribui sarcina și a evita căderea principalului server web, dar nu facem asta pentru baza de date. Dar, dacă baza de date cade, nu are sens în întreaga noastră infrastructură clusterizată — ce folos avem de paginile web goale care returnează o eroare de acces la baza de date?
De aceea trebuie clusterizate nu doar serverele web, așa cum se face în mod obișnuit, ci și infrastructura bazei de date. Numai astfel putem asigura o structură care funcționează complet într-un singur sistem, dar care este, în același timp, independentă una de cealaltă. Chiar dacă jumătate din backend-ul nostru „când rupe” sub sarcină — cealaltă va supraviețui, iar sistemul de sincronizare între bazele de date din cadrul cluster-ului și capacitatea de scalare infinitiă și desfășurarea de noi clustere ne va ajuta să ajungem rapid la puterea necesară — să existe racks în centrul de date.
În plus, modelul distribuit în clustere al bazei de date permite să transportați chiar și această bază de date acolo unde este necesară; dacă vorbim despre un serviciu global, este destul de ilogic să rulăm un cluster web undeva în apropiere de San Francisco și să transferăm pachete cerând baza de date din Podmoscovia și înapoi.
De asemenea, containerizarea bazei de date permite construirea tuturor elementelor sistemului la același nivel de abstractizare. Ceea ce, la rândul său, face posibilă gestionarea acestui sistem direct din cod, de către dezvoltatori, fără a necesita implicarea activă a administratorilor. Dacă dezvoltatorii consideră că au nevoie de o anumită bază de date pentru un nou subproiect — este simplu! scriu un fișier yaml, îl încarcă în cluster și gata.
Și, desigur, exploatarea internă devine de zeci de ori mai ușoară. Spuneți-mi, câteodată ați închis ochii când un nou membru al echipei se băga în baza de date de producție? Pe care, de fapt, o aveți doar pe una, care se află chiar acum în utilizare? Desigur, cu toții suntem oameni maturi și avem, probabil, un backup recent, și mai departe — pe un raft cu murături ale bunicii și schiuri vechi — un alt backup, poate chiar într-un depozit rece, pentru că odată oficiul dumneavoastră a ars. Totuși, fiecare introducere a unui nou membru al echipei, care are acces la infrastructura de producție și, desigur, la baza de date de producție — este ca un cub de validol pentru toți cei din jur. Cine știe, poate acest novice este stângaci? Este înfricoșător, recunoașteți.
Containerizarea și, prin urmare, topologia fizică distribuită a bazei de date a proiectului dumneavoastră ajută la evitarea acestor momente de validol. Nu aveți încredere în novice? Bine! Îi vom ridica un cluster propriu pentru lucru și îi vom deconecta de la celelalte clustere de baze de date — sincronizarea numai printr-un push manual și rotația sincronă a două chei (una pentru liderul echipei, cealaltă pentru admin). Și toată lumea este fericită.
Acum a venit vremea să ne transformăm în dușmani ai clusterizării bazelor de date.
Latura întunecată
Reflectând la motivele pentru care nu ar trebui să containerizăm baza de date și să continuăm să o rulăm pe un singur server central server, să nu ne coborâm la retorica ortodocșilor și afirmațiile de genul „strămoșii au rulat bazele de date pe hardware și noi vom face la fel!” În loc de aceasta, haideți să încercăm să imaginăm o situație în care containerizarea ar aduce cu adevărat beneficii semnificative.
Să fim de acord, proiectele care au cu adevărat nevoie de o bază în container se pot număra pe degetele de la o mână a unui frezor nu foarte talentat. În majoritatea cazurilor, chiar și utilizarea k8s sau Docker Swarm este redundantă — destul de des, aceste instrumente sunt folosite pentru că tehnologiile sunt la modă și pentru a urma directivele „supreme” ale managerilor de a încărca totul în cloud și în containere. Well, pentru că acum este la modă și toată lumea face așa.
În minimum jumătate din cazuri, utilizarea Kubernetes sau doar a Docker pe proiect este excesivă. Problema este că nu toate echipele sau companiile de outsourcing angajate pentru a gestiona infrastructura clientului își dau seama de acest lucru. Mai rău este atunci când containerele sunt impuse, pentru că asta costă un anumit număr de monede clientului.
În general, există o opinie conform căreia mafia Docker/Kubernetes subjugă pur și simplu clienții care externalizează aceste probleme de infrastructură. Deoarece, pentru a lucra cu clustere, sunt necesari ingineri care sunt capabili să facă acest lucru și care înțeleg arhitectura soluției implementate. Am descris deja cazul nostru cu revista Republic — acolo am instruit echipa clientului să lucreze în realitățile Kubernetes, iar toți au fost mulțumiți. Și a fost onorabil. De multe ori, „implementatorii” k8s iau infrastructura clientului ostatice — deoarece acum doar ei înțeleg cum funcionează totul, iar de partea clientului nu există specialiști.
Și acum imaginați-vă că astfel cedăm nu doar partea de server web outsourcing-ului, ci și întreținerea bazei de date. Am spus că baza de date este inima, iar pierderea inimii este fatală pentru orice organism viu. Pe scurt, perspectivele nu sunt cele mai bune. Așa că, în loc de hype-ul Kubernetes, multe proiecte ar trebui pur și simplu să nu fie zgârcite la un tarif normal pe AWS, care ar rezolva toate problemele cu încărcarea pe site-ul/proiectul lor. Dar AWS nu mai este la modă, iar imaginea este mai scumpă decât banii — din păcate, și în mediul IT.
Ok. Poate că clasterizarea este într-adevăr necesară pentru proiect, dar dacă cu aplicațiile stateless totul este clar, cum ar trebui să organizăm o conectivitate adecvată pentru o bază de date clasterizată?
Când vorbim despre o soluție inginerescă fără întreruperi, care este considerată a fi tranziția la k8s, cea mai mare durere de cap este replicarea datelor într-o bază de date clusterizată. Unele SGBD-uri sunt destul de tolerante față de distribuirea datelor între instanțele lor. Multe altele, însă, nu sunt atât de primitoare. De obicei, principalul argument în alegerea SGBD-ului pentru proiectul nostru nu este neapărat capacitatea de a se replica cu resurse și costuri de inginerie minime. În special dacă proiectul nu a fost inițial planificat ca fiind microserviciu, ci a evoluat în această direcție.
Credem că nu trebuie să explicăm despre viteza discurilor de rețea — sunt lente. Adică, în cazul în care este necesar să repornim o instanță de SGBD undeva unde sunt, de exemplu, mai multe puteri de procesare sau memorie RAM disponibilă, totuși nu avem această posibilitate. Ne vom lovi foarte repede de limita de performanță a subsistemului de discuri virtualizate. Prin urmare, SGBD-ul trebuie să fie legat de propriul său set personal de mașini, aflate în imediata apropiere. Alternativ, va trebui să găsim o sincronizare rapidă a datelor către rezervele preconizate.
Continuând tema sistemelor de fișiere virtuale: Volumele Docker, din păcate, nu sunt lipsite de probleme. În general, în ceea ce privește stocarea pe termen lung și fiabilă a datelor, ne-ar plăcea să folosim scheme tehnice cât mai simple. Adăugarea unei noi straturi de abstractizare din sistemul de fișiere al containerului în sistemul de fișiere al gazdei părinte reprezintă deja un risc în sine. Dar atunci când apar dificultăți cu translatrea datelor între aceste straturi în timpul funcționării sistemului de contentie a containerelor, devine chiar mai problematic. În prezent, majoritatea problemelor bine cunoscute de umanitate pare că sunt eradicate. Dar, după cum înțelegeți, cu cât mecanismul este mai complex, cu atât este mai predispus să se rătăcească.
În lumina tuturor acestor „aventuri”, este mult mai rentabil și mai simplu să păstrezi baza de date într-un singur loc, iar chiar dacă ai nevoie de containerizarea aplicației — las-o să ruleze de una singură, obținând conexiunea simultană cu baza de date printr-o poartă de distribuție, care va fi citită și scrisă doar o dată și într-un singur loc. Această abordare reduce la minimum șansele de erori și desincronizări.
Unde vrem să ajungem? Că containerizarea bazei de date este adecvată acolo unde există o necesitate reală. Nu poți să împingi o bază de date de tip full-app și să o rulezi de parcă ai avea două zeci de microservicii — așa nu funcționează. Trebuie să înțelegem foarte clar acest lucru.
În loc de concluzie
Dacă aștepți un răspuns clar de tipul „să virtualizăm sau nu baza de date”, ne pare rău: nu va exista. Pentru că, în crearea oricărei soluții infrastructurale, trebuie să te ghidezi nu după modă și progres, ci în primul rând, după bunul simț.
Există proiecte pentru care principiile și instrumentele care vin odată cu Kubernetes se potrivesc perfect, iar în astfel de proiecte, pacea se stabilește cel puțin în domeniul backend. Și există proiecte care nu necesită containerizare, ci o infrastructură de server normală, deoarece pur și simplu nu pot să se scalzeze sub modelul de cluster microservicii, altfel vor eșua.
Sursa: habr.com
