Historicky sa IT priemysel rozdeľuje na dva tábory: jeden "za" a druhý "proti". Predmetom diskusií môže byť čokoľvek. Ktorý operačný systém je lepší: Windows alebo Linux? Máte smartfón s Androidom alebo iOS? Uchovávate všetko v cloude alebo na studených RAID úložiskách, pričom diskové jednotky uzamknete v trezore? Môžu PHP programátori nazývať seba programátormi? Tieto debaty sú niekedy výlučne existentialistické a nemajú inú podstatu ako športový záujem.
S príchodom kontajnerov a obľúbeného Dockeru a Kubernetes začali aj diskusie "za" a "proti" využívaniu nových možností v rôznych oblastiach backendu. (Pre zjednodušenie sa v tejto úvahe zvyčajne ako orchestrátor uvádza Kubernetes, ale výber tohto nástroja nie je zásadný. Môžete použiť akýkoľvek iný, ktorý považujete za najvhodnejší a najpohodlnejší.)
A zdalo by sa, že ide o jednoduchú debatu medzi dvoma stranami tej istej mince. Tak bezvýznamnú a neúprosne bezcitnú ako večný spor Windows vs Linux, v ktorom racionálni ľudia existujú kdesi uprostred. V prípade kontajnerizácie to však nie je také jednoduché. V týchto diskusiách zvyčajne neexistuje "správna" strana, ale v prípade "použitie" alebo "nepoužitie" kontajnerov pre ukladanie databáz je všetko obrátené naruby. Pretože z určitých hľadísk majú pravdu ako zástancovia, tak aj odporcovia tohto prístupu.
Svetlá strana
Stručne povedané, argumentácia Svetlej strany sa dá zhrnúť jednou vetou: “Ahoj, 2k19 je tu!” Znie to ako populizmus, ale ak sa do tejto situácie podrobne zamyslíme, má svoje výhody. Tieto výhody si teraz podrobne rozoberieme.
Predpokladajme, že máte veľký webový projekt. Môže byť pôvodne postavený na základe mikroslužbového prístupu, alebo sa k nemu postupne dostal — na tom v skutočnosti nezáleží. Rozdelili ste projekt na jednotlivé mikroslužby, nastavili orchestráciu, vyvažovanie zaťaženia a škálovanie. A teraz si s čistým svedomím vychutnávate mojito v hamaku počas Habr efektov, namiesto toho, aby ste zdvíhali padlé servery. Ale vo všetkých činnostiach je dôležité byť dôsledný. Veľmi často sa kontajnerizuje iba samotná aplikácia — kód. A čo ešte máme okrem kódu?
Správne, dáta. Srdce každého projektu sú jeho dáta: to môže byť typická DBMS — MySQL, Postgre, MongoDB, ako aj úložiská používané na vyhľadávanie (ElasticSearch), key-value úložiská na cachovanie — napríklad, redis, a tak ďalej. Teraz sa nebudeme zaoberať nevhodnými implementáciami back-endu, keď DB klesá z dôvodu zle napísaných požiadaviek, ale radšej sa pozrieme na zabezpečenie spoľahlivosti tejto databázy pod klientskou záťažou. Veď keď kontajnerizujeme našu aplikáciu a umožníme jej voľne škálovať na spracovanie akéhokoľvek množstva prichádzajúcich požiadaviek, zákonite to zvyšuje aj záťaž na databázu.
Fakticky sa kanál komunikácie s databázou a server, na ktorom beží, stávajú úzkym miestom v našom krásnom kontajnerizovanom back-ende. Hlavným motívom kontajnerovej virtualizácie je pohyblivosť a flexibilita štruktúry, ktoré umožňujú efektívne rozložiť vrcholové zaťaženie po celej dostupnej infraštruktúre. Teda, ak nekontajnerizujeme a nerozložíme všetky existujúce prvky systému po klastri, robíme veľmi vážnu chybu.
Je oveľa logickejšie klastrovať nielen samotnú aplikáciu, ale aj služby zodpovedajúce za uchovávanie údajov. Pri klastrovaní a nasadzovaní samostatne pracujúcich a medzi sebou rozdeľujúcich záťaž webových serverov v k8s už riešime problém synchronizácie údajov — napríklad komentárov pod príspevkami, ak uvádzame ako príklad nejaké médiá alebo blogovú platformu. V každom prípade máme vo vnútri klastru, aj keď virtuálne, predstavenie DB ako ExternalService. Otázka však zostáva, že samotná DB zatiaľ nie je sklastrovaná — webové servery nasadené v kubexe čerpajú informácie o zmenách z našej statickej prevádzky, ktorá funguje samostatne.
Cítite podvod? Používame k8s alebo Swarm na to, aby sme rozdelili záťaž a predišli pádu hlavného systému, webového servera, ale to nerobíme pre DB. Ale ak padne DB, tak celá naša klastrovaná infraštruktúra nemá zmysel — aký má zmysel mať prázdne webové stránky vracajúce chybu prístupu k databáze?
Presne preto je potrebné klastrovať nielen webové servery, ako sa to zvyčajne robí, ale aj infraštruktúru databázy. Iba tak môžeme zabezpečiť plne fungujúcu štruktúru, ktorá je v jednom ťahu, ale zároveň na sebe nezávislá. Ak by sa aj polovina našich backendov zrútila pod záťažou — zvyšok prežije a systém synchronizácie DB medzi sebou v rámci klastru a možnosť nekonečného škálovania a nasadzovania nových klastrov pomôže rýchlo dosiahnuť potrebné výkony — akurát by boli regály v dátovom centre.
Okrem toho rozdelený model DB v klastroch umožňuje presunúť tú istú DB tam, kde je potrebná; ak hovoríme o globálnom servise, je dosť nelogické mať webový klaster niekde v okolí San Francisca a pritom posielať pakety za databázou do Podmoskovia a naspäť.
Tiež kontajnerizácia DB umožňuje vybudovať všetky prvky systému na jednej úrovni abstrakcie. To zase umožňuje spravovať tento systém priamo z kódu, vývojármi, bez aktívneho zapojenia adminov. Napadlo vývojárom, že potrebujú samostatný SÚDB pre nový podprojekt — jednoducho! napísali yaml súbor, nahrali ho do klastru a hotovo.
A samozrejme, interné využívanie sa výrazne zjednodušuje. Povedzte, koľkokrát ste si zatvorili oči v momentoch, keď sa nový člen tímu snažil preniknúť do produkčnej databázy? Ktorá, v skutočnosti, je len jedna a teraz sa aktívne používa? Samozrejme, všetci tu sme dospelí a niekde máme čerstvý zálohovací kópiu, a ešte ďalej — za poličkou s babičkinými uhorkami a starými lyžami — ďalšiu zálohu, možno aj na studenom úložisku, pretože raz už horel váš kancelárie. Ale aj tak, každé zapojenie nového člena tímu, ktorý má prístup k produkčnej infraštruktúre a, samozrejme, k produkčnej databáze — to je vedro valídolu pre všetkých okolo. Nuž, kto pozná nováčika, čo keď je nešikovný? Hrozné, súhlasíte.
Kontajnerizácia a vlastne distribuovaná fyzická topológia databázy vášho projektu pomáha vyhnúť sa podobným valídolovým momentom. Neveríte nováčikovi? Okej! Vytvoríme mu vlastný klaster pre prácu a odpojíme ho od ostatných databázových klastrov — synchronizácia iba po ručnom pushi a synchronizovanom otočení dvoch kľúčov (jeden tímovému vedúcemu, druhý administrátorovi). A všetci sú šťastní.
A teraz nastal čas prehodnotiť svoj postoj voči klasterizácii databáz.
Temná Strana
Zamyslime sa, prečo by sme nemali kontajnerizovať databázu a pokračovať v jej prevádzke na jednom centrálnom serveri, nebudeme sa znižovať na rétoriku ortodoxných a tvrdení typu „starí majstri prevádzkovali databázy na hardvéri, a my budeme!“ Namiesto toho sa pokúsme vymyslieť situáciu, v ktorej by kontajnerizácia naozaj priniesla významné dividendy.
Súhlasíte, projektov, ktorým naozaj potrebujete databázu v kontajneri, sa dá spočítať na prstoch jednej ruky nie najlepšieho frézara. Vo väčšine prípadov, dokonca aj samotné používanie k8s alebo Docker Swarm môže byť nadmerné — pomerne často sa k týmto nástrojom uchyľujú kvôli všeobecnej populárnosti technológií a nátlaku „vrchných“ v podobe manažérov na zastrčenie všetkého do oblakov a kontajnerov. Nuž, pretože teraz je to módne a všetci to robia.
V minimálne polovici prípadov je používanie Kubernetes alebo jednoducho Dockera v projekte nadbytočné. Otázka je, že nie všetky tímy alebo outsourcingové firmy najaté na správu infraštruktúry klienta si to uvedomujú. Horšie je, keď sú kontajnery vnucované, pretože to stoji určitý počet mincí klienta.
Vo všeobecnosti panuje názor, že Docker/K8s mafia jednoducho podmieňujú klientov, ktorí delegujú tieto infraštruktúrne otázky na outsourcing. Na prácu s klastrami sú potrební inžinieri, ktorí sú schopní to robiť a rozumejú architektúre nasadeného riešenia. Už sme opisovali náš prípad s vydaním Republic — tam sme školili tím klienta, aby pracoval v realitách Kubernetes a všetci boli spokojní. A bolo to na úrovni. Často však "implementátori" K8s berú infraštruktúru klienta ako rukojemníka — pretože teraz iba oni chápu, ako to tam všetko funguje, na strane klienta nie sú odborníci.
A teraz si predstavte, že takýmto spôsobom odovzdávame nie len webovú časť na outsourcing, ale aj správu databázy. Hovorili sme, že databáza je srdce, a strata srdca je fatálna pre akýkoľvek živý organizmus. Skrátka, perspektívy nie sú najlepšie. Takže namiesto hypeového Kubernetes by mnohým projektom stálo za to jednoducho nemrhať na normálny tarif na AWS, ktorý by vyriešil všetky problémy s nákladom na ich stránku/projekt. Ale AWS už nie je módne, a pretvárka je drahšia ako peniaze — bohužiaľ aj v IT prostredí.
Okej. Možno je klasifikácia projektu skutočne potrebná, ale ak je so stateless aplikáciami všetko jasné, tak ako sécurizovať kvalitnú sieťovú konektivitu klasifikovanej databázy?
Ak hovoríme o bezproblémovom inžinierskom riešení, ktorým je prechod na k8s, naším hlavným problémom je replikácia dát v clusterovanej DB. Niektoré SGBD zo začiatku pomerne tolerantne pristupujú k distribúcii dát medzi svojimi jednotlivými inštanciami. Mnohé iné nie sú tak priaznivé. A často sa hlavným argumentom pri výbere SGBD pre náš projekt stáva rozhodne nie schopnosť replikovať sa s minimálnymi zdrojovými a inžinierskymi nákladmi. Osobitne ak projekt nebol pôvodne plánovaný ako mikroservisný, ale jednoducho evolučne smeroval týmto smerom.
Nemyslíme si, že je potrebné rozprávať o rýchlosti práce sieťových diskov — sú pomalé. T.j. v prípade potreby nemáme reálnu možnosť znovu spustiť inštanciu SGBD niekde inde, kde je, povedzme, viac procesorového výkonu alebo voľnej pamäte. Rýchlo narazíme na výkon virtualizovanej diskovej subsystémy. Preto by SGBD mala byť pripevnená k svojmu vlastnému osobnému súboru strojov, ktoré sa nachádzajú v bezprostrednej blízkosti. Alebo budeme musieť nejakým spôsobom zabezpečiť dostatočne rýchlu synchronizáciu dát na predpokladané zálohy.
Pokračujúc v téme virtuálnych FS: Docker Volumes, žiaľ, nie sú bezproblémové. Vo všeobecnosti by sme sa v prípade dlhodobého spoľahlivého ukladania dát chceli držať čo najjednoduchších technických schém. A pridanie novej vrstvy abstrakcie z FS kontajnera do FS rodičovského hostiteľa — už samo o sebe predstavuje riziko. Ale keď sa v práci systému zabezpečenia kontajnerizácie objavujú ťažkosti so prenášaním dát medzi týmito vrstvami, potom sa situácia stáva skutočne zložitou. V súčasnosti bola väčšina známych problémov, ktoré trápili progresívnych ľudí, zrejme odstránená. Ale rozumiete, čím zložitejší je mechanizmus, tým ľahšie sa porušuje.
S ohľadom na všetky tieto "dobrodružstvá" je oveľa výhodnejšie a jednoduchšie držať databázu na jednom mieste, a aj keď potrebujete kontejnerizáciu aplikácie — nech sa spustí sama od seba a cez distribuovaný bránu získa súčasné spojenie s databázou, ktorá sa bude čítať a zapisovať iba raz a na jednom mieste. Tento prístup znižuje pravdepodobnosť chýb a desynchronizácií na minimálne hodnoty.
Kam smerujeme? K tomu, že kontejnerizácia databáz je opodstatnená tam, kde existuje skutočná potreba. Nedomnievajte sa, že môžete vložiť databázu plného aplikačného balíka a beháť ju, akoby ste mali dve desiatky mikroservisov — takto to nefunguje. A toto treba jasne pochopiť.
Namiesto výstupu
Ak čakáte jasný záver „virtualizovať alebo nie databázu“, sklameme vás: nebude tu. Pretože pri vytváraní akéhokoľvek infraštruktúrneho riešenia je potrebné riadiť sa nie módou a pokrokom, ale predovšetkým, zdravým rozumom.
Existujú projekty, na ktoré sa princípy a nástroje spojené s Kubernetes hodia perfektne, a v takýchto projektoch nastáva aspoň pokoj v oblasti backendu. A sú projekty, ktorým treba nie kontejnerizáciu, ale normálnu serverovú infraštruktúru, pretože sa zásadne nemôžu preusporiadať na mikroservisný klastrový model, inak zlyhajú.
Zdroj: habr.com
