Nii on ajalugu näidanud, et IT-sektor jaguneb kaheks laialdaselt eristuvaks leeriks: need, kes on "eest" ja need, kes on "vastu". Vaieldavad teemad võivad olla täiesti meelevaldsed. Milline operatsioonisüsteem on parem: Win või Linux? Kas nutitelefonis peaks olema Android või iOS? Kas hoida kõik pilvedes või salvestada andmed külmadele RAID-põhjakettastele ja panna need seifi? Kas PHP arendajad võivad end programmide väljatöötajateks nimetada? Need vaidlused on mõnikord ülimalt eksistentsiaalsed ega põhine muul kui sportlikul huvil.
Nii juhtus, et selle tõttu, et konteinerite ja meie poolt armastatud docker'i ning tingimusliku k8s'i ilmumisega algasid vaidlused "eest" ja "vastu" nende uute võimaluste kasutamise üle erinevates tagapindades. (Juba ette öeldes, et kuigi enamikult viidatakse selles arutelus orkestratorina Kubernetes'ele, ei ole selle tööriista valik põhimõtteliselt oluline. Selle asemel võib kasutada mõnda muud, mis teile tundub mugavam ja tuttavam.)
Ja, see võiks olla lihtne vaidlus kahe poole vahel, nagu igavene vastasseis Win ja Linux, kus mõistlikud inimesed eksisteerivad kusagil keskel. Kuid konteineriseerimise puhul ei ole kõik nii lihtne. Üldiselt ei ole sellistes vaidlustes õigustatud pooli, kuid küsimuses "rakendada" või "mitte rakendada" andmebaaside konteinerite kasutamist on olukord pea peale pööratud. Sest teatud mõttes on nii pooldajad kui ka vastased sellise lähenemise puhul õiged.
Hea Pool
Hea Pooleti argumendi kokkuvõtteks võib öelda: “Hei, 2k19 on väljas!” See kõlab kindlasti populistlikult, kuid kui situatsiooni süveneda, leidub seal oma eeliseid. Neid uurime nüüd lähemalt.
Kujutage ette, et teil on suur veebiprojekt. See võis algselt rajaneda mikroteenuste lähenemisel või on mingil hetkel sellele evolutsiooniliselt lähenenud — see ei ole tõeliselt oluline. Olete jaganud oma projekti eraldi mikroteenusteks, seadistunud orkestreerimise, koormuse tasakaalustamise ja skaleerimise. Ning nüüd naudite rahulikult mohitosid hamakis, samal ajal kui kaotate servereid. Kuid kõigis tegudes tuleks järgida järjepidevust. Sageli konteineriseeritakse vaid rakendus ise — kood. Aga mis meil veel on peale koodi?
Õige, andmed. Iga projekti süda on selle andmed: see võib olla nii tüüpiline andmebaas nagu MySQL, Postgre, MongoDB, kui ka otsinguks kasutatavad salvestusruumid (ElasticSearch), key-value salvestusruumid vahemäluks — näiteks Redis ja nii edasi. Täna ei räägi me kehvadest back-end'i rakendamise variantidest, kui andmebaas kukub halvasti kirjutatud päringute tõttu, vaid keskendume selle andmebaasi veakindluse tagamisele kliendi koormuse all. Kui konteineriseerime meie rakenduse ja võimaldame sellel vabalt skaleeruda igasuguste sissetulevate päringute töötlemiseks, suurendab see loomulikult ka andmebaasi koormust.
Tegelikult muutuvad andmebaasi juurdepääsu kanal ja server, millel see töötab, meie toreda konteineriseeritud tagaplaanis kitsaskohaks. Sellegipoolest on konteinerite virtualiseerimise peamine motiiv struktuuri liikuvus ja paindlikkus, mis võimaldavad maksimaalselt tõhusalt korraldada tippkoormuse jaotust kogu meie kergesti kätte saadavas infrastruktuuris. Teisisõnu, kui me ei konteineriseeri ja ei laota kogu süsteemi elemente klastrisse — teeme me väga tõsise vea.
On palju mõistlikum klasterdada mitte ainult rakendus, vaid ka teenused, mis vastutavad andmete salvestamise eest. Klasterdamisel ja iseseisvalt töötavate ning koormust omavahel jaotavate veebiserverite juurutamisel k8s, lahendame me juba andmete sünkroniseerimise probleemi — näiteks postituste kommentaarid, kui tuua näiteks mõni meedia või blogiplatvorm. Meil mõlemal juhul moodustatakse klastrisisene, isegi kui virtuaalne, andmebaasi esitus kui ExternalService. Küsimus on selles, et andmebaas ise ei ole veel klasterdatud — kubernetes'is juurutatud veebiserverid võtavad üle teabe muudatustest meie staatilisest tootmisbaasist, mis töötab eraldi.
Kas tunnete petuskeemi? Me kasutame k8s-i või Swarmi, et jaotada koormust ja vältida peamise süsteemi kokkuvarisemist, veebiserver, kuid me ei tee seda andmebaasi jaoks. Kui andmebaas kukub, siis ei ole meie klasterdatud infrastruktuuris mitte mingit mõtet — mis kasu on tühjadest veebilehtedest, mis tagastavad andmebaasi juurdepääsivea?
Seetõttu ei ole klustereerimine vajalik ainult veebiserverite, nagu tavaliselt tehakse, vaid ka andmebaasi infrastruktuuri jaoks. Ainult nii saame tagada, et üks üksteisest sõltumatu struktuur töötab samaaegselt ühes rakenduses. Isegi kui meie tagaplaneerimise pool koormuse all „kukub”, jääb ülejäänud tööle, ning andmebaasi sünkroonimise süsteem klusteri sees ning võimalus lõpmatuks laiendamiseks ja uute klustersüsteemide arendamiseks aitavad kiiresti saavutada vajalikke võimsusi — olgu see siis andmekeskuses asuvate riiulite olemasolu.
Lisaks võimaldab klustrites jaotatud andmebaasimudel viia andmebaasi sinna, kus see on vajalik; kui räägime globaalsest teenusest, on üsna mõttetu jooksutada veebiklustreid kuskil San Franciscos, samal ajal kui andmebaasi päringute pakette saadetakse Moskva oblastisse ja tagasi.
Samuti võimaldab andmebaasi konteineriseerimine kõiki süsteemi elemente ühel abstraktsiooni tasemel üles ehitada. See omakorda teeb võimalikuks selle süsteemi juhtimise otse koodist, arendajate poolt, ilma adminnide aktiivse kaasamiseta. Arendajatel tuli mõte, et uue alaprojekti jaoks on vaja eraldi andmebaasi — lihtne! kirjutasid yaml-faili, laadisid klastrisse ja valmis.
Ja loomulikult lihtsustab see sisemist kasutust kordades. Ütelge, kui tihti te olete silmad kinni pigistanud hetked, kui uus meeskonna liige ulatas käed tootmisesse andmebaasi? Mis teil, tegelikult, on üks ja just praegu töötab? Loomulikult, kõik me oleme siin täiskasvanud inimesed ja meil on kuskil värske varukoopia ning veel kaugemal — kapis vanaema hapukurki ja vanade suuskade taga — veel üks varukoopia, võib-olla isegi külmas säilitamises, sest korra juba teie kontor põles. Kuid igal juhul, iga uue meeskonna liikme, kes pääseb tootmisinfrastruktuurile ja loomulikult tootmisandmebaasile, sisseviimine on kõigile ümbritsevatele nagu liitrine ärevusevaigistaja. No kes teda, algajat, teab, võib-olla on ta kohmakas? Hirmus, nõustute.
Konteinerimine ja sisuliselt teie projekti andmebaasi jaotatud füüsiline topoloogia aitab selliseid probleemseid hetki vältida. Kas te ei usalda algajat? Pole probleemi! Loome talle eraldi klastrite arendamiseks ja eemaldame ta ülejäänud andmebaasi klastritest — sünkroonimine toimub ainult käsitsi tõukamise ja kahe võtme (üks meeskonnaliidrile, teine administraatorile) sünkroonse pööramise kaudu. Ja kõik on õnnelikud.
Nüüd on aeg muutuda andmebaasi klasterdamise vastasteks.
Tumedam Pool
Arutledes, miks ei tohiks andmebaasi konteinerisse panna ja jätkata selle pööramist ühel kesksel serveril, ei lasku me ortodokside retoorikasse ja väidetele nagu "vana kool pööras andmebaasi riistvaral, nii teeme ka meie!" Selle asemel proovime välja mõelda olukorra, kus konteinerimine tõeliselt toob märgatavaid eeliseid.
Leppavad kokku, et projekte, mis tõeliselt vajavad konteineri baasi, saab üles lugeda ühe keskpärase treimise meistri sõrmedel. Enamasti on isegi k8s või Docker Swarmi kasutamine liialdatud — tihti kasutatakse neid tööriistu lihtsalt tehnoloogia ja „jumalate” surve tõttu, et kõik pilve ja konteineritesse suruda. Lihtsalt, sest see on moes ja kõik teevad seda.
Minimaalselt pooled juhtudest on kubernetese või lihtsalt dockeri kasutamine projektis liialdatud. Küsimus on selles, et mitte kõik meeskonnad või välismaised ettevõtted, kes on palgatud kliendi infrastruktuuri haldamiseks, ei teadvusta seda. Hullem on see, kui konteinerid suruvad peale, sest see tõmbab kliendile teatud summa münte.
Üldiselt arvavad paljud, et Docker/Kubernetes lihtsalt haarab kliente, kes on valmis oma infrastruktuuri küsimused outsourcima. Klastritega töötamiseks on vaja insenere, kellel on oskused ja kes mõistavad rakendatud lahenduse arhitektuuri. Oleme juba kirjeldanud meie juhtumit väljaande Republiciga — seal õpetasime kliendi meeskonda Kubernetesega töötama ja kõik jäi rahule. See oli tõeliselt suurepärane. Sageli aga võtavad k8s „rakendajad” kliendi infrastruktuuri pantvangi — kuna nüüd mõistavad vaid nemad, kuidas seal kõik toimib, ei ole kliendi poolel spetsialiste.
Ja nüüd kujutage ette, et anname outsourcisse mitte ainult veebiserveri osa, vaid ka andmebaasi haldamise. Oleme öelnud, et andmebaas on süda, ja südame kaotus on surmav iga elusorganismi jaoks. Ühesõnaga, perspektiivid ei ole just parimad. Seega, selle asemel et keskenduda hype’ile Kubernetesel, peaksid paljud projektid lihtsalt olema valmis maksma normaalse hinnaga AWS-i eest, mis lahendab kõik nende saidi/projekti koormuse probleemid. Kuid AWS ei ole enam moes, ja kahjuks ka IT-valdkonnas on uhkus kallim kui raha.
Olgu. Võib-olla on klasterdamine projektile tõepoolest vajalik, kuid kui stateless-rakendustega on kõik selge, siis kuidas korraldada väärikat võrguühenduse tagamist klasterdatud andmebaasi jaoks?
Kui räägime sujuvast insenerilahendusest, mis näitab, kuidas liikuda k8s-is, siis meie peamine peavalu on andmete replikatsioon klasterdatud andmebaasis. Mõned andmebaasisüsteemid on algselt üsna toetavad andmete jaotamisel oma erinevate eksemplaride vahel. Paljud teised seevastu ei ole nii sõbralikud. Ja sageli ei ole peamine argument andmebaasisüsteemi valimisel meie projekti jaoks sugugi see, kas see suudab replikatsiooni teostada minimaalse ressursside ja inseneritegevuse kulu juures. Eriti kui projekt ei olnud algselt plaanitud mikroteenustena, vaid lihtsalt arenes selliseks.
Ei ole mingit vajadust rääkida võrguketaste töökiirusest – need on aeglased. See tähendab, et meil pole tõelist võimalust, vajadusel, käivitada andmebaasi eksemplar kohas, kus on rohkem näiteks protsessorivõimsust või vaba RAM-i. Me jõuame kiiresti virtuaalsete kettasüsteemide tootlikkuse piiri. Seega peab andmebaas olema kindlalt seotud omaenda isikliku masinakomplektiga, mis asub läheduses. Vastasel juhul tuleb leida piisavalt kiire andmete sünkroniseerimine eeldatavatele varukohtadele.
Jätkates virtuaalsete failisüsteemide teemat: Docker volumes ei ole paraku probleemivabad. Üldiselt soovitakse andmete pikaajalise usaldusväärse säilitamise puhul kasutada maksimaalselt lihtsaid tehnilisi skeeme. Uue abstraktsioonikihi lisamine konteineri failisüsteemist põhihosti failisüsteemi — see on juba iseenesest risk. Kuid kui töö ajal tekivad konteineriteenuse süsteemis probleeme andmete edastamisega nende kihtide vahel, on olukord veelgi keerulisem. Praegu tundub, et enamik tuntud ja progressiivse inimkonna probleeme on elimineeritud. Kuid nagu te mõistate, mida keerulisem on mehhanism, seda lihtsam on selle purunemine.
Kuna kõik need 'seiklused' on aset leidnud, on palju kasulikum ja lihtsam hoida andmebaasi ühes kohas. Ja isegi kui vajate rakenduse konteinerimist — las see töötab iseseisvalt ja saadab jagamisliidese kaudu samal ajal ühendust andmebaasiga, kuhu tuleb andmeid lugeda ja kirjutada vaid üks kord ja ühes kohas. See lähenemine vähendab vigade ja desünkroniseerimise tõenäosust minimumini.
Mille, kuhu me suundume? Me suundume sinna, et andmebaasi konteineriseerimine on asjakohane seal, kus selleks on tõeline vajadus. Ei saa lihtsalt panna täisrakenduse andmebaasi konteinerisse ja käitada seda nii, nagu teil oleks kaks tosinat mikroteenust — see nii ei tööta. Seda tuleb selgelt mõista.
Väljundi asemel
Kui ootad selget vastust «kas virtualiseerida andmebaas või mitte», siis peame pettuma: sellist vastust siin ei ole. Sest igasuguste infrastruktuuri lahenduste loomisel tuleb juhinduda mitte moest ja edusammudest, vaid eelkõige terve mõistuse järgi.
On projekte, kuhu kuberneetiliste põhimõtted ja tööriistad sobivad ideaalselt, ja sellistes projektides saavutatakse vähemalt tagakihi valdkonnas rahu. Kuid on ka projekte, millele ei sobi konteineriseerimine, vaid normaalne serveri infrastruktuur, sest nad ei saa põhimõtteliselt ümber struktureeruda mikroteenuste klastrimudeliks, muidu kukuvad nad kokku.
Allikas: habr.com
