Vi alla Àlskar historier. Vi gillar att sitta vid lÀgerelden och berÀtta om vÄra tidigare segrar, strider eller bara om vÄr erfarenhet.
Idag Àr just en sÄdan dag. Och Àven om du inte sitter vid en lÀgerelden, har vi en historia för dig. Historien om hur vi började arbeta med lagring pÄ Tarantool.
En gÄng för lÀnge sedan fanns det ett par "monoliter" i vÄrt företag och ett gemensamt "tak" som dessa monoliter lÄngsamt men sÀkert nÀrmade sig, vilket begrÀnsade vÄr företags tillvÀxt och utveckling. Och det fanns en tydlig insikt: en dag skulle vi hÄrt stöta mot detta tak.
Nu rÄder en ideologi av separation av allt och alla, frÄn utrustning till affÀrslogik. Som ett resultat har vi till exempel tvÄ datacenter som Àr praktiskt taget oberoende pÄ nÀtverksnivÄ. Men dÄ var allt helt annorlunda.
Idag finns det massor av verktyg och medel för att göra Àndringar i form av CI/CD, K8S och sÄ vidare. Under den "monolitiska" tiden behövde vi inte sÄ mÄnga frÀmmande ord. Det rÀckte med att bara justera "lagringen" i databasen.
Men tiden gick framÄt, och mÀngden förfrÄgningar lÄg i linje med det, vilket ibland sköt upp RPS över vÄra förmÄgor. NÀr vi intog marknaden i CIS-lÀnderna sjönk belastningen pÄ DB-processorn för den första monoliten aldrig under 90 %, med RPS som höll sig pÄ nivÄer runt 2400. Och det var inte bara smÄ förfrÄgningar, utan stora förfrÄgningar med massor av kontroller och JOIN:s som kunde strÀcka sig nÀstan över hÀlften av datan mot en stor IO.
NĂ€r riktiga utförsĂ€ljningar pĂ„ "Svarta fredagen" började dyka upp â och Wildberries var en av de första i Ryssland att genomföra dem â blev situationen riktigt sorglig. För belastningen pĂ„ sĂ„dana dagar ökar tre gĂ„nger.
Ă
h, dessa "monolitiska tider"! Jag Àr sÀker pÄ att du ocksÄ har stött pÄ liknande situationer och fortfarande inte kan förstÄ hur det kunde hÀnda dig.
Vad kan man göra â mode Ă€r ocksĂ„ förknippat med teknik. För ungefĂ€r fem Ă„r sedan var vi tvungna att ompröva en av dessa mode genom att ha en webbplats pĂ„ .NET och MS SQL-server, som noga bevarade all logik för webbplatsens funktion. Den bevarade sĂ„ noga att det blev en lĂ„ng och helt osmidig uppgift att dela upp en sĂ„dan monolit.
En liten avstickare.
PÄ olika typer av evenemang sÀger jag: "Om du inte har delat upp monoliten, sÄ har du inte vÀxt!" Jag Àr intresserad av din Äsikt om detta, skriv gÀrna ner den i kommentarerna.
Och Äskan dÄnade
LÄt oss Äterkomma till vÄr "stapel". För att fördela belastningen av "monolitisk" funktionalitet, beslutade vi att dela upp systemet i mikrotjÀnster baserade pÄ opensource-teknologier. Eftersom, Ätminstone, deras skalning Àr billigare. Och vi visste till 100 % att vi skulle behöva skala (och en hel del). Redan vid den tidpunkten hade vi lyckats expandera till grannlÀnder, och antalet registreringar, liksom antalet bestÀllningar, började vÀxa Ànnu mer.
Genom att analysera de första kandidaterna för att gĂ„ frĂ„n monolit till mikrotjĂ€nster, insĂ„g vi att i 80 % av fallen kom 99 % av skrivoperationerna frĂ„n back office-system, medan lĂ€soperationerna kom frĂ„n fronten. Detta gĂ€llde i första hand tvĂ„ viktiga delsystem för oss â anvĂ€ndardata och systemet för att berĂ€kna det slutgiltiga priset pĂ„ varor baserat pĂ„ information om ytterligare kundrabatter och kuponger.
Som en sidokommentar. Det Ă€r skrĂ€mmande att tĂ€nka pĂ„, men förutom de ovan nĂ€mnda delsystemen, flyttades Ă€ven produktkataloger, kundvagnar, varusöksystem, filtreringssystem för produktkataloger och olika typer av rekommendationssystem ut frĂ„n vĂ„r monolit. För var och en av dem finns det separata klasser av snĂ€vt inriktade system, men en gĂ„ng levde de alla i ett och samma âhusâ.
Vi planerade att flytta information om vÄra kunder till ett shardat system. Att flytta funktionaliteten för att berÀkna det slutgiltiga priset pÄ varor krÀvde god skalbarhet för lÀsning, eftersom det skapade den största belastningen nÀr det gÀller RPS och var det mest komplexa att genomföra för databasen (mycket data Àr inblandad i berÀkningsprocessen).
Som en följd av detta föddes en plan som fungerar bra med Tarantool.
Vid den tiden valdes scheman med flera datacenter för att arbeta med mikrotjÀnster pÄ virtuella och hÄrdvarumaskiner. Som visas i bilderna anvÀndes alternativ för Tarantool-replikering i bÄde master-master- och master-slave-lÀge.
Arkitektur. Alternativ 1. AnvÀndartjÀnst
För nÀrvarande Àr detta 24 shardar, dÀr varje en har 2 instanser (en i varje DC), alla i master-master lÀge.
Ovan databasen finns applikationer som interagerar med databasens repliker. Applikationerna arbetar med Tarantool genom vÄrt anpassade bibliotek, som implementerar grÀnssnittet för Go-drivrutinen för Tarantool. Det ser alla repliker och kan arbeta med master för bÄde lÀsning och skrivning. I grunden implementerar det modellen för replica set, dÀr logik för att vÀlja repliker, utföra omförsök, circuit breaker och rate limit har lagts till.
Det finns möjlighet att konfigurera politik för val av replik i förhÄllande till shard. Till exempel, rund-robin.
Arkitektur. Alternativ 2. TjÀnst för berÀkning av slutpris för produkter.
För nÄgra mÄnader sedan gick majoriteten av begÀrningarna för berÀkning av slutpris för produkter till en ny tjÀnst, som i princip fungerar utan databaser, men för en tid sedan bearbetade det hela 100% av begÀrningarna med Tarantool under huven.
Databasen för tjÀnsten bestÄr av 4 master, som synkronisatorn samlar data i, och varje av dessa master distribuerar data till readonly-repliker genom replikering. Varje master har ungefÀr 15 sÄdana repliker.
BÄde i det första och andra schemat kan applikationen hÀmta data frÄn den andra vid otillgÀnglighet av en datacenter.
Det Àr vÀrt att notera att replikeringen i Tarantool Àr ganska flexibel och kan konfigureras i runtime. I andra system har det funnits komplikationer. Till exempel krÀver förÀndringar av parametrarna max_wal_senders och max_replication_slots i PostgreSQL omstart av master, vilket i vissa fall kan leda till avbrott av anslutningar mellan applikationen och DBMS.
Sök och ni skall finna!
Varför valde vi ett otypiskt sÀtt istÀllet för att göra "som normala mÀnniskor"? Beror pÄ vad man anser vara normalt. MÄnga gör faktiskt en kluster av Mongo och sprider det över tre geo-distribuerade datacenter.
Vid den tiden hade vi redan tvÄ projekt pÄ Redis. Den första var en cache, och den andra var ett persistent lagringssystem för mindre kritiska data. Det var ganska komplicerat, delvis pÄ grund av vÄra egna misstag. Ibland lÄg ganska stora volymer i nyckeln, och dÄ och dÄ fick webbplatsen problem. Detta system anvÀnde vi i en master-slave-konfiguration. Det fanns mÄnga tillfÀllen dÄ nÄgot hÀnde med master och replikeringen bröts.
Det vill sÀga, Redis Àr bra för stateless-uppgifter, inte för stateful. I princip kunde den lösa de flesta uppgifter, men endast om det handlade om key-value-lösningar med ett par index. Men Redis hade vid den tiden ganska stora brister nÀr det kom till persistens och replikering. Dessutom fanns det klagomÄl pÄ prestandan.
Vi övervÀgde MySQL och PostgreSQL. Men den första passade oss inte riktigt, medan den andra Àr en ganska avancerad produkt, och det skulle vara oklokt att bygga enkla tjÀnster pÄ den.
Vi testade RIAK, Cassandra och till och med en grafdatabas. Allt detta Àr ganska nischade lösningar som inte passade som ett allmÀnt universellt verktyg för att skapa tjÀnster.
Till slut stannade vi vid Tarantool.
Vi vÀnde oss till den nÀr den var i version 1.6. Vi blev intresserade av dess symbios av key-value och funktionaliteten hos en relationsdatabas. Det finns sekundÀra index, transaktioner och spacet, som Àr som tabeller, men inte enkla, man kan lagra ett varierande antal kolumner i dem. Men killer-funktionen hos Tarantool var de sekundÀra indexen i kombination med key-value och transaktionalitet.
Det russisktalande communityt, som var lyhört och alltid redo att hjÀlpa till i chatten, spelade ocksÄ en stor roll. Vi anvÀnde detta aktivt och levde nÀstan i chatten. Och man fÄr inte glömma den anstÀndiga persistensen utan tydliga brister och fel. Om man ser pÄ vÄr historia med Tarantool sÄ hade vi mÄnga problem med replikering, men vi har aldrig förlorat nÄgra data pÄ grund av dess fel!
Implementeringen började trögt.
Vid den tiden var vÄrt huvudsakliga utvecklingsstack .NET, för vilket det inte fanns nÄgon anslutning för Tarantool. Vi började genast arbeta med Go. Det gick ganska bra med Lua ocksÄ. Det största problemet dÄ var med felsökning: i .NET fungerar det utmÀrkt, men att gÄ frÄn det till embedded Lua, nÀr man knappt har nÄgot annat Àn loggar för felsökning, var ganska svÄrt. Dessutom bröt replikeringen plötsligt ihop ibland, sÄ vi var tvungna att sÀtta oss in i hur motorn Tarantool fungerar. Chatten hjÀlpte oss med detta, i mindre utstrÀckning dokumentationen, och ibland tittade vi pÄ koden. Vid den tiden var dokumentationen inte sÄ bra.
SÄ under flera mÄnader lyckades vi samla erfarenhet och fÄ bra resultat med Tarantool. Vi skapade en referens i git som hjÀlpte till med utvecklingen av nya mikrotjÀnster. Till exempel, nÀr uppgiften dök upp: att skapa en ny mikrotjÀnst, sÄ tittade utvecklaren pÄ koden för den referenslösning som fanns i repositoryt, och skapandet av den nya tog inte mer Àn en vecka.
Det var speciella tider. Tja, dÄ kunde man gÄ fram till administratören vid det angrÀnsande bordet och be: "Ge mig en virtual machine". Efter ungefÀr trettio minuter hade du maskinen. Du kopplade sjÀlv upp dig, installerade allt, och de dirigerade trafik till den.
Idag fungerar det inte lÀngre sÄ: man mÄste sÀtta upp övervakning, loggning, tÀcka funktionaliteten med tester, bestÀlla en virtuell maskin eller leverans i Kubernetes, etc. Generellt sÀtt Àr det bÀttre sÄ, Àven om det tar lÀngre tid och Àr mer besvÀrligt.
Dela och hÀrska. Hur stÄr det till med Lua?
Det fanns en allvarlig dilemma: vissa team lyckades inte pÄ ett tillförlitligt sÀtt rulla ut Àndringar i tjÀnsten med mycket logik pÄ Lua. Ofta resulterade det i att tjÀnsten blev icke-fungerande.
Det vill sÀga att utvecklarna förbereder nÄgon Àndring. Tarantool börjar göra migreringen, medan replikan fortfarande har gammal kod; nÄgon DDL kommer in via replikering, nÄgot annat, och koden kraschar helt enkelt eftersom det inte beaktas. Resultatet var att proceduren för uppdatering för administratörerna var nedskriven pÄ ett A4-papper: stoppa replikeringen, uppdatera detta, slÄ pÄ replikeringen, stÀng hÀr, uppdatera dÀr. En riktig mardröm!
Som ett resultat försöker vi nu oftast att inte göra nÄgot med Lua. Vi anvÀnder bara iproto (ett binÀrt protokoll för att interagera med servern), och that's it. Kanske Àr det en brist pÄ kunskap hos utvecklarna, men ur det perspektivet verkar systemet komplicerat.
Vi följer inte alltid blint detta scenario. Idag har vi ingen svart eller vit: antingen allt pÄ Lua, eller allt pÄ Go. Vi förstÄr redan hur vi kan kombinera för att sedan inte fÄ problem med migreringen.
Var finns Tarantool just nu?
Tarantool anvÀnds i tjÀnsten för berÀkning av slutförsÀljningspriser för varor med rabattkuponger, Àven kÀnd som «Promo-Tizer». Som nÀmnts tidigare, sÄ gÄr det tjÀnsten nu i pension: den ersÀtts av en ny katalogtjÀnst med förberÀknade priser, men för sex mÄnader sedan gjordes alla berÀkningar i «Promo-Tizer». Tidigare var hÀlften av dess logik skriven i Lua. För tvÄ Är sedan gjordes tjÀnsten till ett lagringssystem, och logiken skrivs om i Go, eftersom mekanismen för rabatter har Àndrats nÄgot och tjÀnsten saknade prestanda.
En av de mest kritiska tjÀnsterna Àr anvÀndarprofilen. Det vill sÀga, alla Wildberries-anvÀndare lagras i Tarantool, och det finns ungefÀr 50 miljoner av dem. Systemet Àr shardat efter anvÀndar-ID och spritt över flera datacenter med en koppling till Go-tjÀnster.
NÀr det gÀller RPS var «Promo-Tizer» en gÄng ledande, upp till 6000 förfrÄgningar. Vid nÄgot tillfÀlle hade vi 50-60 instanser. Nu Àr anvÀndarprofiler ledande med cirka 12 000 RPS. I denna tjÀnst tillÀmpas anpassad shardning med uppdelning enligt intervall av anvÀndar-ID. TjÀnsten hanterar mer Àn 20 maskiner, men det Àr för mÄnga, vi planerar att minska de tilldelade resurserna eftersom den har tillrÀcklig kapacitet med 4-5 maskiner.
Sessionsservicen Àr vÄr första tjÀnst pÄ vshard och Cartridge. Konfigurationen av vshard och uppdateringen av Cartridge krÀvde en del arbetsinsats frÄn oss, men i slutÀndan lyckades vi.
TjÀnsten för att visa olika banners pÄ webbplatsen och i mobilapplikationen var en av de första som slÀpptes direkt pÄ Tarantool. Denna tjÀnst Àr anmÀrkningsvÀrd eftersom den har funnits i cirka 6-7 Är, den Àr fortfarande i drift och har aldrig behövt startas om. Master-master-replikering har anvÀnts. Aldrig har nÄgot gÄtt sönder.
Det finns ett exempel pÄ anvÀndning av Tarantool för snabb referensfunktionalitet i lagersystemet för att snabbt verifiera information i vissa fall. Vi försökte anvÀnda Redis för detta ÀndamÄl, men datan i minnet tog upp mer plats Àn i Tarantool.
TjÀnster för vÀntelista, kundprenumerationer, trendiga stories och uppskjutna varor fungerar ocksÄ med Tarantool. Den sistnÀmnda tjÀnsten tar upp cirka 120 GB i minnet. Detta Àr den mest omfattande tjÀnsten av de som nÀmns ovan.
Slutsats
Tack vare sekundĂ€ra index i kombination med nyckel-vĂ€rde och transaktionsförmĂ„ga passar Tarantool utmĂ€rkt för mikrotjĂ€nstarkitekturer. Men vi stötte pĂ„ svĂ„righeter nĂ€r vi rullade ut Ă€ndringar i tjĂ€nster med mycket logik pĂ„ Lua â tjĂ€nsterna slutade ofta fungera. Vi lyckades inte övervinna detta, och med tiden kom vi fram till olika kombinationer av Lua och Go: vi vet nu nĂ€r vi ska anvĂ€nda det ena sprĂ„ket och nĂ€r det andra.
Vad mer att lÀsa om Àmnet
- Vi bygger en högbelastad applikation frÄn grunden pÄ Tarantool
- Ett pÄlitligt val av ledaren inom Tarantool Cartridge
- Telegram-kanalen för Tarantool med produktnyheter
- Diskutera Tarantool i community-chatten
KĂ€lla: habr.com
