🥇Tarantool Kartutxoa: Lua backend bat hiru lerrotan zatitzea

Mail.ru Group-en Tarantool dugu - hau Lua-ko aplikazio-zerbitzari bat da, datu-base gisa ere bikoizten duena (edo alderantziz?). Azkarra eta freskoa da, baina zerbitzari baten gaitasunak oraindik ez dira mugagabeak. Eskalatze bertikala ere ez da panazea, beraz, Tarantool-ek eskalatze horizontalerako tresnak ditu - vshard modulua [1]. Hainbat zerbitzaritan datuak zatitzeko aukera ematen du, baina haiekin moldatu behar duzu konfiguratzeko eta negozio-logika eransteko.

Berri onak: plano handi batzuk bildu ditugu (adib [2], [3]) eta arazo honen konponbidea nabarmen erraztuko duen beste esparru bat sortu zuen.

Tarantool kartutxoa sistema banatu konplexuak garatzeko esparru berria da. Azpiegitura-arazoak konpondu beharrean negozio-logika idaztera bideratzen du. Ebakiaren azpian marko honek nola funtzionatzen duen eta hura erabiliz banatutako zerbitzuak nola idatzi esango dizut.

Zein da zehazki arazoa?

Tarantula bat dugu, vshard dugu - zer gehiago nahi dezakezu?

Lehenik eta behin, erosotasun kontua da. vshard konfigurazioa Lua taulen bidez konfiguratzen da. Tarantool prozesu anitzen sistema banatu batek behar bezala funtziona dezan, konfigurazioak berdina izan behar du leku guztietan. Inork ez du hori eskuz egin nahi. Hori dela eta, mota guztietako scriptak, Ansible eta hedapen-sistemak erabiltzen dira.

Kartutxoak berak kudeatzen du vshard konfigurazioa, hau bere arabera egiten du konfigurazio banatua propioa. Funtsean YAML fitxategi sinple bat da, eta horren kopia Tarantool-en instantzia bakoitzean gordetzen da. Sinplifikazioa da markoak berak bere konfigurazioa kontrolatzen duela eta leku guztietan berdina dela ziurtatzen duela.

Bigarrenik, berriz ere erosotasun kontua da. vshard konfigurazioak ez du zerikusirik negozio-logikaren garapenarekin eta programatzailea bere lanetik aldentzen du soilik. Proiektu baten arkitekturaz eztabaidatzen dugunean, gehienetan osagai indibidualez eta haien elkarrekintzaz hitz egiten dugu. Goiz da kluster bat 3 datu-zentrotara zabaltzea pentsatzeko.

Arazo horiek behin eta berriz konpondu genituen, eta uneren batean aplikazioarekin bere bizitza-ziklo osoan lan egitea errazten zuen ikuspegi bat garatzea lortu genuen: sorrera, garapena, probak, CI/CD, mantentze-lanak.

Kartutxoak Tarantool prozesu bakoitzeko rol baten kontzeptua aurkezten du. Rolak garatzaile bati kodea idaztera bideratzen duen kontzeptua da. Proiektuan eskuragarri dauden rol guztiak Tarantool-en instantzia batean exekutatu daitezke, eta hori nahikoa izango da probak egiteko.

Tarantool kartutxoaren ezaugarri nagusiak:

cluster orkestrazio automatizatua;
rol berriak erabiliz aplikazioaren funtzionaltasuna zabaltzea;
garapen eta hedapenerako aplikazio txantiloia;
zatiketa automatikoa integratua;
Luatest test-esparruarekin integratzea;
kluster kudeaketa WebUI eta API erabiliz;
ontziratzeko eta zabaltzeko tresnak.

Kaixo Mundua!

Ezin dut itxaron esparrua bera erakusteko, beraz arkitekturari buruzko istorioa gerorako utziko dugu eta zerbait sinple batekin hasiko gara. Tarantool bera dagoeneko instalatuta dagoela suposatzen badugu, geratzen dena da egitea

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

Bi komando hauek komando-lerroko utilitateak instalatuko dituzte eta txantiloitik zure lehen aplikazioa sortzeko aukera emango dizute:

$ cartridge create --name myapp

Eta hauxe da lortzen duguna:

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/

Hau git biltegi bat da, prest egindako "Kaixo, Mundua!" aplikazio. Saia gaitezen berehala exekutatzen, aldez aurretik mendekotasunak instalatuta (esparrua bera barne):

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

Beraz, etorkizuneko sharded aplikaziorako nodo bat dugu martxan. Laiko jakintsu batek berehala ireki dezake web interfazea, saguarekin nodo bateko kluster bat konfiguratu eta emaitzaz gozatu, baina goizegi da pozteko. Orain arte, aplikazioak ezin du ezer baliagarririk egin, gero inplementazioari buruz esango dizut, baina orain kodea idazteko garaia da.

Aplikazioen Garapena

Imajinatu, egunean behin datuak jaso, gorde eta txosten bat eraiki behar duen proiektu bat diseinatzen ari gara.

Diagrama bat marrazten hasiko gara eta hiru osagai jartzen dizkiogu: atea, biltegiratzea eta programatzailea. Arkitektura gehiago lantzen ari gara. vshard biltegiratze gisa erabiltzen dugunez, vshard-router eta vshard-storage gehitzen dizkiogu eskemari. Ez atebidea ez programatzailea ez dira zuzenean sartuko biltegiratzera; horretarako da bideratzailea, horretarako sortu zen.

Diagrama honek oraindik ez du zehazki adierazten proiektuan eraikiko duguna, osagaiek abstraktu itxura dutelako. Oraindik ikusi behar dugu nola proiektatuko den benetako Tarantool-en - taldeka ditzagun gure osagaiak prozesuka.

Ez du ezertarako balio vshard-router eta atea instantzia bereizietan mantentzeak. Zergatik nabigatu behar dugu sarean berriro ere hori jada bideratzailearen ardura bada? Prozesu berean exekutatu behar dira. Hau da, gateway eta vshard.router.cfg prozesu batean abiarazten dira, eta lokalean elkarreragiten uzten dute.

Diseinu fasean, komenigarria izan zen hiru osagairekin lan egitea, baina nik, garatzaile gisa, kodea idazten ari naizenean, ez dut pentsatu nahi Tarnatool-en hiru instantzia abiarazteko. Probak egin behar ditut eta atebidea ondo idatzi dudala egiaztatu behar dut. Edo agian ezaugarri bat erakutsi nahi diet nire lankideei. Zergatik pasatu behar dut hiru kopia zabaltzeko arazoa? Horrela sortu zen rolen kontzeptua. Rol bat Lush modulu erregularra da, zeinaren bizi-zikloa Kartutxoak kudeatzen duen. Adibide honetan lau daude: atebidea, bideratzailea, biltegiratzea, programatzailea. Baliteke beste proiektu batean gehiago egotea. Rol guztiak prozesu batean exekutatu daitezke, eta nahikoa izango da.

Eta eszenaratze edo ekoizpenerako hedapenari dagokionez, Tarantool prozesu bakoitzari bere rol multzoa esleituko diogu hardware-gaitasunen arabera:

Topologiaren kudeaketa

Zein rol exekutatzen ari diren buruzko informazioa nonbait gorde behar da. Eta "nonbait" hau konfigurazio banatua da, lehen aipatu dudana. Horren garrantzitsuena cluster topologia da. Hona hemen 3 Tarantool prozesuen 5 erreplikazio talde:

Ez dugu daturik galdu nahi, beraz, exekutatzen diren prozesuei buruzko informazioa kontu handiz tratatzen dugu. Kartutxoak konfigurazioaren jarraipena egiten du bi faseko konpromisoa erabiliz. Konfigurazioa eguneratu nahi dugunean, lehenik eta behin instantzia guztiak eskuragarri daudela eta konfigurazio berria onartzeko prest daudela egiaztatzen du. Horren ostean, bigarren fasean konfigurazioa aplikatzen da. Horrela, kopia bat aldi baterako erabilgarri ez badago ere, ez da ezer txarrik gertatuko. Konfigurazioa ez da aplikatuko eta errore bat ikusiko duzu aldez aurretik.

Topologia atalean ere, erreplikazio-talde bakoitzaren liderra bezalako parametro garrantzitsu bat adierazten da. Normalean hau da grabatzen den kopia. Gainerakoak irakurtzekoak dira gehienetan, salbuespenak egon daitezkeen arren. Batzuetan, garatzaile ausartak ez dira gatazkei beldurtzen eta paraleloan hainbat errepliketan datuak idatz ditzakete, baina badira eragiketa batzuk, edozein dela ere, bi aldiz egin behar ez direnak. Horretarako lider baten seinalea dago.

Rolen bizitza

Arkitektura horretan rol abstraktu bat egon dadin, esparruak nolabait kudeatu behar ditu. Berez, kontrola Tarantool prozesua berrabiarazi gabe gertatzen da. Rolak kudeatzeko 4 dei-itzulera daude. Kartutxoak berak bere konfigurazio banatuan idatzitakoaren arabera deituko ditu, eta horrela konfigurazioa rol zehatzei aplikatuko die.

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

Rol bakoitzak funtzio bat du init. Behin deitzen da rola gaituta dagoenean edo Tarantool berrabiarazten denean. Erosoa da han, adibidez, box.space.create hasieratzea, edo programatzaileak denbora tarte jakin batzuetan lana egingo duen atzeko zuntz bat abiarazi dezake.

Funtzio bat init agian ez da nahikoa izango. Kartutxoak topologia gordetzeko erabiltzen duen konfigurazio banatua aprobetxatzeko aukera ematen die rolei. Konfigurazio berean atal berri bat deklara dezakegu eta negozioaren konfigurazioaren zati bat bertan gorde dezakegu. Nire adibidean, hau izan daiteke datu-eskema bat edo programazio-ezarpenak programatzaile-eginkizunerako.

Kluster-deiak validate_config и apply_config banatutako konfigurazioa aldatzen den bakoitzean. Konfigurazio bat bi faseko konpromiso baten bidez aplikatzen denean, klusterrak egiaztatzen du rol bakoitza prest dagoela konfigurazio berri hori onartzeko eta, behar izanez gero, errore baten berri ematen dio erabiltzaileari. Denek konfigurazioa normala dela onartzen dutenean, orduan apply_config.

Rolek ere badute metodo bat stop, rolaren irteera garbitzeko beharrezkoa dena. Zerbitzari honetan programatzailea jada behar ez dela esaten badugu, hasitako zuntz horiek geldi ditzake init.

Rolak elkarren artean elkarreragin dezakete. Luan funtzio-deiak idaztera ohituta gaude, baina gerta daiteke prozesu jakin batek behar dugun rola ez izatea. Sarean deiak errazteko, rpc (urruneko prozedura deia) modulu laguntzailea erabiltzen dugu, Tarantool-en integratutako netbox estandarrean oinarrituta eraikia. Hau erabilgarria izan daiteke, adibidez, zure atebideak zuzenean programatzaileari lana oraintxe bertan eskatu nahi badio, egun bat itxaron beharrean.

Beste puntu garrantzitsu bat akatsen tolerantzia bermatzea da. Kartutxoak SWIM protokoloa erabiltzen du osasuna kontrolatzeko [4]. Laburbilduz, prozesuek elkarren artean "zurrumurruak" trukatzen dituzte UDPren bidez —prozesu bakoitzak bere bizilagunei azken berriak kontatzen dizkie, eta haiek erantzuten dute. Bat-batean erantzuna iristen ez bada, Tarantool-ek zerbait gaizki dagoela susmatzen hasten da, eta pixka bat igaro ondoren heriotza errezitatzen du eta denei berri hau kontatzen hasten da.

Protokolo honetan oinarrituta, Cartridgek hutsegiteen prozesamendu automatikoa antolatzen du. Prozesu bakoitzak bere ingurunea kontrolatzen du, eta liderrak bat-batean erantzuteari uzten badio, erreplikak bere eginkizuna har dezake, eta Cartridge-k exekutatzen ari diren rolak konfiguratzen ditu horren arabera.

Kontuz ibili behar duzu hemen, maiz aurrera eta aurrera aldatzeak datu-gatazkak sor ditzake errepliketan zehar. Jakina, ez zenuke hutsegite automatikoa ausaz gaitu behar. Gertatzen ari dena argi ulertu behar dugu eta ziur egon erreplikazioa ez dela hautsiko liderra berreskuratu eta koroa itzuli ondoren.

Horregatik guztiagatik, baliteke rolak mikrozerbitzuen antzekoak direla sentitzea. Zentzu batean, hori besterik ez dira, Tarantool prozesuen barruan dauden modulu gisa soilik. Baina oinarrizko desberdintasun ugari ere badaude. Lehenik eta behin, proiektuko rol guztiek kode-oinarri berean bizi behar dute. Eta Tarantool-eko prozesu guztiak kode-oinarri beretik abiarazi behar dira, programatzailea abiarazten saiatzen garenean bezalako sorpresarik egon ez dadin, baina besterik gabe ez da existitzen. Gainera, ez zenuke kode-bertsioetan desberdintasunak onartu behar, sistemaren portaera horrelako egoera batean oso zaila baita aurreikusten eta araztea.

Docker ez bezala, ezin dugu rol "irudi" bat hartu, beste makina batera eraman eta bertan exekutatu. Gure rolak ez daude Docker edukiontziak bezain isolatuak. Gainera, ezin ditugu bi rol berdin exekutatu instantzia batean. Rol bat existitzen da edo ez dago; zentzu batean, bakarrekoa da. Eta hirugarrenik, rolak berdinak izan behar dira erreplikazio-talde osoaren barruan, bestela zentzugabea litzatekeelako: datuak berdinak dira, baina konfigurazioa ezberdina da.

Hedatzeko tresnak

Kartutxoak aplikazioak zabaltzen nola laguntzen duen erakutsiko nuela agindu nuen. Besteei bizitza errazteko, esparruak RPM paketeak biltzen ditu:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

Instalatutako paketeak behar duzun ia guztia dauka: aplikazioa eta instalatutako menpekotasunak. Tarantool RPM paketearen menpekotasun gisa ere iritsiko da zerbitzarira, eta gure zerbitzua abiarazteko prest dago. Hau systemd bidez egiten da, baina lehenik konfigurazio txiki bat idatzi behar duzu. Gutxienez, zehaztu prozesu bakoitzaren URIa. Hiru nahikoa dira adibidez.

$ 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

Hemen ñabardura interesgarri bat dago. Protokolo-ataka bitarra soilik zehaztu beharrean, prozesuaren helbide publiko osoa zehazten dugu ostalari-izena barne. Hau beharrezkoa da klusterreko nodoek elkarren artean konektatzen jakin dezaten. Ideia txarra da 0.0.0.0 iragarki_uri helbide gisa erabiltzea; kanpoko IP helbidea izan behar du, ez socket-lotura bat. Hori gabe, ezerk ez du funtzionatuko, beraz Cartridgek ez dizu utziko advertise_uri okerreko nodo bat abiarazten.

Orain konfigurazioa prest dagoenean, prozesuak has ditzakezu. Systemd unitate arrunt batek prozesu bat baino gehiago abiarazten uzten ez duenez, Kartutxoko aplikazioak deiturikoak instalatzen ditu. Honela funtzionatzen duten instantziatutako unitateak:

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

Konfigurazioan, Kartutxoak web interfazea zerbitzatzen duen HTTP ataka zehaztu dugu - 8080. Goazen bertara eta begirada bat eman:

Ikusten dugu prozesuak martxan dauden arren, oraindik ez daudela konfiguratuta. Kartutxoak oraindik ez daki nork norekin errepikatu behar duen eta ezin du bere kabuz erabakirik hartu, beraz, gure ekintzen zain dago. Baina ez dugu aukera handirik: kluster berri baten bizitza lehen nodoaren konfigurazioarekin hasten da. Ondoren, besteak gehituko ditugu clusterra, rolak esleituko dizkiegu eta une honetan inplementazioa arrakastaz amaitutzat jo daiteke.

Bota dezagun edalontzi bat zure edari gogokoena eta erlaxatu gaitezen lan aste luze baten ondoren. Aplikazioa erabil daiteke.