Historicky se ukázalo, že IT průmysl se při každé příležitosti dělí na dva zcela podmíněné tábory: ty, které „za“ a ty, které „proti“. Předmětem sporů přitom mohou být zcela náhodné záležitosti. Který operační systém je lepší: Windows nebo Linux? Chcete mít smartphone s Androidem nebo iOS? Uchovávat vše v cloudu, nebo ukládat na studené RAID úložiště a dávat disky do trezoru? Mají PHP vývojáři právo nazývat se programátory? Tyto spory mají občas ryze existenční charakter a nemají žádný jiný základ než sportovní zájem.
Jak se ukázalo, s nástupem kontejnerů a celé této naší oblíbené kuchyně s Dockerem a hypotetickým Kubernetes začaly také spory „za“ a „proti“ použití nových možností v různých oblastech backendu. (Omlouváme se předem, že v této úvaze bude jako orchestrátor často uváděno Kubernetes, volba právě tohoto nástroje však nemá zásadní význam. Můžete místo něj použít jakýkoli jiný, který vám připadá nejpohodlnější a nejznámější.)
A zdálo by se, že by to byl jednoduchý spor mezi dvěma stranami jedné mince. Stejně bezvýznamný a krutý, jako věčné nepřátelství Windows vs Linux, kde rozumní lidé celkem normálně existují někde uprostřed. Jenže v případě kontejnerizace to není tak jednoduché. Obvykle v takových sporech neexistuje pravá strana, ale když přijde na „používat“ nebo „nepoužívat“ kontejnery pro ukládání databází, všechno se obrátí naruby. Protože v určitém smyslu mají pravdu jak zastánci, tak odpůrci tohoto přístupu.
Světlá Strana
Stručně řečeno, argumentaci Světlé Strany lze shrnout jednou větou: “Halo, 2k19 za oknem!” Zní to jako populismus, bezpochyby, ale pokud se podíváte na situaci podrobně, mají své výhody. Ty si nyní rozebereme.
Představte si, že máte velký webový projekt. Mohl být od začátku založen na mikroslužbách, nebo k nim mohl dospět evolučně v určitém okamžiku — to ve skutečnosti není až tak důležité. Rozložili jste projekt do samostatných mikroslužeb, nastavili orchestraci, vyvažování zátěže, škálování. A nyní s čistým svědomím popíjíte mohito v houpací síti během efekty Habr, místo abyste se zabývali pády serverů. Ale ve všem je třeba být důsledný. Velmi často je kontejnerizována pouze samotná aplikace — kód. A co ještě máme kromě kódu?
Správně, data. Srdcem každého projektu jsou jeho data: může to být běžná databáze — MySQL, Postgre, MongoDB, nebo úložiště pro vyhledávání (ElasticSearch), key-value úložiště pro caching — například redis atd. Nyní nebudeme mluvit o křivých variantách implementace backendu, kdy dochází k selhání databáze kvůli špatně napsaným dotazům, ale místo toho budeme hovořit o zajištění odolnosti této databáze vůči zatížení ze strany klienta. Když kontejnerizujeme naši aplikaci a dovolíme jí volně škálovat tak, aby zvládla libovolné množství příchozích požadavků, zákonitě to zvyšuje také zátěž na databázi.
Fakticky se kanál pro přístup k databázi a server, na kterém běží, stávají úzkým hrdlem v našem krásném kontejnerizovaném backendu. Hlavním motivem kontejnerové virtualizace je totiž pohyblivost a plasticita struktury, které umožňují maximálně efektivně organizovat rozložení špičkových zátěží po celé dostupné infrastruktuře. To znamená, že pokud nekontejnerizujeme a nerozložíme do clusteru všechny existující prvky systému — děláme velkou chybu.
Je mnohem logičtější klastrovat nejen samotnou aplikaci, ale také služby odpovědné za ukládání dat. Při klastrování a nasazování nezávisle pracujících a zatížení mezi sebou rozdělujících webových serverů v k8s již řešíme problém synchronizace dat — například komentářů k příspěvkům, pokud uvádíme příklad nějakých médií nebo blogovacích platforem. U nás se v každém případě vytváří intraklastrové, i když virtuální, zobrazení DB jako ExternalService. Otázka je, že samotná DB zatím není klastrována — nasazené webové servery v kubu získávají informace o změnách z naší statické bojové databáze, která běží samostatně.
Cítíte úskok? Používáme k8s nebo Swarm k rozložení zátěže a vyhnutí se pádu hlavního systému, webového serveru, ale neděláme to pro DB. Ale pokud spadne DB, tak v naší klastrové infrastruktuře není žádný smysl — jaký to má význam pro prázdné webové stránky, které vracejí chybu přístupu k databázi?
Právě proto je potřeba klastrovat nejen webové servery, jak se obvykle dělá, ale také infrastrukturu databáze. Jen tak můžeme zajistit plně funkční, ale přitom nezávislou strukturu. A i když nám „spadne“ polovina našeho backendu pod zátěží — zbytek přežije, a systém synchronizace DB mezi sebou v rámci klastru a možnost nekonečné škálovatelnosti a nasazování nových klastrů pomůže rychle dosáhnout potřebného výkonu — stačí mít stojany v datovém centru.
Kromě toho distribuovaný klastrový model DB umožňuje přenášet tuto samotnou DB tam, kde je potřeba; pokud hovoříme o globální službě, je poněkud nelogické provozovat webový klastr někde v oblasti San Francisca a zároveň směrovat pakety při dotazech na databázi do Moskevské oblasti a zpět.
Také kontejnerizace DB umožňuje vytvořit všechny prvky systému na jedné úrovni abstrakce. Což zase umožňuje spravovat tento systém přímo z kódu, vývojáři, bez aktivního zapojení administrátorů. Napadlo vývojáře, že potřebují samostatnou SŘBD pro nový dílčí projekt — snadno! napsali yaml soubor, nahráli do klastru a hotovo.
A samozřejmě, interní provoz se několikanásobně zjednodušuje. Řekněte nám, kolikrát jste přivřeli oči v momentech, kdy nový člen týmu sáhnul do provozní DB? Která je, prakticky, jediná a právě teď běží? Samozřejmě, všichni jsme dospělí lidé a někde máme čerstvou zálohu, a ještě dál — za policí s babiččinými okurkami a starými lyžemi — ještě jednu zálohu, možná dokonce na studeném úložišti, protože jednou už vaše kancelář hořela. Ale stále, každé přijetí nového člena týmu, který má přístup k provozní infrastruktuře a samozřejmě k provozní databázi — to je kbelík validolu pro všechny kolem. Kdo ví, co ten nováček umí, možná je nešika? Děsivé, souhlasíte?
Kontejnerizace a v podstatě distribuovaná fyzická topologie DB vašeho projektu pomáhá vyhnout se podobným validolovým momentům. Nedůvěřujete nováčkovi? Dobře! Založíme mu vlastní klastr pro práci a odpojíme od ostatních klastra DB — synchronizace pouze ručním pushem a synchronním otočením dvou klíčů (jediný pro týmového vedoucího, druhý pro administrátora). A všichni jsou šťastní.
A nyní nastal čas obrátit se proti klasterizaci DB.
Temná strana
Rozvažujme, proč kontejnerizovat databázi a pokračovat ve běhu na jednom centrálním serveru, nepůjdem tak daleko, abychom se uchýlili k rétorice ortodoxních a tvrzení typu „dědové běželi DB na železe, a my budeme!” Místo toho se pokusme vymyslet situaci, ve které by kontejnerizace skutečně přinášela hmatatelné dividendy.
Souhlasíte, že projekty, které skutečně potřebují databázi v kontejneru, je možné spočítat na prstech jedné ruky ne moc dobrého frézaře. V drtivé většině případů je i samotné použití k8s nebo Docker Swarm nadbytečné — velmi často se tyto nástroje používají kvůli obecnému hype a pokynům „všemohoucích” v podobě manažerů natlačit všechno do oblak a kontejnerů. No, protože teď je to moderní a všichni to dělají.
V polovině případů je používání Kubernetes nebo pouze Dockeru v projektu nadbytečné. Otázkou je, že ne všechny týmy nebo outsourcingové společnosti najaté k obsluze klientské infrastruktury si toho jsou vědomy. Horší je, když jsou kontejnery vnucovány, protože to klientovi přináší určité výdaje.
Obecně panuje názor, že Docker/K8s mafie jednoduše podmanila klienty, kteří delegují tyto infrastrukturní záležitosti na outsourcing. Aby bylo možné pracovat s clustery, potřebujete inženýry, kteří mají schopnosti a porozumění pro architekturu implementovaného řešení. Už jsme popisovali náš případ s vydáním Republic — tam jsme školili tým klienta, jak pracovat v podmínkách Kubernetes, a všichni byli spokojeni. A to bylo fair. Často však ‚implementátoři‘ K8s berou klientskou infrastrukturu jako rukojmí — nyní pouze oni chápou, jak vše funguje, a na straně klienta specialisté chybí.
A teď si představte, že takovým způsobem předáváme nejen webovou serverovou část na pospas outsourcingu, ale také správu databází. Říkali jsme, že databáze je srdcem, a ztráta srdce je fatální pro jakýkoli živý organismus. Zkrátka, vyhlídky nejsou nejlepších. Místo hypovaného Kubernetes by mnoha projektům stačilo nešetřit na normální tarifu na AWS, který by vyřešil všechny problémy s náročností na jejich web/projekt. Ale AWS už není trendy, a prázdné znaky jsou dražší než peníze — bohužel, i v IT prostředí.
Okej. Možná clustering projektu skutečně potřebuje, ale pokud už je s stateless aplikacemi vše jasné, jak potom zajistit kvalitní síťovou konektivitu pro klastry databází?
Pokud mluvíme o bezproblémovém inženýrském řešení, kterým je přechod na k8s, naše hlavní starost spočívá v replikaci dat v clusterované databázi. Některé DBMS od začátku tolerují rozdělení dat mezi jednotlivými instancemi. Mnohé jiné však tolik nepřejí. A často se rozhodujícím argumentem pro výběr DBMS pro náš projekt stává zdaleka ne schopnost replikace s minimálními nároky na zdroje a inženýrské náklady. Zvlášť pokud projekt nebyl původně plánován jako mikroslužbový a jednoduše se vyvinul tímto směrem.
O rychlosti provozu síťových disků asi není třeba říkat, že jsou pomalé. Tzn. reálnou možnost přenastavit instanci DBMS někde, kde jsou například větší procesorové možnosti nebo dostupná operační paměť, stejně nemáme. Velmi brzy narazíme na výkon virtualizované diskové subsystémy. Odpovídajícím způsobem musí být DBMS připevněna ke svému vlastnímu osobnímu souboru strojů, které se nacházejí v bezprostřední blízkosti. Nebo musíme nějakým způsobem vytvořit dostatečně rychlou synchronizaci dat na předpokládané rezervy.
Pokud jde o téma virtuálních FS: Docker Volumes bohužel nejsou bezproblémové. Obecně, při dlouhodobém spolehlivém ukládání dat bychom chtěli používat maximálně jednoduché technické schémata. A přidání nového abstrahovaného vrstvy z FS kontejneru do FS hostitelského systému je už samo o sobě riziko. Ale když i během práce systému kontejnerizace vznikají potíže s přenosem dat mezi těmito vrstvami, pak je to opravdu velký problém. V současnosti je většina známých problémů, které lidstvu trápily, zdá se, vyřešená. Ale rozumíte, čím složitější mechanismus, tím snáze se porouchá.
Vzhledem ke všem těmto „dobrodružstvím“ je mnohem výhodnější a jednodušší mít databázi na jednom místě, a i když potřebujete kontejnerizaci aplikace — ať si běží sama a přes distribuční bránu zabezpečuje současné spojení s databází, která bude čtena a zapisována pouze jednou a na jednom místě. Tento přístup snižuje pravděpodobnost chyb a nesynchronizací na minimální úroveň.
Kam tím míříme? K tomu, že kontejnerizace databáze má smysl tam, kde je skutečně potřebná. Nelze narvat databázi plného aplikačního balíčku a provozovat ji tak, jako byste měli dvě desítky mikroslužeb — tak to nefunguje. Je důležité to jasně chápat.
Namísto výstupu
Pokud očekáváte jasný závěr „virtualizovat nebo ne databázi“, pak vás zklameme: takový závěr zde nebude. Protože při vytváření jakéhokoli infrastrukturního řešení je třeba řídit se nikoli módou a pokrokem, ale především zdravým rozumem.
Existují projekty, na které principy a nástroje spojené s Kubernetes dokonale sedí, a v takových projektech nastává klid alespoň v oblasti backendu. A jsou projekty, které nepotřebují kontejnerizaci, ale normální serverovou infrastrukturu, protože nemohou principálně škálovat pod mikroslužebný clusterový model, jinak by zkolabovaly.
Zdroj: habr.com
