🥇Tarantool Cartridge: Lua-tagasiühenduse jagamine kolme realise

Mail.ru Groupis on Tarantool — see on Lua-l põhinev rakenduste server, mis on samal ajal ka andmebaas (või vastupidi?). See on kiire ja suurepärane, kuid ühe serveri võimalused pole siiski piiramatud. Vertikaalne skaleerimine ei ole siiski imerohi, seega on Tarantoolis tööriistad horisontaalseks skaleerimiseks — moodul vshard. [1]. See võimaldab andmeid jagada mitme serveri vahel, kuid selle seadistamine ja äriloogika juurde ühendamine võib olla paras peavalu.

Head uudised: me oleme saanud eksimustest õppida (näiteks [2], [3]) ja oleme loonud uue raamistik, mis lihtsustab selle probleemi lahendamist.

Tarantool Cartridge — see on uus raamistik keerukate jaotatud süsteemide arendamiseks. See võimaldab keskenduda äriloogika kirjutamisele, mitte infrastruktuuri probleemide lahendamisele. Allpool räägin, kuidas see raamistik töötab ja kuidas kasutada seda jaotatud teenuste kirjutamiseks.

Mis on probleem?

Meil on Tarantool, meil on vshard — mida veel soovida?

Esiteks on asi mugavuses. vshard'i konfiguratsioon seadistatakse läbi Lua-tabelite. Et jaotatud süsteem koosseisus mitmest Tarantooli protsessist töötaks õigesti, peab konfiguratsioon olema kõikjal ühesugune. Keegi ei taha seda manu küüritada. Seega kasutame erinevaid skripte, Ansible'i ja juurutussüsteeme.

Cartridge haldab vshard'i konfiguratsiooni automaatselt, tuginedes oma oma jaotatud konfiguratsioonile.Sisuliselt on see lihtne YAML-fail, mille koopia on igas Tarantooli instantsis. Lihtsustamine seisneb selles, et raamistik jälgib ise oma konfiguratsiooni ja tagab selle järjepidevuse.

Teiseks on see taas mugavuses. vshard'i konfiguratsioon ei ole seotud äriloogika arendamisega ning hoopis häirib arendajat. Kui arutame projekti arhitektuuri, räägime enamasti üksikutest komponentidest ja nende omavahelisest suhtlemisest. Klastri käitamise kohta kolmes andmekeskuses mõtlemiseks on veel vara.

Oleme nende probleemidega silmitsi seisnud korduvalt ja mõnes hetkes oleme suutelised välja töötama lähenemise, mis lihtsustab rakenduse tööd kogu selle elutsükli vältel: loomine, arendamine, testimine, CI/CD, hooldus.

Cartridge tutvustab igale Tarantooli protsessile rollide mõistet. Roli on see kontseptsioon, mis võimaldab arendajal keskenduda koodi kirjutamisele. Kõiki projektis olevaid rolle saab käivitada ühe Tarantooli instantsi peal ja testimiseks on see piisav.

Tarantool Cartridge peamised omadused:

automaatne klastrite orkestreerimine;
rakenduse funktsionaalsuse laiendamine uute rollide abil;
rakenduse mall arendamiseks ja juurutamiseks;
sisseehitatud automaatne jaotamine;
integratsioon testimisraamistiku Luatestiga;
klastri haldamine WebUI ja API abil;
pakendamise ja juurutamise tööriistad.

Tere, maailm!

Ma ei suuda oodata, et näidata ise raamistikku, seega arhitektuuri arutamine jääb hilisemaks ja alustame lihtsast. Kui eeldada, et Tarantool on juba installitud, siis jääb vaid teha

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

Need kaks käsku installivad käsurida utiliidid ja võimaldavad luua oma esimese rakenduse mallist:

$ cartridge create --name myapp

Ja siin on, mida me saame:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

See on git-repositoorium valmis «Hello, World!» rakendusega. Proovime seda kohe käivitada, eelnevalt paigaldades sõltuvused (sealhulgas raamistik):

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

Nii et meil on käivitatud üks sõlm tulevasest jaotatud rakendusest. Uudishimu üllatus võib kohe avada veebiliidese, konfigureerida ühe sõlmest klastrit ja nautida tulemust, kuid rõõmu valmistamiseks on veel vara. Praegu ei oska rakendus mitte midagi kasulikku teha, seega räägin edasise juurutamise kohta hiljem, aga nüüd on aeg kirjutada kood.

Rakenduste arendamine

Kujutage ette, et kujundame projekti, mis peab andmeid vastu võtma, neid salvestama ja iga päev aruandeid koostama.

Käivitanud disainis skeemi, paneme sinna kolm komponenti: gateway, storage ja scheduler. Arhitektuuri arendame edasi. Kuna kasutame salvestuseks vshard'i, lisame skeemile vshard-routeri ja vshard-storage'i. Ei gateway ega scheduler ei suhtle salvestusega otse, selleks on seal router, mille jaoks see on loodud.

See skeem ei peegelda täpselt seda, mida me projektis loome, kuna komponendid näevad välja abstraktsed. Peame veel vaatama, kuidas see projitseerub reaalsele Tarantoolile — rühmitame meie komponendid protsesside järgi.

Vshard-routeri ja gateway hoidmine eraldi eksemplarides pole mõttekas. Miks peaksime kordama võrku minemist, kui see kuulub juba ruuteri ülesannete hulka? Need peaksid käima ühes protsessis. See tähendab, et ühes protsessis algatatakse nii gateway kui vshard.router.cfg ning las nad suhtlevad kohapeal.

Projekteerimise etapis oli kolme komponendiga töötamine mugav, kuid mina kui arendaja ei taha koodi kirjutades mõelda kolme Tarnatooli eksemplari käivitamisele. Mul on vaja käivitada testid ja kontrollida, kas olen gateway kirjutamisega õigesti toiminud. Võib-olla soovin näidata omadust kolleegidele. Miks ma peaksin vaeva nägema kolme eksemplari juurutamisega? Just seetõttu sündis rollide kontseptsioon. Rull — see on tavaline Lua moodul, mille elutsüklit haldab Cartridge. Selles näites on neid neli — gateway, router, storage, scheduler. Muus projektis võib neid olla rohkem. Kõiki rolle saab käivitada ühes protsessis ja sellest piisab.

Ja kui tuleb juttu juurutamisest staging'sse või tootmisse, siis määrame igale Tarantooli protsessile oma rollide kogumi vastavalt riistvaralistele võimalustele:

Topoloogia haldamine

Teavet selle kohta, kus millised rollid on käivitatud, tuleb kusagil salvestada. Ja see "kusagil" on jaotatud konfigureerimine, millest olen juba eespool rääkinud. Kõige olulisem selles on klastrite topoloogia. Siin on kujutatud kolme replikatsioonigruppi viiest Tarantooli protsessist:

Me ei soovi andmeid kaotada, seetõttu kohtleme ettevaatlikult teavet käivitatud protsesside kohta. Cartridge jälgib konfiguratsiooni kahefaasilise komiti abil. Korraldades konfiguratsiooni uuendamist, kontrollib ta esmalt, kas kõik eksemplarid on saadaval ja valmis uut konfiguratsiooni vastu võtma. Seejärel rakendatakse teine faas konfig.

Samuti on topoloogia jaotises määratud oluline parameeter, nagu iga replikatsioonigrupi liider. Tavaliselt on see eksemplar, kuhu kirjutatakse. Ülejäänud on tavaliselt ainult lugemiseks, kuigi siin võivad olla erandid. Mõnikord ei karda julgemaid arendajad konflikte ja võivad andmeid paralleelselt kirjutada mitmele koopiale, kuid on olemas teatud toimingud, mida ei tohiks mingil juhul kaks korda teostada. Selleks on olemas liidri tunnus.

Rollide elu

Kuna abstraktse rolli eksisteerimiseks sellises arhitektuuris peab raamistik nendega kuidagi juhtima. Loomulikult toimub juhtimine ilma Tarantooli protsessi taaskäivitamiseta. Rollide juhtimiseks on olemas neli tagasisidet. Cartridge kutsub neid ise välja vastavalt sellele, mis tal on kirjutatud jaotatud konfiguratsioonis, rakendades seega konfiguratsiooni konkreetsetele rollidele.

function init()
function validate_config()
function apply_config()
function stop()

Igal rollil on ülesanne init. Seda kutsutakse välja kas kord, kui roll käivitatakse, või Tarantooli taaskäivitamisel. Seal on mugav näiteks initsialiseerida box.space.create või scheduler võib käivitada mõne taustafiberi, mis täidab tööd teatud ajavahemike järel.

Üks funktsioon init võib olla ebapiisav. Cartridge võimaldab rollidel kasutada jaotatud konfiguratsiooni, mida ta kasutab topoloogia salvestamiseks. Saame selles samas konfiguratsioonis kuulutada uue jaotise ja hoida seal äri konfiguratsiooni fragmenti. Minu näites võib see olla andmemudel või ajakava seadistused scheduler'i rolli jaoks.

Klastri kutsub üles validate_config ja apply_config iga kord, kui jaotatud konfiguratsioonis toimub muudatus. Kui konfiguratsioon rakendatakse kahefaasilise komiti abil, kontrollib klaster, et iga roll on valmis seda uut konfiguratsiooni vastu võtma ja vajadusel teavitab kasutajat veast. Kui kõik nõustuvad, et konfiguratsioon on normaalne, siis täidetakse apply_config.

Samuti on rollidel meetod stop, mis on vajalik rolli tegevuse tulemuste puhastamiseks. Kui me ütlem, et scheduler ei ole enam selles serveris vajalik, võib ta peatada need fiberid, mida ta käivitas abiga. init.

Rollid saavad omavahel suhelda. Oleme harjunud kirjutama funktsioonikõnesid Lua-s, kuid võib juhtuda, et just selle protsessi jooksul pole meil vajalikku rolli. Suhete lihtsustamiseks võrgus kasutame abimoodulit rpc (remote procedure call), mis on loodud Tarantooli standardse netbox'i baasil. See võib olla kasulik, kui näiteks teie gateway soovib otse scheduler'ilt paluda, et ta töö ära teeks kohe, mitte ei ootaks 24 tundi.

Veel üks oluline aspekt on tõrketaluvuse tagamine. Cartridge'is kasutatakse tervise jälgimiseks protokolli SWIM. [4]. Üldiselt vahetavad protsessid omavahel 'kuuldusi' UDP kaudu — iga protsess räägib oma naabritele viimased uudised ja nad vastavad. Kui vastust ei tule, hakkab Tarantool kahtlustama, et midagi on valesti, ja mõne aja pärast kuulutab välja surma ning räägib kõikidele ümberkaudsetele sellest uudisest.

Selle protokolli põhjal korraldab Cartridge automaatse tõrke töötlemise. Iga protsess jälgib oma ümbrust ja kui juht lõpetab äkki vastamise, võib replika võtta tema rolli enda peale, ning Cartridge konfigureerib vastavalt käimasolevad rollid.

Siin tuleb olla ettevaatlik, kuna sage vahetamine võib andmete konfliktidele viia replikatsiooni käigus. Automaatse failover'i lubamine suvaliselt ei ole kindlasti soovitatav. Tuleb selgelt mõista, mis toimub, ja olla kindel, et replikatsioon ei purune pärast seda, kui juht taastub ja talle kroon tagastatakse.

Kokkuvõttes võib tekkida tunne, et rollid on sarnased mikroteenustele. Mõnes mõttes on nad tõepoolest sellised, kuid moodulitena Tarantooli protsesside sees. Siiski on ka mitmeid põhimõttelisi erinevusi. Esiteks peavad kõik projekti rollid elama ühes koodibaasis. Ja kõik Tarantooli protsessid peavad käivitama ühes koodibaasis, et vältida üllatusi, nagu näiteks juhul, kui proovime algatada scheduler'i, mille pole lihtsalt olemas. Samuti ei tohi lubada koodiversioonide erinevusi, kuna süsteemi käitumist on sellises olukorras väga keeruline ette ette näha ja siluda.

Erinevalt Dockerist ei saa me lihtsalt võtta rolli 'pilti', viia selle teisele masinale ja seal käivitada. Meie rollid ei ole nii isoleeritud kui Docker konteinerid. Samuti ei saa me ühel eksemplaril käivitada kaht identset rolli. Roll on kas olemas või seda pole, teatud mõttes on see singleton. Ja kolmandaks, kogu replikatsiooni grupi sees peavad rollid olema ühesugused, kuna muidu oleks see absurdne — andmed on samad, kuid konfiguratsioon on erinev.

Käivitustööriistad

Lubasin näidata, kuidas Cartridge aitab rakenduste käivitamisel. Ümbruse elu lihtsustamiseks pakib raamistik RPM-pakette:

$ cartridge pack rpm myapp -- pakib meie jaoks ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

Installitud paketis on peaaegu kõik vajalik: nii rakendus kui ka installitud lua sõltuvused. Tarantool jõuab serverisse ka RPM-paketi sõltuvusena ja meie teenus on käivitamiseks valmis. See toimub läbi systemd, kuid enne tuleb kirjutada veidi konfi. Peamine on iga protsessi URI määramine. Kolm näitena on piisavad.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

Siin on huvitav nüanss. Selle asemel, et näidata vaid binaarse protokolli porti, näitame protsessi täielikku avalikku aadressi, sealhulgas hostname'i. See on vajalik, et klastrisõlmed teaksid, kuidas omavahel ühendust luua. Kehv idee on kasutada advertise_uri aadressina 0.0.0.0, see peaks olema väline IP-aadress, mitte socketi seondamine. Ilma selleta ei tööta mitte midagi, seega Cartridge ei lase lihtsalt vale advertise_uri'ga sõlme käivitada.

Nüüd, kui konfigureerimine on valmis, saame protsessid käivitada. Kuna tavaline systemd-üksus ei luba rohkem kui ühe protsessi käivitamist, loob Cartridge rakendustes nn instantsi-üksusi, mis töötavad järgmiselt:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

Konfiguratsioonis määrasime HTTP-pordi, millel Cartridge teenindab veebiliidest — 8080. Külastame seda ja vaatame:

Näeme, et protsessid on käivitatud, kuid praegu ei ole nad konfigureeritud. Cartridge ei tea veel, kes kellega peaks replikatsiooni tegema ja ei saa ise otsust teha, seega ootab meie tegevust. Meie väljundvalik ei ole suur: uue klastritegu algab esimese sõlme seadistamisest. Siis lisame klastrisse ülejäänud, määrame neile rollid ja siis võib käitusprotsessi edukaks lugeda.