{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Hur man slutar oroa sig och b\u00f6rjar leva utan ett monolit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hur
\n
\nVi alla \u00e4lskar historier. Vi gillar att sitta vid l\u00e4gerelden och ber\u00e4tta om v\u00e5ra tidigare segrar, strider eller bara om v\u00e5r erfarenhet.<\/p>\n

Idag \u00e4r just en s\u00e5dan dag. Och \u00e4ven om du inte sitter vid en l\u00e4gerelden, har vi en historia f\u00f6r dig. Historien om hur vi b\u00f6rjade arbeta med lagring p\u00e5 Tarantool.<\/p>\n

En g\u00e5ng f\u00f6r l\u00e4nge sedan fanns det ett par \"monoliter\" i v\u00e5rt f\u00f6retag och ett gemensamt \"tak\" som dessa monoliter l\u00e5ngsamt men s\u00e4kert n\u00e4rmade sig, vilket begr\u00e4nsade v\u00e5r f\u00f6retags tillv\u00e4xt och utveckling. Och det fanns en tydlig insikt: en dag skulle vi h\u00e5rt st\u00f6ta mot detta tak.
\n<\/a><\/noindex>
\nNu r\u00e5der en ideologi av separation av allt och alla, fr\u00e5n utrustning till aff\u00e4rslogik. Som ett resultat har vi till exempel tv\u00e5 datacenter som \u00e4r praktiskt taget oberoende p\u00e5 n\u00e4tverksniv\u00e5. Men d\u00e5 var allt helt annorlunda.<\/p>\n

Idag finns det massor av verktyg och medel f\u00f6r att g\u00f6ra \u00e4ndringar i form av CI\/CD, K8S och s\u00e5 vidare. Under den \"monolitiska\" tiden beh\u00f6vde vi inte s\u00e5 m\u00e5nga fr\u00e4mmande ord. Det r\u00e4ckte med att bara justera \"lagringen\" i databasen.<\/p>\n

Men tiden gick fram\u00e5t, och m\u00e4ngden f\u00f6rfr\u00e5gningar l\u00e5g i linje med det, vilket ibland sk\u00f6t upp RPS \u00f6ver v\u00e5ra f\u00f6rm\u00e5gor. N\u00e4r vi intog marknaden i CIS-l\u00e4nderna sj\u00f6nk belastningen p\u00e5 DB-processorn f\u00f6r den f\u00f6rsta monoliten aldrig under 90 %, med RPS som h\u00f6ll sig p\u00e5 niv\u00e5er runt 2400. Och det var inte bara sm\u00e5 f\u00f6rfr\u00e5gningar, utan stora f\u00f6rfr\u00e5gningar med massor av kontroller och JOIN:s som kunde str\u00e4cka sig n\u00e4stan \u00f6ver h\u00e4lften av datan mot en stor IO.<\/p>\n

N\u00e4r riktiga utf\u00f6rs\u00e4ljningar p\u00e5 \"Svarta fredagen\" b\u00f6rjade dyka upp \u2014 och Wildberries var en av de f\u00f6rsta i Ryssland att genomf\u00f6ra dem \u2014 blev situationen riktigt sorglig. F\u00f6r belastningen p\u00e5 s\u00e5dana dagar \u00f6kar tre g\u00e5nger.
\n\u00c5h, dessa \"monolitiska tider\"! Jag \u00e4r s\u00e4ker p\u00e5 att du ocks\u00e5 har st\u00f6tt p\u00e5 liknande situationer och fortfarande inte kan f\u00f6rst\u00e5 hur det kunde h\u00e4nda dig.<\/p>\n

Vad kan man g\u00f6ra \u2014 mode \u00e4r ocks\u00e5 f\u00f6rknippat med teknik. F\u00f6r ungef\u00e4r fem \u00e5r sedan var vi tvungna att ompr\u00f6va en av dessa mode genom att ha en webbplats p\u00e5 .NET och MS SQL-server, som noga bevarade all logik f\u00f6r webbplatsens funktion. Den bevarade s\u00e5 noga att det blev en l\u00e5ng och helt osmidig uppgift att dela upp en s\u00e5dan monolit.
\nEn liten avstickare. <\/p>\n

P\u00e5 olika typer av evenemang s\u00e4ger jag: \"Om du inte har delat upp monoliten, s\u00e5 har du inte v\u00e4xt!\" Jag \u00e4r intresserad av din \u00e5sikt om detta, skriv g\u00e4rna ner den i kommentarerna.<\/p>\n

Och \u00e5skan d\u00e5nade<\/h3>\n

\nL\u00e5t oss \u00e5terkomma till v\u00e5r \"stapel\". F\u00f6r att f\u00f6rdela belastningen av \"monolitisk\" funktionalitet, beslutade vi att dela upp systemet i mikrotj\u00e4nster baserade p\u00e5 opensource-teknologier. Eftersom, \u00e5tminstone, deras skalning \u00e4r billigare. Och vi visste till 100 % att vi skulle beh\u00f6va skala (och en hel del). Redan vid den tidpunkten hade vi lyckats expandera till grannl\u00e4nder, och antalet registreringar, liksom antalet best\u00e4llningar, b\u00f6rjade v\u00e4xa \u00e4nnu mer.<\/p>\n

Genom att analysera de f\u00f6rsta kandidaterna f\u00f6r att g\u00e5 fr\u00e5n monolit till mikrotj\u00e4nster, ins\u00e5g vi att i 80 % av fallen kom 99 % av skrivoperationerna fr\u00e5n back office-system, medan l\u00e4soperationerna kom fr\u00e5n fronten. Detta g\u00e4llde i f\u00f6rsta hand tv\u00e5 viktiga delsystem f\u00f6r oss \u2013 anv\u00e4ndardata och systemet f\u00f6r att ber\u00e4kna det slutgiltiga priset p\u00e5 varor baserat p\u00e5 information om ytterligare kundrabatter och kuponger.<\/p>\n

Som en sidokommentar. Det \u00e4r skr\u00e4mmande att t\u00e4nka p\u00e5, men f\u00f6rutom de ovan n\u00e4mnda delsystemen, flyttades \u00e4ven produktkataloger, kundvagnar, varus\u00f6ksystem, filtreringssystem f\u00f6r produktkataloger och olika typer av rekommendationssystem ut fr\u00e5n v\u00e5r monolit. F\u00f6r var och en av dem finns det separata klasser av sn\u00e4vt inriktade system, men en g\u00e5ng levde de alla i ett och samma \u2018hus\u2019. <\/p>\n

Vi planerade att flytta information om v\u00e5ra kunder till ett shardat system. Att flytta funktionaliteten f\u00f6r att ber\u00e4kna det slutgiltiga priset p\u00e5 varor kr\u00e4vde god skalbarhet f\u00f6r l\u00e4sning, eftersom det skapade den st\u00f6rsta belastningen n\u00e4r det g\u00e4ller RPS och var det mest komplexa att genomf\u00f6ra f\u00f6r databasen (mycket data \u00e4r inblandad i ber\u00e4kningsprocessen). <\/p>\n

Som en f\u00f6ljd av detta f\u00f6ddes en plan som fungerar bra med Tarantool.<\/p>\n

Vid den tiden valdes scheman med flera datacenter f\u00f6r att arbeta med mikrotj\u00e4nster p\u00e5 virtuella och h\u00e5rdvarumaskiner. Som visas i bilderna anv\u00e4ndes alternativ f\u00f6r Tarantool-replikering i b\u00e5de master-master- och master-slave-l\u00e4ge. <\/p>\n

\"Hur
\nArkitektur. Alternativ 1. Anv\u00e4ndartj\u00e4nst<\/i><\/p>\n

F\u00f6r n\u00e4rvarande \u00e4r detta 24 shardar, d\u00e4r varje en har 2 instanser (en i varje DC), alla i master-master l\u00e4ge.<\/p>\n

Ovan databasen finns applikationer som interagerar med databasens repliker. Applikationerna arbetar med Tarantool genom v\u00e5rt anpassade bibliotek, som implementerar gr\u00e4nssnittet f\u00f6r Go-drivrutinen f\u00f6r Tarantool. Det ser alla repliker och kan arbeta med master f\u00f6r b\u00e5de l\u00e4sning och skrivning. I grunden implementerar det modellen f\u00f6r replica set, d\u00e4r logik f\u00f6r att v\u00e4lja repliker, utf\u00f6ra omf\u00f6rs\u00f6k, circuit breaker och rate limit har lagts till.<\/p>\n

Det finns m\u00f6jlighet att konfigurera politik f\u00f6r val av replik i f\u00f6rh\u00e5llande till shard. Till exempel, rund-robin.<\/p>\n

\"Hur
\nArkitektur. Alternativ 2. Tj\u00e4nst f\u00f6r ber\u00e4kning av slutpris f\u00f6r produkter.<\/i><\/p>\n

F\u00f6r n\u00e5gra m\u00e5nader sedan gick majoriteten av beg\u00e4rningarna f\u00f6r ber\u00e4kning av slutpris f\u00f6r produkter till en ny tj\u00e4nst, som i princip fungerar utan databaser, men f\u00f6r en tid sedan bearbetade det hela 100% av beg\u00e4rningarna med Tarantool under huven.<\/p>\n

Databasen f\u00f6r tj\u00e4nsten best\u00e5r av 4 master, som synkronisatorn samlar data i, och varje av dessa master distribuerar data till readonly-repliker genom replikering. Varje master har ungef\u00e4r 15 s\u00e5dana repliker.<\/p>\n

B\u00e5de i det f\u00f6rsta och andra schemat kan applikationen h\u00e4mta data fr\u00e5n den andra vid otillg\u00e4nglighet av en datacenter.<\/p>\n

Det \u00e4r v\u00e4rt att notera att replikeringen i Tarantool \u00e4r ganska flexibel och kan konfigureras i runtime. I andra system har det funnits komplikationer. Till exempel kr\u00e4ver f\u00f6r\u00e4ndringar 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.<\/p>\n

S\u00f6k och ni skall finna!<\/h3>\n

\nVarf\u00f6r valde vi ett otypiskt s\u00e4tt ist\u00e4llet f\u00f6r att g\u00f6ra \"som normala m\u00e4nniskor\"? Beror p\u00e5 vad man anser vara normalt. M\u00e5nga g\u00f6r faktiskt en kluster av Mongo och sprider det \u00f6ver tre geo-distribuerade datacenter.<\/p>\n

Vid den tiden hade vi redan tv\u00e5 projekt p\u00e5 Redis. Den f\u00f6rsta var en cache, och den andra var ett persistent lagringssystem f\u00f6r mindre kritiska data. Det var ganska komplicerat, delvis p\u00e5 grund av v\u00e5ra egna misstag. Ibland l\u00e5g ganska stora volymer i nyckeln, och d\u00e5 och d\u00e5 fick webbplatsen problem. Detta system anv\u00e4nde vi i en master-slave-konfiguration. Det fanns m\u00e5nga tillf\u00e4llen d\u00e5 n\u00e5got h\u00e4nde med master och replikeringen br\u00f6ts. <\/p>\n

Det vill s\u00e4ga, Redis \u00e4r bra f\u00f6r stateless-uppgifter, inte f\u00f6r stateful. I princip kunde den l\u00f6sa de flesta uppgifter, men endast om det handlade om key-value-l\u00f6sningar med ett par index. Men Redis hade vid den tiden ganska stora brister n\u00e4r det kom till persistens och replikering. Dessutom fanns det klagom\u00e5l p\u00e5 prestandan.<\/p>\n

Vi \u00f6verv\u00e4gde MySQL och PostgreSQL. Men den f\u00f6rsta passade oss inte riktigt, medan den andra \u00e4r en ganska avancerad produkt, och det skulle vara oklokt att bygga enkla tj\u00e4nster p\u00e5 den.
\nVi testade RIAK, Cassandra och till och med en grafdatabas. Allt detta \u00e4r ganska nischade l\u00f6sningar som inte passade som ett allm\u00e4nt universellt verktyg f\u00f6r att skapa tj\u00e4nster.<\/p>\n

Till slut stannade vi vid Tarantool.<\/p>\n

Vi v\u00e4nde oss till den n\u00e4r den var i version 1.6. Vi blev intresserade av dess symbios av key-value och funktionaliteten hos en relationsdatabas. Det finns sekund\u00e4ra index, transaktioner och spacet, som \u00e4r som tabeller, men inte enkla, man kan lagra ett varierande antal kolumner i dem. Men killer-funktionen hos Tarantool var de sekund\u00e4ra indexen i kombination med key-value och transaktionalitet.<\/p>\n

Det russisktalande communityt, som var lyh\u00f6rt och alltid redo att hj\u00e4lpa till i chatten, spelade ocks\u00e5 en stor roll. Vi anv\u00e4nde detta aktivt och levde n\u00e4stan i chatten. Och man f\u00e5r inte gl\u00f6mma den anst\u00e4ndiga persistensen utan tydliga brister och fel. Om man ser p\u00e5 v\u00e5r historia med Tarantool s\u00e5 hade vi m\u00e5nga problem med replikering, men vi har aldrig f\u00f6rlorat n\u00e5gra data p\u00e5 grund av dess fel!<\/p>\n

Implementeringen b\u00f6rjade tr\u00f6gt.<\/h3>\n

\nVid den tiden var v\u00e5rt huvudsakliga utvecklingsstack .NET, f\u00f6r vilket det inte fanns n\u00e5gon anslutning f\u00f6r Tarantool. Vi b\u00f6rjade genast arbeta med Go. Det gick ganska bra med Lua ocks\u00e5. Det st\u00f6rsta problemet d\u00e5 var med fels\u00f6kning: i .NET fungerar det utm\u00e4rkt, men att g\u00e5 fr\u00e5n det till embedded Lua, n\u00e4r man knappt har n\u00e5got annat \u00e4n loggar f\u00f6r fels\u00f6kning, var ganska sv\u00e5rt. Dessutom br\u00f6t replikeringen pl\u00f6tsligt ihop ibland, s\u00e5 vi var tvungna att s\u00e4tta oss in i hur motorn Tarantool fungerar. Chatten hj\u00e4lpte oss med detta, i mindre utstr\u00e4ckning dokumentationen, och ibland tittade vi p\u00e5 koden. Vid den tiden var dokumentationen inte s\u00e5 bra.<\/p>\n

S\u00e5 under flera m\u00e5nader lyckades vi samla erfarenhet och f\u00e5 bra resultat med Tarantool. Vi skapade en referens i git som hj\u00e4lpte till med utvecklingen av nya mikrotj\u00e4nster. Till exempel, n\u00e4r uppgiften d\u00f6k upp: att skapa en ny mikrotj\u00e4nst, s\u00e5 tittade utvecklaren p\u00e5 koden f\u00f6r den referensl\u00f6sning som fanns i repositoryt, och skapandet av den nya tog inte mer \u00e4n en vecka. <\/p>\n

Det var speciella tider. Tja, d\u00e5 kunde man g\u00e5 fram till administrat\u00f6ren vid det angr\u00e4nsande bordet och be: \"Ge mig en virtual machine\". Efter ungef\u00e4r trettio minuter hade du maskinen. Du kopplade sj\u00e4lv upp dig, installerade allt, och de dirigerade trafik till den.<\/p>\n

Idag fungerar det inte l\u00e4ngre s\u00e5: man m\u00e5ste s\u00e4tta upp \u00f6vervakning, loggning, t\u00e4cka funktionaliteten med tester, best\u00e4lla en virtuell maskin eller leverans i Kubernetes, etc. Generellt s\u00e4tt \u00e4r det b\u00e4ttre s\u00e5, \u00e4ven om det tar l\u00e4ngre tid och \u00e4r mer besv\u00e4rligt.<\/p>\n

Dela och h\u00e4rska. Hur st\u00e5r det till med Lua?<\/h3>\n

\nDet fanns en allvarlig dilemma: vissa team lyckades inte p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt rulla ut \u00e4ndringar i tj\u00e4nsten med mycket logik p\u00e5 Lua. Ofta resulterade det i att tj\u00e4nsten blev icke-fungerande. <\/p>\n

Det vill s\u00e4ga att utvecklarna f\u00f6rbereder n\u00e5gon \u00e4ndring. Tarantool b\u00f6rjar g\u00f6ra migreringen, medan replikan fortfarande har gammal kod; n\u00e5gon DDL kommer in via replikering, n\u00e5got annat, och koden kraschar helt enkelt eftersom det inte beaktas. Resultatet var att proceduren f\u00f6r uppdatering f\u00f6r administrat\u00f6rerna var nedskriven p\u00e5 ett A4-papper: stoppa replikeringen, uppdatera detta, sl\u00e5 p\u00e5 replikeringen, st\u00e4ng h\u00e4r, uppdatera d\u00e4r. En riktig mardr\u00f6m! <\/p>\n

Som ett resultat f\u00f6rs\u00f6ker vi nu oftast att inte g\u00f6ra n\u00e5got med Lua. Vi anv\u00e4nder bara iproto (ett bin\u00e4rt protokoll f\u00f6r att interagera med servern), och that's it. Kanske \u00e4r det en brist p\u00e5 kunskap hos utvecklarna, men ur det perspektivet verkar systemet komplicerat.<\/p>\n

Vi f\u00f6ljer inte alltid blint detta scenario. Idag har vi ingen svart eller vit: antingen allt p\u00e5 Lua, eller allt p\u00e5 Go. Vi f\u00f6rst\u00e5r redan hur vi kan kombinera f\u00f6r att sedan inte f\u00e5 problem med migreringen.<\/p>\n

Var finns Tarantool just nu?
\nTarantool anv\u00e4nds i tj\u00e4nsten f\u00f6r ber\u00e4kning av slutf\u00f6rs\u00e4ljningspriser f\u00f6r varor med rabattkuponger, \u00e4ven k\u00e4nd som \u00abPromo-Tizer\u00bb. Som n\u00e4mnts tidigare, s\u00e5 g\u00e5r det tj\u00e4nsten nu i pension: den ers\u00e4tts av en ny katalogtj\u00e4nst med f\u00f6rber\u00e4knade priser, men f\u00f6r sex m\u00e5nader sedan gjordes alla ber\u00e4kningar i \u00abPromo-Tizer\u00bb. Tidigare var h\u00e4lften av dess logik skriven i Lua. F\u00f6r tv\u00e5 \u00e5r sedan gjordes tj\u00e4nsten till ett lagringssystem, och logiken skrivs om i Go, eftersom mekanismen f\u00f6r rabatter har \u00e4ndrats n\u00e5got och tj\u00e4nsten saknade prestanda. <\/p>\n

En av de mest kritiska tj\u00e4nsterna \u00e4r anv\u00e4ndarprofilen. Det vill s\u00e4ga, alla Wildberries-anv\u00e4ndare lagras i Tarantool, och det finns ungef\u00e4r 50 miljoner av dem. Systemet \u00e4r shardat efter anv\u00e4ndar-ID och spritt \u00f6ver flera datacenter med en koppling till Go-tj\u00e4nster.
\nN\u00e4r det g\u00e4ller RPS var \u00abPromo-Tizer\u00bb en g\u00e5ng ledande, upp till 6000 f\u00f6rfr\u00e5gningar. Vid n\u00e5got tillf\u00e4lle hade vi 50-60 instanser. Nu \u00e4r anv\u00e4ndarprofiler ledande med cirka 12 000 RPS. I denna tj\u00e4nst till\u00e4mpas anpassad shardning med uppdelning enligt intervall av anv\u00e4ndar-ID. Tj\u00e4nsten hanterar mer \u00e4n 20 maskiner, men det \u00e4r f\u00f6r m\u00e5nga, vi planerar att minska de tilldelade resurserna eftersom den har tillr\u00e4cklig kapacitet med 4-5 maskiner.<\/p>\n

Sessionsservicen \u00e4r v\u00e5r f\u00f6rsta tj\u00e4nst p\u00e5 vshard och Cartridge. Konfigurationen av vshard och uppdateringen av Cartridge kr\u00e4vde en del arbetsinsats fr\u00e5n oss, men i slut\u00e4ndan lyckades vi.<\/p>\n

Tj\u00e4nsten f\u00f6r att visa olika banners p\u00e5 webbplatsen och i mobilapplikationen var en av de f\u00f6rsta som sl\u00e4pptes direkt p\u00e5 Tarantool. Denna tj\u00e4nst \u00e4r anm\u00e4rkningsv\u00e4rd eftersom den har funnits i cirka 6-7 \u00e5r, den \u00e4r fortfarande i drift och har aldrig beh\u00f6vt startas om. Master-master-replikering har anv\u00e4nts. Aldrig har n\u00e5got g\u00e5tt s\u00f6nder.<\/p>\n

Det finns ett exempel p\u00e5 anv\u00e4ndning av Tarantool f\u00f6r snabb referensfunktionalitet i lagersystemet f\u00f6r att snabbt verifiera information i vissa fall. Vi f\u00f6rs\u00f6kte anv\u00e4nda Redis f\u00f6r detta \u00e4ndam\u00e5l, men datan i minnet tog upp mer plats \u00e4n i Tarantool.<\/p>\n

Tj\u00e4nster f\u00f6r v\u00e4ntelista, kundprenumerationer, trendiga stories och uppskjutna varor fungerar ocks\u00e5 med Tarantool. Den sistn\u00e4mnda tj\u00e4nsten tar upp cirka 120 GB i minnet. Detta \u00e4r den mest omfattande tj\u00e4nsten av de som n\u00e4mns ovan. <\/p>\n

Slutsats<\/h3>\n

\nTack vare sekund\u00e4ra index i kombination med nyckel-v\u00e4rde och transaktionsf\u00f6rm\u00e5ga passar Tarantool utm\u00e4rkt f\u00f6r mikrotj\u00e4nstarkitekturer. Men vi st\u00f6tte p\u00e5 sv\u00e5righeter n\u00e4r vi rullade ut \u00e4ndringar i tj\u00e4nster med mycket logik p\u00e5 Lua \u2014 tj\u00e4nsterna slutade ofta fungera. Vi lyckades inte \u00f6vervinna detta, och med tiden kom vi fram till olika kombinationer av Lua och Go: vi vet nu n\u00e4r vi ska anv\u00e4nda det ena spr\u00e5ket och n\u00e4r det andra.<\/p>\n

Vad mer att l\u00e4sa om \u00e4mnet<\/b><\/p>\n