Akosi historicky je IT priemysel z akéhokoľvek dôvodu rozdelený na dva podmienené tábory: na tých, ktorí sú „za“ a na tých, ktorí sú „proti“. Predmet sporov môže byť navyše úplne ľubovoľný. Ktorý OS je lepší: Win alebo Linux? Na smartfóne so systémom Android alebo iOS? Mali by ste všetko uložiť do oblakov alebo to dať na studené úložisko RAID a skrutky uložiť do trezoru? Majú ľudia PHP právo nazývať sa programátormi? Tieto spory majú niekedy výlučne existenčný charakter a nemajú iný základ ako športové záujmy.
Stalo sa tak, že s príchodom kontajnerov a všetkej tejto milovanej kuchyne s dockermi a podmienenými k8 sa začali debaty „za“ a „proti“ o využívaní nových schopností v rôznych oblastiach backendu. (Vopred si urobme výhradu, že hoci Kubernetes bude v tejto diskusii najčastejšie uvádzaný ako orchestrátor, výber tohto konkrétneho nástroja nemá zásadný význam. Namiesto toho môžete nahradiť ktorýkoľvek iný, ktorý sa vám zdá byť najpohodlnejší a známy .)
A zdá sa, že by to bol jednoduchý spor medzi dvoma stranami tej istej mince. Rovnako nezmyselné a nemilosrdné ako večná konfrontácia Win vs Linux, v ktorej niekde uprostred existujú adekvátni ľudia. Ale v prípade kontajnerizácie nie je všetko také jednoduché. V takýchto sporoch zvyčajne neexistuje správna strana, ale v prípade kontajnerov „používať“ alebo „nepoužívať“ na ukladanie databáz sa všetko obracia hore nohami. Pretože v určitom zmysle majú pravdu priaznivci aj odporcovia tohto prístupu.
Svetlá stránka
Argument Svetlej strany možno stručne opísať jednou frázou: „Ahoj, 2k19 je za oknom!“ Znie to ako populizmus, samozrejme, ale ak sa do situácie ponoríte do detailov, má to svoje výhody. Poďme si ich teraz roztriediť.
Povedzme, že máte veľký webový projekt. Pôvodne mohol byť postavený na základe mikroservisného prístupu, alebo sa k nemu v určitom bode dostal evolučnou cestou – to v skutočnosti nie je veľmi dôležité. Rozdelili ste náš projekt do samostatných mikroslužieb, nastavili ste orchestráciu, vyvažovanie záťaže a škálovanie. A teraz s čistým svedomím popíjate mojito v hojdacej sieti počas efektov habra namiesto toho, aby ste dvíhali padlých serverov. Ale vo všetkých akciách musíte byť dôslední. Veľmi často je kontajnerizovaná iba samotná aplikácia – kód. Čo ešte máme okrem kódu?
Presne tak, údaje. Srdcom každého projektu sú jeho dáta: môžu to byť buď typické DBMS – MySQL, Postgre, MongoDB, alebo úložisko používané na vyhľadávanie (ElasticSearch), úložisko kľúč-hodnota na ukladanie do vyrovnávacej pamäte – napríklad redis atď. budeme hovoriť o pokrivených možnostiach implementácie backendu, keď databáza spadne kvôli zle napísaným dotazom, a namiesto toho sa budeme baviť o zabezpečení odolnosti voči chybám práve tejto databázy pri záťaži klienta. Keď totiž našu aplikáciu kontajnerizujeme a umožňujeme jej voľne sa škálovať na spracovanie ľubovoľného počtu prichádzajúcich požiadaviek, prirodzene to zvyšuje zaťaženie databázy.
Kanál na prístup k databáze a server, na ktorom beží, sa v skutočnosti stávajú okom ihly v našom krásnom kontajnerovom backende. Hlavným motívom virtualizácie kontajnerov je zároveň mobilita a flexibilita štruktúry, ktorá nám umožňuje čo najefektívnejšie organizovať distribúciu špičkového zaťaženia naprieč celou nám dostupnou infraštruktúrou. To znamená, že ak nekontajnerujeme a nerozvinieme všetky existujúce prvky systému naprieč klastrom, robíme veľmi vážnu chybu.
Oveľa logickejšie je klastrovať nielen samotnú aplikáciu, ale aj služby zodpovedné za ukladanie dát. Klastrovaním a nasadením webových serverov, ktoré fungujú samostatne a rozdeľujú si záťaž medzi sebou v k8, už riešime problém synchronizácie dát – rovnaké komentáre k príspevkom, ak si vezmeme ako príklad nejaké médium alebo blogovú platformu. V každom prípade máme vnútroklastrovú, dokonca virtuálnu reprezentáciu databázy ako ExternalService. Otázkou je, že samotná databáza ešte nie je klastrovaná – webové servery nasadené v kocke berú informácie o zmenách z našej statickej bojovej databázy, ktorá rotuje samostatne.
Cítite úlovok? Používame k8s alebo Swarm na rozloženie záťaže a vyhnutie sa zlyhaniu hlavného webového servera, ale nerobíme to pre databázu. Ale ak dôjde k zlyhaniu databázy, potom celá naša klastrovaná infraštruktúra nemá zmysel – načo sú dobré prázdne webové stránky, ktoré vracajú chybu prístupu k databáze?
Preto je potrebné klastrovať nielen webové servery, ako sa to bežne robí, ale aj databázovú infraštruktúru. Len tak môžeme zabezpečiť štruktúru, ktorá plnohodnotne funguje v jednom tíme, no zároveň je od seba nezávislá. Navyše, aj keď sa nám polovica backendu „zrúti“ pri záťaži, zvyšok prežije a systém vzájomnej synchronizácie databáz v rámci klastra a možnosť nekonečného škálovania a nasadzovania nových klastrov pomôže rýchlo dosiahnuť požadovanú kapacitu – len keby boli v dátovom centre stojany .
Navyše, databázový model distribuovaný v klastroch vám umožňuje preniesť túto databázu tam, kde je to potrebné; Ak hovoríme o globálnej službe, potom je dosť nelogické roztáčať webový klaster niekde v oblasti San Francisca a zároveň posielať pakety pri prístupe do databázy v regióne Moskva a späť.
Kontajnerizácia databázy vám tiež umožňuje vybudovať všetky prvky systému na rovnakej úrovni abstrakcie. Čo zase umožňuje spravovať práve tento systém priamo z kódu, vývojármi, bez aktívneho zapojenia administrátorov. Vývojári si mysleli, že pre nový podprojekt je potrebný samostatný DBMS - jednoduché! napísal súbor yaml, nahral ho do klastra a hotovo.
A samozrejme, vnútorné ovládanie je výrazne zjednodušené. Povedzte mi, koľkokrát ste zavreli oči, keď nový člen tímu vložil ruky do bojovej databázy kvôli práci? Ktorý vlastne jediný máte a práve sa točí? Samozrejme, všetci sme tu dospelí a niekde máme čerstvú zálohu a ešte ďalej - za policou s babkinými uhorkami a starými lyžami - ďalšiu zálohu, možno aj v chladiarenskom sklade, pretože vám už raz horela kancelária. Ale aj tak, každé predstavenie nového člena tímu s prístupom k bojovej infraštruktúre a samozrejme k bojovej databáze je pre všetkých okolo vedro validolu. No, kto ho pozná, nováčik, možno má kríže ruky? Je to strašidelné, budete súhlasiť.
Kontajnerizácia a v skutočnosti distribuovaná fyzická topológia databázy vášho projektu pomáha vyhnúť sa takýmto momentom overovania. Neveríte nováčikovi? OK! Dajme mu vlastný klaster, s ktorým bude pracovať a odpojíme databázu od ostatných klastrov - synchronizácia iba manuálnym stlačením a synchrónnym otáčaním dvoch kľúčov (jeden pre vedúceho tímu, druhý pre admina). A všetci sú šťastní.
A teraz je čas zmeniť sa na odporcov klastrovania databáz.
Temná strana
Argumentujúc tým, prečo sa neoplatí kontajnerizovať databázu a pokračovať v jej prevádzke na jednom centrálnom serveri, neznížime sa k ortodoxnej rétorike a vyhláseniam typu „starí otcovia prevádzkovali databázy na hardvéri a my tiež!“ Namiesto toho skúsme prísť so situáciou, v ktorej by kontajnerizácia skutočne priniesla hmatateľné dividendy.
Súhlaste, projekty, ktoré skutočne potrebujú základ v kontajneri, by nie najlepší frézar spočítal na prstoch jednej ruky. Väčšinou je nadbytočné aj samotné používanie k8s alebo Docker Swarm – dosť často sa k týmto nástrojom uchyľuje kvôli všeobecnému humbuku technológií a postojom „všemohúceho“ v osobe rodov, aby všetko presadili. mraky a kontajnery. No preto, lebo teraz je to módne a robí to každý.
Minimálne v polovici prípadov je používanie Kubernetisu alebo len Dockera na projekte nadbytočné. Problém je v tom, že nie všetky tímy alebo outsourcingové spoločnosti najaté na údržbu infraštruktúry klienta si to uvedomujú. Horšie je to pri ukladaní kontajnerov, pretože to klienta stojí určité množstvo mincí.
Vo všeobecnosti panuje názor, že mafia docker/cube hlúpo drví klientov, ktorí outsourcujú tieto záležitosti infraštruktúry. Veď na prácu s klastrami potrebujeme inžinierov, ktorí sú toho schopní a celkovo rozumejú architektúre implementovaného riešenia. Náš prípad sme už raz opísali v publikácii Republika - tam sme zaškolili tím klienta na prácu v realite Kubernetis a všetci boli spokojní. A bolo to slušné. „Implementátori“ k8 často berú ako rukojemníkov klientovu infraštruktúru – pretože teraz len oni chápu, ako tam všetko funguje, na strane klienta nie sú žiadni špecialisti.
Teraz si predstavte, že týmto spôsobom outsourcujeme nielen časť webového servera, ale aj údržbu databázy. Povedali sme, že BD je srdce a strata srdca je smrteľná pre každý živý organizmus. Vyhliadky skrátka nie sú najlepšie. Takže namiesto hype Kubernetis by sa mnohé projekty jednoducho nemali obťažovať bežnou tarifou pre AWS, ktorá vyrieši všetky problémy so zaťažením ich stránky/projektu. Ale AWS už nie je v móde a predvádzanie sa stojí viac ako peniaze – žiaľ, aj v IT prostredí.
OK. Možno projekt skutočne potrebuje klastrovanie, ale ak je všetko jasné s bezstavovými aplikáciami, ako potom môžeme zorganizovať slušné sieťové pripojenie pre klastrovanú databázu?
Ak hovoríme o bezproblémovom inžinierskom riešení, čo je prechod na k8s, potom našou hlavnou bolesťou je replikácia údajov v klastrovanej databáze. Niektoré DBMS sú spočiatku celkom lojálne k distribúcii údajov medzi ich jednotlivými inštanciami. Mnohí iní nie sú takí ústretoví. A dosť často hlavným argumentom pri výbere DBMS pre náš projekt nie je schopnosť replikácie s minimálnymi nákladmi na zdroje a inžinierstvo. Najmä ak projekt nebol pôvodne plánovaný ako mikroslužba, ale jednoducho sa vyvinul týmto smerom.
Myslíme si, že o rýchlosti sieťových diskov sa netreba baviť – sú pomalé. Tie. Stále nemáme skutočnú príležitosť, ak sa niečo stane, reštartovať inštanciu DBMS niekde, kde je viac výkonu, napríklad výkonu procesora alebo voľnej pamäte RAM. Veľmi rýchlo nabehneme na výkon virtualizovaného diskového subsystému. V súlade s tým musí byť DBMS pribitý k vlastnej osobnej súprave strojov umiestnených v tesnej blízkosti. Alebo je potrebné nejako samostatne schladiť dostatočne rýchlu synchronizáciu dát pre predpokladané rezervy.
Pokračovanie v téme virtuálnych súborových systémov: Docker Volumes, žiaľ, nie sú bezproblémové. Vo všeobecnosti by som si v takej záležitosti, ako je dlhodobé spoľahlivé ukladanie dát, rád vystačil s technicky najjednoduchšími schémami. A pridanie novej abstrakcie z FS kontajnera do FS nadradeného hostiteľa je riziko samo o sebe. Keď však prevádzka systému podpory kontajnerizácie narazí aj na ťažkosti s prenosom údajov medzi týmito vrstvami, je to naozaj katastrofa. V súčasnosti sa zdá, že väčšina problémov známych progresívnemu ľudstvu bola vykorenená. Ale chápete, čím je mechanizmus zložitejší, tým ľahšie sa rozbije.
Vo svetle všetkých týchto „dobrodružstiev“ je oveľa výnosnejšie a jednoduchšie uchovávať databázu na jednom mieste, a aj keď potrebujete aplikáciu kontajnerizovať, nechajte ju bežať samostatne a cez distribučnú bránu získavajte súčasnú komunikáciu s databázy, ktorá sa bude čítať a zapisovať iba raz a na jednom mieste. Tento prístup znižuje pravdepodobnosť chýb a desynchronizácie na minimum.
K čomu smerujeme? Okrem toho je kontajnerizácia databázy vhodná tam, kde je to skutočne potrebné. Nemôžete napchať databázu plnej aplikácie a roztočiť ju, ako keby ste mali dva tucty mikroslužieb – takto to nefunguje. A toto treba jasne pochopiť.
Namiesto výstupu
Ak čakáte na jasný záver „virtualizovať databázu alebo nie“, sklameme vás: tu nebude. Pretože pri vytváraní akéhokoľvek infraštruktúrneho riešenia sa treba riadiť nie módou a pokrokom, ale predovšetkým zdravým rozumom.
Sú projekty, pre ktoré princípy a nástroje, ktoré sú súčasťou Kubernetisu, dokonale sedia a v takýchto projektoch je pokoj aspoň v backendovej oblasti. A sú projekty, ktoré nepotrebujú kontajnerizáciu, ale normálnu serverovú infraštruktúru, pretože sa zásadne nemôžu preškálovať na klastrový model mikroslužieb, pretože padnú.
Zdroj: hab.com