Valahogy úgy alakult, hogy az IT-ipar bármilyen okból két feltételezett táborra oszlik: akik "érdekeltek" és akik "ellenérdekeltek". Emellett a vitatott téma teljesen véletlenszerű lehet. Melyik operációs rendszer jobb: a Windows vagy a Linux? Android vagy iOS a mobiltelefonon? Mindenadatot felhőben tárolni vagy hideg RAID tárolókra tölteni és a merevlemezeket széfbe tenni? Jogos-e, hogy a PHP fejlesztők programozóknak nevezzék magukat? Ezek a viták időnként kizárólag egzisztenciális jellegűek, és semmilyen más, mint sportérdeklődés alapjuk sincs.
Így történt, hogy a konténerek megjelenésével és e szeretett Docker és a feltételes k8s világával elkezdődtek a viták a "pro" és "kontra" használatáról az új lehetőségekkel kapcsolatban a backend különböző területein. (Előre leszögezzük, hogy bár a gondolatmenetben a Kubernetes lesz megemlítve mint orchestrátor, a választás ennek az eszköznek az alapvető jelentőségű. Bármilyen másik, amit kényelmesebbnek és megszokottabbnak tart, helyettesíthető vele.)
És úgy tűnik, hogy ez egy egyszerű vita lenne a két oldalon egy érmén. Ugyanolyan értelmetlen és kíméletlen, mint a Windows vs Linux örök ellenállása, ahol a normális emberek valahol a közepén léteznek. Csak ezúttal a konténerek esetében nem minden olyan egyszerű. Általában az ilyen vitákban nincs helyes oldal, de az adatbázisok tárolása esetén a "használni" vagy "nem használni" konténerek pedig felfordítják a dolgokat. Mert bizonyos értelemben mind a támogatóik, mind az ellenzékeik igazuk van ennek a megközelítésnek.
A Világos Oldal
A Világos Oldal érvelését röviden egy mondatban lehet összefoglalni: "Helló, 2k19 az ablakon!" Ez hangzik, mint populizmus, kétségtelenül, de ha részletekbe menően megvizsgáljuk a helyzetet, vannak előnyei. Ezeket most részletezzük.
Tegyük fel, hogy van egy nagy webprojekted. Az elején mikroszolgáltatás-alapú megközelítést alkalmaztál, vagy idővel evolúciós úton jutottál el ehhez - ez valójában nem annyira fontos. A projektet különböző mikroszolgáltatásokra osztottad, beállítottad az orkesztrációt, a terheléselosztást és a skálázhatóságot. Most pedig tiszta lelkiismerettel iszogatsz egy mojitót a függőágyban a Habr-effektek alatt, ahelyett, hogy a leállt szervereket állítanád helyre. De minden tevékenységben következetesnek kell lenni. Nagyon gyakran csak magát az alkalmazást - a kódot - konténerizálják. De mit is jelent ez a kód mellett?
Helyesen, az adatok. Bármely projekt szíve az adatok: ezek lehetnek tipikus adatbázisok, mint a MySQL, PostgreSQL, MongoDB, és olyan tárolók, amelyeket keresésre használnak (ElasticSearch), vagy kulcs-érték tárolók a gyorsításhoz - például redis, stb. Nem fogunk most a hibás backend megvalósításokkal foglalkozni, amikor az adatbázis leáll a rosszul megírt lekérdezések miatt, hanem arról beszélünk, hogy hogyan biztosítsuk az adatbázis megbízhatóságát az ügyfél terhelése alatt. Hiszen amikor konténerizáljuk az alkalmazásunkat és lehetővé tesszük, hogy szabadon skálázódjon a bejövő kérések tetszőleges számának kezelésére, az logikusan növeli az adatbázis terhelését.
A gyakorlatban az adatbázis elérési csatornája és az a szerver, amelyen fut, tűvé és cérnává válik a csodálatosan konténerizált backendünkben. Ezt figyelembe véve a konténeres virtualizáció fő motivációja a struktúra mobilitása és rugalmassága, amely lehetővé teszi a csúcs terhelés hatékony elosztását a rendelkezésre álló infrastruktúránkon. Tehát, ha nem konténerizáljuk és nem terítjük szét a rendszer összes elemét klaszterbe - súlyos hibát követünk el.
Sokkal logikusabb klaszterezni nemcsak az alkalmazást, hanem a tárolásért felelős szolgáltatásokat is. A függetlenül működő, terhelést egymás között elosztó webszerverek klaszterezése és telepítésekor a k8s-ben már megoldjuk az adatok szinkronizálásának problémáját – például a bejegyzések hozzászólásait, ha valamilyen médiát vagy blogplatformot említünk. Bármi legyen is, létrejön egy belső klaszteren belüli, még ha virtuális is, DB megjelenés ExternalService-ként. A kérdés az, hogy az adatbázis még nem klaszterezett – a kubikban telepített webszerverek a statikus éles adatbázisunkból, amely külön fut, szerzik be a változásokkal kapcsolatos információkat.
Érzik a cselt? A k8s vagy a Swarm segítségével terhelést osztunk el, hogy elkerüljük a fő rendszer leállását, webszerver, de ezt az adatbázisra nem alkalmazzuk. De hiszen ha az adatbázis leáll, akkor az egész klaszterezett infrastruktúránknak nincs értelme – mit érünk el üres weboldalakkal, amelyek adatbázis-hozzáférési hibát adnak vissza?
Éppen ezért nemcsak a webszervereket kell klaszterezni, ahogy azt általában csinálják, hanem az adatbázis infrastruktúráját is. Csak így tudjuk biztosítani a teljes értékűen működő, de egymástól független struktúrát. Ezen kívül még ha a háttérszerverünk fele le is omlik a terhelés alatt – a maradék túlél, és a klaszteren belüli adatbázisok közötti szinkronizálási lehetőség, valamint az új klaszterek végtelen skálázásának és telepítésének lehetősége gyorsan elérheti a szükséges kapacitásokat – amennyiben vannak rackek az adatközpontban.
Ezen kívül a klaszterezett adatbázis modell lehetővé teszi, hogy az adatbázist oda helyezzük, ahol szükséges; ha globális szolgáltatásról beszélünk, akkor meglehetősen illogikus egy webszervert San Franciscóban futtatni, miközben az adatbázishoz Budapest közeléből és vissza küldünk csomagokat.
A DB konténerizálása szintén lehetővé teszi a rendszer összes elemének egy szinten való abstraktálását. Ami viszont lehetővé teszi, hogy ezt a rendszert közvetlenül a kódból, a fejlesztők által irányítsák, aktív adminisztrátorok bevonása nélkül. A fejlesztőknek eszükbe jutott, hogy szükség van egy külön DB-re az új alprojekthez – egyszerűen írtak egy yaml fájlt, feltöltötték a klaszterbe, és kész.
Természetesen, a belső üzemeltetés drasztikusan egyszerűsödik. Mondja, hányszor zárta be a szemét, amikor az új csapattag keze a működő adatbázisához nyúlt? Amelyik igazából csak egy van, és éppen most forog? Természetesen mindannyian felnőttek vagyunk itt, és van valahol egy friss biztonsági mentésünk, meg egy másik, a nagymama savanyúságai és a régi síléc között - talán egy hidegtárolóban, mert egyszer már égett az irodája. De akkor is, minden új csapattag, aki hozzáfér a működő infrastruktúrához és természetesen a működő adatbázishoz - ez egy vödröt ér a valódolnak mindenki körülötte. Hát ki ismeri azt az újoncot, lehet, hogy ügyetlen? Félelmetes, egyetért?
A konténerizáció és lényegében a projekt adatbázisának elosztott fizikai topológiája segít elkerülni az ilyen valódoli pillanatokat. Nem bízol az újoncban? Oké! Emeljük számára saját klasztert a munkára, és kapcsoljuk le a többi adatbázis klaszterről - a szinkronizálás csak manuális push-al és két kulcs szinkronikus megfordításával zajlik (az egyik a csapatvezetőé, a másik az adminisztrátoré). És mindenki boldog.
Most pedig elérkezett az idő, hogy a klaszterizáció ellenfeleivé váljunk.
Sötét Oldal
Miközben azt vitatjuk, hogy miért nem érdemes konténerizálni az adatbázist és folytatni annak futtatását egy központi szerveren, nem fogunk alámerülni az ortodoxok retorikájába és az olyan kijelentésekbe, mint például: "az öregek gépen futtatták az adatbázisokat, és mi is fogunk!" Inkább próbáljunk meg kitalálni egy helyzetet, ahol a konténerizáció valódi előnyöket hozna.
Elfogadja, hogy azok a projektek, amelyeknek valóban szükségük van konténerizált adatbázisra, egy kéz ujjain meg lehet számolni egy nem túl jó marosító számára. A legtöbb esetben még a k8s vagy a Docker Swarm használata is felesleges - gyakran ezekhez az eszközökhöz a technológiák és a „minden hatalmasként” hasonló beállítások hypesége miatt folyamodnak, hogy mindent felhőkbe és konténerekbe tereljenek. Mert most ez menő, és mindenki ezt csinálja.
A projekt esetében a Kubernetes vagy egyszerűen a Docker használata legalább felében túlzás. A kérdés az, hogy nem minden csapat vagy külsős cég, amelyet a kliens infrastruktúrájának kezelésére fogadtak, tisztában van ezzel. Még rosszabb, amikor a konténereket rákényszerítik, mert ez a kliensnek bizonyos költségekbe kerül.
Valójában elterjedt a vélemény, hogy a Docker/Kubernetes mafia egyszerűen uralja a külsős cégeket, amelyek az infrastruktúrával kapcsolatos kérdéseket kiadnak alvállalkozásba. Hiszen a klaszterek kezeléséhez szükség van olyan mérnökökre, akik ezt képesek megvalósítani és értik az implementált megoldás architektúráját. Már említettük a Republic kiadása kapcsán az esetünket – ott megtanítottuk a kliens csapatát, hogyan dolgozzon a Kubernetes valóságában, és mindenki elégedett volt. Ez rendkívül korrekt volt. Általában azonban a k8s „implementálók” túszként kezelik a kliens infrastruktúráját – hiszen most már csak ők értik, hogyan működik minden, a kliens oldalon pedig nincs szakértő.
Most képzelje el, hogy így nemcsak a webszerver részét bízzuk rá alvállalkozásra, hanem a DB karbantartását is. Már mondtuk, hogy a DB a szív, és a szív elvesztése halálos bármely élő szervezet számára. Röviden, az kilátások nem a legjobbak. Szóval a hype-os Kubernetes helyett sok projektnek egyszerűen nem kellene fukarkodnia egy normális AWS tarifán, ami megoldaná a weboldaluk/projektjük terhelési problémáit. De az AWS már nem divatos, és a fiatalos megjelenés drágább, sajnos az IT szférában is.
Rendben. Lehet, hogy valóban szükség van a klaszterezésre a projekthez, de ha a stateless alkalmazásokkal minden rendben van, hogyan lehet akkor megfelelő hálózati összeköttetést biztosítani a klaszterizált adatbázis számára?
Ha a k8s-re való áttérésről beszélünk, mint zökkenőmentes mérnöki megoldásról, akkor a legnagyobb problémánk az adatok replikálása a klaszterezett adatbázisban. Néhány DBMS kezdetben meglehetősen kedvezően viszonyul az adatok elosztásához a saját példányai között. Sok más viszont nem ilyen megértő. Gyakran a legfőbb érv a DBMS kiválasztásakor nem is az, hogy képes-e minimális erőforrás- és mérnöki költségekkel replikálni. Különösen, ha a projekt eredetileg nem mikroszolgáltatásként indult, hanem egyszerűen csak fejlődött ebbe az irányba.
A hálózati lemezek sebességéről nem szükséges beszélni — lassúak. Vagyis valójában nincs lehetőségünk például egy DBMS példányt más helyre áttelepíteni, ahol nagyobb processzorteljesítmény vagy szabad memóriakapacitás van. Nagyon gyorsan beleütközünk a virtualizált lemezrendszer teljesítményébe. Ennek megfelelően a DBMS-nek szorosan hozzá kell kötődnie a saját, közvetlen közelben lévő gépeinek személyes halmazához. Vagy valahogy külön kell megszervezni egy eléggé gyors adat-szinchronizációt a tervezett tartalékokra.
A virtuális fájlrendszerekkel kapcsolatos téma folytatásaként: a Docker Volumes sajnos nem problémamentes. Általánosságban, egy ilyen hosszú távú megbízható adatmegőrzési megoldás esetén szeretnénk a lehető legkönnyebb technikai sémákkal dolgozni. Az újabb absztrakciós réteg hozzáadása a konténer fájlrendszeréből a szülő gazda fájlrendszerébe már önmagában is kockázatos. De amikor a konténerizációs rendszer működésében problémák merülnek fel az adatok ezen rétegek közötti átvitelével kapcsolatban, akkor komoly gond van. Jelenleg a legtöbb, az emberiség számára ismert problémát látszólag sikerült megoldani. De tudják, minél bonyolultabb a mechanizmus, annál könnyebben törik el.
Mindezek fényében sokkal előnyösebb és egyszerűbb a DB-t egy helyen tartani, és még ha szükség van is az alkalmazás konténerizációjára - hagyja, hogy az önállóan fusson, és egy elosztott átjárón keresztül kapjon párhuzamos kapcsolatot a DB-vel, amely egyszer és egy helyen lesz olvasva és írva. Ez a megközelítés minimálisra csökkenti a hibák és a deszinkronizációk valószínűségét.
Mit is akarunk mondani? Azt, hogy a DB konténerizációja akkor indokolt, ha valóban szükség van rá. Nem lehet egy teljes alkalmazás adatbázisát bedugni és úgy futtatni, mintha húsz mikroszolgáltatás lenne - ez így nem működik. Ezt világosan meg kell érteni.
A kimenet helyett
Ha egyértelmű választ vár a "virtuális adatokhoz való hozzáférésről vagy sem", akkor sajnálattal közlöm: itt nem lesz. Mert bármilyen infrastruktúrával kapcsolatos megoldás létrehozásakor nem a divat és a haladás, hanem elsősorban a józan ész a mérvadó.
Vannak olyan projektek, ahol a Kubernetes-el kapcsolatos alapelvek és eszközök tökéletesen működnek, és ezekben a projektekben béke uralkodik legalább a backend területén. Más projekteknek viszont nem konténerizációra, hanem normális szerverinfrastruktúrára van szükségük, mert alapvetően nem tudnak átkonfigurálódni mikroszolgáltatás-alapú klasztermodellre, különben összeomlanak.
Forrás: habr.com
