{"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\/et\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Kuidas l\u00f5petada muretsemine ja alustada elu ilma monoliidita","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n
\nMe k\u00f5ik armastame lugusid. Meile meeldib istuda lafirel ja r\u00e4\u00e4kida oma varasematest v\u00f5itudest, lahingutest v\u00f5i lihtsalt oma t\u00f6\u00f6kogemusest.<\/p>\n

T\u00e4na on just selline p\u00e4ev. Ja kuigi te ei istu v\u00f5ib-olla lafirel, on meil teile lugu r\u00e4\u00e4kida. Lugu sellest, kuidas me hakkasime t\u00f6\u00f6tama Tarantooli andmesalvesti peal.<\/p>\n

Kaua aega tagasi oli meie ettev\u00f5ttes paar 'monoliiti' ja \u00fcks tipp, mille poole need monoliidid aeglaselt, kuid kindlalt liikusid, piirates meie ettev\u00f5tte, meie arengu edasiviimist. Ja oli kindel arusaam: \u00fchel p\u00e4eval seisame me selle tipuga silmitsi.
\n<\/a><\/noindex>
\nPraegu valitseb meil ideoloogia, et k\u00f5ik tuleb eraldada, alates riistvarast kuni \u00e4ri loogikani. Selle tulemusena on meil n\u00e4iteks kaks andmekeskust, mis on praktiliselt s\u00f5ltumatud v\u00f5rgu tasemel. Aga siis oli k\u00f5ik hoopis teistmoodi.<\/p>\n

T\u00e4nap\u00e4eval on muudatuste tegemiseks palju t\u00f6\u00f6riistu ja vahendeid nagu CI\/CD, K8S jne. 'Monoliidi' ajal ei l\u00e4inud meil vajagi nii palju v\u00f5\u00f5rkeelseid termineid. Piisas lihtsalt 'salvestamise' t\u00e4iendamisest andmebaasis.<\/p>\n

Aga aeg kulges edasi, samas kui p\u00e4ringute arv k\u00fc\u00fcnitas \u00fclespoole, ulatudes RPS numbriteni, mis m\u00f5nikord \u00fcletasid meie v\u00f5imed. Kui sisenesime SR\u00dc turgudele, ei langenud esimese monoliidi andmebaasi koormus kunagi alla 90%, samas kui RPS p\u00fcsis tasemel 2400. Ja need ei olnud lihtsalt v\u00e4ikesed p\u00e4ringud, vaid massiivsed p\u00e4ringud, kus oli palju kontrollimisi ja JOIN'e, mis pidid l\u00e4bima suisa poole andmete hulgast suure IO taustal.<\/p>\n

Kui turule hakkasid korralikult langevad hinnad n\u00fc\u00fcd, \u2014 ja Wildberries alustas nende korraldamist esimesena Venemaal, \u2014 muutus olukord t\u00e4iesti murettekitav. Sest koormus sellistel p\u00e4evadel suureneb kolmekordseks.
\nAh, need 'monoliidi ajad'! Olen kindel, et olete ka teinud sama kogemuse ja t\u00f5en\u00e4oliselt ei suuda siiani m\u00f5ista, kuidas see k\u00f5ik teiega juhtuda sai.<\/p>\n

Mis sa teed \u2014 trendid on seotud ka tehnoloogiaga. Veel viis aastat tagasi pidime oma .NET ja MS SQL-serveri saidiga, mis hoidis k\u00f5iki saidi t\u00f6\u00f6loogika elemente, t\u00f5eliselt \u00fcmber m\u00f5tlema. Ta hoidis seda nii hoolega, et sellise monoliidi l\u00f5hkumine osutus pikaajalise ja v\u00e4ga keerulise ettev\u00f5ttena.
\nPisike k\u00f5rvalep\u00f5ige. <\/p>\n

Erinevatel \u00fcritustel \u00fctlen: 'kui te ei ole monoliiti l\u00f5hkunud, siis te ei ole kasvanud!' Teie arvamused selle kohta on huvitavad, palun kirjutage need kommentaaridesse.<\/p>\n

Ja \u00e4kki k\u00f5las k\u00f5ue.<\/h3>\n

\nNaaseme meie 'lafire' juurde. Et jagada 'monoliidi' funktsionaalsuse koormust, otsustasime s\u00fcsteemi jagada microservices-iks, aluseks avatud l\u00e4htekoodiga tehnoloogiatele. Sest v\u00e4hemalt, nende skaleerimine on odavam. Ja arusaam sellest, et meil tuleb skaleerida (ja piisavalt palju) oli meil 100% ulatuses. Tolleks hetkeks olid meil juba \u00f5nnestunud siseneda naaberriikide turgudele ja registreerimiste arv ning tellimuste arv hakkas veelgi rohkem kasvama.<\/p>\n

Esialgsete kandidaatide anal\u00fc\u00fcsimisel monoliidist mikroteenustesse siirdumiseks saime aru, et 80%-l juhtudest tuli 99% kirjutamisest back office-s\u00fcsteemidest, samas kui lugemine toimus esirinnas. Eelk\u00f5ige puudutas see kaht meie jaoks olulist alams\u00fcsteemi \u2014 kasutajate andmeid ja l\u00f5pphinnastamise s\u00fcsteemi, mis p\u00f5hineb informatsioonil klientide allahindluste ja kupongide kohta.<\/p>\n

Kohati k\u00f5rvalep\u00f5ige. Praegu tundub uskumatu, aga lisaks eespool mainitud alams\u00fcsteemidele t\u00f5stsime meie monoliidist v\u00e4lja ka tootekataloogid, kasutajakorvi, tooteotsingu s\u00fcsteemi, tootekataloogide filtreerimise s\u00fcsteemi ja erinevad soovituss\u00fcsteemid. Iga\u00fche jaoks eksisteerivad eraldi kitsas fookusega s\u00fcsteemid, kuid kunagi elasid nad k\u00f5ik \u00fches 'taredes'. <\/p>\n

Otsustasime oma klientide andmed viia sharding-s\u00fcsteemi. Toote l\u00f5pphinna arvutamise funktsionaalsuse v\u00e4ljaviimine n\u00f5udis head skaleeritavust lugemise osas, kuna see p\u00f5hjustas RPS koormuse ja oli andmebaasi jaoks k\u00f5ige keerulisem teostada (protsessis osales v\u00e4ga palju andmeid). <\/p>\n

Selle tulemusena tekkis meil skeem, mis sobib h\u00e4sti Tarantooli jaoks.<\/p>\n

Sel ajal valisime microservices'ide t\u00f6\u00f6ks skeemid, mis t\u00f6\u00f6tavad mitme andmekeskusega virtuaalsete ja f\u00fc\u00fcsiliste masinatega. Nagu joonistel n\u00e4idatud, rakendati Tarantooli replikatsiooni variante nii master-master re\u017eiimis kui ka master-slave re\u017eiimis. <\/p>\n

\"Kuidas
\nArhitektuur. Variant 1. Kasutajate teenus<\/i><\/p>\n

Praeguseks on see 24 shardi, millest igas on 2 instantsi (\u00fcks igas andmekeskuses), k\u00f5ik master-master re\u017eiimis.<\/p>\n

Andmete kohal on rakendused, mis suhtlevad andmebaasi koopiatega. Rakendused t\u00f6\u00f6tavad Tarantooliga meie kohandatud raamatukogu kaudu, mis rakendab Go-draiveri Tarantooli liidest. See n\u00e4eb k\u00f5iki koopiad ja suudab t\u00f6\u00f6tada peamise andmeallikaga lugemiseks ja kirjutamiseks. Sisuliselt rakendab see koopiate komplekti mudelit, kuhu on lisatud koopiate valiku, uuesti proovimise, ringluste katkestamise ja m\u00e4\u00e4ratud piirangute loogika.<\/p>\n

Lisaks on v\u00f5imalik konfigureerida koopiate valimise poliitikat shardide l\u00f5ikes. N\u00e4iteks v\u00f5ivad need olla \u00fcksteise j\u00e4rel valitud.<\/p>\n

\"Kuidas
\nArhitektuur. Variant 2. Toote l\u00f5pphinna arvutamise teenus.<\/i><\/p>\n

M\u00f5ned kuud tagasi suunati enamik toote l\u00f5pphinna arvutamise p\u00e4ringutest uuele teenusele, mis p\u00f5him\u00f5tteliselt t\u00f6\u00f6tab ilma andmebaasita, kuid m\u00f5ni aeg tagasi t\u00f6\u00f6tas 100% Tarantooli teenus, mis oli selle taga.<\/p>\n

Teenuse andmebaas koosneb 4 peast, kuhu s\u00fcsinikekvaliteedi kogumine toimub ja iga peamine andmeallikas jagab koopiatele loetud andmeid. Iga peamise andmeallika kohta on umbes 15 koopiat.<\/p>\n

Nii esimeses kui ka teises skeemis, kui \u00fcks andmekeskus on saadaval, saavad rakendused andmeid teiselt poolt.<\/p>\n

Tasub m\u00e4rkida, et Tarantoolis on koopiate tegemine \u00fcsna paindlik ja konfigureeritav reaalajas. Muudes s\u00fcsteemides on esinenud probleeme, n\u00e4iteks PostgreSQL'is, kui max_wal_senders ja max_replication_slots parameetrite muutmine n\u00f5uab peamise andmeallika taask\u00e4ivitamist, mis m\u00f5nel juhul v\u00f5ib p\u00f5hjustada \u00fchenduste katkemist rakenduse ja andmebaasi vahel.<\/p>\n

Otsige ja leiate!<\/h3>\n

\nMiks me ei teinud \u00abnagu tavalised inimesed\u00bb ja valisime ebatavalise meetodi? S\u00f5ltub, mida pidada tavaliseks. Paljudel on kokku pandud Mongo klaster ja jaotatud see kolme geograafiliselt jaotatud andmekeskuse vahel.<\/p>\n

Sel ajal olid meil juba kaks projekti Redisil. Esimene \u2013 cache, ja teine, mis esindas p\u00fcsivalt salvestatud mitte liiga kriitiliste andmete hoiust. Sellega oli \u00fcsna keeruline, osaliselt meie s\u00fc\u00fc. Vahetevahel olid suured mahud v\u00f5tmes, ja aeg-ajalt l\u00e4ks veebileht halvemaks. Kasutasime seda s\u00fcsteemi peamine-koopiatena. Ja juhtus palju juhtumeid, millega seoses peamise andmeallikaga juhtus midagi ja koopiate tegemine puruneb. <\/p>\n

See t\u00e4hendab, et Redis sobib stateless-\u00fclesannete jaoks, mitte stateful-\u00fclesannete jaoks. P\u00f5him\u00f5tteliselt suudab see lahendada enamikku \u00fclesandeid, kuid ainult siis, kui need olid v\u00f5tme-v\u00e4\u00e4rtuse lahendused paaride indeksitega. Kuid sel ajal olid Redisil suured probleemid j\u00e4rjepidevuse ja koopiate tegemisega. Samuti olid esinenud kaebusi j\u00f5udluse osas.<\/p>\n

M\u00f5tlesime MySQL'le ja PostgreSQL'ile. Kuid esimene ei sobinud meile kuidagi, teine on \u00fcsna keeruline toode ja selle p\u00f5hjal lihtsaid teenuseid rajada oleks olnud m\u00f5tlematu.
\nProovisime RIAKi, Cassandra't, isegi graafi andmebaasi. K\u00f5ik need olid \u00fcsna ni\u0161\u0161ilahendused, mis ei sobinud universaalse t\u00f6\u00f6riistana teenuste loomisel.<\/p>\n

L\u00f5puks peatume Tarantoolil.<\/p>\n

Me p\u00f6\u00f6rdusime selle poole, kui see oli versioonis 1.6. See k\u00f6itis meid key-value ja relatsioonilise andmebaasi funktsionaalsuse s\u00fcmbioosiga. On teise taseme indeksid, tehingud ja ruumid, mis on nagu tabelid, kuid mitte lihtsad; neis saab hoida erinevat arvu veerge. Kuid Tarantooli tapmise funktsioonid olid teise taseme indeksid koos key-value ja tehingulisusega.<\/p>\n

Oma osa m\u00e4ngis ka vastutulelik venekeelne kogukond, kes oli valmis vestluses abi osutama. Kasutasime seda aktiivselt ja elasime praktiliselt vestluses. Ja \u00e4rge unustage korralikku j\u00e4rjepidevust ilma ilmsete vigade ja probleemideta. Kui vaadata meie ajalugu Tarantooliga, oli palju valusid ja komistusi koopiate tegemise osas, kuid me ei kaotanud tema s\u00fc\u00fc t\u00f5ttu kunagi andmeid!<\/p>\n

Rakendamine algas raskelt.<\/h3>\n

\nSel ajal oli meie peamine arendust\u00f6\u00f6riist .NET, millega ei olnud Tarantooli \u00fchendust. Alustasime kohe Go peal. Lua-ga l\u00e4ks ka \u00fcsna h\u00e4sti. Peamine probleem sel ajal oli t\u00f5rkeotsing: .NET'is on see h\u00e4mmastavalt lihtne, aga p\u00e4rast seda sukelduda sisseehitatud Lua maailma, kui sul on ainult logid, mitte mingit t\u00f5rkeotsingut, oli keeruline. Samuti purunes koopiate tegemine mingil p\u00f5hjusel perioodiliselt, pidime s\u00fcvenema Tarantooli mootori struktuuri. Sellega aitas vestlus, v\u00e4hemal m\u00e4\u00e4ral \u2013 dokumentatsioon, aeg-ajalt vaatasime koodi. Sel ajal ei olnud dokumentatsioon kuigi hea.<\/p>\n

Nii said paar kuud jooksul paljusid vigu tekitada ja saavutada head tulemused Tarantooliga t\u00f6\u00f6tades. Koondasime git'is eeskujulikke t\u00f6id, mis aitasid uute mikroteenuste rajamisel. N\u00e4iteks, kui tekkis \u00fclesanne: teha j\u00e4rjekordne mikroteenus, siis arendaja vaatas eeskujulike lahenduste l\u00e4htekoodile hoidlas, ja uue loomine ei v\u00f5tnud aega rohkem kui n\u00e4dal. <\/p>\n

Need olid erilised ajad. Toona sai l\u00e4heneda k\u00f5rvalolevale administraatorile ja paluda: \u201eAnna mulle virtuaal\u201d. Umbes kolme k\u00fcmne minuti p\u00e4rast oli masin juba sinu k\u00e4es. Sa \u00fchendasid ise, installisid k\u00f5ik ja suunati sulle liiklus.<\/p>\n

T\u00e4nap\u00e4eval ei toimi see enam nii: tuleb seadistada monitorimine, logimine, katsetada funktsionaalsust, tellida virtuaal v\u00f5i tarnimine Kuberisse jne. \u00dcldiselt on see parem, kuigi see on aegan\u00f5udvam ja keerukam.<\/p>\n

Jagage ja valitsege. Kuidas on lood Luaga?<\/h3>\n

\nOli t\u00f5sine dilemma: m\u00f5nedes meeskondades ei \u00f5nnestunud usaldusv\u00e4\u00e4rselt muudatusi teenusesse v\u00e4lja viia, kus oli palju loogikat Luas. Tihti kaasnes sellega teenuse mittet\u00f6\u00f6tamine. <\/p>\n

See t\u00e4hendab, et arendajad valmistavad ette m\u00f5ne muudatuse. Tarantool alustab migratsiooni, kuid replikatsioon on veel vana koodiga; sinna tuleb replikatsiooni kaudu mingi DDL, veel midagi, ja kood lihtsalt kokku kukub, kuna seda pole arvesse v\u00f5etud. Tulemuseks oli, et administraatorite uuendamisprotseduur oli kirja pandud A4-le: peatage replikatsioon, uuendage see, k\u00e4ivitage replikatsioon, l\u00fclitage siin v\u00e4lja, uuendage seal. \u00d5udne! <\/p>\n

Kokkuv\u00f5ttes proovime praegu enamasti Luas mitte midagi teha. Lihtsalt iprotoga (binaarne protokoll serveriga suhtlemiseks) ja k\u00f5ik. V\u00f5ib-olla on see arendajate teadmiste puudumise probleem, kuid sellisest vaatenurgast on s\u00fcsteem keeruline.<\/p>\n

Me ei j\u00e4rgige alati seda stsenaariumi pimesi. T\u00e4na pole meil mustvalget: kas k\u00f5ik on Luas v\u00f5i k\u00f5ik Go-s. Aru saame, kuidas neid kombineerida, et hiljem migratsiooniga probleeme ei tekiks.<\/p>\n

Kus on Tarantool praegu?
\nTarantool on kasutusel toodete l\u00f5plikku maksumust arvestavas teenuses, mis v\u00f5tab arvesse allahindluste kupongid, mida tuntakse kui \u201ePromotaister\u201d. Nagu eelnevalt mainitud, on see n\u00fc\u00fcd tagaplaanile j\u00e4\u00e4mas: uut kataloogiteenust, kus on eelnevalt arvutatud hinnad, kuid veel kuus kuud tagasi tehti k\u00f5ik arvutused \u201ePromotaisteris\u201d. Varem oli pool selle loogikast kirjutatud Luas. Kaks aastat tagasi muudeti teenus ladustamiseks ja loogika kirjutati Go-s \u00fcmber, kuna allahindluste mehhanika muutus ja teenusel puudus j\u00f5udlus. <\/p>\n

\u00dcks k\u00f5ige kriitilisemaid teenuseid on kasutajaprofiil. See t\u00e4hendab, et k\u00f5ik Wildberriesi kasutajad on salvestatud Tarantooli, kokku umbes 50 miljonit. ID kasutaja p\u00f5hjal jaotatud s\u00fcsteem, jagatud mitmesse andmekeskusesse, Go-teenustega.
\nRPS osas oli kunagi liidriks \u201ePromotaister\u201d, saavutades kuni 6000 p\u00e4ringut. Mingil ajal oli meil 50-60 eksemplari. Praegu on RPS juht kasutajaprofiilid, umbes 12 000. Selles teenuses kasutatakse kohandatud jagamist kasutaja ID-de vahemike p\u00f5hjal. Teenus teenindab \u00fcle 20 masina, kuid see on liiga palju; plaanime ressursse v\u00e4hendada, kuna 4-5 masinat on piisavad.<\/p>\n

Seansiteenus on meie esimene teenus vshard ja Cartridge peal. Vshardi seadistamine ja Cartridge\u2019i uuendamine n\u00f5udsid meist teatud t\u00f6\u00f6j\u00f5uressursse, kuid l\u00f5puks l\u00e4ks k\u00f5ik korda.<\/p>\n

Ainult reklaamide kuvamise teenus veebilehel ja mobiilirakenduses oli \u00fcks esimesi, mis v\u00e4lja anti Tarantoolile. See teenus on huvitav, et see on olnud aktiivne umbes 6-7 aastat ja pole kordagi taask\u00e4ivitatud. Kasutati master-master replikatsiooni. Midagi pole kunagi katki l\u00e4inud.<\/p>\n

On n\u00e4ide Tarantooli kasutamisest kiirete registrite funktsionaalsuse jaoks laos\u00fcsteemis, et m\u00f5nes olukorras kiiresti teavet \u00fcle kontrollida. Proovisime selleks kasutada Redis\u2019t, kuid andmed m\u00e4lus v\u00f5tsid rohkem ruumi kui Tarantoolil.<\/p>\n

Ootej\u00e4rjekordade teenused, kliendilepingud, moodsad lugu ja edasil\u00fckatud tooted t\u00f6\u00f6tavad samuti Tarantooliga. Viimane teenus v\u00f5tab m\u00e4lus umbes 120 GB ja on \u00fcks mahukamaid eespool mainitud teenustest. <\/p>\n

Kokkuv\u00f5te<\/h3>\n

\nAit\u00e4h teisej\u00e4rguliste indeksite koos key-value ja tehingutega, sobib Tarantool suurep\u00e4raselt mikroteenuste p\u00f5histele arhitektuuridele. Siiski oleme kokku puutunud raskustega, kui muudatusi v\u00e4lja viidud teenustes, kus on palju loogikat Luas \u2014 teenused katkestavad sageli t\u00f6\u00f6. Seda me ei suutnud \u00fcletada ja aja jooksul j\u00f5udsime erinevate Lua ja Go kombinatsioonideni: teame, kus \u00fchte keelt kasutada ja kus teist.<\/p>\n

Mida veel teemast lugeda<\/b><\/p>\n