Vsi imamo radi zgodbe. Radi sedimo okoli ognja in se pogovarjamo o preteklih zmagah, bitkah ali preprosto o naših delovnih izkušnjah.
Danes je pač tak dan. In tudi če trenutno niste pri ognju, imamo zgodbo za vas. Zgodba o tem, kako smo začeli delati s shranjevanjem na Tarantoolu.
Nekoč je imelo naše podjetje par »monolitov« in en »plafon« za vse, h kateremu so se ti monoliti počasi, a vztrajno bližali in omejevali polet našega podjetja, naš razvoj. In bilo je jasno razumevanje: nekega dne bomo močno udarili po tej zgornji meji.
Zdaj prevladuje ideologija ločevanja vsega in vseh, od opreme do poslovne logike. Posledično imamo na primer dva DC-ja, ki sta praktično neodvisna na ravni omrežja. In potem je bilo vse popolnoma drugače.
Danes obstaja veliko orodij in orodij za spreminjanje v obliki CI/CD, K8S itd. V »monolitnem« času nismo potrebovali toliko tujih besed. Dovolj je bilo preprosto popraviti "shrambo" v bazi podatkov.
Toda čas je tekel naprej in število zahtevkov se je premikalo skupaj z njim, pri čemer so včasih streljanje RPS preseglo naše zmožnosti. Z vstopom držav CIS na trg obremenitev procesorja baze podatkov prvega monolita ni padla pod 90%, RPS pa je ostal na ravni 2400. In to niso bili le majhni izbirniki, ampak zajetne poizvedbe z kup preverjanj in JOIN-jev, ki bi se lahko izvajali za skoraj polovico podatkov v ozadju velikih IO.
Ko so se na sceni začele pojavljati polne razprodaje na črni petek - in Wildberries je bil eden prvih, ki jih je organiziral v Rusiji - je situacija postala popolnoma žalostna. Navsezadnje se obremenitev v takih dneh poveča trikrat.
Oh, ti "monolitni časi"! Prepričan sem, da ste že kdaj doživeli kaj podobnega, pa še vedno ne razumete, kako se vam je to lahko zgodilo.
Kaj lahko storite - moda je neločljivo povezana s tehnologijo. Pred približno 5 leti smo morali premisliti eno od teh modifikacij v obliki obstoječe strani na .NET in MS SQL strežniku, ki je skrbno shranila vso logiko same strani. Hranil sem ga tako skrbno, da se je žaganje takšnega monolita izkazalo za dolg in prav nič lahek užitek.
Majhen odmik.
Na različnih dogodkih rečem: "če nisi videl monolita, potem nisi zrasel!" Zanima me vaše mnenje o tej zadevi, napišite ga v komentarje.
Zvok groma
Vrnimo se k našemu "pogorišču". Za porazdelitev bremena »monolitne« funkcionalnosti smo se odločili sistem razdeliti na mikrostoritve, ki temeljijo na odprtokodnih tehnologijah. Ker so vsaj cenejši za obseg. In 100-odstotno smo se zavedali, da se bomo morali povečati (in veliko). Navsezadnje je bil že takrat možen vstop na trge sosednjih držav, število registracij, pa tudi naročil je začelo še močneje rasti.
Po analizi prvih kandidatov za odhod iz monolita v mikrostoritve smo ugotovili, da 80 % pisanja v njih prihaja iz zalednih sistemov, branja pa iz frontnih pisarn. V prvi vrsti je šlo za nekaj za nas pomembnih podsistemov - podatke o uporabnikih in sistem za izračun končne cene blaga na podlagi informacij o dodatnih popustih in kuponih kupcev.
Zamaknjeno. Zdaj si je grozljivo predstavljati, a poleg zgoraj omenjenih podsistemov so bili iz našega monolita odstranjeni tudi katalogi izdelkov, uporabniška nakupovalna košarica, sistem iskanja izdelkov, sistem filtriranja katalogov izdelkov in različni sistemi priporočil. Za delovanje vsakega od njih obstajajo ločeni razredi ozko ukrojenih sistemov, a nekoč so vsi živeli v eni »hiši«.
Takoj smo načrtovali prenos podatkov o naših strankah v razdeljeni sistem. Odstranitev funkcionalnosti za izračun končne cene blaga je zahtevala dobro razširljivost za branje, saj je povzročila največjo obremenitev RPS in je bila najtežje implementirana za bazo (veliko podatkov je vključenih v proces izračuna).
Kot rezultat smo prišli do sheme, ki se dobro ujema s programom Tarantool.
Takrat so bile za delovanje mikrostoritev izbrane sheme za delo z več podatkovnimi centri na virtualnih in strojnih strojih. Kot je prikazano na slikah, so bile možnosti replikacije Tarantool uporabljene v načinih master-master in master-slave.
Arhitektura. Možnost 1. Uporabniška storitev
Trenutno je na voljo 24 drobcev, od katerih ima vsak 2 primerka (po enega za vsak DC), vsi v načinu master-master.
Na vrhu baze podatkov so aplikacije, ki dostopajo do replik baze podatkov. Aplikacije delujejo s Tarantoolom prek naše knjižnice po meri, ki implementira vmesnik gonilnika Tarantool Go. Vidi vse replike in lahko sodeluje z mojstrom pri branju in pisanju. V bistvu implementira model nabora replik, ki dodaja logiko za izbiranje replik, izvajanje ponovnih poskusov, odklopnik in omejitev hitrosti.
V tem primeru je možno konfigurirati politiko izbire replike v kontekstu drobcev. Na primer, roundrobin.
Arhitektura. Možnost 2. Storitev za izračun končne cene blaga
Pred nekaj meseci je največ zahtevkov za izračun končne cene blaga šlo na novo storitev, ki načeloma deluje brez podatkovnih baz, pred časom pa je vse 100% obdelala storitev s Tarantoolom pod pokrovom.
Servisno bazo podatkov sestavljajo 4 glavni, v katere sinhronizator zbira podatke, in vsak od teh glavnih podvajanj distribuira podatke replikam samo za branje. Vsak mojster ima približno 15 takih replik.
V prvi ali drugi shemi, če en DC ni na voljo, lahko aplikacija prejme podatke v drugem.
Omeniti velja, da je replikacija v Tarantoolu precej prilagodljiva in jo je mogoče konfigurirati med izvajanjem. Pri drugih sistemih so se pojavile težave. Na primer, spreminjanje parametrov max_wal_senders in max_replication_slots v PostgreSQL zahteva ponovni zagon čarovnika, kar lahko v nekaterih primerih povzroči prekinitev povezav med aplikacijo in DBMS.
Iščite in našli boste!
Zakaj tega nismo storili »kot normalni ljudje«, ampak smo izbrali netipičen način? Odvisno od tega, kaj velja za normalno. Mnogi ljudje na splošno naredijo gručo iz Monga in jo razširijo na tri geografsko porazdeljene DC-je.
Takrat smo imeli že dva Redis projekta. Prvi je bil predpomnilnik, drugi pa obstojna shramba za ne preveč kritične podatke. Z njim je bilo kar težko, deloma tudi po naši krivdi. Včasih so bile v ključu precej velike količine in od časa do časa je spletno mesto postalo slabo. Ta sistem smo uporabili v različici master-slave. In bilo je veliko primerov, ko se je nekaj zgodilo z masterjem in se je replikacija pokvarila.
To pomeni, da je Redis dober za naloge brez stanja, ne za tiste s stanjem. Načeloma je omogočal reševanje večine problemov, vendar le, če so bile rešitve ključ-vrednost s parom indeksov. Toda Redis je bil takrat precej žalosten z vztrajnostjo in razmnoževanjem. Poleg tega so bile pritožbe glede delovanja.
Razmišljali smo o MySQL in PostgreSQL. Toda prvi se nam nekako ni prijel, drugi pa je že sam po sebi precej sofisticiran izdelek in bi bilo neprimerno na njem graditi enostavne storitve.
Preizkusili smo RIAK, Cassandra, celo podatkovno bazo grafov. Vse to so dokaj nišne rešitve, ki niso bile primerne za vlogo splošnega univerzalnega orodja za ustvarjanje storitev.
Na koncu smo se odločili za Tarantool.
Obrnili smo se nanj, ko je bil v različici 1.6. Zanimala nas je simbioza ključ-vrednosti in funkcionalnosti relacijske podatkovne baze. Obstajajo sekundarni indeksi, transakcije in presledki, ti so kot tabele, vendar niso enostavni, vanje lahko shranite različno število stolpcev. Toda ubijalska lastnost Tarantoola so bili sekundarni indeksi v kombinaciji s ključno vrednostjo in transakcijskostjo.
Svojo vlogo je odigrala tudi odzivna rusko govoreča skupnost, pripravljena pomagati v klepetu. To smo aktivno uporabljali in živimo neposredno v klepetu. In ne pozabite na spodobno vztrajnost brez očitnih zmot in napak. Če pogledate našo zgodovino s Tarantoolom, smo imeli veliko težav in napak s podvajanjem, vendar nikoli nismo izgubili podatkov zaradi njegove napake!
Izvajanje se je začelo težko
Takrat je bil naš glavni razvojni sklad .NET, na katerega ni bilo priključka za Tarantool. Takoj smo začeli nekaj delati v Go. Dobro je delovalo tudi z Luo. Glavna težava takrat je bila odpravljanje napak: v .NET je s tem vse super, potem pa se je bilo težko potopiti v svet vgrajene Lue, ko razen dnevnikov nimate nobenega odpravljanja napak. Poleg tega je iz nekega razloga replikacija občasno razpadala, zato sem se moral poglobiti v strukturo mehanizma Tarantool. Pri tem je pomagal klepet in v manjši meri dokumentacija, včasih smo pogledali kodo. Takrat je bila dokumentacija tako-tako.
Tako mi je v nekaj mesecih uspelo priti do glave in doseči spodobne rezultate dela s Tarantoolom. Zbrali smo referenčni razvoj v git, ki je pomagal pri oblikovanju novih mikrostoritev. Na primer, ko se je pojavila naloga: ustvariti drugo mikrostoritev, je razvijalec pogledal izvorno kodo referenčne rešitve v skladišču in ni trajalo več kot en teden, da je ustvaril novo.
To so bili posebni časi. Običajno bi lahko šel do skrbnika za sosednjo mizo in ga vprašal: "Daj mi virtualni stroj." Približno trideset minut kasneje je bil avto že pri vas. Sami ste se povezali, vse namestili in promet je bil poslan k vam.
Danes to ne bo več delovalo: storitvi morate dodati spremljanje in beleženje, pokriti funkcionalnost s testi, naročiti virtualni stroj ali dostavo Kuberju itd. Na splošno bo tako bolje, čeprav bo trajalo dlje in bo bolj težavno.
Razdeli in vladaj. Kaj je narobe z Luo?
Obstajala je resna dilema: nekatere ekipe niso mogle zanesljivo uvesti sprememb storitve z veliko logike v Lui. To je pogosto spremljalo nedelovanje storitve.
To pomeni, da razvijalci pripravljajo neke vrste spremembo. Tarantool začne izvajati selitev, vendar je replika še vedno s staro kodo; Prek replikacije tja pride kakšen DDL ali kaj drugega, koda pa enostavno razpade, ker se ne upošteva. Posledično je bil postopek posodabljanja za skrbnike postavljen na list A4: ustavi podvajanje, posodobi to, vklopi podvajanje, izklopi tukaj, posodobi tam. Nočna mora!
Kot rezultat, zdaj najpogosteje poskušamo narediti nič v Lui. Samo uporabite iproto (binarni protokol za interakcijo s strežnikom) in to je to. Morda gre za pomanjkanje znanja med razvijalci, a s tega vidika je sistem kompleksen.
Temu scenariju ne sledimo vedno slepo. Danes nimamo črno-belega: ali je vse v Lui ali pa je vse v Go. Razumemo že, kako jih lahko kombiniramo, da kasneje ne bomo imeli težav z migracijo.
Kje je zdaj Tarantool?
Tarantool se uporablja v storitvi za izračun končne cene blaga ob upoštevanju kuponov za popust, znanih tudi kot "Promotor". Kot sem že rekel, zdaj odhaja v pokoj: nadomešča ga nova kataloška storitev z vnaprej izračunanimi cenami, vendar so bili pred šestimi meseci vsi izračuni narejeni v Promotizerju. Prej je bila polovica njegove logike napisana v Lui. Pred dvema letoma so storitev spremenili v skladišče, logiko pa prepisali v Go, ker se je mehanika popustov nekoliko spremenila, storitev pa premajhna.
Ena najbolj kritičnih storitev je uporabniški profil. To pomeni, da so vsi uporabniki Wildberries shranjeni v Tarantoolu in jih je okoli 50 milijonov. Sistem, razdeljen z ID-jem uporabnika, porazdeljen na več DC-jev, povezanih s storitvami Go.
Po RPS je bil nekoč vodilni Promoter, ki je dosegel 6 tisoč zahtev. Na neki točki smo imeli 50-60 izvodov. Zdaj so vodilni v RPS uporabniški profili, približno 12 tisoč.Ta storitev uporablja deljenje po meri, razdeljeno na obsege ID-jev uporabnikov. Servis oskrbuje več kot 20 strojev, vendar je to preveč, nameravamo zmanjšati dodeljena sredstva, saj mu zadostuje zmogljivost 4-5 strojev.
Storitev Session je naša prva storitev na vshard in Cartridge. Nastavitev vshard-a in posodobitev Cartridge-a sta od nas zahtevala nekaj truda, vendar se je na koncu vse izšlo.
Storitev za prikaz različnih pasic na spletni strani in v mobilni aplikaciji je bila ena prvih, ki je bila izdana neposredno na Tarantoolu. Ta storitev je znana po tem, da je stara 6-7 let, še vedno deluje in ni bila nikoli znova zagnana. Uporabljena je bila replikacija master-master. Nikoli se ni nič pokvarilo.
Obstaja primer uporabe Tarantoola za hitro referenčno funkcijo v skladiščnem sistemu za hitro dvojno preverjanje informacij v nekaterih primerih. Za to smo poskušali uporabiti Redis, vendar so podatki v pomnilniku zavzeli več prostora kot Tarantool.
Storitve čakalne vrste, naročnine strank, trenutno modne zgodbe in odloženo blago delujejo tudi s Tarantoolom. Zadnja storitev v pomnilniku zavzame približno 120 GB. To je najobsežnejša storitev od naštetih.
Zaključek
Zahvaljujoč sekundarnim indeksom v kombinaciji s ključno vrednostjo in transakcijskostjo je Tarantool zelo primeren za arhitekture, ki temeljijo na mikrostoritvah. Vendar smo pri uvajanju sprememb storitev z veliko logike v Lui naleteli na težave - storitve so pogosto prenehale delovati. Tega nismo mogli premagati in sčasoma smo prišli do različnih kombinacij Lua in Go: vemo, kje uporabiti en jezik in kje drugega.
Kaj še prebrati na to temo
- Ustvarjanje visoko obremenjene aplikacije iz nič z uporabo Tarantoola
- Izbira zaupanja vrednega vodje v Tarantool Cartridge
- Telegram kanal Tarantool z novicami o izdelku
- Razpravljajte o Tarantoolu v klepetu skupnosti
Vir: www.habr.com