Na neki način, historijski se razvila situacija u kojoj se IT industrija po svemu razdvaja na dva uvjetna tabora: one 'za' i one 'protiv'. Tema sporova može biti apsolutno proizvoljna. Koji operativni sustav je bolji: Windows ili Linux? Na pametnom telefonu, Android ili iOS? Imati sve u oblaku ili pohraniti na hladne RAID uređaje i staviti diskove u sef? Imaju li PHP programeri pravo nazvati se programerima? Ovi sporovi često imaju isključivo egzistencijalnu prirodu i ne temelje se ni na čemu osim sportskog interesa.
Naime, s pojavom kontejnera i svih ovih voljenih kuhinja s Dockerom i uvjetnim k8s započeli su i sporovi 'za' i 'protiv' korištenja novih mogućnosti u različitim sferama backend-a. (Unaprijed se dogovaramo da će se u ovom razmatranju kao orkestrator najčešće navoditi Kubernetes, ali izbor ovog alata nije od suštinskog značaja. Umjesto njega može se staviti bilo koji drugi koji vam se čini najprikladnijim i najpoznatijim.)
I, činilo bi se, bio bi to jednostavan spor između dvije strane jedne medalje. Isto tako besmislen i neumoljiv kao vječno suprotstavljanje Windows vs Linux, u kojem razboriti ljudi sramežljivo postoje negdje na sredini. No, kod kontejnerizacije, stvari nisu tako jednostavne. Obično u takvim sporovima nema prave strane, ali u slučaju 'koristiti' ili 'ne koristiti' kontejnere za pohranu baza podataka, sve se preokrene naopačke. Jer u određenom smislu, i pristalice i protivnici ovog pristupa su u pravu.
Svetla strana
Kratko opisati argumentaciju Svetle strane može se jednom rečenicom: 'Halo, 2k19 je vani!' Zvuči kao populizam, naravno, ali ako se detaljno razmotri situacija, postoje svoje prednosti. To ćemo sada i analizirati.
Pretpostavimo da imate veliki web projekt. Mogao se izvorno graditi na temelju mikroservisnog pristupa, ili ste do njega došli evolucijskim putem — to u stvari nije toliko važno. Rasporedili ste naš projekt po pojedinačnim mikroservisima, postavili orkestraciju, ravnotežu opterećenja, skaliranje. I sada s čistom savesti pijete mojito u ležaljci tijekom habra-efekata umesto da podižete srušene servere. No, u svemu se mora biti dosljedan. Vrlo često se containerizuje samo samo aplikacija — kod. A što još imamo osim koda?
Točno, podaci. Srce svakog projekta — su njegovi podaci: to može biti tipična baza podataka — MySQL, Postgre, MongoDB, kao i skladišta koja se koriste za pretraživanje (ElasticSearch), key-value skladišta za keširanje — na primjer, redis, itd. Sada nećemo govoriti o lošim varijantama implementacije backenda, kada se baza podataka sruši zbog loše napisanih upita, već ćemo razgovarati o osiguravanju otpornosti te iste baze podataka pod klijentskim opterećenjem. Kada containeriziramo našu aplikaciju i omogućimo joj slobodno skaliranje za obradu bilo kojeg broja ulaznih zahtjeva, to logično povećava i opterećenje na bazi podataka.
U suštini, kanal pristupa bazi podataka i server na kojem se ona vrti postaju iglene uši u našem prekrasnom containeriziranom backendu. Pri tome je osnovna motivacija containerne virtualizacije — pokretljivost i fleksibilnost strukture, što omogućava organizaciju raspodjele vršnog opterećenja u cijeloj dostupnoj infrastrukturi na najučinkovitiji način. Dakle, ako ne containeriziramo i ne raspoređujemo sve elemente sustava po klasteru — pravimo vrlo ozbiljnu grešku.
Mnogo je logičnije klasterizirati ne samo samo aplikaciju, već i usluge koje su odgovorne za pohranu podataka. Prilikom klasterizacije i implementacije neovisnih web poslužitelja koji raspoređuju opterećenje unutar k8s, već rješavamo problem sinhronizacije podataka — na primjer, komentara na objave, ako uzmemo u obzir neku medijsku ili blog platformu. U svakom slučaju, unutar klastera imamo, iako virtualni, prikaz baze podataka kao ExternalService. Pitanje je to što sama baza podataka još nije klasterizirana — web poslužitelji raspoređeni u klasteru povlače informacije o promjenama iz naše statične produkcijske baze koja radi odvojeno.
Osjećate li sumnju? Koristimo k8s ili Swarm da bismo rasporedili opterećenje i izbjegli pad glavnog web poslužitelja, ali to ne radimo za bazu podataka. Ali ako padne baza podataka, cijela naša klasterizirana infrastruktura gubi smisao — kakva je korist od praznih web stranica koje vraćaju grešku pristupa bazi podataka?
Zato klasterizirati trebamo ne samo web poslužitelje, kao što se obično radi, već i infrastrukturu baze podataka. Samo na taj način možemo osigurati potpuno funkcionalnu strukturu koja radi u jednoj ekipi, ali je pri tome neovisna jedna o drugoj. Čak i ako polovica našeg backend-a 'padne' pod opterećenjem — ostatak će preživjeti, a sustav sinhronizacije baza podataka unutar klastera i mogućnost beskonačnog skaliranja i implementacije novih klastera pomoći će da brzo dođemo do potrebnih kapaciteta — ako su rackovi u data centru.
Osim toga, distribuirani klasterski model baze podataka omogućava premještanje te baze podataka na mjesta gdje je potrebna; ako govorimo o globalnoj usluzi, prilično je nelogično imati web klaster negdje u blizini San Francisca i istodobno slati pakete prema bazi podataka u Podmoskovlju i natrag.
Osim toga, kontejnerizacija baze podataka omogućava izgradnju svih elemenata sustava na istoj razini apstrakcije. To, pak, omogućuje upravljanje tim sustavom iz koda, od strane programera, bez aktivnog uključivanja administratora. Programerima se učinilo da je potrebna posebna DBMS za novi podprojekt — lako! napisali su yaml datoteku, učitali je u klaster i gotovi.
Naravno, unutarnje upravljanje postaje znatno jednostavnije. Recite mi, koliko ste puta zatvorili oči kad je novi član tima pružao ruke prema produkcijskoj bazi podataka? Koja vam, zapravo, jedina postoji i upravo se vrti? Naravno, svi smo mi ovdje odrasli ljudi, i negdje imamo svježi backup, a još dalje — iza police s bakinim krastavcima i starim skijama — još jedan backup, možda čak i na hladnom skladištu, jer je jednom vaša kancelarija gorjela. Ali bez obzira na to, svaki dolazak novog člana tima koji ima pristup produkcijskoj infrastrukturi i, naravno, produkcijskoj bazi podataka — to je za sve prisutne veliki stres. Tko zna, možda je taj novajlija nespretan? Strašno, slažete se.
Kontainerizacija i, u suštini, distribuirana fizička topologija baze podataka vašeg projekta pomažu izbjeći ovakve stresne trenutke. Ne vjerujete novajliji? U redu! Ovdje ćemo mu podići vlastiti cluster za rad i isključiti ga od drugih databazelovskih klastera — sinkronizacija samo putem ručnog push-a i sinkronog okretanja ključevima (jedan tim lideru, drugi administratoru). I svi su sretni.
A sada je došlo vrijeme da se prebacimo na suprotstavljanje klasterizaciji baza podataka.
Tamna strana
Razmatrajući zašto ne bismo trebali kontainerizirati bazu podataka i nastaviti je pokretati na jednom centralnom serveru, nećemo se spuštati na razinu retorike ortodoksa i tvrdnji tipa "djedovi su pokretali baze na hardveru, pa ćemo i mi!" Umjesto toga, pokušajmo smisliti situaciju u kojoj bi kontainerizacija zaista donijela opipljive dividende.
Slažete se, projekata kojima zapravo treba baza u kontejneru može se prebrojati na prste jedne ruke ne baš najspretnijeg frizera. U većini slučajeva, čak i korištenje k8s ili Docker Swarm može biti suvišno — prilično često se ti alati koriste zbog opće popularnosti tehnologija i smjernica "sveznalica" u liku menadžera da sve stave u oblake i kontejnere. Pa, zato što je to sada popularno i svi to rade.
U najmanje polovici slučajeva korištenje Kubectl-a ili jednostavno Dockera na projektu je suvišno. Problem je što ne sve ekipe ili outsourcing kompanije zadužene za održavanje infrastrukture klijenta shvaćaju to. Još gore - kada se kontejneri nameću, jer to košta određeni iznos novca klijentu.
Općenito, postoji mišljenje da Docker/kubik-mafija jednostavno podčinjava klijente koji prepuštaju ova infrastrukturna pitanja outsourcingu. Jer za rad s klastraima trebaju inženjeri koji to mogu i razumiju arhitekturu implementiranog rješenja. Već smo opisali naš slučaj s publikacijom Republic - tamo smo obučili klijentovu ekipu da radi u stvarnosti Kubernetesa, i svi su bili zadovoljni. I to je bilo pravedno. Često „implementatori“ k8s uzimaju klijentovu infrastrukturu kao taoce - jer sada samo oni razumiju kako sve to funkcionira, dok na strani klijenta nema stručnjaka.
A sada zamislite da time predajemo ne samo web-server dio u outsourcing, već i održavanje baze podataka. Rekli smo da je baza podataka srce, a gubitak srca smrtonosan za svaki živi organizam. Ukratko, perspektive nisu najbolje. Dakle, umjesto hype-a Kubernetesa, mnogim projektima bi bilo bolje jednostavno ne štedjeti na normalnom tarifnom planu na AWS-u, koji bi riješio sve probleme s opterećenjem na njihovoj web stranici/projektu. No AWS više nije u modi, a pretencioznost je skuplja od novca - nažalost, to važi i u IT okruženju.
U redu. Možda klasterizacija stvarno treba projektu, ali ako je s ne-stateless aplikacijama sve jasno, kako organizirati dostojno osiguranje mrežne povezanosti klasterizirane baze podataka?
Kada govorimo o bešavnom inženjerskom rešenju koje naša migracija na k8s predstavlja, naš najveći problem je replikacija podataka u klasterizovanoj bazi podataka. Neki DBMS-ovi su od samog početka prilično tolerantni prema distribuciji podataka među svojim instancama. Međutim, mnogi drugi nisu tako ljubazni. Često je glavni argument pri izboru DBMS-a za naš projekat sposobnost replikacije sa minimalnim resursnim i inženjerskim troškovima, posebno ako projekat nije izvorno zamišljen kao mikroservisni, već se samo razvio u tom pravcu.
Ne mislimo da je potrebno objašnjavati brzinu rada mrežnih diskova — oni su spori. U slučaju potrebe, nemamo stvarnu mogućnost da podignemo instancu DBMS-a negde gde bi, na primer, bilo više procesorske snage ili slobodne RAM memorije. Veoma brzo ćemo naići na ograničenja performansi virtualizovanog diskovnog sistema. Shodno tome, DBMS mora biti vezan za svoj vlastiti set mašina koje se nalaze u neposrednoj blizini. Ili se mora na neki način napraviti brza sinhronizacija podataka za pripremljene rezerve.
Nastavljajući temu virtualnih FS: Docker Volumes, nažalost, nisu bez problema. U pravilu, kada je reč o dugoročnom pouzdanom skladištenju podataka, želeli bismo da se oslanjamo na što jednostavnije tehničke sheme. Dodavanje novog sloja apstrakcije iz FS-a kontejnera u FS roditeljskog hosta je već samo po sebi rizik. Ali kada se u radu sistema za obezbeđivanje kontejnerizacije suočimo sa problemima pri translatiranju podataka između ovih slojeva, to je već ozbiljna situacija. Trenutno se čini da su većina poznatih problema tehničke zajednice otklonjena. No, kao što znate, što je mehanizam složeniji, to je lakše da se pokvari.
S obzirom na sve ove "avanture", daleko je isplativije i jednostavnije držati bazu podataka na jednom mjestu. Čak i ako vam zatreba kontejnerizacija aplikacije, neka ona radi sama za sebe i putem distribucijskog pristupa ostvaruje istovremenu komunikaciju s bazom podataka, koja će se čitati i pisati samo jednom i na jednom mjestu. Ovaj pristup smanjuje mogućnost grešaka i desinkronizacija na minimalne vrijednosti.
Kamo mi idemo? Do toga da je kontejnerizacija baze podataka opravdana tamo gdje postoji stvarna potreba. Ne možete ugurati bazu punog odgovora i vrtjeti je kao da imate dvije desetine mikroslužbi — to ne funkcionira tako. To treba jasno razumjeti.
Umjesto izlaza
Ako očekujete jasan odgovor na pitanje "virtualizirati ili ne bazu podataka?", moramo vas razočarati: ovdje ga neće biti. Jer pri stvaranju bilo kojeg infrastrukturnog rješenja treba se rukovoditi ne modom i napretkom, već prije svega, zdravim razumom.
Postoje projekti na koje principi i alati koji dolaze s Kubernetesom savršeno odgovaraju, i u takvim projektima dolazi do mira barem u backend području. A postoje projekti kojima nije potrebna kontejnerizacija, već normalna serverska infrastruktura, jer se načelno ne mogu prilagoditi za mikroslužbenu klastersku samotak, inače će propasti.
Izvor: habr.com
