Me kõik armastame lugusid. Meile meeldib istuda lafirel ja rääkida oma varasematest võitudest, lahingutest või lihtsalt oma töökogemusest.
Täna on just selline päev. Ja kuigi te ei istu võib-olla lafirel, on meil teile lugu rääkida. Lugu sellest, kuidas me hakkasime töötama Tarantooli andmesalvesti peal.
Kaua aega tagasi oli meie ettevõttes paar 'monoliiti' ja üks tipp, mille poole need monoliidid aeglaselt, kuid kindlalt liikusid, piirates meie ettevõtte, meie arengu edasiviimist. Ja oli kindel arusaam: ühel päeval seisame me selle tipuga silmitsi.
Praegu valitseb meil ideoloogia, et kõik tuleb eraldada, alates riistvarast kuni äri loogikani. Selle tulemusena on meil näiteks kaks andmekeskust, mis on praktiliselt sõltumatud võrgu tasemel. Aga siis oli kõik hoopis teistmoodi.
Tänapäeval on muudatuste tegemiseks palju tööriistu ja vahendeid nagu CI/CD, K8S jne. 'Monoliidi' ajal ei läinud meil vajagi nii palju võõrkeelseid termineid. Piisas lihtsalt 'salvestamise' täiendamisest andmebaasis.
Aga aeg kulges edasi, samas kui päringute arv küünitas ülespoole, ulatudes RPS numbriteni, mis mõnikord ületasid meie võimed. Kui sisenesime SRÜ turgudele, ei langenud esimese monoliidi andmebaasi koormus kunagi alla 90%, samas kui RPS püsis tasemel 2400. Ja need ei olnud lihtsalt väikesed päringud, vaid massiivsed päringud, kus oli palju kontrollimisi ja JOIN'e, mis pidid läbima suisa poole andmete hulgast suure IO taustal.
Kui turule hakkasid korralikult langevad hinnad nüüd, — ja Wildberries alustas nende korraldamist esimesena Venemaal, — muutus olukord täiesti murettekitav. Sest koormus sellistel päevadel suureneb kolmekordseks.
Ah, need 'monoliidi ajad'! Olen kindel, et olete ka teinud sama kogemuse ja tõenäoliselt ei suuda siiani mõista, kuidas see kõik teiega juhtuda sai.
Mis sa teed — trendid on seotud ka tehnoloogiaga. Veel viis aastat tagasi pidime oma .NET ja MS SQL-serveri saidiga, mis hoidis kõiki saidi tööloogika elemente, tõeliselt ümber mõtlema. Ta hoidis seda nii hoolega, et sellise monoliidi lõhkumine osutus pikaajalise ja väga keerulise ettevõttena.
Pisike kõrvalepõige.
Erinevatel üritustel ütlen: 'kui te ei ole monoliiti lõhkunud, siis te ei ole kasvanud!' Teie arvamused selle kohta on huvitavad, palun kirjutage need kommentaaridesse.
Ja äkki kõlas kõue.
Naaseme meie 'lafire' juurde. Et jagada 'monoliidi' funktsionaalsuse koormust, otsustasime süsteemi jagada microservices-iks, aluseks avatud lähtekoodiga tehnoloogiatele. Sest vähemalt, nende skaleerimine on odavam. Ja arusaam sellest, et meil tuleb skaleerida (ja piisavalt palju) oli meil 100% ulatuses. Tolleks hetkeks olid meil juba õnnestunud siseneda naaberriikide turgudele ja registreerimiste arv ning tellimuste arv hakkas veelgi rohkem kasvama.
Esialgsete kandidaatide analüüsimisel monoliidist mikroteenustesse siirdumiseks saime aru, et 80%-l juhtudest tuli 99% kirjutamisest back office-süsteemidest, samas kui lugemine toimus esirinnas. Eelkõige puudutas see kaht meie jaoks olulist alamsüsteemi — kasutajate andmeid ja lõpphinnastamise süsteemi, mis põhineb informatsioonil klientide allahindluste ja kupongide kohta.
Kohati kõrvalepõige. Praegu tundub uskumatu, aga lisaks eespool mainitud alamsüsteemidele tõstsime meie monoliidist välja ka tootekataloogid, kasutajakorvi, tooteotsingu süsteemi, tootekataloogide filtreerimise süsteemi ja erinevad soovitussüsteemid. Igaühe jaoks eksisteerivad eraldi kitsas fookusega süsteemid, kuid kunagi elasid nad kõik ühes 'taredes'.
Otsustasime oma klientide andmed viia sharding-süsteemi. Toote lõpphinna arvutamise funktsionaalsuse väljaviimine nõudis head skaleeritavust lugemise osas, kuna see põhjustas RPS koormuse ja oli andmebaasi jaoks kõige keerulisem teostada (protsessis osales väga palju andmeid).
Selle tulemusena tekkis meil skeem, mis sobib hästi Tarantooli jaoks.
Sel ajal valisime microservices'ide tööks skeemid, mis töötavad mitme andmekeskusega virtuaalsete ja füüsiliste masinatega. Nagu joonistel näidatud, rakendati Tarantooli replikatsiooni variante nii master-master režiimis kui ka master-slave režiimis.
Arhitektuur. Variant 1. Kasutajate teenus
Praeguseks on see 24 shardi, millest igas on 2 instantsi (üks igas andmekeskuses), kõik master-master režiimis.
Andmete kohal on rakendused, mis suhtlevad andmebaasi koopiatega. Rakendused töötavad Tarantooliga meie kohandatud raamatukogu kaudu, mis rakendab Go-draiveri Tarantooli liidest. See näeb kõiki koopiad ja suudab töötada peamise andmeallikaga lugemiseks ja kirjutamiseks. Sisuliselt rakendab see koopiate komplekti mudelit, kuhu on lisatud koopiate valiku, uuesti proovimise, ringluste katkestamise ja määratud piirangute loogika.
Lisaks on võimalik konfigureerida koopiate valimise poliitikat shardide lõikes. Näiteks võivad need olla üksteise järel valitud.
Arhitektuur. Variant 2. Toote lõpphinna arvutamise teenus.
Mõned kuud tagasi suunati enamik toote lõpphinna arvutamise päringutest uuele teenusele, mis põhimõtteliselt töötab ilma andmebaasita, kuid mõni aeg tagasi töötas 100% Tarantooli teenus, mis oli selle taga.
Teenuse andmebaas koosneb 4 peast, kuhu süsinikekvaliteedi kogumine toimub ja iga peamine andmeallikas jagab koopiatele loetud andmeid. Iga peamise andmeallika kohta on umbes 15 koopiat.
Nii esimeses kui ka teises skeemis, kui üks andmekeskus on saadaval, saavad rakendused andmeid teiselt poolt.
Tasub märkida, et Tarantoolis on koopiate tegemine üsna paindlik ja konfigureeritav reaalajas. Muudes süsteemides on esinenud probleeme, näiteks PostgreSQL'is, kui max_wal_senders ja max_replication_slots parameetrite muutmine nõuab peamise andmeallika 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» ja valisime ebatavalise meetodi? Sõltub, mida pidada tavaliseks. Paljudel on kokku pandud Mongo klaster ja jaotatud see kolme geograafiliselt jaotatud andmekeskuse vahel.
Sel ajal olid meil juba kaks projekti Redisil. Esimene – cache, ja teine, mis esindas püsivalt salvestatud mitte liiga kriitiliste andmete hoiust. Sellega oli üsna keeruline, osaliselt meie süü. Vahetevahel olid suured mahud võtmes, ja aeg-ajalt läks veebileht halvemaks. Kasutasime seda süsteemi peamine-koopiatena. Ja juhtus palju juhtumeid, millega seoses peamise andmeallikaga juhtus midagi ja koopiate tegemine puruneb.
See tähendab, et Redis sobib stateless-ülesannete jaoks, mitte stateful-ülesannete jaoks. Põhimõtteliselt suudab see lahendada enamikku ülesandeid, kuid ainult siis, kui need olid võtme-väärtuse lahendused paaride indeksitega. Kuid sel ajal olid Redisil suured probleemid järjepidevuse ja koopiate tegemisega. Samuti olid esinenud kaebusi jõudluse osas.
Mõtlesime MySQL'le ja PostgreSQL'ile. Kuid esimene ei sobinud meile kuidagi, teine on üsna keeruline toode ja selle põhjal lihtsaid teenuseid rajada oleks olnud mõtlematu.
Proovisime RIAKi, Cassandra't, isegi graafi andmebaasi. Kõik need olid üsna niššilahendused, mis ei sobinud universaalse tööriistana teenuste loomisel.
Lõpuks peatume Tarantoolil.
Me pöördusime selle poole, kui see oli versioonis 1.6. See köitis meid key-value ja relatsioonilise andmebaasi funktsionaalsuse sümbioosiga. 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.
Oma osa mängis ka vastutulelik venekeelne kogukond, kes oli valmis vestluses abi osutama. Kasutasime seda aktiivselt ja elasime praktiliselt vestluses. Ja ärge unustage korralikku järjepidevust ilma ilmsete vigade ja probleemideta. Kui vaadata meie ajalugu Tarantooliga, oli palju valusid ja komistusi koopiate tegemise osas, kuid me ei kaotanud tema süü tõttu kunagi andmeid!
Rakendamine algas raskelt.
Sel ajal oli meie peamine arendustööriist .NET, millega ei olnud Tarantooli ühendust. Alustasime kohe Go peal. Lua-ga läks ka üsna hästi. Peamine probleem sel ajal oli tõrkeotsing: .NET'is on see hämmastavalt lihtne, aga pärast seda sukelduda sisseehitatud Lua maailma, kui sul on ainult logid, mitte mingit tõrkeotsingut, oli keeruline. Samuti purunes koopiate tegemine mingil põhjusel perioodiliselt, pidime süvenema Tarantooli mootori struktuuri. Sellega aitas vestlus, vähemal määral – dokumentatsioon, aeg-ajalt vaatasime koodi. Sel ajal ei olnud dokumentatsioon kuigi hea.
Nii said paar kuud jooksul paljusid vigu tekitada ja saavutada head tulemused Tarantooliga töötades. Koondasime git'is eeskujulikke töid, mis aitasid uute mikroteenuste rajamisel. Näiteks, kui tekkis ülesanne: teha järjekordne mikroteenus, siis arendaja vaatas eeskujulike lahenduste lähtekoodile hoidlas, ja uue loomine ei võtnud aega rohkem kui nädal.
Need olid erilised ajad. Toona sai läheneda kõrvalolevale administraatorile ja paluda: „Anna mulle virtuaal”. Umbes kolme kümne minuti pärast oli masin juba sinu käes. Sa ühendasid ise, installisid kõik ja suunati sulle liiklus.
Tänapäeval ei toimi see enam nii: tuleb seadistada monitorimine, logimine, katsetada funktsionaalsust, tellida virtuaal või tarnimine Kuberisse jne. Üldiselt on see parem, kuigi see on aeganõudvam ja keerukam.
Jagage ja valitsege. Kuidas on lood Luaga?
Oli tõsine dilemma: mõnedes meeskondades ei õnnestunud usaldusväärselt muudatusi teenusesse välja viia, kus oli palju loogikat Luas. Tihti kaasnes sellega teenuse mittetöötamine.
See tähendab, et arendajad valmistavad ette mõne 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õetud. Tulemuseks oli, et administraatorite uuendamisprotseduur oli kirja pandud A4-le: peatage replikatsioon, uuendage see, käivitage replikatsioon, lülitage siin välja, uuendage seal. Õudne!
Kokkuvõttes proovime praegu enamasti Luas mitte midagi teha. Lihtsalt iprotoga (binaarne protokoll serveriga suhtlemiseks) ja kõik. Võib-olla on see arendajate teadmiste puudumise probleem, kuid sellisest vaatenurgast on süsteem keeruline.
Me ei järgige alati seda stsenaariumi pimesi. Täna pole meil mustvalget: kas kõik on Luas või kõik Go-s. Aru saame, kuidas neid kombineerida, et hiljem migratsiooniga probleeme ei tekiks.
Kus on Tarantool praegu?
Tarantool on kasutusel toodete lõplikku maksumust arvestavas teenuses, mis võtab arvesse allahindluste kupongid, mida tuntakse kui „Promotaister”. Nagu eelnevalt mainitud, on see nüüd tagaplaanile jäämas: uut kataloogiteenust, kus on eelnevalt arvutatud hinnad, kuid veel kuus kuud tagasi tehti kõik arvutused „Promotaisteris”. Varem oli pool selle loogikast kirjutatud Luas. Kaks aastat tagasi muudeti teenus ladustamiseks ja loogika kirjutati Go-s ümber, kuna allahindluste mehhanika muutus ja teenusel puudus jõudlus.
Üks kõige kriitilisemaid teenuseid on kasutajaprofiil. See tähendab, et kõik Wildberriesi kasutajad on salvestatud Tarantooli, kokku umbes 50 miljonit. ID kasutaja põhjal jaotatud süsteem, jagatud mitmesse andmekeskusesse, Go-teenustega.
RPS osas oli kunagi liidriks „Promotaister”, saavutades kuni 6000 päringut. 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õhjal. Teenus teenindab üle 20 masina, kuid see on liiga palju; plaanime ressursse vähendada, kuna 4-5 masinat on piisavad.
Seansiteenus on meie esimene teenus vshard ja Cartridge peal. Vshardi seadistamine ja Cartridge’i uuendamine nõudsid meist teatud tööjõuressursse, kuid lõpuks läks kõik korda.
Ainult reklaamide kuvamise teenus veebilehel ja mobiilirakenduses oli üks esimesi, mis välja anti Tarantoolile. See teenus on huvitav, et see on olnud aktiivne umbes 6-7 aastat ja pole kordagi taaskäivitatud. Kasutati master-master replikatsiooni. Midagi pole kunagi katki läinud.
On näide Tarantooli kasutamisest kiirete registrite funktsionaalsuse jaoks laosüsteemis, et mõnes olukorras kiiresti teavet üle kontrollida. Proovisime selleks kasutada Redis’t, kuid andmed mälus võtsid rohkem ruumi kui Tarantoolil.
Ootejärjekordade teenused, kliendilepingud, moodsad lugu ja edasilükatud tooted töötavad samuti Tarantooliga. Viimane teenus võtab mälus umbes 120 GB ja on üks mahukamaid eespool mainitud teenustest.
Kokkuvõte
Aitäh teisejärguliste indeksite koos key-value ja tehingutega, sobib Tarantool suurepäraselt mikroteenuste põhistele arhitektuuridele. Siiski oleme kokku puutunud raskustega, kui muudatusi välja viidud teenustes, kus on palju loogikat Luas — teenused katkestavad sageli töö. Seda me ei suutnud ületada ja aja jooksul jõudsime erinevate Lua ja Go kombinatsioonideni: teame, kus ühte keelt kasutada ja kus teist.
Mida veel teemast lugeda
- Loodame nullist välja kõrge koormusega rakenduse Tarantooli peale
- Usaldusväärne valik Tarantool Cartridge’i liidriks
- Telegrami kanal Tarantooli tooteteated
- Arutame Tarantooli kogukonna vestlusruumis
Allikas: habr.com
