Istorijski gledajući, IT industrija se deli na dve uslovne grupe: one koje su "za" i one koje su "protiv". Tema rasprave može biti bilo koja. Koji operativni sistem je bolji: Windows ili Linux? Da li koristiti Android ili iOS na pametnom telefonu? Čuvati sve u oblaku ili na hladnim RAID skladištima sa hard diskovima u sefu? Da li PHP programeri imaju pravo da se nazivaju programerima? Ove rasprave su, povremeno, isključivo egzistencijalne prirode i nemaju osnova osim sportskog interesa.
Desilo se da su sa pojavom kontejnera i cele ove omiljene 'kuhinje' sa Docker-om i uslovnim k8s počele i rasprave 'za' i 'protiv' korišćenja novih mogućnosti u različitim oblastima pozadinskog razvoja. (Da odmah napomenemo, iako se u ovom razmatranju kao orkestra često navodi Kubernetes, izbor ovog alata nije presudan. Na njegovo mesto možete staviti bilo koji drugi koji vam se čini najprikladnijim i najpoznatijim.)
I, činilo bi se, ovo bi trebalo da bude jednostavna rasprava između dve strane istog novčića. Tako beznačajna i nemilosrdna kao večna borba između Windows-a i Linux-a, u kojoj razboriti ljudi sasvim dobro postoje negde na sredini. Međutim, u slučaju kontejnerizacije, stvari nisu tako jednostavne. Obično u takvim raspravama nema 'prave' strane, ali u slučaju 'primeniti' ili 'ne primeniti' kontejnere za čuvanje baza podataka, sve postaje naglavačke. Jer, u određenom smislu, i pristalice i protivnici takvog pristupa su u pravu.
Svetla strana
Kratak opis argumentacije Svetle strane može se sažeti jednom frazom: 'Halo, 2k19 je napolju!' Zvuči kao populizam, bez sumnje, ali ako se detaljno upustite u situaciju, ima svojih prednosti. One ćemo sada i razmotriti.
Представimo, da imate obsežen spletni projekt. Morda je bil sprva zgrajen na mikroservisnem pristopu ali pa je do njega prišel po evolucijski poti — to dejansko ni toliko pomembno. Razdelili ste projekt na posamezne mikroservise, nastavili orkestracijo, uravnoteženje obremenitve in širitev. In zdaj, z odličnim občutkom, pijete mojito v gugalniku med 'Habra' učinki, namesto da bi se bavili s padlimi strežniki. Vendar pa moramo biti v vseh dejanjih dosledni. Zelo pogosto se samo aplikacija — koda — kontejnerizira. Kaj pa imamo še poleg kode?
Pravilno, podatke. Srce vsakega projekta so podatki: to je lahko običajna podatkovna baza — MySQL, Postgre, MongoDB, pa tudi shrambe, ki se uporabljajo za iskanje (ElasticSearch), shrambe ključ-vrednost za predpomnjenje — na primer, Redis, itd. Zdaj se ne bomo ukvarjali s slabimi rešitvami backend implementacije, ko baza podatkov odpove zaradi slabo napisanih poizvedb, temveč se bomo osredotočili na zagotavljanje odpornosti te baze podatkov pod obremenitvijo strank. Ko kontejneriziramo našo aplikacijo in ji omogočimo prosto širitev za obdelavo poljubnega števila vhodnih poizvedb, to nujno povečuje tudi obremenitev na podatkovni bazi.
Dejansko postane dostop do podatkovne baze in strežnik, na katerem deluje, ozka grla v našem čudovitem kontejneriziranem backendu. Hkrati je glavni cilj kontejnerske virtualizacije — gibljivost in prilagodljivost strukture, kar omogoča učinkovito organizacijo porazdelitve vršne obremenitve po vsem dostopnem infrastrukturi. To pomeni, da če ne kontejneriziramo in ne razporedimo vseh elementov sistema po gruči — delamo zelo resno napako.
Pomembno je, da se ne le aplikacije, temveč tudi storitve, odgovorne za shranjevanje podatkov, clusterizirajo. Pri clusterizaciji in nameščanju neodvisno delujočih in med seboj obremenitev distribuirajočih spletnih strežnikov v k8s že rešujemo problem sinhronizacije podatkov — na primer, komentarjev k objavam, če vzamemo za primer kakšna medijska podjetja ali platforme za bloganje. V vsakem primeru se ustvari notranji, četudi virtualni, prikaz baze podatkov kot ExternalService. Vprašanje pa je, da sama baza podatkov še ni clusterizirana — nameščeni spletni strežniki v kubičnem okolju pridobivajo informacije o spremembah iz naše statične produkcijske baze, ki teče ločeno.
Občutite prevaro? Uporabljamo k8s ali Swarm, da razdelimo obremenitev in se izognemo izpadu glavnega spletnega strežnika, vendar tega ne delamo za baze podatkov. Če namreč baza podatkov odpove, potem v vsem našem clusteriziranem okolju ni smisla — kakšna korist nam je od praznih spletnih strani, ki vrnejo napako dostopa do baze podatkov?
Zato je nujno clusterizirati ne le spletne strežnike, kot je običajno, temveč tudi infrastrukturo baze podatkov. Le tako lahko zagotovimo, da struktura deluje učinkovito kot enota, a je še vedno neodvisna ena od druge. Tudi če polovica našega backenda odpove pod obremenitvijo — preostala bo preživela, sistem sinhronizacije baze podatkov med seboj znotraj klasterja in možnost neskončnega razširjanja ter nameščanja novih klasterjev bosta pomagala hitro doseči potrebne zmogljivosti — le imeti moramo stojala v podatkovnem centru.
Poleg tega distribuirani v klasterjih model baze podatkov omogoča prenos te baze tja, kjer je potrebna; če govorimo o globalni storitvi, je precej nelogično imeti spletni klaster nekje v okolici San Francisca in ob tem prenašati pakete, ko dostopamo do baze podatkov v Podmoskovju in nazaj.
Prav tako omrežno delovanje baze podatkov omogoča postavitev vseh elementov sistema na enem nivoju abstrakcije. To pa posledično omogoča upravljanje tega sistema neposredno iz kode, razvijalci to lahko počnejo brez aktivnega vključevanja administratorjev. Razvijalci so pomislili, da potrebujemo posebno DBMS za nov podprojekt — enostavno! napisali so yaml-datoteko, naložili v klaster in pripravljeno.
In addition, the internal operation is significantly simplified. Tell me, how many times have you squinted when a new team member reached into the production database for work? The one database you actually have and is currently running? Of course, we're all adults here, and somewhere we have a fresh backup, and further back — behind the shelf with grandma's pickles and old skis — there’s another backup, possibly even in cold storage, because your office has burned down once before. Still, every time a new team member is introduced with access to the production infrastructure and, of course, the production database — it’s a bucket of valerian for everyone around. Who knows this rookie? Maybe he’s clumsy? It’s scary, admit it.
Containerization and, essentially, the distributed physical topology of your project's database help avoid such stressful moments. Don't trust the newcomer? Okay! Let’s set up his own cluster for work and disconnect it from the other database clusters — synchronization only through manual push and synchronous turning of two keys (one for the team lead and the other for the admin). And everyone is happy.
Now it's time to argue against database clustering.
The Dark Side
Considering why one shouldn't containerize the database and continue running it on a single central server, strežnikomlet's not stoop to the rhetoric of the orthodox and statements like 'grandfathers ran databases on hardware, and so will we!' Instead, let’s try to come up with a situation where containerization would indeed yield tangible benefits.
Agreed, the projects that really need a database in a container can be counted on one hand, not belonging to the best miller. In most cases, even using k8s or Docker Swarm is excessive — quite often, these tools are resorted to due to the overall hype around technologies and the directives from higher-ups pushing to put everything in the cloud and containers. Well, because it’s fashionable now and everyone is doing it.
V več kot polovici primerov je uporaba Kubernetes ali preprosto Docker na projektu pretirana. Težava je v tem, da si vse ekipe ali zunanja podjetja, ki so bila najeta za vzdrževanje infrastrukture stranke, tega ne zavedajo. Še huje je, ko se kontejnerji vsiljujejo, ker to stranko stane določeno število kovancev.
Na splošno prevladuje mnenje, da Docker/K8s mafija preprosto podbija stranke, ki predajajo te infrastrukturne zadeve v outsourcing. Kajti za delo s klastrskimi rešitvami so potrebni inženirji, ki to zmorejo in razumejo arhitekturo implementiranih rešitev. Že prej smo opisali naš primer z izdajo Republic – tam smo ekipo stranke naučili delati v realnostih Kubernetes-a in vsi so bili zadovoljni. In to je bilo pošteno. Velikokrat pa izvajalci K8s vzamejo infrastrukturo stranke za talce – saj le oni razumejo, kako vse deluje, stranka pa nima strokovnjakov.
Zdaj si predstavljajte, da na ta način oddamo ne samo spletni strežnik v outsourcing, temveč tudi upravljanje z bazo podatkov. Rekli smo, da je baza podatkov srce, in izguba srca je usodna za vsak živ organizem. Na kratko, obeti niso najboljši. Namesto hipersodobnega Kubernetes-a bi se mnogim projektom splačalo preprosto investirati v normalen tarifni načrt na AWS, kar bi rešilo vse težave s prometom njihovih spletnih strani/projektov. A AWS že ni več moderen, in prazne obljube so dražje od denarja – žal tudi v IT okolju.
Okej. Morda je klasterizacija res potrebna za projekt, vendar če je pri stateless aplikacijah vse jasno, kako torej organizirati dostojno zagotovitev omrežne povezljivosti za klasterizirano bazo podatkov?
Ko govorimo o brezšivni inženirski rešitvi, ki jo predstavlja prehod na k8s, je naš največji problem replikacija podatkov v klasterizirani bazi podatkov. Nekatere DBMS se od začetka precej prijazno držijo razporejanja podatkov med svojimi posameznimi primerki. Mnogi drugi niso tako prijazni. In pogosto postane glavni argument pri izbiri DBMS za naš projekt sposobnost replikacije z minimalnimi stroški virov in inženiringa. Še posebej, če projekt sprva ni bil načrtovan kot mikroservis, ampak se je preprosto razvil v to smer.
Mislim, da ni treba razlagati o hitrosti delovanja omrežnih diskov — so počasni. To pomeni, da v primeru, da bi morali znova zagnati primer DBMS nekje, kjer je več procesorske moči ali prostih gigabajtov pomnilnika, te možnosti nimamo. Zelo hitro se bomo soočili s težavami pri zmogljivosti virtualiziranega diska. Zato mora biti DBMS povezan s svojim lastnim naborom naprav, ki se nahajajo v neposredni bližini. Ali pa moramo nekako posebej zagotoviti dovolj hitro sinhronizacijo podatkov za predvidene rezerve.
Kar zadeva virtualne datotečne sisteme: žal Docker Volumes niso brez težav. Na splošno bi želeli pri dolgoročnem zanesljivem shranjevanju podatkov upoštevati čim bolj preproste tehnične sheme. Dodajanje nove plasti abstrakcije iz datotečnega sistema kontejnerja v datotečni sistem gostitelja je že samo po sebi tvegano. A ko pride do težav pri prenosu podatkov med temi plastmi v delovanju sistema za zagotavljanje kontejnerizacije, je to že povsem katastrofalno. Trenutno se zdi, da je večina znanih težav, ki jih je prepoznala človeštvo, odpravljena. A sami veste, čim bolj zapleten je mehanizem, tem lažje se pokvari.
Ob vsej tej priložnosti je bolj smiselno in enostavneje hraniti BDP na enem mestu, in če potrebujete kontejnerizacijo aplikacije — naj deluje sama in prek distribucijskega prehoda pridobiva hkratno povezavo z BDP, ki se bo brala in pisala le enkrat in na enem mestu. Tak pristop zmanjša verjetnost napak in razhajanj na minimalne vrednosti.
Kam torej ciljamo? K temu, da je kontejnerizacija BDP smiselna le, kjer obstaja prava potreba. Ni mogoče stlačiti baze celotne aplikacije in jo obravnavati, kot da imate dva ducata mikroservisov — tako ne deluje. In to je treba jasno razumeti.
Namesto izida
Če pričakujete jasen izid "virtualizirati ali ne BDP", vas moramo razočarati: tu ga ne bo. Ker ob ustvarjanju kakršne koli infrastrukturne rešitve morate ravnati ne po modi in napredku, temveč predvsem po zdravi pameti.
Obstajajo projekti, kjer principi in orodja, ki prihajajo s Kubernetesom, delujejo popolnoma, in v takšnih projektih vsaj v ozadju pride do harmonije. Obstajajo pa tudi projekti, ki ne potrebujejo kontejnerizacije, ampak normalno strežniško infrastrukturo, saj se preprosto ne morejo prilagoditi mikroservisnemu klaster modelu, ker bi se sesuli.
Izvor: habr.com
