🥇Tarantool Cartridge: sharding av Lua-backend i tre rader

På Mail.ru Group har vi Tarantool — en applikationsserver i Lua, som även fungerar som en databas (eller tvärtom?). Den är snabb och fantastisk, men kapaciteten hos en enda server är trots allt inte oändlig. Vertikal skalning är inte heller en universallösning, så i Tarantool finns det verktyg för horisontell skalning — modulen vshard. [1]. Den låter dig shardera data över flera servrar, men det krävs en del arbete för att ställa in det och koppla på affärslogiken.

Bra nyheter: vi har lärt oss av våra misstag (till exempel [2], [3]) och utvecklat ännu ett ramverk som avsevärt förenklar lösningen på detta problem.

Tarantool Cartridge — är ett nytt ramverk för utveckling av komplexa distribuerade system. Det gör att du kan fokusera på att skriva affärslogik istället för att lösa infrastrukturella problem. Under rubriken berättar jag hur detta ramverk fungerar och hur man skriver distribuerade tjänster med dess hjälp.

Men vad är egentligen problemet?

Vi har en tarantula, vi har vshard — vad mer kan man önska?

För det första handlar det om bekvämlighet. Vshard-konfigurationen ställs in via Lua-tabeller. För att ett distribuerat system bestående av flera Tarantool-processer ska fungera korrekt måste konfigurationen vara densamma överallt. Ingen vill hantera detta manuellt. Därför används alla möjliga skript, Ansible, och distributionssystem.

Cartridge hanterar själv vshard-konfigurationen, och gör det baserat på sin egen distribuerade konfiguration. I princip är det en enkel YAML-fil, vars kopia lagras i varje instans av Tarantool. Förenklingen ligger i att ramverket själv övervakar sin konfiguration och ser till att den är densamma överallt.

För det andra handlar det återigen om bekvämlighet. Vshard-konfigurationen har inget att göra med utvecklingen av affärslogik och distraherar bara programmeraren från arbetet. När vi diskuterar arkitekturen för ett visst projekt handlar det oftast om enskilda komponenter och deras interaktion. Det är för tidigt att börja tänka på distributionen av klustret över 3 datacenter.

Vi har stött på dessa problem gång på gång, och vid något tillfälle lyckades vi utveckla en metod som förenklar arbetet med applikationen genom hela dess livscykel: skapande, utveckling, testning, CI/CD, underhåll.

Cartridge introducerar begreppet roller för varje process i Tarantool. Roller är ett koncept som gör det möjligt för utvecklaren att fokusera på att skriva kod. Alla roller som finns i projektet kan köras på en enda instans av Tarantool, och för tester räcker detta.

Huvudfunktioner i Tarantool Cartridge:

automatiserad orkestrering av klustret;
utökning av applikationens funktionalitet med nya roller;
applikationsmall för utveckling och distribution;
inbyggd automatisk sharding;
integration med testramverket Luatest;
hantering av klustret med hjälp av WebUI och API;
verktyg för paketering och distribution.

Hello, World!

Jag ser fram emot att visa själva ramverket, så vi sparar beskrivningen av arkitekturen till senare och börjar enkelt. Om vi antar att Tarantool redan är installerat, återstår endast att göra

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

Dessa två kommandon installerar kommandoradsverktyg och låter dig skapa din första applikation från en mall:

$ cartridge create --name myapp

Och här är vad 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/

Detta är ett git-repo med en färdig "Hello, World!"-applikation. Låt oss omedelbart försöka köra den, efter att ha installerat beroenden (inklusive själva ramverket):

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

Så, vi har en nod av den framtida sharded-applikationen igång. En nyfiken användare kan omedelbart öppna webbingången, konfigurera klustret från en nod med musen och njuta av resultatet, men det är för tidigt att glädjas. Just nu kan applikationen inte göra något nyttigt, så jag kommer att berätta om distribution senare, men nu är det dags att skriva kod.

Applikationsutveckling

Tänk dig att vi designar ett projekt som ska ta emot data, spara dem och en gång om dagen generera en rapport.

Vi börjar skissa på en schemat och placerar tre komponenter på den: gateway, storage och scheduler. Vi går vidare med arkitekturen. Eftersom vi använder vshard som lagring, lägger vi till vshard-router och vshard-storage i schemat. Varken gateway eller scheduler kommer att kontakta lagringssystemet direkt, det är därför vi har en router, den är skapad just för det.

Denna schema återspeglar fortfarande inte riktigt vad vi ska skapa i projektet, eftersom komponenterna ser abstrakta ut. Vi behöver också titta på hur detta projiceras på verklig Tarantool — vi grupperar våra komponenter efter processer.

Att hålla vshard-router och gateway på separata instanser ger ingen mening. Varför ska vi gå över nätverket om det redan ingår i routerens uppgifter? De bör köras inom samma process. Det vill säga att både gateway och vshard.router.cfg initieras i en och samma process, så att de kan interagera lokalt.

I designfasen var det praktiskt att arbeta med tre komponenter, men som utvecklare vill jag inte tänka på att starta tre instanser av Tarantool medan jag skriver koden. Jag behöver köra tester och kontrollera att jag har skrivit gateway rätt. Eller kanske vill jag visa en funktion för kollegor. Varför ska jag plågas med att deployera tre instanser? Därför föddes konceptet med roller. En roll är en vanlig Lua-modul vars livscykel hanteras av Cartridge. I detta exempel finns det fyra — gateway, router, storage, scheduler. I ett annat projekt kan det finnas fler. Alla roller kan köras i samma process, och det räcker.

Och när det kommer till deployering i staging eller produktion, kommer vi då att tilldela varje Tarantool-process sin egen uppsättning roller beroende på hårdvarufunktioner:

Låt oss kombinera våra nya instanser i en replicaset

Information om var vilka roller är igång måste lagras någonstans. Och detta "någonstans" är den distribuerade konfigurationen som jag nämnde tidigare. Det viktigaste i den är klustrets topologi. Här visas 3 replikgrupper av 5 Tarantool-processer:

Vi vill inte förlora data, så vi är försiktiga med informationen om de aktiva processerna. Cartridge övervakar konfigurationen med hjälp av en tvåfascommit. Så snart vi vill uppdatera konfigurationen kontrollerar den först tillgängligheten av alla instanser och deras beredskap att ta emot den nya konfigurationen. Därefter tillämpas konfigurationsfilen i den andra fasen. På så sätt, även om en instans tillfälligt är otillgänglig, händer ingenting allvarligt. Konfigurationen tillämpas helt enkelt inte och du kommer att se felet i förväg.

I sektionen för topologi anges också en så viktig parameter som ledaren för varje replikationsgrupp. Vanligtvis är detta den instans där skrivningar görs. De andra är oftast read-only, även om det här kan finnas undantag. Ibland räds modiga utvecklare inte för konflikter och kan skriva data på flera repliker parallellt, men det finns vissa operationer som under alla omständigheter inte får utföras två gånger. Det finns en indikator för ledaren.

Rollernas liv

För att en abstrakt roll ska kunna existera i en sådan arkitektur måste ramverket på något sätt hantera dem. Självklart sker hanteringen utan att processerna i Tarantool startas om. Det finns 4 callbacks för att hantera roller. Cartridge kommer att anropa dem beroende på vad som står i dess distribuerade konfiguration, och applicera konfigurationen på specifika roller.

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

Varje roll har en funktion init. Den anropas en gång antingen vid aktivering av rollen eller vid omstart av Tarantool. Där kan man enkelt initialisera box.space.create, eller så kan schemaläggaren köra en bakgrundsfiber som kommer att utföra arbete med vissa tidsintervall.

En funktion init kan vara otillräcklig. Cartridge gör det möjligt för roller att använda den distribuerade konfigurationen som den använder för att lagra topologin. Vi kan deklarera en ny sektion i denna konfiguration och lagra en del av affärskonfigurationen där. I mitt exempel kan detta vara en databasstruktur eller inställningar för schemaläggaren.

Klusteret anropar validate_config och apply_config vid varje förändring av den distribuerade konfigurationen. När konfigurationen appliceras med tvåfaskommitté, kontrollerar klusteret att varje roll är redo att ta emot denna nya konfiguration och meddelar vid behov användaren om ett fel. När alla är överens om att konfigurationen är normal, utförs apply_config.

Rollerna har också en metod stop, som behövs för att rensa upp resultatet av rollens livscykel. Om vi säger att schemaläggaren inte längre behövs på denna server kan den stoppa de fiber som den startade med hjälp av init.

Roller kan interagera med varandra. Vi är vana vid att skriva funktionsanrop i Lua, men det kan hända att den roll vi behöver inte är tillgänglig i processen. För att underlätta nätverksanrop använder vi hjälpmodulen rpc (remote procedure call), som bygger på den standardiserade netbox som är integrerad i Tarantool. Detta kan vara användbart om till exempel din gateway vill be scheduler att utföra en uppgift omedelbart istället för att vänta i ett dygn.

En annan viktig sak är att säkerställa fel tolerans. För övervakning av hälsan används protokollet SWIM i Cartridge. [4]. Om vi ska sammanfatta, så utbyter processerna "rykten" med varandra över UDP – varje process berättar för sina grannar det senaste nytt, och de svarar. Om ett svar plötsligt inte kommer, börjar Tarantool misstänka att något är fel, och efter en tid deklarerar det dödsfall och börjar sprida den nyheten till omgivningen.

Baserat på detta protokoll organiserar Cartridge automatisk hantering av fel. Varje process övervakar sin omgivning, och om ledaren plötsligt slutar svara kan en replik ta hans roll, och Cartridge konfigurerar de aktiva rollerna på lämpligt sätt.

Här behöver man vara försiktig, eftersom frekvent växling fram och tillbaka kan leda till datakonflikter vid replikering. Att aktivera automatisk failover utan noggrant övervägande är förstås inte att rekommendera. Man måste ha en tydlig förståelse för vad som pågår och vara säkra på att replikeringen inte kommer att gå sönder efter att ledaren återhämtat sig och fått kronan tillbaka.

Av allt som sagts kan man få intrycket att rollerna liknar mikrotjänster. På ett sätt är de verkligen det, bara som moduler inom Tarantools processer. Men det finns också ett antal grundläggande skillnader. För det första måste alla roller i projektet leva i en gemensam kodbas. Och alla Tarantool-processer måste startas från samma kodbas för att undvika överraskningar, som när vi försöker initiera scheduler men den helt enkelt inte finns. Man bör också undvika skillnader i kodversioner, eftersom systemets beteende i en sådan situation är mycket svårt att förutsäga och felsöka.

Till skillnad från Docker kan vi inte bara ta en "bild" av en roll, flytta den till en annan maskin och köra den där. Våra roller är inte lika isolerade som Docker-containrar. Vi kan heller inte köra två identiska roller på samma instans. Antingen finns rollen eller så gör den inte det, på ett sätt är det en singleton. För det tredje måste rollerna inom hela replikationsgruppen vara identiska, för annars skulle det vara absurt — data är densamma, men konfigurationen är olika.

Deployering verktyg

Jag lovade att visa hur Cartridge hjälper till att deployera applikationer. För att underlätta livet för andra paketerar ramverket RPM-paket:

$ cartridge pack rpm myapp -- paketerar för oss .\/myapp-0.1.0-1.rpm
$ sudo yum install .\/myapp-0.1.0-1.rpm

Det installerade paketet innehåller nästan allt som behövs: både applikationen och dess installerade Lua-beroenden. Tarantool kommer också att levereras till servern som en beroende av RPM-paketet, och vår tjänst är redo att starta. Detta görs genom systemd, men först behöver vi skriva lite konfiguration. Minst måste vi ange URI för varje process. Tre exempel är tillräckliga.

$ 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

Här finns en intressant detalj. Istället för att bara ange porten för det binära protokollet anger vi hela den offentliga adressen för processen inklusive värdnamnet. Detta är nödvändigt så att klusterknutarna vet hur de ska ansluta till varandra. Det är en dålig idé att använda adressen 0.0.0.0 som advertise_uri; detta bör vara en extern IP-adress, inte bind-socketen. Utan det kommer inget att fungera, så Cartridge kommer helt enkelt inte att tillåta oss att starta en nod med en felaktig advertise_uri.

Nu när konfigurationen är klar kan vi starta processerna. Eftersom en vanlig systemd-enhet inte tillåter att mer än en process startas, installerar applikationer på Cartridge så kallade instansierade enheter som fungerar så här:

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

I konfigurationen angav vi HTTP-porten där Cartridge tjänar webbgränssnittet — 8080. Låt oss gå dit och ta en titt:

Vi ser att processerna har startat, men de är ännu inte konfigurerade. Kartuschen vet fortfarande inte vem som ska replikeras med vem och kan därför inte fatta beslut självständigt, utan väntar på våra åtgärder. Vårt val är inte stort: livet för den nya klustret börjar med konfigurationen av den första noden. Sedan lägger vi till de andra till klustret, tilldelar dem roller, och då kan vi anse att distributionen är framgångsrikt avslutad.