Všichni milujeme příběhy. Rádi sedíme u ohně a mluvíme o našich minulých vítězstvích, bitvách nebo jednoduše o našich pracovních zkušenostech.
Dnes je přesně takový den. A i když zrovna nejste u ohně, máme pro vás příběh. Příběh o tom, jak jsme začali pracovat s úložištěm na Tarantool.
Kdysi naše firma měla pár „monolitů“ a jeden „strop“ pro všechny, ke kterému se tyto monolity pomalu, ale jistě blížily, omezovaly rozlet naší firmy, náš rozvoj. A došlo k jasnému pochopení: jednoho dne na tento strop tvrdě narazíme.
Nyní převládá ideologie oddělení všeho a všech, od vybavení po obchodní logiku. V důsledku toho máme například dva DC, které jsou prakticky nezávislé na úrovni sítě. A pak bylo všechno úplně jinak.
Dnes existuje spousta nástrojů a nástrojů pro provádění změn v podobě CI/CD, K8S atp. V „monolitické“ době jsme tolik cizích slov nepotřebovali. Stačilo jednoduše opravit „úložiště“ v databázi.
Čas se ale posunul kupředu a s ním se posouval i počet požadavků, které někdy vystřelily RPS nad naše možnosti. Vstupem zemí SNS na trh nekleslo zatížení databázového procesoru prvního monolitu pod 90 % a RPS zůstal na úrovni 2400. A nebyly to jen malé selektory, ale mohutné dotazy s spoustu kontrol a JOINů, které by mohly běžet téměř pro polovinu dat na pozadí velkých IO.
Když se na scéně začaly objevovat plnohodnotné výprodeje Black Friday – a Wildberries je v Rusku pořádaly jako jedny z prvních –, situace se stala naprosto tristní. Koneckonců, zatížení v takových dnech se zvyšuje třikrát.
Ach, tyto „monolitické časy“! Jsem si jist, že jste něco podobného zažili a stále nechápete, jak se vám to mohlo stát.
Co se dá dělat – móda k technologii neodmyslitelně patří. Asi před 5 lety jsme museli přehodnotit jeden z těchto modů v podobě existujícího webu na .NET a MS SQL serveru, který pečlivě uložil veškerou logiku samotného webu. Držel jsem to tak pečlivě, že pilování takového monolitu se ukázalo jako dlouhé a vůbec ne snadné potěšení.
Malá odchylka.
Na různých akcích říkám: "Pokud jsi neviděl monolit, pak jsi nevyrostl!" Zajímá mě váš názor na tuto věc, napište ho prosím do komentářů.
Zvuk hromu
Vraťme se k našemu „ohništi“. Pro rozložení zátěže „monolitické“ funkčnosti jsme se rozhodli rozdělit systém na mikroslužby založené na opensource technologiích. Protože jsou minimálně levnější v měřítku. A 100% jsme chápali, že budeme muset škálovat (a hodně). Ostatně již v té době bylo možné vstoupit na trhy sousedních zemí a počet registrací, stejně jako počet objednávek, začal růst ještě silněji.
Po analýze prvních kandidátů na přechod od monolitu k mikroslužbám jsme zjistili, že 80 % psaní v nich pochází ze systémů back office a čtení z front office. V první řadě se to týkalo pro nás dvou důležitých subsystémů – uživatelských dat a systému pro výpočet konečné ceny zboží na základě informací o dalších zákaznických slevách a kuponech.
Odsazené. Nyní je děsivé si to představit, ale kromě výše uvedených subsystémů byly z našeho monolitu odstraněny také produktové katalogy, uživatelský nákupní košík, systém vyhledávání produktů, filtrační systém pro katalogy produktů a různé druhy systémů doporučení. Pro provoz každého z nich existují samostatné třídy úzce přizpůsobených systémů, ale kdysi dávno všichni žili v jednom „domě“.
Okamžitě jsme plánovali přenos dat o našich klientech do shardovaného systému. Odstranění funkcionality pro kalkulaci konečných nákladů zboží vyžadovalo dobrou škálovatelnost pro čtení, protože vytvářela největší RPS zátěž a byla nejnáročnější na implementaci pro databázi (proces výpočtu je zahrnut hodně dat).
Výsledkem bylo, že jsme přišli se schématem, které se dobře hodí k Tarantoolu.
V té době byla pro provoz mikroslužeb zvolena schémata pro práci s několika datovými centry na virtuálních a hardwarových strojích. Jak je znázorněno na obrázcích, možnosti replikace Tarantool byly použity v režimech master-master i master-slave.
Architektura. Možnost 1. Uživatelská služba
V současné době existuje 24 shardů, z nichž každý má 2 instance (jedna pro každého DC), všechny v režimu master-master.
Na vrcholu databáze jsou aplikace, které přistupují k replikám databáze. Aplikace spolupracují s Tarantool prostřednictvím naší vlastní knihovny, která implementuje rozhraní ovladače Tarantool Go. Vidí všechny repliky a může pracovat s mistrem při čtení a psaní. V podstatě implementuje model sady replik, který přidává logiku pro výběr replik, provádění opakování, jistič a omezení rychlosti.
V tomto případě je možné nakonfigurovat politiku výběru replik v kontextu shardů. Například roundrobin.
Architektura. Možnost 2. Služba pro výpočet konečné ceny zboží
Před pár měsíci směřovala většina požadavků na kalkulaci konečné ceny zboží na novou službu, která v zásadě funguje bez databází, ale před časem vše stoprocentně zpracovala služba s Tarantoolem pod kapotou.
Servisní databáze se skládá ze 4 hlavních serverů, do kterých synchronizátor shromažďuje data, a každý z těchto hlavních replikačních serverů distribuuje data do replik pouze pro čtení. Každý master má přibližně 15 takových replik.
Buď v prvním nebo ve druhém schématu, pokud jeden DC není dostupný, může aplikace přijímat data ve druhém.
Stojí za zmínku, že replikace v Tarantool je poměrně flexibilní a lze ji nakonfigurovat za běhu. V jiných systémech nastaly potíže. Například změna parametrů max_wal_senders a max_replication_slots v PostgreSQL vyžaduje restart průvodce, což v některých případech může vést k přerušení spojení mezi aplikací a DBMS.
Hledej a najdi!
Proč jsme to neudělali „jako normální lidé“, ale zvolili atypický způsob? Záleží na tom, co je považováno za normální. Mnoho lidí obecně vytváří cluster z Mongo a šíří ho mezi tři geograficky distribuované DC.
V té době jsme již měli dva projekty Redis. Prvním byla mezipaměť a druhým trvalé úložiště pro nepříliš důležitá data. Bylo to s ním docela těžké, částečně i naší vinou. Někdy byly v klíči poměrně velké objemy a čas od času se na webu stávalo špatně. Tento systém jsme použili ve verzi master-slave. A bylo mnoho případů, kdy se masteru něco stalo a replikace se porouchala.
To znamená, že Redis je dobrý pro bezstavové úkoly, ne pro stavové. V zásadě umožňoval řešení většiny problémů, ale pouze pokud šlo o řešení klíč-hodnota s párem indexů. Ale Redis byl v té době docela smutný s vytrvalostí a replikací. Kromě toho se objevily stížnosti na výkon.
Přemýšleli jsme o MySQL a PostgreSQL. Ten první se u nás ale nějak neuchytil a ten druhý je sám o sobě dost sofistikovaný produkt a stavět na něm jednoduché služby by bylo nevhodné.
Vyzkoušeli jsme RIAK, Cassandru, dokonce i grafovou databázi. To vše jsou dosti specializovaná řešení, která se nehodila do role obecného univerzálního nástroje pro tvorbu služeb.
Nakonec jsme se rozhodli pro Tarantool.
Obrátili jsme se na to, když to bylo ve verzi 1.6. Zaujala nás symbiózou hodnoty klíč-hodnota a funkčností relační databáze. Existují sekundární indexy, transakce a prostory, jsou to jako tabulky, ale nejsou jednoduché, můžete do nich uložit různý počet sloupců. Ale zabijáckým rysem Tarantoolu byly sekundární indexy kombinované s hodnotou klíče a transakční schopnosti.
Svou roli sehrála i vstřícná ruskojazyčná komunita, připravená pomoci v chatu. Toho jsme aktivně využívali a žili přímo v chatu. A nezapomeňte na slušné vytrvalé bez zjevných chyb a chyb. Když se podíváte na naši historii s Tarantoolem, měli jsme spoustu problémů a selhání s replikací, ale nikdy jsme nepřišli o data kvůli jeho vině!
Realizace začala drsně
V té době byl naším hlavním vývojovým stackem .NET, ke kterému nebyl žádný konektor pro Tarantool. Hned jsme začali něco dělat v Go. S Luou to fungovalo dobře. Hlavní problém byl v té době s laděním: v .NET je s tím všechno skvělé, ale poté bylo těžké se vrhnout do světa embedded Lua, když nemáte žádné ladění kromě logů. Navíc se replikace z nějakého důvodu periodicky rozpadala, takže jsem se musel ponořit do struktury enginu Tarantool. S tím pomohl chat a v menší míře i dokumentace, občas jsme se podívali na kód. V té době byla dokumentace taková.
Takže během několika měsíců se mi podařilo dostat hlavu a získat slušné výsledky z práce s Tarantool. Sestavili jsme referenční vývoj v git, který pomohl s tvorbou nových mikroslužeb. Když se například objevil úkol: vytvořit další mikroslužbu, vývojář se podíval na zdrojový kód referenčního řešení v úložišti a vytvoření nového netrvalo déle než týden.
Byly to zvláštní časy. Obvykle byste pak mohli jít za administrátorem u dalšího stolu a zeptat se: „Dejte mi virtuální počítač“. Asi po třiceti minutách už bylo auto u vás. Sami jste se připojili, nainstalovali vše a byl vám odeslán provoz.
Dnes už to nepůjde: ke službě je potřeba přidat monitoring a logování, pokrýt funkčnost testy, objednat virtuální stroj nebo doručení do Kuberu atd. Obecně to bude takto lepší, i když to bude trvat déle a bude to více potíží.
Rozděl a panuj. Co je s Luou?
Nastalo vážné dilema: některé týmy nebyly schopny spolehlivě zavést změny ve službě s velkou logikou v Lua. To bylo často doprovázeno nefunkčností služby.
To znamená, že vývojáři připravují nějakou změnu. Tarantool začne provádět migraci, ale replika je stále se starým kódem; Replikací tam dorazí nějaké DDL nebo něco jiného a ten kód se prostě rozpadne, protože se s ním nepočítá. V důsledku toho byl postup aktualizace pro administrátory uveden na listu A4: zastavit replikaci, aktualizovat toto, zapnout replikaci, vypnout zde, aktualizovat tam. Noční můra!
V důsledku toho se nyní v Lua nejčastěji snažíme nedělat nic. Stačí použít iproto (binární protokol pro interakci se serverem) a je to. Možná je to nedostatečná znalost vývojářů, ale z tohoto pohledu je systém složitý.
Ne vždy se slepě řídíme tímto scénářem. Dnes nemáme žádné černobílé: buď je vše v Lua, nebo je vše v Go. Už chápeme, jak je můžeme kombinovat, abychom později neskončili s problémy s migrací.
Kde je teď tarantool?
Tarantool se ve službě používá pro výpočet konečné ceny zboží s přihlédnutím ke slevovým kupónům, známým také jako „Promotér“. Jak jsem řekl dříve, nyní odchází do důchodu: nahrazuje ho nová katalogová služba s předem kalkulovanými cenami, ale před šesti měsíci byly všechny výpočty provedeny v Promotizeru. Dříve byla polovina jeho logiky napsána v Lua. Před dvěma lety se služba změnila na úložiště a v Go se přepsala logika, protože se trochu změnila mechanika slev a služba postrádala výkon.
Jednou z nejdůležitějších služeb je uživatelský profil. To znamená, že všichni uživatelé Wildberries jsou uloženi v Tarantool a je jich asi 50 milionů. Systém rozdělený podle ID uživatele, distribuovaný mezi několika DC připojenými ke službám Go.
Podle RPS byl Promoter kdysi lídrem a dosáhl 6 tisíc žádostí. V jednu chvíli jsme měli 50-60 kopií. Nyní jsou lídrem v RPS uživatelské profily, asi 12 20. Tato služba využívá vlastní sharding, rozdělený podle rozsahů uživatelských ID. Služba obsluhuje více než 4 strojů, ale to je příliš mnoho, plánujeme snížit přidělené prostředky, protože kapacita 5-XNUMX strojů jí stačí.
Služba relace je naší první službou na vshard a Cartridge. Nastavení vshard a aktualizace Cartridge od nás vyžadovalo určité úsilí, ale nakonec vše fungovalo.
Služba pro zobrazování různých bannerů na webu a v mobilní aplikaci byla jako jedna z prvních uvolněna přímo na Tarantool. Tato služba je pozoruhodná tím, že je 6-7 let stará, je stále v provozu a nikdy nebyla restartována. Byla použita replikace master-master. Nikdy se nic nezlomilo.
Existuje příklad použití Tarantool pro funkce rychlého odkazu ve skladovém systému, aby se v některých případech rychle zkontrolovaly informace. Zkoušeli jsme k tomu použít Redis, ale data v paměti zabírala více místa než Tarantool.
S Tarantoolem fungují i služby pořadníku, klientské předplatné, aktuálně módní příběhy a odložené zboží. Poslední služba v paměti zabírá asi 120 GB. Jedná se o nejkomplexnější službu z výše uvedených.
Závěr
Díky sekundárním indexům v kombinaci s hodnotou klíč-hodnota a transakčností se Tarantool dobře hodí pro architektury založené na mikroslužbách. Při zavádění změn do služeb s velkou logikou v Lua jsme však narazili na potíže - služby často přestaly fungovat. Toto jsme nedokázali překonat a postupem času jsme došli k různým kombinacím Lua a Go: víme, kde použít jeden jazyk a kde jiný.
Co si k tématu ještě přečíst
- Vytváříme aplikaci s vysokým zatížením od začátku pomocí Tarantool
- Volba důvěryhodného lídra v kazetě Tarantool
- Telegramový kanál Tarantool s novinkami o produktu
- Diskutujte o Tarantolu v komunitním chatu
Zdroj: www.habr.com