Svi volimo priče. Volimo sjediti oko vatre i razgovarati o našim prošlim pobjedama, bitkama ili jednostavno našem radnom iskustvu.
Danas je upravo takav dan. Čak i ako trenutno niste na vatri, imamo priču za vas. Priča o tome kako smo počeli raditi s pohranom na Tarantoolu.
Nekada je naša tvrtka imala par “monolita” i jedan “plafon” za sve, kojem su se ti monoliti polako ali sigurno približavali, ograničavajući let naše tvrtke, naš razvoj. I postojalo je jasno razumijevanje: jednog dana ćemo snažno udariti u ovaj strop.
Sada je prevladavajuć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 neovisni na razini mreže. A onda je sve bilo potpuno drugačije.
Danas postoji puno alata i alata za izradu promjena u obliku CI/CD, K8S itd. U “monolitnom” vremenu nismo trebali toliko stranih riječi. Bilo je dovoljno samo ispraviti “skladištenje” u bazi podataka.
Ali vrijeme je teklo naprijed, a 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 razini od 2400. I to nisu bili samo mali selektori, već pozamašni upiti s hrpa provjera i JOIN-ova koji bi mogli raditi za gotovo polovicu podataka u pozadini velikog IO-a.
Kada su se na sceni pojavile 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 povećava se tri puta.
Oh, ova “monolitna vremena”! Sigurna sam da ste i vi doživjeli nešto slično, a još uvijek ne možete shvatiti kako vam se to moglo dogoditi.
Što možete - moda je svojstvena tehnologiji. Prije otprilike 5 godina, morali smo ponovno osmisliti jedan od ovih modova u obliku postojeće stranice na .NET i MS SQL poslužitelju, koji je pažljivo pohranio svu logiku same stranice. 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 niste vidjeli monolit, onda niste rasli!" Zanima me vaše mišljenje o ovom pitanju, napišite ga u komentarima.
Zvuk grmljavine
Vratimo se našoj „lomači“. Kako bismo rasporedili opterećenje „monolitne“ funkcionalnosti, odlučili smo podijeliti sustav na mikroservise temeljene na opensource tehnologijama. Jer, u najmanju ruku, jeftiniji su za mjerenje. I imali smo 100% razumijevanja da ćemo morati skalirati (i to puno). Uostalom, već tada se moglo izać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 odlazak iz monolita u mikroservise, uvidjeli smo da 80% pisanja kod njih dolazi iz back office sustava, a čitanja iz front officea. Prije svega, radilo se o nekoliko nama važnih podsustava - korisničkih podataka i sustava za obračun konačne cijene robe na temelju informacija o dodatnim popustima za kupce i kuponima.
Uvučeno. Sada je to strašno zamisliti, ali osim gore navedenih podsustava, iz našeg monolita uklonjeni su i katalozi proizvoda, korisnička košarica za kupnju, sustav pretraživanja proizvoda, sustav filtriranja kataloga proizvoda i razne vrste sustava preporuka. Za rad svakog od njih postoje zasebne klase usko skrojenih sustava, ali nekada davno svi su živjeli u jednoj “kući”.
Odmah smo planirali prebaciti podatke o našim klijentima u shard sustav. Uklanjanje funkcionalnosti za izračun konačnog troška robe zahtijevalo je dobru skalabilnost za očitavanje, jer je stvaralo najveće RPS opterećenje i najteže ga je implementirati za bazu (mnogo podataka je uključeno u proces izračuna).
Kao rezultat toga, došli smo do sheme koja dobro pristaje uz Tarantool.
Tada su za rad mikroservisa odabrane sheme za rad s nekoliko podatkovnih centara na virtualnim i hardverskim strojevima. Kao što je prikazano na slikama, opcije replikacije Tarantoola primijenjene su iu načinu rada master-master i master-slave.
Arhitektura. Opcija 1. Korisnički servis
Trenutačno postoje 24 sharda, od kojih svaki ima 2 instance (jednu za svaki DC), sve u načinu master-master.
Na vrhu baze podataka nalaze se aplikacije koje pristupaju replikama baze podataka. Aplikacije rade s Tarantoolom kroz našu prilagođenu biblioteku, koja implementira sučelje upravljačkog programa Tarantool Go. Ona vidi sve replike i može raditi s majstorom čitanja i pisanja. U osnovi, implementira model skupa replika, koji dodaje logiku za odabir replika, izvođenje ponovnih pokušaja, prekidač strujnog kruga i ograničenje brzine.
U ovom slučaju, moguće je konfigurirati politiku odabira replike u kontekstu fragmenata. Na primjer, roundrobin.
Arhitektura. Opcija 2. Usluga za izračun konačne cijene robe
Prije nekoliko mjeseci većina zahtjeva za izračun konačne cijene robe išla je na novi servis, koji u principu radi bez baza podataka, no prije nekog vremena sve je 100% obrađivao servis s Tarantoolom ispod haube.
Servisna baza podataka sastoji se od 4 mastera u koje sinkronizator skuplja podatke, a svaki od tih mastera replikacije distribuira podatke na replike samo za čitanje. Svaki majstor ima otprilike 15 takvih replika.
Bilo u prvoj ili drugoj shemi, ako je jedan DC nedostupan, aplikacija može primati podatke u drugom.
Vrijedno je napomenuti da je replikacija u Tarantoolu prilično fleksibilna i može se konfigurirati tijekom izvođenja. U drugim sustavima pojavile su se 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 veze između aplikacije i DBMS-a.
Tražite i naći ćete!
Zašto to nismo učinili „kao normalni ljudi“, nego smo odabrali netipičan način? Ovisi o tome što se smatra normalnim. Mnogi općenito čine klaster od Monga i šire ga na tri geo-distribuirana DC-a.
U to vrijeme već smo imali dva Redis projekta. Prvi je bio predmemorija, a drugi trajna pohrana ne previše kritičnih podataka. S njim je bilo dosta teško, dijelom i našom krivnjom. Ponekad su u ključu bili prilično veliki volumeni, a s vremena na vrijeme mjesto je postalo loše. Koristili smo ovaj sustav u master-slave verziji. A bilo je mnogo slučajeva gdje se nešto dogodilo masteru i replikacija se pokvarila.
Odnosno, Redis je dobar za zadatke bez stanja, a ne za one sa stanjem. U načelu, to je omogućilo rješavanje većine problema, ali samo ako su to bila ključ-vrijednost rješenja s parom indeksa. Ali Redis je u to vrijeme bio prilično tužan zbog upornosti i replikacije. Osim toga, bilo je pritužbi na performanse.
Razmišljali smo o MySQL-u i PostgreSQL-u. Ali prvi nam se nekako nije zaživio, a drugi je sam po sebi prilično sofisticiran proizvod i bilo bi neprikladno na njemu graditi jednostavne usluge.
Isprobali smo RIAK, Cassandra, čak i bazu podataka grafikona. 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 kad je bio u verziji 1.6. Zainteresirala nas je simbioza ključ-vrijednosti i funkcionalnosti relacijske baze podataka. Postoje sekundarni indeksi, transakcije i razmaci, oni su poput tablica, ali nisu jednostavni, u njih možete pohraniti različite brojeve stupaca. Ali ubojita značajka Tarantoola bili su sekundarni indeksi u kombinaciji s ključnom vrijednošću i transakcijskom sposobnošću.
Odgovarajuća zajednica koja govori ruski, spremna pomoći u chatu, također je odigrala svoju ulogu. Ovo smo aktivno koristili i živimo izravno u chatu. I ne zaboravite na pristojnu upornost bez očitih grešaka i grešaka. Ako pogledate našu povijest s Tarantoolom, imali smo puno problema i neuspjeha s replikacijom, ali nikad nismo izgubili podatke njegovom krivnjom!
Implementacija je teško počela
U to vrijeme naš glavni razvojni skup bio je .NET, na koji nije postojao priključak za Tarantool. Odmah smo počeli nešto raditi u Gou. Dobro je funkcioniralo i s Luom. Glavni problem u to vrijeme bio je otklanjanje pogrešaka: u .NET-u je sve super s ovim, ali nakon toga bilo je teško uroniti u svijet ugrađene Lue, kada nemate otklanjanja pogrešaka osim zapisnika. Osim toga, iz nekog razloga replikacija se povremeno raspadala, pa sam morao proniknuti u strukturu Tarantool motora. Chat je pomogao u tome, au manjoj mjeri i dokumentacija; ponekad smo gledali kod. Tada je dokumentacija bila kako-tako.
Dakle, tijekom nekoliko mjeseci uspio sam se snaći i postići pristojne rezultate rada s Tarantoolom. Sastavili smo referentne razvoje u git-u koji su pomogli u formiranju novih mikroservisa. Na primjer, kada se pojavio zadatak: stvoriti drugu mikroservis, programer je pogledao izvorni kod referentnog rješenja u repozitoriju, a za izradu novog nije trebalo više od tjedan dana.
Bila su to posebna vremena. Uobičajeno, onda možete otići do administratora za susjednim stolom i pitati: "Dajte mi virtualni stroj." Tridesetak minuta kasnije auto je već bio kod vas. Sami ste se spojili, sve instalirali i promet vam je poslan.
Danas to više neće funkcionirati: trebate dodati praćenje i logovanje servisu, pokriti funkcionalnost testovima, naručiti virtualni stroj ili dostavu Kuberu itd. Općenito, ovako će biti bolje, iako će trajati duže i biti će mukotrpnije.
Podijeli pa vladaj. Što je s Luom?
Postojala je ozbiljna dilema: neki timovi nisu mogli pouzdano uvesti promjene u uslugu s puno logike u Lui. To je često bilo popraćeno neradom usluge.
Odnosno, programeri pripremaju neku vrstu promjene. Tarantool počinje s 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 uvažava. Kao rezultat toga, postupak ažuriranja za administratore postavljen je na A4 listu: zaustavi replikaciju, ažuriraj ovo, uključi replikaciju, isključi ovdje, ažuriraj tamo. Noćna mora!
Kao rezultat toga, sada najčešće pokušavamo ne raditi ništa u Lui. Samo upotrijebite iproto (binarni protokol za interakciju s poslužiteljem) i to je to. Možda je to nedostatak znanja među programerima, ali s ove točke gledišta sustav je složen.
Ne slijedimo uvijek slijepo ovaj scenarij. Danas nemamo crno-bijelo: ili je sve u Lui, ili je sve u Gou. Već znamo kako ih možemo kombinirati da kasnije ne bismo imali problema s migracijom.
Gdje je Tarantool sada?
Tarantool se koristi u usluzi za izračun konačne cijene robe uzimajući u obzir kupone za popust, poznate i kao "Promoter". Kao što sam ranije rekao, on sada odlazi u mirovinu: na njegovo mjesto dolazi nova kataloška služba s unaprijed izračunatim cijenama, ali prije šest mjeseci svi su izračuni napravljeni u Promotizeru. Prethodno je pola njegove logike bilo napisano u Lua. Prije dvije godine usluga je pretvorena u skladište, a logika je prepisana u Go, jer se mehanika popusta malo promijenila, a usluzi je nedostajala izvedba.
Jedna od najkritičnijih usluga je korisnički profil. Odnosno, svi korisnici Wildberriesa pohranjeni su u Tarantoolu, a ima ih oko 50 milijuna.Sustav razdijeljen po korisničkom ID-u, raspoređen na nekoliko DC-ova povezanih s Go servisima.
Prema RPS-u, Promoter je nekada bio vodeći, dosegnuvši 6 tisuća zahtjeva. U jednom trenutku imali smo 50-60 primjeraka. Sada su vodeći u RPS-u korisnički profili, oko 12 tisuća.Ova usluga koristi prilagođeno dijeljenje, podijeljeno prema rasponima korisničkih ID-ova. Servis opslužuje više od 20 strojeva, ali to je previše, planiramo smanjiti dodijeljene resurse, jer mu je dovoljan kapacitet od 4-5 strojeva.
Usluga sesije je naša prva usluga na vshard i Cartridge. Postavljanje vshard-a i ažuriranje Cartridge-a od nas je zahtijevalo malo truda, ali na kraju je sve uspjelo.
Usluga za prikazivanje različitih bannera na web stranici i u mobilnoj aplikaciji bila je jedna od prvih koja je puštena izravno na Tarantool. Ova usluga je poznata po tome što je stara 6-7 godina, još uvijek je u funkciji i nikada nije ponovno pokrenuta. Korištena je replikacija master-master. Nikad se ništa nije pokvarilo.
Postoji primjer korištenja Tarantoola za funkciju brze reference u sustavu skladišta za brzu dvostruku provjeru informacija u nekim slučajevima. Pokušali smo za to upotrijebiti Redis, ali podaci u memoriji su zauzimali više prostora od Tarantoola.
Usluge liste čekanja, pretplate klijenata, trenutno modernih priča i robe na odgodu također rade s Tarantoolom. Zadnji servis u memoriji zauzima oko 120 GB. Ovo je najopsežnija usluga od navedenih.
Zaključak
Zahvaljujući sekundarnim indeksima u kombinaciji s ključnom vrijednošću i transakcijskom sposobnošću, Tarantool je vrlo prikladan za arhitekture temeljene na mikroservisima. Međutim, naišli smo na poteškoće prilikom uvođenja promjena u usluge s puno logike u Lui - usluge su često prestajale raditi. Nismo uspjeli to prevladati i s vremenom smo došli do različitih kombinacija Lua i Go: znamo gdje treba koristiti jedan jezik, a gdje drugi.
Što još pročitati na temu
- Stvaranje visokoopterećene aplikacije od nule pomoću Tarantoola
- Izbor pouzdanog lidera u Tarantool Cartridgeu
- Telegram kanal Tarantool s vijestima o proizvodu
- Raspravljajte o Tarantoolu u chatu zajednice
Izvor: www.habr.com