🥇Tarantool Cartridge: Lua-backendi jaotamine kolme reaga

Mail.ru Grupil on meil Tarantool – see on Lua-skripti server, mis on ühtlasi ka andmebaas (või vastupidi?). See on kiire ja suurepärane, kuid ühe serveri võimalused pole ikkagi piiramatud. Vertikaalne skaleerimine pole ka imerohi, seega on Tarantoolis tööriistad horisontaalseks skaleerimiseks – moodul vshard. [1]See võimaldab andmeid jagada mitme serveri vahel, kuid selle seadistamine ja äriloogika lisamine nõuab siiski vaeva.

Hea uudis: me õppisime oma vigadest (näiteks [2], [3]) ja lõime uue raamistiku, mis lihtsustab selle probleemi lahendamist oluliselt.

Tarantool Cartridge on uus raamistiku komplekt keerukate jaotatud süsteemide arendamiseks. See võimaldab keskenduda äriloogika kirjutamisele, mitte infrastruktuuri probleemide lahendamisele. Allpool räägin, kuidas see raamistiku struktuur töötab ja kuidas selle abil kirjutada jaotatud teenuseid.

Mis siis täpselt probleem on?

Meil on tainanul, meil on vshard – mida veel soovida?

Esiteks, asi on mugavuses. Vshardi konfiguratsioon seadistatakse Lua-tabelite kaudu. Et jaotatud süsteem mitme Tarantooli protsessiga õigesti töötaks, peab konfiguratsioon olema igal pool sama. Keegi ei taha seda käsitsi teha. Seetõttu tuleb mängu erinevad skriptid, Ansible, juurutussüsteemid.

Cartridge haldab ise vshardi konfiguratsiooni, tehes seda oma enda jaotatud konfiguratsiooni. Sisuliselt on see lihtne YAML-fail, mille koopia on iga Tarantooli eksemplari juures. Lihtsustamine seisneb selles, et raamistiku enda ülesanne on jälgida oma konfiguratsiooni ja tagada, et see kõikjal ühesugune oleks.

Teiseks, asi on taas mugavuses. Vshardi konfiguratsioonil pole mingit seost äriloogika arendamisega ja see häirib arendajat tööst. Kui arutame, kuidas projektide arhitektuur välja näeb, räägime enamasti eraldi komponentidest ja nende omavahelisest suhtlemisest. Kolme andmeregioni kasti viimisele mõtlemine on veel liiga vara.

Oleme neid probleeme korduvalt lahendanud ja mingil hetkel oleme suutnud välja töötada lähenemise, mis lihtsustab igasuguseid ülesandeid kogu rakenduse elutsükli jooksul: loomine, arendamine, testimine, CI/CD, hooldus.

Cartridge toob introduktsiooni kontseptsiooni rollist iga Tarantooli protsessi jaoks. Rollid on see kontseptsioon, mis võimaldab arendajal keskenduda koodi kirjutamisele. Kõiki projekti rolle saab käivitada ühes Tarantooli kopeerimises, ja testimiseks on sellest piisavalt.

Tarantool Cartridge peamised funktsioonid:

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

Tere, maailm!

Ma ei suuda oodata, et näidata raamistiku enda, seega jätame arhitektuuri jutu hiljem ja alustame lihtsast. Kui eeldada, et Tarantool on juba paigaldatud, siis tuleb teha ainult

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

Need kaks käsku installivad käsurealiidesed 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-repositorium valmis "Tere, maailm!" rakendusega. Proovime seda kohe käivitada, enne kui paigaldame sõltuvused (sh raamistik):

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

Seega on meil käivitunud üks sõlm tulevase shardimise rakenduse jaoks. Uudishimu tõttu võib tavaline kasutaja kohe avada veebiliidese, konfigureerida ühe sõlme klusti hiire abil ja nautida tulemust, kuid veel on vara rõõmustada. Praegu ei oska rakendus teha midagi kasulikku, seega räägin juurutamisest hiljem, ja nüüd on aeg kirjutada koodi.

Rakenduste arendamine

Kujutage ette, et kujundame projekti, mis peab andmeid vastu võtma, neid salvestama ja korra päevas aruannet koostama.

Alustame skeemi joonistamist ja paigutame sinna kolm komponenti: gateway, storage ja scheduler. Töötame arhitektuuri edasi. Kuna kasutame salvestusena vshard, siis lisame skeemile vshard-routeri ja vshard-storage'i. Ei gateway ega scheduler ei võta salvestusega otseselt ühendust, selleks on olemas ruuter, mis on selle jaoks loodud.

See skeem ei kajasta veel täpselt, mida me projektis loome, sest komponendid näevad välja abstraktsed. Peame veel vaatama, kuidas see tõelisele Tarantoolile projitseerub — grupeerime komponendid protsesside kaupa.

Hoida vshard-routerit ja gateway'd eraldi instantsides pole mõtet. Miks me peaksime nätukene rohkem võrgus liikuma, kui see on juba routeri ülesanne? Need peaksid olema käivitatud ühes protsessis. See tähendab, et ühes protsessis initsialiseeritakse nii gateway kui vshard.router.cfg, ja las nad suhtlevad kohapeal.

Projekteerimise etapis oli mugav töötada kolme komponendiga, kuid mina, kui arendaja, ei taha koodi kirjutades mõelda kolme Tarnatooli instantsi käivitamisele. Mul on vaja käivitada testid ja kontrollida, et olen õigesti gateway'd kirjutanud. Või võib-olla tahan, et mu kolleegid näeksid funktsiooni. Miks ma peaksin hädaldama kolme instantsi käivitamise üle? Sellest sündis rollide kontseptsioon. Rool on tavaline Lua moodul, mille elu tsüklit haldab Cartridge. Antud näites on neid neli — gateway, router, storage ja scheduler. Teises projektis võib neid olla rohkem. Kõiki rolle saab käivitada ühes protsessis, ja sellest piisab.

Ja kui tuleb rääkida juurutamisest stagingus või toodangus, siis määrame igale Tarantooli protsessile vastavalt riistvarale oma rollide komplekti:

Topoloogia haldamine

Teavet selle kohta, kus missugused rollid on käivitatud, tuleb kuskil hoida. Ja see 'kuskil' on jaotatud konfiguratsioon, millest ma juba varem mainisin. Kõige tähtsam selles on klastrite topoloogia. Siin on kujutatud 3 replikaatide gruppi, kus on 5 Tarantooli protsessi:

Me ei taha andmeid kaotada, seega kohtleme hoolikalt teavet käimasolevate protsesside kohta. Cartridge jälgib konfiguratsiooni kahefaasilise commitiga. Kui soovime konfiguratsiooni värskendada, kontrollib ta esmalt, kas kõik instantsid on saadaval ja valmis uut konfiguratsiooni vastu võtma. Seejärel rakendatakse teine faas konfiguratsioon. Seega, isegi kui üks instants peaks ajutiselt kättesaamatuks osutuma, ei juhtu midagi halba. Konfiguratsioon lihtsalt ei rakendu ja te näete ette viga.

Samuti on topoloogia jaotises märgitud oluline parameeter, nagu iga replikatsioonigruppi juht. Tavaline on, et see on see eksemplar, kuhu kirjutatakse. Ülejäänud on enamasti ainult lugemiseks, kuigi siin võivad olla erandeid. Mõnikord ei karda julged arendajad konflikte ja võivad kirjutada andmeid mitmele replikale samaaegselt, kuid on teatud toimingud, mida hoolimata kõigest ei tohiks kaks korda täita. Selleks on olemas liidri tunnus.

Rollide elu

Et abstraktne roll võiks sellises arhitektuuris eksisteerida, peab raamistik neid kuidagi haldama. Loomulikult toimub juhtimine ilma Tarantooli protsessi taaskäivitamiseta. Rollide haldamiseks on olemas 4 tagasisidet. Cartridge kutsub need automaatselt esile vastavalt sellele, mida on määratud jaotatud konfiguratsioonis, rakendades seeläbi konfiguratsiooni konkreetsetele rollidele.

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

Igal rollil on funktsioon — algne ettevalmistus enne juurutamist, siin võib olla kõike: sõltuvuste allalaadimist, saladuste lahtipakkimist ja muud.. See kutsutakse esile ainult üks kord kas rolli sisselülitamisel või Tarantooli taaskäivitamisel. Seal on mugav näiteks initsialiseerida box.space.create või võib ajakava käivitada mõne taustafunktsiooni, mis täidab tööd teatud ajavahemike järel.

Üks funktsioon — algne ettevalmistus enne juurutamist, siin võib olla kõike: sõltuvuste allalaadimist, saladuste lahtipakkimist ja muud. võib olla ebapiisav. Cartridge võimaldab rollidel kasutada jaotatud konfiguratsiooni, mida ta topoloogia salvestamiseks kasutab. Saame samas konfiguratsioonis kuulutada uue sektsiooni ja salvestada sinna osa ärikonfiguratsioonist. Minu näites võib see olla andmeedastus või ajakava seaded rolli ajakava jaoks.

Klastri kutsub esile validate_config ja apply_config iga kord, kui jaotatud konfiguratsioonis toimub muudatus. Kui konfiguratsioon rakendatakse kahefosaalse pühendamisega, kontrollib klass, et iga roll on valmis selle uue konfiguratsiooniga nõustuma ja vajadusel teavitab kasutajat veast. Kui kõik on nõus, et konfiguratsioon on korras, siis täidetakse apply_config.

Samuti on rollidel meetod stop, mis on vajalik rolli tegevuse tulemuste puhastamiseks. Kui me ütleme, et ajakava ei ole enam sellel serveril vajalik, võib ta peatada need funktsioonid, mille ta oli käivitanud. — algne ettevalmistus enne juurutamist, siin võib olla kõike: sõltuvuste allalaadimist, saladuste lahtipakkimist ja muud..

Rolle võivad omavahel suhelda. Oleme harjunud kirjutama funktsioonikõnesid Lua keeles, kuid võib juhtuda, et selle protsessi käigus ei ole meil vajalikku rolli. Selleks, et hõlbustada võrguülekandeid, kasutame abimoodulit rpc (remote procedure call), mis on üles ehitatud standardsele netboxile, mis on integreeritud Tarantooli. See võib olla kasulik, kui näiteks teie gateway soovib otse schedulerilt küsida, et teha töö praegu, mitte oodata terve päev.

Teine oluline punkt on tõrketaluvuse tagamine. Cartridge'is kasutatakse tervisekontrolliks SWIM-protokolli. [4]. Kui öelda lühidalt, siis protsessid jagavad üksteisega "kuuldusi" UDP kaudu — iga protsess räägib oma naabritele viimased uudised ning nad vastavad. Kui vastust ei tule, hakkab Tarantool midagi kahtlustama ja mõne aja pärast kuulutab välja surma ja hakkab seda uudist kõigile ümbritsevatele rääkima.

Selle protokolli põhjal korraldab Cartridge automaatse tõrke käitlemise. Iga protsess jälgib oma keskkonda, ja kui liider äkki enam ei vasta, võib replikatsioon võtta tema rolli enda kanda ning Cartridge konfigureerib vastavalt käivitatud rolle.

Siin peab olema ettevaatlik, sest sage edasi-tagasi lülitamine võib põhjustada andmete konflikte replikatsioonis. Automaatse failoveri lubamine ilma kaalutlemata ei ole kindlasti mõistlik. Tuleb selgelt mõista, mis toimub, ja olla kindel, et replikatsioon ei riku end pärast seda, kui liider on taastunud ja tema troon on talle tagasi antud.

Kõigest eelnevast võib jääda mulje, et rollid sarnanevad mikroteenustele. Mõnes mõttes nad ongi seda, vaid kui moodulid Tarantooli protsesside sees. Kuid on ka mitmeid põhimõttelisi erinevusi. Esiteks peavad kõik projekti rollid olema ühes koodibaasis. Ja kõik Tarantooli protsessid peaksid käivituma ühest koodibaasist, et vältida üllatusi, nagu need, kui püüame algatada schedulerit, aga see ei ole lihtsalt olemas. Samuti ei tohiks lubada koodiversioonide erinevusi, kuna sellises olukorras on süsteemi käitumine väga keeruline ennustada ja tõrkeid lahendada.

Erinevalt Dockerist ei saa me lihtsalt võtta rolli „kuvandi“, viia see teisele masinale ja seal käivitada. Meie rollid ei ole sama suletud kui Docker-konteinerid. Samuti ei saa me ühel eksemplaril käivitada kaht identset rolli. Rull on kas olemas või mitte, mingis mõttes on see ainus (singleton). Ja kolmandaks, kogu replikatsioonigrupi sees peavad rollid olema ühesugused, sest muidu oleks see absurdne — andmed on ühesugused, aga konfigureerimine erinev.

Paigaldustooted

Lubasin näidata, kuidas Cartridge aitab rakendusi paigaldada. Kolleegide elu lihtsustamiseks pakib raamistik RPM-pakette:

$ cartridge pack rpm myapp -- pakib meile .\/myapp-0.1.0-1.rpm
$ sudo yum install .\/myapp-0.1.0-1.rpm

Installitud pakett sisaldab peaaegu kõike vajalikku: nii rakendust kui ka installitud luu-nõudeid. Tarantool tuleb serverisse ka RPM-paketi sõltuvusena, ja meie teenus on valmis käivitamiseks. See toimub läbi systemd, kuid enne tuleb kirjutada veidi konfigureerimist. Vähemalt tuleb näidata iga protsessi URI. Kolm näidet 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 ainult binaarprotokolli porti, näitame me protsessi avalikku aadressi koos hostinimega. See on vajalik, et klastrite sõlmed teaksid, kuidas omavahel ühendust luua. Halb idee on kasutada advertise_uri aadressina 0.0.0.0, see peaks olema väline IP-aadress, mitte soketi bindi aadress. Ilma selleta ei toimi mitte miski, seega Cartridge ei luba lihtsalt vale advertise_uri'ga sõlme käivitada.

Nüüd, kui konfigureerimine on valmis, saame protsessid käivitada. Kuna tavaline systemd-ühik ei luba käivitada rohkem kui ühte protsessi, paigaldab Cartridge rakendused nn instantsi-ühikud, mis töötavad järgmiselt:

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

Konfigureerimises oleme määranud HTTP-pordi, millel Cartridge teenindab veebiliidest — 8080. Käime seal ja vaatame:

Näeme, et protsessid on käivitatud, kuid pole veel konfigureeritud. Kassett ei tea veel, kes kellega replitseerima peab, ja ei saa otsuseid iseseisvalt teha, seetõttu ootab ta meie samme. Meie valik on piiratud: uue klastriga alustamine toimub esimese sõlme konfigureerimisega. Hiljem lisame ülejäänud klastrisse, määrame neile rollid ja seeläbi võib juurutust pidada edukalt lõpule viidud.