Mindannyian szeretjük a történeteket. Szeretünk a tűz körül ülve beszélgetni múltbeli győzelmeinkről, csatáinkról, vagy egyszerűen csak a munkatapasztalatainkról.
A mai nap csak egy ilyen nap. És még ha nem is vagy éppen a tűznél, van egy történetünk az Ön számára. A történet arról, hogyan kezdtünk el dolgozni a tárolással a Tarantool-on.
Valamikor cégünknek volt egy-két „monolitja” és egy „plafonja”, amelyhez lassan, de biztosan közeledtek ezek a monolitok, korlátozva cégünk repülését, fejlődésünket. És világos volt a megértés: egy napon keményen megütjük ezt a plafont.
Manapság ez az uralkodó ideológia, hogy szétválaszt mindent és mindenkit, a berendezésektől az üzleti logikáig. Ennek eredményeként például két DC-nk van, amelyek gyakorlatilag függetlenek hálózati szinten. És akkor minden teljesen más volt.
Manapság rengeteg eszköz és eszköz létezik a változtatások végrehajtására CI/CD, K8S stb. formájában. A „monolit” időben nem volt szükségünk ennyi idegen szóra. Elég volt egyszerűen kijavítani a „tárhelyet” az adatbázisban.
De az idő haladt előre, és ezzel együtt a kérések száma is előrehaladt, néha a képességeinket meghaladó RPS-t lőtt. A FÁK-országok piacra lépésével az első monolit adatbázis-processzorának terhelése nem esett 90% alá, az RPS pedig 2400-as szinten maradt. És ezek nem csak kis szelektorok voltak, hanem vaskos lekérdezések csomó ellenőrzések és JOIN-ok, amelyek az adatok majdnem felén futhatnak a nagy IO háttérben.
Amikor a teljes Black Friday akciók elkezdtek megjelenni a színen – és a Wildberries volt az elsők között, amelyek Oroszországban tartottak – a helyzet teljesen szomorúvá vált. Végül is az ilyen napokon a terhelés háromszorosára nő.
Ó, ezek a „monolitikus idők”! Biztos vagyok benne, hogy Ön is átélt már hasonlót, és még mindig nem tudja megérteni, hogyan történhet ez meg Önnel.
Mit tehet - a divat a technológia velejárója. Körülbelül 5 évvel ezelőtt át kellett gondolnunk az egyik ilyen modot egy .NET-en és MS SQL szerveren meglévő webhely formájában, amely gondosan tárolta magának az oldalnak az összes logikáját. Olyan óvatosan tartottam, hogy egy ilyen monolit fűrészelése hosszú és egyáltalán nem könnyű örömnek bizonyult.
Kis kitérő.
Különböző rendezvényeken azt mondom: "Ha nem láttál monolitot, akkor nem nőttél!" Érdekel a véleményed ezzel kapcsolatban, kérlek írd meg kommentben.
Mennydörgés hangja
Térjünk vissza a "máglyánkhoz". A „monolit” funkcionalitás terhelésének elosztása érdekében úgy döntöttünk, hogy a rendszert nyílt forráskódú technológiákon alapuló mikroszolgáltatásokra osztjuk fel. Mert legalább olcsóbb a méretezésük. És 100%-ban megértettük, hogy skáláznunk kell (és sokat). Hiszen már ekkor be lehetett lépni a környező országok piacaira, és a regisztrációk, valamint a megrendelések száma még erőteljesebben kezdett növekedni.
A monolittól a mikroszolgáltatások felé vezető első jelöltek elemzése után rájöttünk, hogy a bennük lévő írások 80%-a back office rendszerből, az olvasás pedig a front office rendszerből származik. Mindenekelőtt ez néhány számunkra fontos alrendszerre vonatkozott - a felhasználói adatokra és az áruk végső költségének kiszámítására szolgáló rendszerre a további vásárlói kedvezményekről és kuponokról szóló információk alapján.
Behúzott. Most ijesztő elképzelni, de a fent említett alrendszerek mellett a termékkatalógusok, a felhasználói kosár, a termékkereső rendszer, a termékkatalógusok szűrőrendszere és a különféle ajánlórendszerek is kikerültek a monolitunkból. Mindegyikük működéséhez szűkre szabott rendszerek külön osztályai vannak, de valamikor mind egy „házban” éltek.
Rögtön azt terveztük, hogy ügyfeleink adatait továbbítjuk a szilánkos rendszerbe. Az áruk végső költségének számítására szolgáló funkcionalitás megszüntetése jó skálázhatóságot igényelt az olvasáshoz, mert ez okozta a legnagyobb RPS terhelést és a legnehezebb volt az adatbázis számára megvalósítani (sok adatot vesz igénybe a számítási folyamat).
Ennek eredményeként egy olyan sémát találtunk ki, amely jól illeszkedik a Tarantoolhoz.
Abban az időben a mikroszolgáltatások működtetéséhez olyan sémákat választottak, amelyek több adatközponttal dolgoznak virtuális és hardveres gépeken. Amint az ábrákon látható, a Tarantool replikációs beállításai mind mester-master, mind master-slave módban kerültek alkalmazásra.
Építészet. Opció 1. Felhasználói szolgáltatás
Jelenleg 24 szilánk létezik, amelyek mindegyikének 2 példánya van (egy minden DC-hez egy), mindegyik fő-fő módban.
Az adatbázis tetején olyan alkalmazások találhatók, amelyek hozzáférnek az adatbázis-replikákhoz. Az alkalmazások együttműködnek a Tarantool-lal az egyéni könyvtárunkon keresztül, amely megvalósítja a Tarantool Go illesztőprogram felületét. Látja az összes másolatot, és a mesterrel együtt tud olvasni és írni. Lényegében a replikakészlet modelljét valósítja meg, amely logikát ad a replikák kiválasztásához, az újrapróbálkozások végrehajtásához, egy megszakítót és egy sebességkorlátot.
Ebben az esetben lehetőség van a replikakiválasztási házirend konfigurálására a szilánkok kontextusában. Például a roundrobin.
Építészet. 2. lehetőség. Az áru végső költségének kiszámítására szolgáló szolgáltatás
Néhány hónappal ezelőtt az áruk végső költségének kiszámítására vonatkozó kérések többsége egy új szolgáltatáshoz érkezett, amely elvileg adatbázisok nélkül működik, de néhány évvel ezelőtt mindent 100%-ban feldolgozott egy szolgáltatás a Tarantool motorháztető alatt.
A szolgáltatási adatbázis 4 főből áll, amelyekbe a szinkronizáló adatokat gyűjt, és ezek a replikációs mesterek mindegyike elosztja az adatokat a csak olvasható replikákhoz. Minden mesternek körülbelül 15 ilyen másolata van.
Akár az első, akár a második sémában, ha az egyik DC nem elérhető, az alkalmazás a másodikban is fogadhat adatokat.
Érdemes megjegyezni, hogy a Tarantool replikációja meglehetősen rugalmas, és futás közben konfigurálható. Más rendszerekben nehézségek adódtak. Például a max_wal_senders és a max_replication_slots paraméterek módosításához a PostgreSQL-ben újra kell indítani a varázslót, ami bizonyos esetekben az alkalmazás és a DBMS közötti kapcsolatok megszakadásához vezethet.
Keress és találj!
Miért nem csináltuk „mint a normális emberek”, hanem választottunk egy atipikus utat? Attól függ, hogy mi tekinthető normálisnak. Sokan általában a Mongóból készítenek klasztert, és három földrajzilag elosztott DC-re osztják szét.
Ekkor már volt két Redis projektünk. Az első gyorsítótár volt, a második pedig a nem túl kritikus adatok állandó tárolója. Elég nehéz volt vele, részben a mi hibánkból. Néha elég nagy kötetek voltak a kulcsban, és időről időre rosszul lett az oldal. Ezt a rendszert a master-slave verzióban használtuk. És sok olyan eset volt, amikor valami történt a mesterrel, és a replikáció meghibásodott.
Vagyis a Redis állapot nélküli feladatokra jó, nem állapotos feladatokra. Elvileg lehetővé tette a legtöbb probléma megoldását, de csak akkor, ha kulcs-érték megoldásokról volt szó pár indexszel. De Redis akkoriban meglehetősen szomorú volt a kitartás és a replikáció miatt. Emellett a teljesítményre is voltak panaszok.
Gondoltunk a MySQL-re és a PostgreSQL-re. De az első valahogy nem fogott meg minket, a második pedig már önmagában is egy meglehetősen kifinomult termék, és nem lenne célszerű rá egyszerű szolgáltatásokat építeni.
Kipróbáltuk a RIAK-ot, Cassandrát, sőt még egy gráf adatbázist is. Ezek mind meglehetősen niche megoldások, amelyek nem voltak alkalmasak az általános univerzális szolgáltatásteremtési eszköz szerepére.
Végül a Tarantool mellett döntöttünk.
Akkor fordultunk hozzá, amikor az 1.6-os verzióban volt. Minket a kulcs-érték szimbiózisa és egy relációs adatbázis funkcionalitása érdekelt. Vannak másodlagos indexek, tranzakciók és szóközök, ezek olyanok, mint a táblázatok, de nem egyszerűek, különböző számú oszlopot tárolhatunk bennük. De a Tarantool gyilkos jellemzője a másodlagos indexek kulcsértékkel és tranzakciós képességgel kombinálva voltak.
A csevegésben segítő kész orosz nyelvű közösség is szerepet játszott. Aktívan használtuk ezt, és közvetlenül a chaten élünk. És ne feledkezzünk meg a tisztességes kitartóról sem, nyilvánvaló baklövések és hibák nélkül. Ha megnézzük a Tarantool történetét, sok fájdalmat és kudarcot tapasztaltunk a replikációval, de soha nem vesztettünk adatot a hibája miatt!
A megvalósítás nehezen indult be
Akkoriban a fő fejlesztési veremünk a .NET volt, amelyhez nem volt csatlakozó a Tarantool. Azonnal elkezdtünk valamit csinálni a Go-ban. Luával is jól működött. A fő probléma akkoriban a hibakereséssel volt: a .NET-ben minden remek, utána viszont nehéz volt belecsöppenni a beágyazott Lua világába, amikor a naplókon kívül nincs hibakeresés. Ráadásul a replikáció valamiért időnként szétesett, így bele kellett mélyednem a Tarantool motor felépítésébe. Ebben segített a chat, és kisebb mértékben a dokumentáció is, néha megnéztük a kódot. Akkoriban a dokumentáció olyan volt.
Így több hónap alatt sikerült felkapnom a fejem, és tisztességes eredményeket értek el a Tarantool-lal való munka során. Gitben állítottuk össze a referenciafejlesztéseket, amelyek segítettek új mikroszolgáltatások kialakításában. Például, amikor felmerült egy feladat: egy másik mikroszolgáltatás létrehozásához a fejlesztő megnézte a referenciamegoldás forráskódját a repositoryban, és egy hétnél nem tartott tovább az új létrehozásához.
Különleges idők voltak ezek. Hagyományosan felmehet a szomszéd asztalhoz az adminisztrátorhoz, és megkérdezheti: „Adj egy virtuális gépet”. Körülbelül harminc perccel később az autó már veled volt. Ön csatlakoztatta magát, mindent telepített, és a forgalmat elküldték Önnek.
Ma ez már nem fog működni: figyelni és naplózni kell a szolgáltatást, le kell fedni a funkcionalitást tesztekkel, virtuális gépet vagy szállítást kell rendelni a Kubernek stb. Általában jobb lesz így, bár hosszabb ideig tart és zavaróbb.
Oszd meg és uralkodj. Mi a helyzet Luával?
Komoly dilemma adódott: egyes csapatok nem tudtak megbízhatóan bevezetni a Lua-ban sok logikával rendelkező szolgáltatás módosításait. Ez gyakran azzal járt, hogy a szolgáltatás nem működött.
Vagyis a fejlesztők készülnek valamiféle változtatásra. A Tarantool elkezdi az áttelepítést, de a replika még mindig a régi kóddal van. Valami DDL vagy valami más érkezik oda replikáción keresztül, és a kód egyszerűen szétesik, mert nem veszik figyelembe. Ennek eredményeként az adminisztrátorok frissítési eljárása A4-es lapra került: replikáció leállítása, frissítés, replikáció bekapcsolása, itt kikapcsolása, frissítése oda. Lidércnyomás!
Ennek eredményeként most a legtöbbször megpróbálunk semmit sem tenni a Lua-ban. Csak használja az iproto-t (bináris protokoll a szerverrel való interakcióhoz), és ennyi. Talán ez a fejlesztők tudáshiánya, de ebből a szempontból a rendszer összetett.
Nem mindig követjük vakon ezt a forgatókönyvet. Ma már nincs fekete-fehér: vagy minden Lua-ban van, vagy minden Go-ban. Már értjük, hogyan kombinálhatjuk ezeket úgy, hogy később ne legyen migrációs gondunk.
Hol van most a Tarantool?
A Tarantool a szolgáltatásban az áruk végső árának kiszámítására szolgál, figyelembe véve a kedvezményes kuponokat, más néven „Promóter”. Ahogy korábban is mondtam, most nyugdíjba vonul: egy új katalógusszolgáltatás váltja fel, előre kalkulált árakkal, de hat hónapja minden számítás a Promotizerben történt. Korábban a logikájának fele Lua nyelven íródott. Két éve raktársá alakították a szolgáltatást, a Go-ban átírták a logikát, mert a kedvezmények mechanikája kicsit megváltozott, a szolgáltatás teljesítménye hiányzott.
Az egyik legkritikusabb szolgáltatás a felhasználói profil. Vagyis az összes Wildberry-felhasználót a Tarantool tárolja, és körülbelül 50 millióan vannak. Egy felhasználói azonosítóval megosztott rendszer, amely több, a Go szolgáltatásokhoz kapcsolódó DC-n van elosztva.
Az RPS szerint egykor a Promoter volt a vezető, elérte a 6 ezer kérést. Valamikor 50-60 példányunk volt. Az RPS-ben jelenleg a felhasználói profilok vezetnek, körülbelül 12 ezer. Ez a szolgáltatás egyéni shardingot használ, elosztva a felhasználói azonosítók tartományaival. A szolgáltatás több mint 20 gépet szolgál ki, de ez túl sok, tervezzük az allokált erőforrások csökkentését, mert a 4-5 gép kapacitása elegendő rá.
A Session szolgáltatás az első szolgáltatásunk a vshard és a kazetta területén. A vshard beállítása és a Cartridge frissítése némi erőfeszítést igényelt tőlünk, de végül minden sikerült.
A különböző bannerek weboldalon és mobilalkalmazásban való megjelenítésére szolgáló szolgáltatás az elsők között jelent meg közvetlenül a Tarantool-on. Ez a szolgáltatás arról nevezetes, hogy 6-7 éves, még mindig működik, és soha nem volt újraindítva. Master-master replikációt használtak. Soha semmi nem tört el.
Van egy példa arra, hogy a Tarantool-t gyorsreferencia funkcióként használják egy raktári rendszerben az információk gyors kétszeri ellenőrzésére bizonyos esetekben. Megpróbáltuk erre a Redis-t használni, de a memóriában lévő adatok több helyet foglaltak el, mint a Tarantool.
A várólista, ügyfél-előfizetések, jelenleg divatos sztorik és halasztott áruk szolgáltatásai is működnek a Tarantool-lal. Az utolsó szolgáltatás a memóriában körülbelül 120 GB-ot foglal el. Ez a legátfogóbb szolgáltatás a fentiek közül.
Következtetés
A kulcsértékkel és tranzakciós képességgel kombinált másodlagos indexeknek köszönhetően a Tarantool kiválóan alkalmas mikroszolgáltatás-alapú architektúrákhoz. Azonban nehézségekbe ütköztünk, amikor a Lua-ban sok logikát tartalmazó szolgáltatások módosításait vezettük be – a szolgáltatások gyakran leálltak. Nem tudtuk felülkerekedni ezen, és idővel a Lua és a Go különböző kombinációihoz jutottunk: tudjuk, hol használjunk egy nyelvet és hol egy másikat.
Mit kell még olvasni a témában
- Nagy terhelésű alkalmazás létrehozása a semmiből a Tarantool segítségével
- Megbízható vezető választás a Tarantool Cartridge-ben
- A Tarantool távirati csatorna hírekkel a termékről
- Beszéljétek meg a Tarantool-t a közösségi csevegésben
Forrás: will.com