Me kõik armastame lugusid. Meile meeldib istuda lõkke ümber ja rääkida oma varasematest võitudest, lahingutest või lihtsalt oma töökogemusest.
Täna on just selline päev. Ja isegi kui te ei ole praegu tule ääres, on meil teie jaoks lugu. Lugu sellest, kuidas me Tarantoolis ladustamisega tööd alustasime.
Kunagi oli meie ettevõttel paar “monoliiti” ja üks “lagi” kõigile, millele need monoliidid aeglaselt, kuid kindlalt lähenesid, piirates meie ettevõtte lendu, meie arengut. Ja oli selge arusaam: ühel päeval lööme selle lae kõvasti vastu.
Nüüd on valitsev ideoloogia eraldada kõik ja kõik, alates seadmetest kuni äriloogikani. Selle tulemusena on meil näiteks kaks alalisvoolu, mis on võrgu tasandil praktiliselt sõltumatud. Ja siis oli kõik täiesti erinev.
Tänapäeval on CI/CD, K8S jne kujul muudatuste tegemiseks palju tööriistu ja tööriistu. “Monoliitsel” ajal polnud meil nii palju võõrsõnu vaja. Piisas lihtsalt andmebaasis oleva "salvestuse" parandamisest.
Kuid aeg liikus edasi ja koos sellega liikus edasi ka taotluste arv, mis mõnikord ületas meie võimete piires RPS-i. SRÜ riikide turule tulekuga ei langenud esimese monoliidi andmebaasiprotsessori koormus alla 90% ja RPS jäi 2400 tasemele. Ja need polnud lihtsalt väikesed valijad, vaid kopsakad päringud, millel oli hunnik kontrolle ja JOIN-e, mis võiks suurte IO taustal töötada peaaegu poole andmetega.
Kui lavale hakkasid ilmuma täieõiguslikud musta reede müügid – ja Wildberries oli üks esimesi, kes neid Venemaal korraldas – muutus olukord täiesti kurvaks. Lõppude lõpuks suureneb koormus sellistel päevadel kolm korda.
Oh neid "monoliitseid aegu"! Olen kindel, et olete kogenud midagi sarnast ja te ei saa siiani aru, kuidas see teiega juhtuda sai.
Mis teha – mood on tehnoloogiale omane. Umbes 5 aastat tagasi pidime ühe neist modifikatsioonidest ümber mõtlema olemasoleva saidi kujul .NET-is ja MS SQL-serveris, mis salvestas hoolikalt kogu saidi enda loogika. Hoidsin seda nii hoolega, et sellise monoliidi saagimine osutus pikaks ja sugugi mitte lihtsaks naudinguks.
Väike kõrvalepõige.
Erinevatel üritustel ütlen: "Kui sa ei näinud monoliiti, siis sa ei kasvanud!" Olen huvitatud teie arvamusest selles küsimuses, palun kirjutage see kommentaaridesse.
Äikese heli
Tuleme tagasi oma "jaanitule" juurde. “Monoliitse” funktsionaalsuse koormuse jaotamiseks otsustasime jagada süsteemi avatud lähtekoodiga tehnoloogiatel põhinevateks mikroteenusteks. Sest neid on vähemalt odavam skaleerida. Ja meil oli 100% arusaam, et peame skaleerima (ja palju). Oli ju juba sel ajal võimalik siseneda naaberriikide turgudele ning registreerimiste arv, aga ka tellimuste arv hakkas veelgi jõudsamalt kasvama.
Olles analüüsinud esimesi monoliidist mikroteenustele lahkumise kandidaate, saime aru, et 80% nendes kirjutatavast pärineb back office süsteemidest ja lugemine front office'ist. Esiteks puudutas see paari meie jaoks olulist alamsüsteemi - kasutajaandmeid ja kauba lõpliku maksumuse arvutamise süsteemi, mis põhineb teabel klientide täiendavate allahindluste ja kupongide kohta.
Sissetõmmatud. Nüüd on hirmutav ette kujutada, aga lisaks eelpool mainitud alamsüsteemidele eemaldati meie monoliidist ka tootekataloogid, kasutaja ostukorvi, tooteotsingusüsteem, tootekataloogide filtreerimissüsteem ja mitmesugused soovitussüsteemid. Kõigi nende toimimiseks on eraldi klassid kitsalt kohandatud süsteeme, kuid kunagi elasid nad kõik ühes “majas”.
Kohe plaanisime oma klientide andmed killustatud süsteemi üle kanda. Kauba lõppmaksumuse arvutamise funktsionaalsuse eemaldamine eeldas lugemiseks head skaleeritavust, sest see tekitas suurima RPS-i koormuse ja oli andmebaasi jaoks kõige raskemini teostatav (arvutusprotsessis on palju andmeid).
Selle tulemusena jõudsime välja skeemi, mis sobib hästi Tarantooliga.
Sel ajal valiti mikroteenuste tööks skeemid mitme andmekeskusega töötamiseks virtuaal- ja riistvaramasinatel. Nagu joonistel näidatud, rakendati Tarantooli replikatsioonivalikuid nii ülem-ülem kui ka ülem-alluv režiimis.
Arhitektuur. Valik 1. Kasutajateenus
Praegu on 24 killukest, millest igaühel on 2 eksemplari (üks iga alalisvoolu jaoks), kõik ülem-ülemas režiimis.
Andmebaasi peal on rakendused, mis pääsevad juurde andmebaasi koopiatele. Rakendused töötavad Tarantooliga meie kohandatud teegi kaudu, mis rakendab Tarantool Go draiveri liidest. Ta näeb kõiki koopiaid ja saab koos kapteniga lugeda ja kirjutada. Põhimõtteliselt rakendab see koopiakomplekti mudelit, mis lisab loogikat koopiate valimiseks, korduskatsete tegemiseks, kaitselülitit ja kiiruse piirangut.
Sel juhul on võimalik replikate valimise poliitikat konfigureerida kildude kontekstis. Näiteks roundrobin.
Arhitektuur. Variant 2. Teenus kauba lõpliku maksumuse arvutamiseks
Kui paar kuud tagasi läks suurem osa kauba lõpliku maksumuse arvutamise taotlustest uude teenindusse, mis põhimõtteliselt töötab ilma andmebaasideta, siis mõni aeg tagasi töötas kõik 100% hoolde, mille kapoti all oli Tarantool.
Teenindusandmebaas koosneb neljast põhimassist, millesse sünkroonija andmeid kogub, ja igaüks neist replikatsiooniülematest jagab andmeid kirjutuskaitstud koopiatele. Igal meistril on umbes 4 sellist koopiat.
Kas esimeses või teises skeemis, kui üks DC pole saadaval, saab rakendus andmeid vastu võtta teises.
Väärib märkimist, et Tarantooli replikatsioon on üsna paindlik ja seda saab käitusajal konfigureerida. Teistes süsteemides tekkisid raskused. Näiteks parameetrite max_wal_senders ja max_replication_slots muutmine PostgreSQL-is nõuab viisardi taaskäivitamist, mis mõnel juhul võib viia rakenduse ja DBMS-i vaheliste ühenduste katkemiseni.
Otsi ja leiad!
Miks me ei teinud seda "nagu normaalsed inimesed", vaid valisime ebatüüpilise viisi? See sõltub sellest, mida peetakse normaalseks. Paljud inimesed loovad tavaliselt Mongost klastri ja levitavad seda kolmes geograafiliselt hajutatud DC-s.
Sel ajal oli meil juba kaks Redise projekti. Esimene oli vahemälu ja teine mitte liiga kriitiliste andmete püsiv salvestusruum. Temaga oli üsna raske, osaliselt meie süül. Vahel olid võtmes päris suured mahud ja aeg-ajalt muutus sait halvaks. Kasutasime seda süsteemi ülem-alluv versioonis. Ja oli palju juhtumeid, kus masteriga juhtus midagi ja replikatsioon läks katki.
See tähendab, et Redis sobib kodakondsuseta ülesannete, mitte olekuga ülesannete jaoks. Põhimõtteliselt võimaldas see lahendada enamiku probleemidest, kuid ainult siis, kui need olid võtmeväärtuste lahendused koos indeksite paariga. Kuid Redis oli sel ajal üsna kurb püsivuse ja kordamise pärast. Lisaks kurdeti jõudluse üle.
Mõtlesime MySQL-ile ja PostgreSQL-ile. Kuid esimene ei saanud meile kuidagi külge ja teine on iseenesest üsna keerukas toode, millele poleks kohane lihtsaid teenuseid ehitada.
Proovisime RIAKi, Cassandrat, isegi graafikute andmebaasi. Need on kõik üsna nišilahendused, mis ei sobinud üldise universaalse teenuste loomise tööriista rolli.
Lõpuks leppisime Tarantooliga.
Pöördusime selle poole, kui see oli versioonis 1.6. Meid huvitas see võtmeväärtuse sümbioos ja relatsiooniandmebaasi funktsionaalsus. Seal on sekundaarsed indeksid, tehingud ja tühikud, need on nagu tabelid, kuid mitte lihtsad, neisse saab salvestada erineva arvu veerge. Kuid Tarantooli tappev funktsioon olid sekundaarsed indeksid koos võtmeväärtuse ja tehingulisusega.
Oma osa oli ka vastutulelikul venekeelsel kogukonnal, kes oli valmis vestluses aitama. Kasutasime seda aktiivselt ja elame otse vestluses. Ja ärge unustage korralikku püsivust ilma ilmsete vigade ja vigadeta. Kui vaadata meie ajalugu Tarantooliga, oli meil palju piina ja tõrkeid replikatsiooniga, kuid me ei kaotanud kunagi andmeid selle süül!
Rakendamine algas raskelt
Sel ajal oli meie põhiliseks arenduspinnaks .NET, mille külge Tarantooli jaoks ühendust polnud. Hakkasime Go-s kohe midagi tegema. See töötas hästi ka Luaga. Peamine probleem oli sel ajal silumisega: .NET-is on sellega kõik suurepärane, kuid pärast seda oli raske manustatud Lua maailma sukelduda, kui teil pole silumist peale logide. Lisaks lagunes replikatsioon mingil põhjusel perioodiliselt laiali, nii et pidin Tarantooli mootori ülesehitusse süvenema. Sellega aitas kaasa vestlus ja vähemal määral ka dokumentatsioon; mõnikord vaatasime koodi. Tol ajal oli dokumentatsioon nii-nii.
Nii õnnestus mul mitme kuu jooksul peast lahti saada ja Tarantooliga töötades korralikud tulemused saada. Koostasime gitis viitearendused, mis aitasid kaasa uute mikroteenuste loomisele. Näiteks kui tekkis ülesanne: teise mikroteenuse loomiseks vaatas arendaja hoidlas oleva võrdluslahenduse lähtekoodi ja uue loomiseks ei kulunud rohkem kui nädal.
Need olid erilised ajad. Tavaliselt võite minna järgmise laua administraatori juurde ja küsida: "Anna mulle virtuaalmasin." Umbes kolmkümmend minutit hiljem oli auto juba teie juures. Ühendasite ise, installisite kõik ja liiklus saadeti teile.
Täna see enam ei toimi: tuleb lisada teenusesse jälgimine ja logimine, katta funktsionaalsus testidega, tellida virtuaalmasin või Kuberisse tarnimine jne. Üldiselt on see nii parem, kuigi see võtab kauem aega ja on tülikam.
Jaga ja valitse. Mis lugu Luaga on?
Tekkis tõsine dilemma: mõned meeskonnad ei suutnud Lua loogikaga teenuses muudatusi usaldusväärselt juurutada. Sellega kaasnes sageli see, et teenus ei tööta.
See tähendab, et arendajad valmistavad ette mingisuguseid muudatusi. Tarantool alustab migreerimist, kuid koopia on endiselt vana koodiga; Sinna saabub replikatsiooni teel mingi DDL või midagi muud ja kood läheb lihtsalt laiali, kuna sellega ei arvestata. Selle tulemusel pandi administraatorite värskendamise protseduur A4-lehele: peatage replikatsioon, värskendage seda, lülitage replikatsioon sisse, lülitage siit välja, värskendage seal. Õudusunenägu!
Selle tulemusena püüame praegu Luas kõige sagedamini mitte midagi teha. Kasutage lihtsalt iprotot (binaarprotokoll serveriga suhtlemiseks) ja ongi kõik. Võib-olla on see arendajate teadmiste puudumine, kuid sellest vaatenurgast on süsteem keeruline.
Me ei järgi seda stsenaariumi alati pimesi. Täna pole meil must-valget: kas kõik on Luas või kõik Go-s. Me juba mõistame, kuidas saame neid kombineerida nii, et meil ei tekiks hiljem rändeprobleeme.
Kus Tarantool praegu on?
Tarantooli kasutatakse teenuses kaupade lõpliku maksumuse arvutamiseks, võttes arvesse sooduskuponge, tuntud ka kui "Promootor". Nagu ma varem ütlesin, läheb ta nüüd pensionile: teda asendab uus kataloogiteenus, mille hinnad on ette arvutatud, kuid kuus kuud tagasi tehti kõik arvutused Promotizeris. Varem oli pool selle loogikast kirjutatud lua keeles. Kaks aastat tagasi muudeti teenus laoks ja Go-s kirjutati loogika ümber, kuna allahindluste mehaanika oli veidi muutunud ja teenusel puudus jõudlus.
Üks kriitilisemaid teenuseid on kasutajaprofiil. See tähendab, et kõik Wildberry kasutajad on salvestatud Tarantoolis ja neid on umbes 50 miljonit. Kasutaja ID-ga jagatud süsteem, mis on jaotatud mitme Go teenustega ühendatud alalisvoolu vahel.
RPS-i andmetel oli Promoter kunagi liider, jõudes 6 tuhande päringuni. Ühel hetkel oli meil 50-60 eksemplari. Nüüd on RPS-i liider kasutajaprofiilid, umbes 12 tuhat. See teenus kasutab kohandatud jagamist, mis on jagatud kasutajatunnuste vahemikega. Teenus teenindab üle 20 masina, kuid seda on liiga palju, plaanime eraldatud ressursse vähendada, sest selleks piisab 4-5 masina võimsusest.
Seansiteenus on meie esimene vshardi ja kasseti teenus. Vshardi seadistamine ja Cartridge'i värskendamine nõudis meilt pingutust, kuid lõpuks läks kõik korda.
Veebilehel ja mobiilirakenduses erinevate bännerite kuvamise teenus oli üks esimesi, mis ilmus otse Tarantoolis. See teenus on tähelepanuväärne selle poolest, et see on 6-7 aastat vana, see on endiselt töös ja seda pole kunagi taaskäivitatud. Kasutati master-master replikatsiooni. Mitte miski pole kunagi katki läinud.
Seal on näide Tarantooli kasutamisest laosüsteemi kiirviitefunktsioonide jaoks, et mõnel juhul teavet kiiresti üle kontrollida. Proovisime selleks kasutada Redist, kuid mälus olevad andmed võtsid rohkem ruumi kui Tarantool.
Tarantooliga töötavad ka ootenimekirja teenused, klienditellimused, hetkel moekad lood ja edasilükatud kaubad. Viimane mäluteenus võtab umbes 120 GB. See on ülalnimetatutest kõige põhjalikum teenus.
Järeldus
Tänu sekundaarsetele indeksitele koos võtmeväärtuse ja tehingulisusega sobib Tarantool hästi mikroteenustel põhinevate arhitektuuride jaoks. Lua loogikaga teenuste muudatuste juurutamisel tekkis aga raskusi – teenused lakkasid sageli töötamast. Me ei saanud sellest üle ja aja jooksul jõudsime erinevate Lua ja Go kombinatsioonideni: teame, kus kasutada üht keelt ja kus teist keelt.
Mida muud selle teema kohta lugeda
- Suure koormusega rakenduse loomine nullist Tarantooli abil
- Usaldusväärne liidri valik Tarantool Cartridge'is
- Telegrammi kanal Tarantool toote uudistega
- Arutage Tarantooli kogukonna vestluses
Allikas: www.habr.com