🥇Tarantool Cartridge: sharding af Lua-backenden på tre linjer

Vi har Tarantool hos Mail.ru Group — en applikationsserver skrevet i Lua, som også fungerer som en database (eller omvendt?). Den er hurtig og fantastisk, men kapaciteten på en enkelt server er stadig ikke ubegribelig. Vertikal skalerbarhed er heller ikke en kur mod alt, så Tarantool har værktøjer til horisontal skalerbarhed — modulet vshard. [1]. Det giver mulighed for at shardere data på flere servere, men det kræver lidt arbejde at få det konfigureret og integrere forretningslogikken.

Gode nyheder: Vi har lavet mange fejl (for eksempel [2], [3]) og har udviklet endnu et framework, som gør det betydeligt lettere at løse dette problem.

Tarantool Cartridge — er et nyt framework til udvikling af komplekse distribuerede systemer. Det tillader at fokusere på at skrive forretningslogik i stedet for at løse infrastrukturelle problemer. Nedenfor vil jeg forklare, hvordan dette framework fungerer, og hvordan man bruger det til at skrive distribuerede tjenester.

Hvad er egentlig problemet?

Vi har Tarantool, vi har vshard — hvad mere kan man ønske?

For det første handler det om bekvemmelighed. Konfigurationen af vshard sættes op via Lua-tabeller. For at et distribueret system bestående af flere Tarantool-processer kan fungere korrekt, skal konfigurationen være ens overalt. Ingen ønsker at gøre dette manuelt. Derfor benyttes forskellige scripts, Ansible, deploymentsystemer.

Cartridge håndterer selv konfigurationen af vshard, baseret på sin egen distribuerede konfiguration. I bund og grund er det en simpel YAML-fil, hvis kopi opbevares i hver Tarantool-instans. Forenklingen ligger i, at frameworket selv overvåger sin konfiguration og sikrer, at den er ens overalt.

For det andet handler det igen om bekvemmelighed. Vshard-konfigurationen har ingen relation til udviklingen af forretningslogik og distraherer programmøren fra arbejdet. Når vi diskuterer arkitekturen for et givent projekt, drejer det sig oftest om individuelle komponenter og deres interaktion. Det er for tidligt at tænke på at starte et cluster med 3 datacentre.

Vi har gentagne gange arbejdet med disse problemer, og på et tidspunkt fandt vi en tilgang, der gør arbejdet med applikationen mere ligetil i hele dens livscyklus: oprettelse, udvikling, test, CI/CD, vedligeholdelse.

Cartridge introducerer begrebet rolle for hver proces i Tarantool. Roller er det koncept, der gør det muligt for udvikleren at fokusere på at skrive kode. Alle roller i projektet kan køres på en enkelt instans af Tarantool, og til testformål vil det være tilstrækkeligt.

Hovedfunktioner i Tarantool Cartridge:

automatiseret orkestrering af klyngen;
udvidelse af applikationens funktionalitet med nye roller;
applikationsskabelon til udvikling og distribution;
indbygget automatisk sharding;
integration med testframeworket Luatest;
styring af klyngen via WebUI og API;
pakke- og deployværktøjer.

Hej, verden!

Jeg kan ikke vente med at vise frameworket, så vi sparer arkitekturdiskussionen til senere og starter med det enkle. Hvis vi antager, at Tarantool allerede er installeret, er der kun tilbage at gøre:

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

Disse to kommandoer vil installere kommandolinjeværktøjer og gøre det muligt at oprette din første applikation fra en skabelon:

$ cartridge create --name myapp

Og her er hvad vi får:

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/

Dette er et git-repositorium med en færdig "Hello, World!" applikation. Lad os straks prøve at køre den, efter at vi har installeret afhængigheder (inklusive selve frameworket):

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

Så vi har en node af den kommende sharded applikation kørende. Den nysgerrige bruger kan straks åbne webgrænsefladen, konfigurere klyngen fra en node med musen og nyde resultatet, men glæden må vente. Indtil videre kan applikationen ikke gøre noget nyttigt, så jeg vil tale om deployment senere, men nu er det tid til at skrive kode.

Udvikling af applikationer

Forestil dig, at vi designer et projekt, der skal modtage data, gemme dem og generere en rapport én gang om dagen.

Vi begynder at skitsere diagrammet og placerer tre komponenter: gateway, storage og scheduler. Vi arbejder videre med arkitekturen. Da vi bruger vshard som lager, tilføjer vi vshard-router og vshard-storage til diagrammet. Hverken gateway eller scheduler vil få adgang til lageret direkte; det vil routeren gøre, som er netop hvad den er til.

Denne skema afspejler stadig ikke helt præcist, hvad vi skal skabe i projektet, fordi komponenterne ser abstrakte ud. Vi skal også se på, hvordan det projiceres på den virkelige Tarantool — lad os gruppere vores komponenter efter processer.

Det giver ikke mening at holde vshard-router og gateway på separate instanser. Hvorfor skal vi gå gennem netværket unødigt, når det alligevel er en del af routerens opgaver? De bør køre inden for én proces. Det vil sige, at både gateway, vshard.router.cfg initialiseres i én proces, og lad dem interagere lokalt.

I designfasen var det praktisk at arbejde med tre komponenter, men som udvikler ønsker jeg ikke at bekymre mig om at køre tre instanser af Tarantool, mens jeg skriver kode. Jeg har brug for at køre tests og sikre, at jeg har skrevet gateway korrekt. Eller måske vil jeg demonstrere en funktion for mine kolleger. Hvorfor skulle jeg bøvle med at implementere tre instanser? Således blev konceptet med roller født. En rolle er et almindeligt Lua-modul, hvis livscyklus styres af Cartridge. I dette eksempel er der fire — gateway, router, storage, scheduler. I et andet projekt kan der være flere. Alle roller kan køres i én proces, og det vil være tilstrækkeligt.

Når det kommer til implementering i staging eller produktion, vil vi tildele hver Tarantool-proces sit eget sæt roller afhængigt af den hardware, der er tilgængelig:

Topology Management

Oplysninger om, hvor hvilke roller der kører, skal opbevares et sted. Og dette 'et sted' er den distribuerede konfiguration, som jeg allerede har nævnt tidligere. Det vigtigste i den er cluster-topologien. Her ses 3 replikationsgrupper med 5 Tarantool-processer:

Vi ønsker ikke at miste data, så vi tager stor omhu med informationerne om de kørende processer. Cartridge overvåger konfigurationen ved hjælp af en to-faset commit. Så snart vi ønsker at opdatere konfigurationen, kontrollerer den først tilgængeligheden af alle instanser og deres parathed til at modtage den nye konfiguration. Herefter anvendes konfigurationen i anden fase. Dermed, selv hvis en instans midlertidigt er utilgængelig, vil der ikke ske noget alvorligt. Konfigurationen vil blot ikke blive anvendt, og du vil på forhånd se en fejl.

I sektionen for topologi er der også angivet en vigtig parameter, nemlig lederen af hver replikationsgruppe. Normalt er dette den instans, hvortil der skrives. De andre er ofte read-only, selvom der kan være undtagelser. Nogle gange er modige udviklere ikke bange for konflikter og kan skrive data til flere replikaer parallelt, men der er visse operationer, der under ingen omstændigheder bør udføres to gange. Dette for det formål har vi en leder-flag.

Rolles liv

For at en abstrakt rolle kan eksistere i en sådan arkitektur, skal rammeværket på en eller anden måde styre dem. Naturligvis sker styringen uden at genstarte Tarantool-processen. Der findes 4 callbacks til rolleadministration. Cartridge vil selv kalde dem afhængigt af det, der er skrevet i den distribuerede konfiguration, og dermed anvende konfigurationen til de specifikke roller.

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

Hver rolle har en funktion init. Den kaldes én gang enten ved aktivering af rollen eller ved genstart af Tarantool. Her kan man eksempelvis nemt initialisere box.space.create, eller scheduler kan starte en eller anden baggrundsfiber, som udfører opgaver med bestemte tidsintervaller.

Én funktion init kan være utilstrækkelig. Cartridge tillader roller at bruge den distribuerede konfiguration, som den benytter til at gemme topologien. Vi kan i denne konfiguration erklære en ny sektion og opbevare et fragment af forretningskonfigurationen i den. I mit eksempel kan dette være dataskemaet eller indstillingerne for tidsplanen til rollen scheduler.

Klyngen kalder validate_config og apply_config ved hver ændring af den distribuerede konfiguration. Når konfigurationen anvendes med to-phased commit, kontrollerer klyngen, at hver rolle er klar til at acceptere denne nye konfiguration, og informerer brugeren om en fejl, hvis nødvendigt. Når alle er enige om, at konfigurationen er normal, udføres apply_config.

Derudover har rollerne en metode stop, der er nødvendig for at rydde op efter rolleaktivitetens resultater. Hvis vi siger, at scheduler ikke længere er nødvendig på denne server, kan den stoppe de fibere, som den har startet med hjælp af init.

Roller kan interagere med hinanden. Vi er vant til at skrive funktionsopkald i Lua, men det kan ske, at den rolle, vi har brug for, ikke er til stede i den pågældende proces. For at lette netværksanmodninger bruger vi et hjælpmodule, rpc (remote procedure call), der er bygget på standard netbox'en indbygget i Tarantool. Dette kan være nyttigt, hvis, for eksempel, din gateway ønsker at anmode scheduler om at udføre en opgave lige nu i stedet for at vente i et døgn.

En anden vigtig faktor er at sikre fejltolerance. Til overvågning af sundhed i Cartridge bruges SWIM-protokollen. [4]Kort sagt, så udveksler processerne "rygter" med hinanden via UDP - hver proces fortæller sine naboer de seneste nyheder, og de svarer. Hvis der pludselig ikke kom et svar, begynder Tarantool at mistænke, at der er noget galt, og efter et stykke tid erklærer den døden og begynder at fortælle alle i nærheden denne nyhed.

Baseret på denne protokol organiserer Cartridge automatisk håndtering af fejl. Hver proces overvåger sit miljø, og hvis lederen pludselig holder op med at svare, kan en replica tage hans rolle på sig, og Cartridge konfigurerer de kørende roller derefter.

Her må man være forsigtig, fordi hyppig skift frem og tilbage kan føre til datakonflikter under replikation. Det er selvfølgelig ikke en god idé at tænde for automatisk failover uden videre. Man skal have en klar forståelse af, hvad der foregår, og være sikre på, at replikationen ikke går i stykker, når lederen genopstår og får sin krone tilbage.

Fra alt, hvad der er sagt, kan man få indtrykket af, at rollerne ligner mikrotjenester. På en måde er de det, kun som moduler inden for Tarantool-processer. Men der er også en række væsentlige forskelle. For det første skal alle roller i projektet leve i én kodebase. Og alle Tarantool-processer skal startes fra én kodebase for at undgå overraskelser som de situationer, hvor vi prøver at initialisere scheduler, men den simpelthen ikke er til stede. Desuden bør der ikke være forskelle i kodeversioner, fordi systemets adfærd i sådan en situation er meget svær at forudsige og fejlfinde.

I modsætning til Docker kan vi ikke bare tage et 'billede' af en rolle, tage det til en anden maskine og starte det der. Vores roller er ikke så isolerede som Docker-containere. Vi kan heller ikke køre to identiske roller på én instans. En rolle eksisterer enten, eller den gør ikke; på sin vis er det et singleton. Og for det tredje skal rollerne inden for hele replikationsgruppen være ens, for ellers ville det være absurd — dataene er ens, men konfigurationen er forskellig.

Udrulningsværktøjer

Jeg lovede at vise, hvordan Cartridge hjælper med at udrulle applikationer. For at gøre livet lettere for alle pakker rammeværket RPM-pakker:

$ cartridge pack rpm myapp -- pakker for os .\/myapp-0.1.0-1.rpm
$ sudo yum install .\/myapp-0.1.0-1.rpm

Den installerede pakke indeholder næsten alt nødvendigt: både applikationen og de installerede Lua-afhængigheder. Tarantool vil også blive installeret på serveren som en afhængighed af RPM-pakken, og vores service er klar til at starte. Dette gøres gennem systemd, men først skal der skrives en smule konfiguration. Mindst skal vi angive URI for hver proces. Tre eksempler er tilstrækkelige.

$ 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

Her er der en interessant nuance. I stedet for kun at angive porten for binærprotokollen, angiver vi den offentlige adresse for processen helt, inklusive hostname. Dette er nødvendigt for, at cluster-noderne ved, hvordan de skal forbinde med hinanden. Det er en dårlig idé at bruge adressen 0.0.0.0 som advertise_uri; det skal være en ekstern IP-adresse, ikke en bind-socket. Uden dette vil intet fungere, og derfor vil Cartridge simpelthen ikke tillade at starte en node med et forkert advertise_uri.

Nu hvor konfigurationen er klar, kan processerne startes. Da en almindelig systemd-enhed ikke tillader at starte mere end én proces, bruger applikationerne på Cartridge såkaldte instantiated-enheder, som fungerer sådan her:

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

I konfigurationen har vi angivet HTTP-porten, hvor Cartridge leverer webgrænsefladen — 8080. Lad os gå ind på den og se:

Vi ser, at processerne er startet, men endnu ikke konfigureret. Patronen ved endnu ikke, hvem der skal replikere med hvem og kan ikke træffe beslutninger selv, derfor venter den på vores handlinger. Vores valg er ikke stort: Livet for det nye cluster starter med konfigurationen af den første node. Derefter tilføjer vi de andre til clusteren, tildeler dem roller, og så kan implementeringen betragtes som vellykket.