Svi volimo priče. Volimo sjediti oko vatre i pričati o našim prošlim pobjedama, bitkama ili jednostavno o našem radnom iskustvu.
Danas je upravo takav dan. Čak i ako trenutno niste na požarištu, imamo priču za vas. Priča o tome kako smo počeli da radimo sa skladištem na Tarantoolu.
Nekada je naša kompanija imala par “monolita” i jedan “plafon” za sve, kojem su se ti monoliti polako ali sigurno približavali, ograničavajući let naše kompanije, naš razvoj. I postojalo je jasno razumevanje: jednog dana ćemo jako udariti u ovaj plafon.
Sada je preovlađujuća ideologija razdvajanja svega i svakoga, od opreme do poslovne logike. Kao rezultat toga, mi, na primjer, imamo dva DC-a koji su praktički nezavisni na nivou mreže. A onda je sve bilo potpuno drugačije.
Danas postoji mnogo alata i alata za unošenje promjena u obliku CI/CD, K8S, itd. U “monolitnom” vremenu nije nam trebalo toliko stranih riječi. Bilo je dovoljno jednostavno ispraviti "skladište" u bazi podataka.
Ali vrijeme je napredovalo, a zajedno s njim i broj zahtjeva, ponekad pucajući RPS iznad naših mogućnosti. Ulaskom zemalja ZND-a na tržište opterećenje procesora baze podataka prvog monolita nije palo ispod 90%, a RPS je ostao na nivou od 2400. I to nisu bili samo mali selektori, već veliki upiti sa hrpa provjera i JOIN-ova koji bi mogli raditi za skoro polovinu podataka u pozadini velikog IO-a.
Kada su na sceni počele da se pojavljuju pune rasprodaje Crnog petka - a Wildberries je bio jedan od prvih koji ih je održao u Rusiji - situacija je postala potpuno tužna. Uostalom, opterećenje u takvim danima se povećava tri puta.
Oh, ova "monolitna vremena"! Siguran sam da ste doživjeli nešto slično, a još uvijek ne možete shvatiti kako bi vam se to moglo dogoditi.
Šta možete učiniti - moda je svojstvena tehnologiji. Prije otprilike 5 godina morali smo ponovo razmisliti o jednom od ovih modova u obliku postojećeg sajta na .NET i MS SQL serveru, koji je pažljivo pohranio svu logiku samog sajta. Toliko sam ga pažljivo čuvao da se piljenje takvog monolita pokazalo dugim i nimalo lakim užitkom.
Mala digresija.
Na raznim događajima kažem: "ako nisi vidio monolit, onda nisi ni rastao!" Zanima me vaše mišljenje o ovom pitanju, napišite ga u komentarima.
Zvuk groma
Vratimo se našoj "lomači". Kako bismo rasporedili opterećenje „monolitne“ funkcionalnosti, odlučili smo da podijelimo sistem na mikroservise zasnovane na tehnologijama otvorenog koda. Zato što su, u najmanju ruku, jeftiniji za skaliranje. I imali smo 100% razumijevanja da ćemo morati skalirati (i to mnogo). Uostalom, već u to vrijeme bilo je moguće ući na tržišta susjednih zemalja, a broj registracija, kao i broj narudžbi, počeo je još snažnije rasti.
Analizirajući prve kandidate za prelazak iz monolita u mikroservise, shvatili smo da 80% pisanja u njima dolazi iz back office sistema, a čitanje iz front officea. Prije svega, radilo se o nekoliko nama važnih podsistema – korisničkih podataka i sistema za obračun konačne cijene robe na osnovu informacija o dodatnim popustima i kuponima za kupce.
Uvučeno. Sada je strašno zamisliti, ali osim gore navedenih podsistema, iz našeg monolita su uklonjeni i katalozi proizvoda, korisnička korpa za kupovinu, sistem za pretragu proizvoda, sistem filtriranja kataloga proizvoda i razne vrste sistema preporuka. Za rad svakog od njih postoje odvojene klase usko prilagođenih sistema, ali su nekada svi živjeli u jednoj „kući“.
Odmah smo planirali da podatke o našim klijentima prenesemo u razdijeljeni sistem. Uklanjanje funkcionalnosti za obračun konačne cijene robe zahtijevalo je dobru skalabilnost za očitavanje, jer je stvaralo najveće RPS opterećenje i bilo je najteže implementirati bazu podataka (u proces proračuna uključeno je mnogo podataka).
Kao rezultat toga, došli smo do šeme koja se dobro uklapa u Tarantool.
Tada su za rad mikroservisa odabrane šeme za rad sa nekoliko data centara na virtuelnim i hardverskim mašinama. Kao što je prikazano na slikama, opcije replikacije Tarantool-a primijenjene su i u master-master i master-slave modovima.
Arhitektura. Opcija 1. Korisnički servis
Trenutno postoje 24 šarda, od kojih svaka ima 2 instance (po jednu za svaki DC), sve u master-master modu.
Na vrhu baze podataka su aplikacije koje pristupaju replikama baze podataka. Aplikacije rade sa Tarantoolom kroz našu prilagođenu biblioteku, koja implementira interfejs drajvera Tarantool Go. Ona vidi sve replike i može raditi sa majstorom da čita i piše. U suštini, implementira model skupa replika, koji dodaje logiku za odabir replika, izvođenje ponovnih pokušaja, prekidač i ograničenje brzine.
U ovom slučaju, moguće je konfigurirati politiku odabira replika u kontekstu krhotina. Na primjer, roundrobin.
Arhitektura. Opcija 2. Usluga kalkulacije konačne cijene robe
Prije nekoliko mjeseci većina zahtjeva za obračun konačne cijene robe išla je novom servisu, koji u principu radi bez baza podataka, ali prije nekog vremena sve je 100% obrađeno od strane servisa sa Tarantoolom ispod haube.
Baza podataka usluge sastoji se od 4 mastera u koje sinhronizator prikuplja podatke, a svaki od ovih mastera replikacije distribuira podatke replikama samo za čitanje. Svaki master ima otprilike 15 takvih replika.
Bilo u prvoj ili drugoj shemi, ako je jedan DC nedostupan, aplikacija može primiti podatke u drugom.
Vrijedi napomenuti da je replikacija u Tarantoolu prilično fleksibilna i može se konfigurirati u vrijeme izvođenja. U drugim sistemima su se pojavile poteškoće. Na primjer, promjena parametara max_wal_senders i max_replication_slots u PostgreSQL-u zahtijeva ponovno pokretanje čarobnjaka, što u nekim slučajevima može dovesti do prekida veza između aplikacije i DBMS-a.
Tražite i naći ćete!
Zašto to nismo uradili „kao normalni ljudi“, nego smo izabrali netipičan način? Zavisi šta se smatra normalnim. Mnogi općenito prave klaster od Mongoa i šire ga na tri geo-distribuirana DC-a.
U to vrijeme smo već imali dva Redis projekta. Prvi je bio keš, a drugi je bila trajna pohrana za ne previše kritične podatke. S njim je bilo dosta teško, dijelom i našom krivicom. Ponekad su prilično velike količine bile u ključu, a s vremena na vrijeme stranica je postajala loše. Ovaj sistem smo koristili u master-slave verziji. I bilo je mnogo slučajeva kada se nešto dogodilo masteru i replikacija se pokvarila.
To jest, Redis je dobar za zadatke bez državljanstva, a ne za zadatke sa stanjem. U principu, to je omogućilo rješavanje većine problema, ali samo ako su to bila rješenja ključ/vrijednost sa parom indeksa. Ali Redis je u to vrijeme bio prilično tužan zbog upornosti i ponavljanja. Osim toga, bilo je pritužbi na performanse.
Razmišljali smo o MySQL-u i PostgreSQL-u. Ali prvi nam se nekako nije dopao, a drugi je sam po sebi prilično sofisticiran proizvod i na njemu bi bilo neprikladno graditi jednostavne servise.
Probali smo RIAK, Cassandra, čak i bazu podataka grafova. Sve su to prilično nišna rješenja koja nisu bila prikladna za ulogu općeg univerzalnog alata za kreiranje usluga.
Na kraju smo se odlučili za Tarantool.
Okrenuli smo mu se kada je bio u verziji 1.6. Zanimala nas je simbioza ključ/vrijednost i funkcionalnost relacijske baze podataka. Postoje sekundarni indeksi, transakcije i razmaci, to su kao tabele, ali nisu jednostavne, u njih možete pohraniti različit broj kolona. Ali ubilačka karakteristika Tarantoola bili su sekundarni indeksi u kombinaciji sa ključ/vrijednost i transakcija.
Odgovorna zajednica koja govori ruski, spremna da pomogne u ćaskanju, takođe je odigrala svoju ulogu. Aktivno smo ovo koristili i živimo direktno u chatu. I ne zaboravite na pristojnu upornost bez očiglednih grešaka i grešaka. Ako pogledate našu istoriju sa Tarantoolom, imali smo mnogo muka i neuspjeha s replikacijom, ali nikada nismo izgubili podatke zbog njegove krivice!
Implementacija je počela grubo
U to vrijeme, naš glavni razvojni stog bio je .NET, za koji nije postojao konektor za Tarantool. Odmah smo počeli da radimo nešto u Go. I sa Luom je dobro funkcionirao. Glavni problem u to vrijeme bio je s otklanjanjem grešaka: u .NET-u je sve super s ovim, ali nakon toga je bilo teško uroniti u svijet ugrađene Lua-e, kada nemate otklanjanje grešaka osim logova. Osim toga, iz nekog razloga replikacija se povremeno raspadala, pa sam morao proći u strukturu Tarantool motora. U tome je pomogao chat, a u manjoj mjeri i dokumentacija; ponekad smo pogledali kod. U to vrijeme dokumentacija je bila tako-tako.
Tako sam, tokom nekoliko mjeseci, uspio da se okrenem i dobijem pristojne rezultate od rada sa Tarantoolom. Sastavili smo referentni razvoj u git-u koji je pomogao u formiranju novih mikroservisa. Na primjer, kada se pojavio zadatak: kreirati još jedan mikroservis, programer je pogledao izvorni kod referentnog rješenja u spremištu i nije mu trebalo više od tjedan dana da se stvori novi.
Bila su to posebna vremena. Uobičajeno, tada biste mogli otići do administratora za susjednim stolom i pitati: “Daj mi virtuelnu mašinu.” Tridesetak minuta kasnije auto je već bio kod vas. Sami ste se povezali, sve instalirali i promet vam je poslat.
Danas to više neće funkcionirati: trebate dodati nadzor i logovanje servisu, pokriti funkcionalnost testovima, naručiti virtuelnu mašinu ili isporuku u Kuber, itd. Općenito, ovako će biti bolje, iako će potrajati duže i biti problematičnije.
Zavadi pa vladaj. Šta je sa Luom?
Postojala je ozbiljna dilema: neki timovi nisu bili u stanju da pouzdano unesu promene na servis sa puno logike u Lui. Ovo je često bilo praćeno nefunkcionisanjem servisa.
Odnosno, programeri pripremaju neku vrstu promjene. Tarantool počinje sa migracijom, ali replika je još uvijek sa starim kodom; Replikacijom tamo stigne neki DDL ili nešto drugo, a kod se jednostavno raspadne jer se ne uzima u obzir. Kao rezultat toga, procedura ažuriranja za administratore bila je postavljena na A4 listu: zaustavi replikaciju, ažurirajte ovo, uključite replikaciju, isključite ovdje, ažurirajte tamo. Noćna mora!
Kao rezultat toga, sada najčešće pokušavamo da ne radimo ništa u Lua-i. Samo koristite iproto (binarni protokol za interakciju sa serverom) i to je to. Možda je to nedostatak znanja među programerima, ali sa ove tačke gledišta sistem je složen.
Ne slijedimo uvijek slijepo ovaj scenario. Danas nemamo crno-belo: ili je sve u Lui, ili je sve u Go. Već razumijemo kako ih možemo kombinirati da kasnije ne bismo imali probleme s migracijom.
Gdje je Tarantool sada?
Tarantool se u servisu koristi za obračun konačne cijene robe uzimajući u obzir kupone za popust, poznat i kao „Promoter“. Kao što sam ranije rekao, on sada odlazi u penziju: zamjenjuje ga novi kataloški servis sa unaprijed obračunatim cijenama, ali prije šest mjeseci sve kalkulacije su rađene u Promotizeru. Ranije je polovina njegove logike bila napisana na Lua. Prije dvije godine servis je pretvoren u skladište, a logika je prepisana u Go, jer se mehanika popusta malo promijenila i servisu je nedostajalo performanse.
Jedna od najkritičnijih usluga je korisnički profil. Odnosno, svi korisnici Wildberriesa su pohranjeni u Tarantool-u, a ima ih oko 50 miliona.Sistem podijeljen po ID-u korisnika, distribuiran na nekoliko DC-ova povezanih na Go servise.
Prema RPS-u, Promoter je nekada bio lider, dostigavši 6 hiljada zahteva. U jednom trenutku smo imali 50-60 primjeraka. Sada su lideri u RPS-u korisnički profili, oko 12 hiljada. Ova usluga koristi prilagođeno dijeljenje, podijeljeno rasponima korisničkih ID-ova. Servis opslužuje više od 20 mašina, ali to je previše, planiramo da smanjimo dodeljena sredstva, jer mu je dovoljan kapacitet od 4-5 mašina.
Servis sesije je naš prvi servis za vshard i Cartridge. Podešavanje vshard-a i ažuriranje Cartridge-a je od nas zahtijevalo malo truda, ali na kraju je sve uspjelo.
Usluga za prikazivanje različitih banera na web stranici i u mobilnoj aplikaciji bila je jedna od prvih koja je puštena direktno na Tarantool. Ovaj servis je prepoznatljiv po tome što je star 6-7 godina, još uvijek je u funkciji i nikada nije ponovo pokrenut. Korištena je master-master replikacija. Nikad se ništa nije pokvarilo.
Postoji primjer korištenja Tarantool-a za brzu referentnu funkcionalnost u sistemu skladišta za brzu provjeru informacija u nekim slučajevima. Pokušali smo koristiti Redis za ovo, ali su podaci u memoriji zauzimali više prostora nego Tarantool.
Usluge liste čekanja, pretplate klijenata, trenutno moderne priče i odložena roba također rade s Tarantoolom. Posljednja usluga u memoriji zauzima oko 120 GB. Ovo je najsveobuhvatnija usluga od gore navedenih.
zaključak
Zahvaljujući sekundarnim indeksima u kombinaciji sa ključ/vrijednost i transakcionalnošću, Tarantool je vrlo pogodan za arhitekture zasnovane na mikroservisima. Međutim, naišli smo na poteškoće prilikom uvođenja promjena u servise s puno logike u Lua-i - servisi su često prestajali raditi. Nismo uspjeli ovo prevazići, a vremenom smo došli do različitih kombinacija Lua i Go: znamo gdje koristiti jedan jezik, a gdje drugi.
Šta još pročitati na temu
- Kreiranje aplikacije visokog opterećenja od nule koristeći Tarantool
- Izbor pouzdanog lidera u Tarantool Cartridge-u
- Telegram kanal Tarantool sa vijestima o proizvodu
- Raspravljajte o Tarantoolu u chatu zajednice
izvor: www.habr.com