Všetci milujeme príbehy. Radi sedíme pri ohni a rozprávame sa o minulých víťazstvách, bitkách alebo jednoducho o našich pracovných skúsenostiach.
Dnes je presne taký deň. A aj keď práve nie ste pri ohni, máme pre vás príbeh. Príbeh o tom, ako sme začali pracovať s úložiskom na Tarantool.
Kedysi mala naša spoločnosť pár „monolitov“ a jeden „strop“ pre všetkých, ku ktorým sa tieto monolity pomaly, ale isto približovali, obmedzovali rozlet našej spoločnosti, náš rozvoj. A došlo k jasnému pochopeniu: jedného dňa tvrdo narazíme na tento strop.
Teraz je to prevládajúca ideológia oddelenia všetkého a všetkých, od vybavenia až po obchodnú logiku. Výsledkom je, že máme napríklad dva DC, ktoré sú prakticky nezávislé na úrovni siete. A potom bolo všetko úplne inak.
Dnes existuje množstvo nástrojov a nástrojov na vykonávanie zmien v podobe CI/CD, K8S atď. V „monolitickej“ dobe sme nepotrebovali toľko cudzích slov. Stačilo jednoducho opraviť „úložisko“ v databáze.
Čas sa však posunul dopredu a spolu s ním sa posunul aj počet žiadostí, ktoré niekedy vystrelili RPS nad naše možnosti. Vstupom krajín SNŠ na trh nekleslo zaťaženie databázového procesora prvého monolitu pod 90% a RPS zostala na úrovni 2400. A neboli to len malé selektory, ale mohutné dopyty s tzv. hromada kontrol a JOINov, ktoré by mohli bežať takmer pre polovicu údajov na pozadí veľkých IO.
Keď sa na scéne začali objavovať plnohodnotné výpredaje Black Friday – a Wildberries ich v Rusku usporiadali medzi prvými – situácia sa stala úplne tristnou. Koniec koncov, zaťaženie v takýchto dňoch sa zvyšuje trikrát.
Ach, tieto „monolitické časy“! Som si istý, že ste niečo podobné zažili a stále neviete pochopiť, ako sa vám to mohlo stať.
Čo môžete robiť - móda je neodmysliteľnou súčasťou technológie. Asi pred 5 rokmi sme museli prehodnotiť jeden z týchto modov v podobe existujúcej stránky na .NET a MS SQL serveri, kde bola starostlivo uložená celá logika samotnej stránky. Držal som to tak starostlivo, že pílenie takého monolitu sa ukázalo ako dlhé a vôbec nie ľahké potešenie.
Malá odbočka.
Na rôznych podujatiach hovorím: „Ak ste nevideli monolit, potom ste nevyrástli! Zaujíma ma váš názor na túto vec, napíšte ho prosím do komentárov.
Zvuk hromu
Vráťme sa k nášmu „ohničku“. Aby sme rozložili záťaž „monolitickej“ funkcionality, rozhodli sme sa rozdeliť systém na mikroslužby založené na opensource technológiách. Pretože sú prinajmenšom lacnejšie v rozsahu. A 100% sme pochopili, že budeme musieť škálovať (a veľa). Veď už v tom čase bolo možné vstúpiť na trhy susedných krajín a počet registrácií, ako aj počet objednávok začali rásť ešte výraznejšie.
Po analýze prvých kandidátov na prechod z monolitu na mikroslužby sme si uvedomili, že 80 % písania v nich pochádza zo systémov back office a čítania z front office. V prvom rade sa to týkalo niekoľkých pre nás dôležitých podsystémov – užívateľských dát a systému na výpočet konečnej ceny tovaru na základe informácií o dodatočných zákazníckych zľavách a kupónoch.
Odsadené. Teraz je strašidelné si to predstaviť, ale okrem vyššie uvedených podsystémov boli z nášho monolitu odstránené aj produktové katalógy, užívateľský nákupný košík, systém vyhľadávania produktov, filtračný systém pre produktové katalógy a rôzne druhy odporúčacích systémov. Na fungovanie každého z nich existujú samostatné triedy úzko prispôsobených systémov, ale kedysi dávno všetci žili v jednom „dome“.
Okamžite sme plánovali prenos údajov o našich klientoch do shardovaného systému. Odstránenie funkcionality na výpočet konečnej ceny tovaru si vyžadovalo dobrú škálovateľnosť na čítanie, pretože vytváralo najväčšiu RPS záťaž a bolo najťažšie implementovať databázu (do procesu výpočtu je zahrnutých veľa údajov).
V dôsledku toho sme prišli so schémou, ktorá sa dobre hodí k Tarantoolu.
V tom čase boli pre prevádzku mikroslužieb zvolené schémy práce s viacerými dátovými centrami na virtuálnych a hardvérových strojoch. Ako je znázornené na obrázkoch, možnosti replikácie Tarantool boli použité v režime master-master aj master-slave.
Architektúra. Možnosť 1. Služba pre používateľov
V súčasnosti je k dispozícii 24 fragmentov, z ktorých každý má 2 inštancie (jeden pre každý DC), všetky v režime master-master.
Navrchu databázy sú aplikácie, ktoré pristupujú k replikám databázy. Aplikácie fungujú s Tarantool prostredníctvom našej vlastnej knižnice, ktorá implementuje rozhranie ovládača Tarantool Go. Vidí všetky repliky a môže pracovať s majstrom pri čítaní a písaní. V podstate implementuje model sady replík, ktorý pridáva logiku pre výber replík, vykonávanie opakovaní, istič a obmedzenie rýchlosti.
V tomto prípade je možné konfigurovať politiku výberu repliky v kontexte zlomkov. Napríklad roundrobin.
Architektúra. Možnosť 2. Služba na výpočet konečnej ceny tovaru
Pred niekoľkými mesiacmi väčšina požiadaviek na výpočet konečnej ceny tovaru smerovala na novú službu, ktorá v zásade funguje bez databáz, ale pred časom všetko na 100% spracovala služba s Tarantool pod kapotou.
Databáza služieb pozostáva zo 4 masterov, do ktorých synchronizátor zhromažďuje údaje a každý z týchto masterov replikácie distribuuje údaje do replík určených len na čítanie. Každý majster má približne 15 takýchto replík.
Buď v prvej alebo v druhej schéme, ak jeden DC nie je dostupný, aplikácia môže prijímať údaje v druhom.
Stojí za zmienku, že replikácia v Tarantool je dosť flexibilná a dá sa nakonfigurovať za behu. V iných systémoch nastali ťažkosti. Napríklad zmena parametrov max_wal_senders a max_replication_slots v PostgreSQL vyžaduje reštart sprievodcu, čo môže v niektorých prípadoch viesť k prerušeniu spojení medzi aplikáciou a DBMS.
Hľadaj a nájdeš!
Prečo sme to neurobili „ako normálni ľudia“, ale zvolili sme atypický spôsob? Záleží na tom, čo sa považuje za normálne. Mnoho ľudí vo všeobecnosti vytvára klaster z Mongo a šíri ho cez tri geograficky distribuované DC.
V tom čase sme už mali dva projekty Redis. Prvým bola vyrovnávacia pamäť a druhým trvalé úložisko pre nie príliš kritické údaje. Bolo to s ním dosť ťažké, čiastočne aj našou vinou. Niekedy boli v kľúči dosť veľké objemy a z času na čas sa stránka stala nezdravou. Tento systém sme použili vo verzii master-slave. A bolo veľa prípadov, keď sa masterovi niečo stalo a replikácia sa pokazila.
To znamená, že Redis je vhodný na úlohy bez stavu, nie na úlohy so stavom. V princípe to umožňovalo riešiť väčšinu problémov, ale iba ak išlo o riešenia kľúč-hodnota s párom indexov. Ale Redis bol v tom čase dosť smutný s vytrvalosťou a replikáciou. Okrem toho sa vyskytli sťažnosti na výkon.
Uvažovali sme o MySQL a PostgreSQL. Ten prvý sa nám ale akosi neujal a ten druhý je sám o sebe dosť sofistikovaný produkt a stavať na ňom jednoduché služby by bolo nevhodné.
Vyskúšali sme RIAK, Cassandru, dokonca aj databázu grafov. Všetko sú to pomerne úzke riešenia, ktoré sa nehodili do úlohy všeobecného univerzálneho nástroja na vytváranie služieb.
Nakoniec sme sa rozhodli pre Tarantool.
Obrátili sme sa na to, keď to bolo vo verzii 1.6. Zaujala nás symbiózou kľúč-hodnota a funkcionalitou relačnej databázy. Existujú sekundárne indexy, transakcie a medzery, sú to ako tabuľky, ale nie jednoduché, môžete do nich uložiť rôzny počet stĺpcov. Ale zabijáckou črtou Tarantool boli sekundárne indexy kombinované s hodnotou kľúča a transakciou.
Svoju úlohu zohrala aj ústretová rusky hovoriaca komunita, pripravená pomôcť na chate. Toto sme aktívne využívali a bývame priamo v chate. A nezabudnite na slušnú vytrvalosť bez zjavných chýb a chýb. Ak sa pozriete na našu históriu s Tarantool, mali sme veľa problémov a zlyhaní s replikáciou, ale nikdy sme nestratili dáta kvôli jej chybe!
Implementácia začala tvrdo
V tom čase bol náš hlavný vývojový stack .NET, ku ktorému neexistoval konektor pre Tarantool. Hneď sme začali niečo robiť v Go. Dobre to fungovalo aj s Luou. Hlavný problém bol v tom čase s ladením: v .NET je s tým všetko skvelé, ale potom bolo ťažké vrhnúť sa do sveta embedded Lua, keď nemáte žiadne ladenie okrem protokolov. Okrem toho sa replikácia z nejakého dôvodu pravidelne rozpadala, takže som sa musel ponoriť do štruktúry motora Tarantool. Pomohol v tom chat a v menšej miere aj dokumentácia, občas sme sa pozreli na kód. V tom čase bola dokumentácia taká aká.
Takže v priebehu niekoľkých mesiacov sa mi podarilo dostať z hlavy a získať slušné výsledky z práce s Tarantool. Zostavili sme referenčný vývoj v git, ktorý pomohol pri vytváraní nových mikroslužieb. Napríklad, keď vznikla úloha: vytvoriť ďalšiu mikroslužbu, vývojár sa pozrel na zdrojový kód referenčného riešenia v úložisku a vytvorenie nového netrvalo dlhšie ako týždeň.
Boli to zvláštne časy. Zvyčajne môžete ísť za administrátorom pri ďalšom stole a opýtať sa: „Dajte mi virtuálny stroj“. Asi po tridsiatich minútach už bolo auto pri vás. Sami ste sa pripojili, všetko nainštalovali a bola vám odoslaná návštevnosť.
Dnes to už nepôjde: treba do služby pridať monitoring a logovanie, pokryť funkcionalitu testami, objednať virtuálny stroj či doručenie do Kuberu atď. Vo všeobecnosti to bude takto lepšie, aj keď to bude trvať dlhšie a bude to nepríjemnejšie.
Rozdeľuj a panuj. Ako je to s Luou?
Nastala vážna dilema: niektoré tímy neboli schopné spoľahlivo zaviesť zmeny v službe s veľkou logikou v Lua. Toto bolo často sprevádzané nefunkčnosťou služby.
To znamená, že vývojári pripravujú nejakú zmenu. Tarantool spustí migráciu, ale replika je stále so starým kódom; Replikáciou tam príde nejaké DDL alebo niečo iné a kód sa jednoducho rozpadne, pretože sa s ním nepočíta. V dôsledku toho bol postup aktualizácie pre administrátorov uvedený na hárku A4: zastaviť replikáciu, aktualizovať toto, zapnúť replikáciu, vypnúť tu, aktualizovať tam. Nočná mora!
V dôsledku toho sa teraz najčastejšie snažíme nerobiť nič v Lua. Stačí použiť iproto (binárny protokol na interakciu so serverom) a je to. Možno je to nedostatok vedomostí medzi vývojármi, ale z tohto hľadiska je systém zložitý.
Nie vždy sa slepo riadime týmto scenárom. Dnes nemáme čiernobiele: buď je všetko v Lua, alebo je všetko v Go. Už chápeme, ako ich môžeme kombinovať, aby sme neskôr nemali problémy s migráciou.
Kde je teraz Tarantool?
Tarantool sa v službe používa na výpočet konečnej ceny tovaru s prihliadnutím na zľavové kupóny, známe aj ako „Promotér“. Ako som už povedal, teraz odchádza do dôchodku: nahrádza ho nová katalógová služba s vopred vypočítanými cenami, ale pred šiestimi mesiacmi boli všetky výpočty vykonané v Promotizeri. Predtým bola polovica jeho logiky napísaná v Lua. Pred dvoma rokmi sa služba zmenila na úložisko a v Go sa prepísala logika, pretože sa trochu zmenila mechanika zliav a službe chýbal výkon.
Jednou z najdôležitejších služieb je užívateľský profil. To znamená, že všetci používatelia Wildberries sú uložení v Tarantool a je ich asi 50 miliónov. Systém rozdelený podľa ID používateľa, distribuovaný cez niekoľko DC pripojených k službám Go.
Podľa RPS bol Promoter kedysi lídrom a dosiahol 6 tisíc žiadostí. V jednom momente sme mali 50-60 kópií. Teraz sú lídrom v RPS používateľské profily, asi 12 20. Táto služba využíva vlastné sharding, rozdelené podľa rozsahov ID používateľov. Služba obsluhuje viac ako 4 strojov, ale to je príliš veľa, plánujeme znížiť alokované zdroje, pretože kapacita 5-XNUMX strojov jej stačí.
Služba relácie je naša prvá služba na vsharde a kazete. Nastavenie vshard a aktualizácia Cartridge od nás vyžadovalo určité úsilie, ale nakoniec všetko fungovalo.
Služba pre zobrazovanie rôznych bannerov na webe a v mobilnej aplikácii bola jednou z prvých, ktorá vyšla priamo na Tarantool. Táto služba je pozoruhodná tým, že má 6-7 rokov, je stále v prevádzke a nikdy nebola reštartovaná. Bola použitá replikácia master-master. Nikdy sa nič nezlomilo.
Existuje príklad použitia Tarantool na rýchle referenčné funkcie v skladovom systéme na rýchlu dvojitú kontrolu informácií v niektorých prípadoch. Skúšali sme na to použiť Redis, no dáta v pamäti zaberali viac miesta ako Tarantool.
S Tarantoolom fungujú aj služby poradovníka, klientske predplatné, aktuálne módne príbehy a odložený tovar. Posledná služba v pamäti zaberá približne 120 GB. Ide o najkomplexnejšiu službu z vyššie uvedených.
Záver
Vďaka sekundárnym indexom v kombinácii s hodnotou kľúča a transakciou sa Tarantool dobre hodí pre architektúry založené na mikroslužbách. Pri zavádzaní zmien do služieb s veľkou logikou v Lua sme však narazili na ťažkosti – služby často prestali fungovať. Nedokázali sme to prekonať a časom sme prišli na rôzne kombinácie Lua a Go: vieme, kde použiť jeden jazyk a kde použiť iný.
Čo si ešte prečítať k téme
- Vytvorenie aplikácie s vysokým zaťažením od začiatku pomocou Tarantool
- Spoľahlivá voľba lídra v kazete Tarantool
- Telegramový kanál Tarantool s novinkami o produkte
- Diskutujte o Tarantole v komunitnom chate
Zdroj: hab.com