Me kõik armastame lugusid. Meile meeldib istuda lõkke ääres ja rääkida oma möödunud võitudest, lahingutest või lihtsalt oma töökogemusest.
Täna on just selline päev. Ja kuigi te ei istu praegu lõkke ääres, on meil teile lugu. Lugu sellest, kuidas me hakkasime töötama Tarantooli salvestusega.
Kord ammu oli meie firmas paar «monoliiti» ja üks kõikidele «lagi», mille poole need monoliidid aeglaselt, kuid kindlalt liikusid, piirates meie ettevõtte edasiviimist. Meil oli selge arusaam: ühel päeval saame me sellesse lage tugevalt takistuseks.
Praegu valitseb meil ideoloogia kõike ja kõiki jagada, alustades seadmetest ja lõpetades äriloogikaga. Selle tulemusena on meil näiteks kaks andmekeskust, mis on praktiliselt sõltumatud võrgu tasandil. Kuid tol ajal oli kõik hoopis teistmoodi.
Tänapäeval on muudatuste tegemiseks palju vahendeid ja tööriistu, nagu CI/CD, K8S jne. «Monoliitsetel» aegadel ei olnud meil vaja nii palju ilusaid sõnu. Piisas, kui lihtsalt parandada «salvestust» andmebaasis.
Aeg möödus ning päringute arv kasvas koos sellega, tulistades RPS mõnikord kõrgemale kui meie võimalused. Kui me sisenesime SRÜ riikide turule, ei langenud andmebaasi esimese monoliidi protsessorikoormus kunagi alla 90 %, samas kui RPS püsis 2400 tasemel. Ja need ei olnud lihtsalt väiksed päringud, vaid hiiglaslikud päringud, millel oli palju kontrollimisi ja JOIN-e, mis jooksid läbi peaaegu poole andmetest suure IO taustal.
Kui täiecene hakkasid ilmnema tõelised allahindlused «Mustal reedel», — ja Wildberries alustas nende korraldamist ühtesid esimesi Venemaal, — siis olukord muutus tõeliselt kurvaks. Sellistel päevadel tõuseb koormus kolm korda.
Oeh, need «monoliitsed ajad»! Olen kindel, et olete sarnast kogenud ja siiani ei saa aru, kuidas see teie jaoks juhtuda sai.
Mida siin teha — mood on iseloomulik ka tehnoloogiatele. Veel 5 aastat tagasi pidime mõtlema ümber ühe sellise moe — .NET-is ja MS SQL-serveris eksisteeriva veebisaidi, mis hoidis enda sees kogu saidi tööloogikat. Hoidis nii hoolikalt, et sellise monoliidi lahtivõtmine osutus pika ja väga keerulise naudinguga.
Väike kõrvalepõige.
Erinevatel üritustel ütlen: "kui te ei ole monoliiti lõhkemiseks saanud, siis te ei ole kasvanud!" Huvitav on teie arvamus selle kohta, palun kirjutage see kommentaaridesse.
Ja müristades kõlas äike
Naaseme meie "mäge". Koormuse jaotamiseks "monoliitse" funktsionaalsuse vahel otsustasime süsteemi jagada mikroteenusteks, mis põhinevad avatud lähtekoodiga tehnoloogiatel. Sest vähemalt on nende skaleerimine odavam. Ja arusaamine, et tuleb skaleerida (ja mitte vähe) oli meil 100% selge. Sest juba sel hetkel oli meil õnnestunud siseneda naaberriikide turgudele ja registreerimiste arv, nagu ka tellimuste arv, hakkas veelgi kiiremini kasvama.
Analüüsides esimesi kandidaate, kes lahkusid monoliidist mikroteenustesse, mõistsime, et 80% andmetest nende kohta pärineb 99% ulatuses back office süsteemidest, samas kui lugemine toimub esirinnast. Eriti puudutas see kahe olulise alamsüsteemi — kasutajate andmete süsteemi ja kaupade lõpphinnastamise süsteemi, mis põhineb lisakliendi allahindlustel ja kupongidel — funktsionaalsust.
Nüüd, kui me tagasi vaatame, on raske ette kujutada, et lisaks ülalmainitud alamsüsteemidele viidi meie monoliidist välja ka tootekataloogid, kasutajakorv, tooteotsingu süsteem, tootekataloogide filtreerimissüsteem ja erinevad soovituslikud süsteemid. Igaühe jaoks on olemas eraldi kitsa fookusega süsteemide klassid, kuid kunagi elasid nad kõik ühes "majas".
Kliendiandmete väljavõtmine plaaniti kohe sharded süsteemi peal. Kuid kaupade lõpphinna arvutamise funktsionaalsusele esitatud nõuded nõudsid head skaleeritavust lugemisel, kuna see genereeris suurima koormuse RPS-i põhjal ja oli baasiga teostamiseks kõige keerulisem (protsessis kaasatud väga palju andmeid).
Selle tulemusena tekkis meil skeem, mis sobib hästi Tarantooliga.
Sel ajal valiti mikroteenuste tööks mitme andmekeskuse süsteemid virtuaalsetel ja riistvaralistel masinatel. Nagu on näidatud joonistel, kasutati Tarantooli replikatsiooni variante nii master-master kui ka master-slave režiimis.
Arhitektuur. Variant 1. Kasutajate teenus
Praeguseks on olemas 24 shard'i, milles igas on 2 instants (üks igas andmekeskuses), kõik master-master režiimis.
Andmete kohal on rakendused, mis pöörduvad andmebaasi koopiate poole. Rakendused töötavad Tarantooliga meie kohandatud raamatukogu kaudu, mis rakendab Go-draiveri Tarantooli liidest. See näeb kõiki koopiaid ja suudab töötada peamise andmebaasiga lugemise ja kirjutamise osas. Sisuliselt rakendab see koopiate komplekti mudelit, millele on lisatud koopiate valiku loogika, uuesti proovimise teostamine, küsitluskatkestaja ja määratud limiit.
Samuti on võimalik konfigureerida koopiate valimise poliiikat shardi lõikes. Näiteks ringhääletamine.
Arhitektuur. Variant 2. Teenus toote lõpphinnangu arvutamiseks
Mõned kuud tagasi suunati enamik lõpphinnangu arvutamise päringutest uuele teenusele, mis põhimõtteliselt töötab ilma andmebaasideta, kuid mõni aeg tagasi töötas 100% teenusest Tarantooli peal.
Teenuse andmebaas koosneb neljast peamise andmebaasi serverist, kuhu sünkronisaator kogub andmeid, ja igaühel neist masteritest jagatakse koopiad ainult lugemiseks ettenähtud koopiatele. Igal peamisel andmebaasi serveril on umbes 15 sellist koopiat.
Nii esimeses kui teises skeemis, kui üks andmeressurss ei ole saadaval, saavad rakendused andmeid teiselt.
Tasub märkida, et Tarantooli koopiate replikatsioon on suhteliselt paindlik ja konfigureeritav reaalajas. Teistes süsteemides on tekkinud probleeme. Näiteks PostgreSQL-is nõuab max_wal_sendersi ja max_replication_slots parameetrite muutmine peamise andmebaasi serveri taaskäivitamist, mis mõnel juhul võib põhjustada ühenduste katkemist rakenduse ja andmebaasi vahel.
Otsige ja leiate!
Miks me ei teinud «nagu tavalised inimesed», vaid valisime ebatavalise meetodi? Sõltub sellest, mida normaalseks pidada. Paljud teevad hoopis Mongo klustere ja hajutavad selle kolme geograafiliselt jaotatud andmeressursi vahel.
Sel ajal olid meil juba kaks projekti Redisil. Esiteks — vahemälu ja teiseks oli see püsiv salvestus mitte väga kriitilistele andmetele. Sellega oli üsna keeruline, osaliselt meie enda süül. Mõnikord oli märkimisväärne kogus andmeid võtmes, ja aeg-ajalt oli saidil halvad hetked. Kasutasime seda süsteemi peamine-moodul variandina. Ja oli palju juhtumeid, kui midagi juhtus põhiserveriga ja replikatsioon katkestas.
Redis on hea stateless-ülesannete jaoks, mitte stateful. Üldiselt aitas see enamikke probleeme lahendada, kuid vaid juhul, kui need olid key-value lahendused koos paari indeksiga. Kuid Redis'i varasematel aegadel oli püsivuse ja replikatsiooni osas olukord üsna nukker. Lisaks olid ka kaebused jõudluse üle.
Mõtlesime MySQL ja PostgreSQL üle. Kuid esimene ei sobinud kuidagi meile, samas kui teine on iseenesest üsna keeruline toode, ning lihtsate teenuste loomine selle põhjal ei oleks otstarbekas.
Proovisime RIAK'i, Cassandra't, isegi graafikandmebaasi. Need olid kõik piisavalt nišilahendused, mis ei sobinud üldiseks universaalseks tööriistaks teenuste loomiseks.
Lõpuks valisime Tarantooli.
Me pöördusime selle poole, kui see oli versioonis 1.6. Meid huvitas key-value ja relatsioonilise andmebaasi funktsionaalsuse sümbioos. Seal on teised indeksid, tehingud ja spacet, need on nagu tabelid, kuid mitte lihtsad, sinna saab salvestada erinevate arvu veerge. Kuid Tarantooli tõeline müügiargument olid sekundaarsed indeksid koos key-value ja tehingutel põhineva lähenemisega.
Samuti mängis oma rolli reageeriv venekeelne kogukond, kes oli valmis chatis appi tulema. Kasutasime seda aktiivselt ja elasime chatis. Ja ei tohi unustada korralikku püsivust ilma ilmselgete probleemide ja vigadeta. Kui vaadata meie ajalugu Tarantooliga, siis meil oli palju valu ja ebaõnnestumisi replikatsiooniga, kuid me ei ole kunagi andmeid tema tõttu kaotanud!
Rakendamine algas raskelt.
Sel ajal oli meie peamine arendustegevuse virn .NET, mille jaoks Tarantoolile ei olnud konnektorit. Alustasime kohe Go'ga midagi kirjutamist. Lua'ga tuli ka päris hästi välja. Sel hetkel oli peamine probleem silumisest: .NET-is oli sellega kõik suurepärane, aga seejärel siseneda embedded Lua maailma, kus sul pole mingit silumist peale logide, oli keeruline. Lisaks hakkas replikatsioon mingil põhjusel perioodiliselt purunema, pidime süvenema Tarantooli mootori seadmetesse. Sellega aitas chat, dokumentatsioon vähem, mõnikord vaatasime ka koodi. Sel ajal oli dokumentatsioon keskpärane.
Nii on mõne kuu jooksul õnnestunud koguda kogemusi ja saavutada muljetavaldavaid tulemusi Tarantooliga töötamisel. Meie git-repositooriumis on dokumenteeritud ideaalnäidised, mis on aidanud luua uusi mikroteenuseid. Näiteks, kui tekkis ülesanne luua uus mikroteenus, vaatas arendaja standardlahenduse lähtekoodi repositooriumist ja uue loomine ei võtnud rohkem kui nädal.
Need olid erilised ajad. Sel ajal sai administ naabertöölaual küsida: "Anna mulle virtuaalserver". Umbes kolmkümmend minutit hiljem oli masin juba sinu käes. Sa ise ühendusid, installisid kõik vajaliku ja sulle suunati sinna liiklus.
Tänapäeval ei õnnestu see enam niimoodi: peab seadistama teenusele monitooringu, logimise, funktsionaalsuse katmiseks testid, tellima virtuaalserveri või Kuberneetse seadistuse jne. Üldiselt on see parem, kuigi see võtab rohkem aega ja on vaevarikam.
Jaga ja valluta. Kuidas on lood Luaga?
Sellel oli tõsine dilemma: mõnel meeskonnal ei õnnestunud usaldusväärselt reklaamida muudatusi teenuses, milles oli palju loogikat Luas. Sageli saatis see kaasa teenuse toimimatuks jäämise.
See tähendab, et arendajad valmistavad mingisuguse muudatuse ette. Tarantool hakkab tegema migratsiooni, samas kui replikal on veel vana kood; sinna jõuab replikatsiooni kaudu mingi DDL, veel midagi, ja kood lihtsalt laguneb, kuna see ei ole arvesse võetud. Tulemuseks oli see, et administraatorite uuendamisprotseduur oli kirjutatud A4-le: peata replikatsioon, uuenda see, käivita replikatsioon, lülita siit välja, uuenda seal. Õudus!
Lõpuks üritame me nüüd enamasti Luaga mitte midagi teha. Lihtsalt iproto kaudu (binaarne protokoll serveriga suhtlemiseks) ja kõik. Võib-olla on see arendajate teadmiste puudus, kuid sellisest vaatenurgast on süsteem keeruline.
Me ei järgigi seda stsenaariumi alati pimesi. Täna ei ole meil musta ega valget: kas kõik on Luas või kõik on Go-s. Me juba mõistame, kuidas neid kombineerida, et hiljem migratsiooni probleemidega silmitsi seista.
Kus on praegu Tarantool?
Tarantool on kasutusel kauba lõpphinnangute arvutamise teenuses, mis arvestab ka allahindluskupongidega, tuntud kui «Promotayzer». Nagu eelnevalt mainitud, jääb see nüüd ajalukku: selle asemele tuleb uus katalooge teenus koos eelnevalt arvutatud hindadega, kuid veel kuus kuud tagasi tehti kõik arvutused «Promotayzeris». Varem oli pool selle loogikast kirjutatud Lua-s. Kaks aastat tagasi muudeti teenus arhiveerimiseks ja loogika kirjutati Go-s ümber, kuna allahindluste töömehaanika muutus veidi ja teenusele ei piisanud jõudlusest.
Üks kriitilisemaid teenuseid on kasutajaprofiil. Seega kõik Wildberries kasutajad on salvestatud Tarantooli, neid on umbes 50 miljonit. ID põhjal sharditud süsteem, mis on jaotatud mitme andmekeskuse vahel ja ühendatud Go-teenustega.
RPS järgi oli kunagi liider «Promotayzer», mis jõudis 6000 päringuni. Ühel hetkel oli meil 50-60 eksemplari. Praegu on RPS liider - kasutajaprofiilid, umbes 12 tuhat. Selle teenuse puhul kasutatakse kohandatud shardingut, jagades kasutaja ID-de vahemike kaupa. Teenus teenindab rohkem kui 20 masinat, kuid see on liiga palju, plaanime eraldatud ressursse vähendada, sest 4-5 masina võimekusest piisab.
Sessiooniteenus on meie esimene teenus vshard ja Cartridge'i peal. Vshard'i seadistamine ja Cartridge'i uuendamine nõudis meilt teatud tööjõudu, kuid lõpuks sai kõik korda.
Teenuse, mis kuvab erinevaid bännerid veebisaidil ja mobiilirakenduses, oli üks esimesi, mis lasti välja kohe Tarantooli peal. See teenus on tähelepanuväärne, et see on olnud kasutuses umbes 6-7 aastat ning pole kordagi taaskäivitatud. Kasutati replikeerimist master-master. Midagi ei ole kunagi katkenud.
On näide Tarantooli kasutamisest kiirete kataloogide funktsionaalsuses laosüsteemis, et kiiremini teatud juhtudel teavet uuesti kontrollida. Proovisime selleks kasutada Redis't, kuid andmed mälus võtsid rohkem kohta kui Tarantoolil.
Ootejärjekorra, klienditellimuste, praegu moes olevate lugude ja ootel toodete teenused töötavad samuti Tarantooliga. Viimane teenus võtab mälus umbes 120 GB. See on kõige mahukam teenus eespool nimetatutest.
Kokkuvõte
Sekundaarsete indeksite, key-value ja tehingute kombinatsioon teeb Tarantooli suurepäraseks valikuks mikroteenuste arhitektuuridele. Siiski kohtasime raskusi teenuste muudatuste juurutamisel, kus oli palju Lua-logi - teenused lakkasid tihti töötamast. Seda me ei suutnud lahendada ja aja jooksul jõudsime erinevatesse Lua ja Go kombinatsioonidesse: teame, millal kasutada ühte keelt ja millal teist.
Mida veel selle kohta lugeda
- Loome nullist kõrge koormusega rakendust Tarantoolis
- Usaldusväärne valik Tarantool Cartridge liidrilt
- Tarantooli Telegrami kanal tooteteabega
- Arutage Tarantooli meie kogukonna vestluses
Allikas: habr.com
