Elavad andmebaasid Kuberneteses?

Ajalooliselt on IT-tööstus jagunenud kaheks tinglikuks leeriks: need, kes on "pool" ja need, kes on "vastu". Ja teemad, mille üle vaieldakse, võivad olla täiesti ettearvamatud. Milline operatsioonisüsteem on parem: Win või Linux? Kas nutitelefon peab olema Android või iOS? Kas hoida kõik pilves või laadida need külmade RAID-hoidlatele ja panna kõvakettad seifi? Kas PHP arendajad võivad end programmeerijateks nimetada? Need vaidlused on mõnikord rangelt eksistentsiaalsed ja neil ei ole mingit muud, peale spordihuvitava, alust.

Nii ongi juhtunud, et koos konteinerite tekkimisega ja kogu selle armastatud Docker'i ja jätkuva k8s'iga, algasid vaidlused "poolte" ja "vastu" uute võimaluste kasutamise üle erinevates tagaridade valdkondades. (Enne algust tasub mainida, et kuigi antud arutelus kasutatakse orkestrimise tööriistana sageli Kubernetes, ei ole selle tööriista valik põhimõtteliselt oluline. Selle asemel võib kasutada mis tahes muud, mis tundub teile kõige mugavam ja tuttavam.)

Ja tundub, et see oleks lihtsalt vaidlus kahe poole vahel nagu kahepoolne münt. Niisama mõttetu ja halastamatu, nagu igavene vastasseis Win vs Linux, kus adekvaatsed inimesed eksisteerivad kuskil keskel. Kuid konteineriseerimise osas ei ole kõik nii lihtne. Tavalistes vaidlustes ei ole enamasti õigustavat poolt, kuid seisukohal "kas rakendada" või "mitte rakendada" konteinerid andmebaaside hoidmiseks pööratakse kõik tagurpidi. Sest teatud mõttes on nii pooldajad kui ka vastased selle lähenemise suhtes õiged.

Hea Pool

Hea Poole argumendi lühike kirjeldamine võib mahtuda ühte lausesse: “Halloo, 2k19 on möödas!” See kõlab kahtlemata populistlikuna, kuid kui olukorraga põhjalikult tutvuda, siis seal on oma eelised. Nüüd vaatame neid lähemalt.

Oletame, et sul on suur veebiprojekt. See võis algselt olla rajatud mikroteenuste lähenemisel või jõuda selleni evolutsioonilise tee kaudu – see pole tegelikult oluline. Sa jagasid oma projekti eraldi mikroteenusteks, seadistasid orkestreerimise, koormuse jaotamise, skaleeritavuse. Ja nüüd naudid rahuliku südamega mähkides maltet, mitte ei tõsta maha kukkunud servereid. Kuid kõigis tegudes tuleb olla järjepidev. Väga sageli konteineriseeritakse ainult rakendus ise – kood. Mis meil veel koodi kõrval on?

Õige, andmed. Iga projekti süda on selle andmed: need võivad olla nagu tüüpiline andmebaasisüsteem – MySQL, Postgre, MongoDB, samuti ladustamislahendused, mida kasutatakse otsinguks (ElasticSearch), key-value ladustamislahendused vahemäluks – näiteks Redis jne. Praegu ei hakka me rääkima kummalistest tagasiside lahendustest, kus andmebaas kukub alla halvasti kirjutatud päringute tõttu, vaid räägime sellest, kuidas tagada selle andmebaasi töökindlus kliendi koormuse all. Sest kui me konteineriseerime oma rakenduse ja lubame sellel vabalt skaleeruda, et töödelda mis tahes arvu sisendeid, suureneb paratamatult ka koormus andmebaasile.

Tegelikult muutuvad andmebaasi ja serveri, kus see töötab, ühenduspunktiks kitsaskoha meie kaunis konteineriseeritud tagaplaanis. Samal ajal on konteinerite virtualiseerimise põhieesmärk ülesehituse liikuvus ja paindlikkus, mis võimaldavad koormuse jaotamist meie kogu kergesti kätte saadavas infrastruktuuris maksimaalselt efektiivselt. See tähendab, et kui me ei konteineriseeri ja ei laota kõiki süsteemi komponente klastrisse – teeme me väga tõsise vea.

On logiilisem klasterdada mitte ainult rakendust, vaid ka teenuseid, mis vastutavad andmete salvestamise eest. Klasterdamisel ja iseseisvalt töötavate veebiserverite juurutamisel k8s-is lahendame me juba andmete sünkroonimise probleemi — näiteks kommentaaride postitustele, kui tuua näitena mõni meedia või blogiplatvorm. Meil on igal juhul loodud siseklaster, olgu see isegi virtuaalne, andmebaasi kujutis kui ExternalService. Küsimus on selles, et ise andmebaas ei ole hetkel klasterdatud — kubises juurutatud veebiserverid võtavad teavet muudatuste kohta meie staatilisest tootmisandmebaasist, mis töötab eraldi.

Kas tunnetad ohtu? Me kasutame k8s-i või Swarm'i koormuse jaotamiseks ning peamise langemise vältimiseks, veebiserver, kuid me ei tee seda andmebaasi jaoks. Kuid kui andmebaas kukub, siis pole meie klasterdatud infrastruktuuri mõtet - mis kasu on meil tühi veebileht, mis tagastab andmebaasi juurdepääsuviga?

Seetõttu tuleb klasterdada mitte ainult veebiserverid, nagu tavaliselt tehakse, vaid ka andmebaasi infrastruktuur. Ainult sel viisil saame tagada, et kõik funktsioneerib ühes paaris, kuid omavahel iseseisvana. Ja isegi kui meie tagaplaanist poole koormusega «kukub», jääb ülejäänud ellu ning andmebaaside sünkroonimise süsteem klastris ja lõpmatu skaleerimise ja uute klastrite juurutamise võimalus aitab kiiresti saavutada nõutavad võimed - olgu andmehoidlatele andmekeskuses.

Lisaks võimaldab klasterdatud andmebaasimudel viia andmebaasi sinna, kus seda on vajalik; kui me räägime globaalset teenusest, on üsna ebaotstarbekas hoida veebiklaster kusagil San Franciscos ja samal ajal saata paketid andmebaasi poole Moskvas ja tagasi.

Samuti võimaldab andmebaasi konteinerimine tõsta kõik süsteemi elemendid ühele abstraktsioonitasemele. See omakorda võimaldab arendajatel seda süsteemi otse koodist hallata, ilma et oleks vaja aktiivset administraatorite kaasamist. Arendajatel tuli mõte, et uut ala projekti jaoks on vaja eraldi andmebaasi - kergesti! Kirjutasid yaml-faili, laadisid selle klastrisse ja valmis.

Ja loomulikult, sisemine haldamine lihtsustub mitmekordseks. Öelge, kui sageli olete silmad kinni pigistanud hetkel, kui uus meeskonnaliige ulatab käed tootmisandmebaasi? Mis teil, tõeliselt, on olemas ja millega te praegu töötate? Loomulikult, me kõik oleme täiskasvanud inimesed ja kuskil on meil värske varukoopia, ning veel kaugemal — vanade kurkide ja suuskade taga — veel üks varukoopia, võib-olla isegi külmhoidlas, sest teie kontor on juba kord põlenud. Kuid ikkagi, iga uue meeskonnaliikme liitumine, kes pääseb tootmisinfrastruktuuri ja loomulikult tootmisandmebaasi — see on kõikidele ümbritsevatele üks suur rahustav tablett. Kes teab seda uuest tulijat? Võib-olla on ta oskamatu? See on hirmutav, nõustute.

Konteineriseerimine ja sisuliselt teie projekti andmebaasi jaotatud füüsiline topoloogia aitab selliseid rahustavaid olukordi vältida. Ei usalda uut töötajat? Pole probleemi! Loome talle iseseisva klastritööstuse ja lahutame selle ülejäänud andmebaasiklasteritest — sünkroniseerimine ainult käsitsi edastamise ja kahe võtme sünkroonse pööramise kaudu (üks tiimijuhile, teine administraatorile). Ja kõik on õnnelikud.

Ja nüüd on aeg astuda vastu andmebaasi klasteriseerimise vastastele.

Tume Pool

Mõeldes, miks ei peaks andmebaasi konteineriseerima ja seda ühel kesksel seadmel tööle panema, serveris, ei lasku me ortodokside retoorikasse ja väidete tasemeni, nagu „vanaemad töötasid andmebaasidega rauast, ja me teeme ka!” Selle asemel proovime arendada olukorda, kus konteineriseerimine tõeliselt toob kaubal tugevat kasu.

Nõustute, et projekte, mis tõeliselt vajavad andmebaasi konteineris, saab lugeda ühe halvima freesija sõrmedel. Enamikul juhtudel on lausa k8s või Docker Swarmi kasutamine liig, kuna neid tööriistu kasutatakse üsna sageli ainult tehnoloogia ja seadmete „kõrgemate” soovituste tõttu, et kõik viia pilve ja konteineritesse. Noh, kuna see on praegu moes ja kõik teevad seda.

Poolha arvavad, et Kubernetes või Docker kasutamine projektis on enamasti üleliigne. Küsimus on selles, et mitte kõik meeskonnad või infrastruktuuri hooldamiseks palgatud välisfirmad ei teadvusta seda. Halvem on see, kui konteinerid on sunnitud kasutusele, kuna see toob kliendile kaasa teatud kulud.

Üldiselt levinud arvamus on, et Docker/K8s mafias lihtsalt allutab endale kliente, kes usaldavad need infrastruktuuri küsimused välismaistele teenusepakkujatele. Lõppude lõpuks, klastritega töötamiseks on vaja insenere, kes suudavad seda teha ja kes üldse mõistavad rakendatud lahenduse arhitektuuri. Oleme juba kirjeldanud oma juhtumit väljaande Republiciga — seal koolitasime kliendi meeskonda töötama Kubernetesese tingimustes, ja kõik jäid rahule. See oli korralik. Kuid tihti võtavad „rakendajad“ K8s-i kliendi infrastruktuuri pantvangi — sest nüüd mõistavad seda ainult nemad, kliendi poolel spetsialiste pole.

Ja nüüd kujutage ette, et sel viisil anname mitte ainult veebiserveri osa väliseks teenuseks, vaid ka andmebaasi hoolduse. Oleme öelnud, et andmebaas on süda ja südame kaotus on fataalne igasuguste elusolendite jaoks. Ühesõnaga, perspektiivid pole kõige paremad. Seega, hype'liku Kubernetes'e asemel peaks paljusid projekte lihtsalt mitte kokku hoidma normaalse AWS-i hinnataseme pealt, mis lahendab kõik nende veebisaidi/projekti koormusprobleemid. Kuid AWS ei ole enam moes, ja uhkus maksab rohkem kui raha — kahjuks ka IT-valdkonnas.

Okei. Võib-olla on projekti jaoks klasterdamine tõeliselt vajalik, kuid kui stateless-rakendustega on kõik selge, siis kuidas korraldada korralikku võrgukonne klasterdatud andmebaasi jaoks?

Kui me räägime sujuvast insenerlahendusest, millega kaasneb üleminek k8s-ile, siis peamine mure on andmete replikatsioon klasterdatud andmebaasis. Mõned andmebaasid suhtuvad algselt suhteliselt leebelt andmete jaotamisse oma individuaalsete instantside vahel. Paljud teised ei ole siiski nii lahked. Ja üsna sageli ei ole peamine argument andmebaasi valikul meie projekti jaoks sugugi mitte suutlikkus replitseerida minimaalseid ressursi- ja insenerikulusid. Eriti kui projekt ei olnud algselt mõeldud mikroteenustena, vaid arenes lihtsalt sinna suunas.

Arvatavasti ei ole vaja rääkida võrgudiskide töökiirusest — need on aeglased. See tähendab, et meil ei ole reaalset võimalust, kui midagi juhtub, tuua andmebaasi instants kuskile, kus on rohkem näiteks protsessori võimekust või vaba operatiivmälu. Me jõuame väga kiiresti virtuaalsete distsipliinide tootlikkuse piiridesse. Seega peab andmebaas olema seotud oma isikliku masina komplektiga, mis asub otseses läheduses. Või tuleb kuidagi eraldi luua piisavalt kiire andmete sünkroonimise lahendus kavandatud reservide jaoks.

Jätkates teemat virtuaalsetest failisüsteemidest: Docker Volume'ide probleemid ei ole kahjuks kadunud. Üldiselt oleks soovitav pikaajalise usaldusväärse andmete säilitamise osas kasutada maksimaalselt lihtsaid tehnilisi skeeme. Uue abstraktsioonikihi lisamine konteineri failisüsteemist vanema hosti failisüsteemi — on juba ise risk. Kuid kui süsteemis, mis tagab konteinerit, tekivad keerukused andmete edastamisel nende kihtide vahel, siis on asi tõeliselt hull. Praeguseks on enamik tuntud progressiivsete probleemide lahendatud. Kuid te mõistate, et mida keerulisem on mehhanism, seda tõenäolisem on, et see puruneb.

Kõikide nende "seikluste" valguses on palju kasulikum ja lihtsam hoida andmebaasi ühes kohas, ning isegi kui teil on vaja rakenduse konteineriseerimist — las see töötab iseseisvalt ja pääseb jaotussüsteemi kaudu samal ajal andmebaasiga, mis loetakse ja kirjutatakse vaid üks kord ja ühes kohas. Selline lähenemine vähendab vigade ja desünkroniseerimise tõenäosust minimaalseteks väärtusteks.

Kuhu me jõuame? Tõdemuseni, et andmebaasi konteineriseerimine on asjakohane seal, kus see on tõeliselt vajalik. Te ei saa mahutada andmebaasi täisrakenduse ja käitada seda nii, nagu teil oleks kaks tosinat mikroteenust — see ei tööta nii. Ja seda tuleb selgelt mõista.

Väljundi asemel

Kui te ootate arusaadavat vastust küsimusele "kas virtualiseerida andmebaas või mitte", siis peame teid pettuma: sellist vastust siin ei tule. Sest iga infrastruktuuri lahenduse loomisel tuleb lähtuda mitte moest ja arengust, vaid eeskätt terve mõistuse põhimõtetest.

On projekte, kuhu põhimõtted ja tööriistad, mis tulevad koos Kubernetesega, sobivad ideaalselt, ja sellistes projektides saavutatakse rahu vähemalt tagumises osas. Kuid on projekte, mis vajavad mitte konteineriseerimist, vaid normaalset serveri infrastruktuuri, sest nad ei suuda põhimõtteliselt mikroteenuste klastrimudeli alla ümber skaaleerida, muidu kukuvad nad kokku.

Allikas: habr.com