Mindannyiunk kedveljük a történeteket. Szeretjük, ha a tűz mellett ülve mesélhetünk korábbi győzelmeinkről, harcainkról vagy egyszerűen arról, hogy milyen tapasztalataink voltak.
Ma pont egy ilyen nap van. És bár lehet, hogy nem a tűz mellett ül, de van egy történetünk az Ön számára. Azt a történetet szeretnénk elmesélni, hogy hogyan kezdtünk el dolgozni a Tarantool tárolójával.
Valaha a cégünknél volt néhány "monolit" és egy közös "mennyezet", amelyhez ezek a monolitok lassan, de biztosan közeledtek, korlátozva a cégünk fejlődését. Egyértelműen tudtuk, hogy egyszer keményen beleütközünk ebbe a mennyezetbe.
Ma már az a vezérelvünk, hogy mindent és mindenkit szétválasztunk, kezdve a hardvertől egészen az üzleti logikáig. Ennek eredményeként például van két DC-nk, amelyek gyakorlatilag függetlenek hálózati szinten. Akkor viszont minden nagyon más volt.
Ma már rengeteg eszköz és megoldás áll rendelkezésünkre a változtatásokhoz, mint például CI/CD, K8S és hasonlók. A "monolitikus" időszakban viszont nem volt szükségünk ennyi idegen szóra. Elég volt egyszerűen megjavítani a "tárolót" az adatbázisban.
De az idő telt, és a kérések száma is együtt haladt, olykor a RPS-t a kapacitásunk felett lőve ki. Amikor megjelenünk a Közép-Ázsiai piacon, az első monolit adatbázisának terhelése sosem esett 90% alá, a RPS szinten 2400-on tartózkodott. Ezek nem csupán apró lekérdezések voltak, hanem hatalmas kérések sok ellenőrzéssel és JOIN-nal, amelyek szinte az adatok felén végigfutottak a nagy IO mellett.
Amikor azonban megjelentek a komoly akciók a "Fekete pénteken" — és a Wildberries kezdte el az elsőkként Oroszországban — a helyzet igazán szomorúra fordult. Mert ilyenkor a terhelés háromszorosára nő.
Ó, ezek a "monolitikus idők"! Biztos vagyok benne, hogy Ön is találkozott hasonlóval, és még mindig nem érti, hogyan történhetett meg ez Önnel.
Mit lehet tenni — a trendek a technológiákra is jellemzőek. Még öt évvel ezelőtt újragondoltuk az egyik ilyen trendet, amely egy .NET és MS SQL szerver alapú weboldal volt, amely gondosan őrizte az oldal működésének logikáját. Annyira gondosan őrizte, hogy egy ilyen monolithot szétszedni hosszú és meglehetősen nehéz mulatság volt.
Egy kis kitérő.
Különféle eseményeken azt szoktam mondani: „ha nem vágtad fel a monolitot, akkor nem nőttél!” Kíváncsi vagyok a véleményedre ezzel kapcsolatban, kérlek, írd meg a megjegyzésekben.
Megdörrent az ég.
Térjünk vissza a „tüzelőnkhöz”. Az „egységes” funkciók terhelésének elosztására úgy döntöttünk, hogy a rendszert nyílt forráskódú technológiákra alapozva mikroszolgáltatásokra bontjuk. Mert legalábbis a skálázhatóságuk olcsóbb. És tudtuk, hogy skálázni fogunk (és nem is keveset) 100%-ban. Már akkorra sikerült piacra lépnünk a szomszédos országokban, és a regisztrációk száma, valamint a rendelések mennyisége még inkább növekedni kezdett.
Az első jelölteket elemezve, akik a monolitból a mikroszolgáltatásokba távoznak, rájöttünk, hogy az írás 80%-a 99%-ban a back office rendszerekből történik, míg az olvasás a frontvonalból. Ez először is két fontos alrendszert érintett – a felhasználói adatokat és a termékek végső költségének kalkulálására szolgáló rendszert, amely a kiegészítő ügyfélkedvezmények és kuponok információin alapul.
Mellékes megjegyzésként. Jelenleg félelmetes elképzelni, de a fent említett alrendszerek mellett a monolitunkból kiemelésre került a termékkatalógus, a felhasználói kosár, a termékek kereső rendszere, a termékkatalógusok szűrő rendszere és különféle ajánlórendszerek is. Mindegyikükhöz külön osztályokkal ellátott, szűk területű rendszerek léteztek, de régen mindannyian egy „kuckóban” éltek.
Az ügyfeleink adatait egy sharding rendszerbe terveztük átkonvertálni. A termékek végső költségének kalkulálása azonban jó skálázhatóságot igényelt az olvasás terén, mivel ez okozta a legnagyobb terhelést az RPS szempontjából, és a legnehezebb volt a végrehajtásra a bázis számára (nagyon sok adat volt érintve a számítások során).
Ennek következtében született meg egy rendszer, amely jól illeszkedik a Tarantoolhoz.
Abban az időben a mikroszolgáltatások működtetésére a virtuális és hardveres gépekkel rendelkező több adatközponttal való együttműködést választottuk. Ahogy a képeken is látható, a Tarantool replikációs változatait alkalmaztuk master-master és master-slave módokban.
Architektúra. 1. lehetőség. Felhasználói szolgáltatás.
Jelenleg 24 shard létezik, mindegyikben 2 instance található (egy a minden adatközpont számára), mindegyik master-master módban működik.
Az adatbázisok felett olyan alkalmazások találhatók, amelyek a db replikákhoz fordulnak. Az alkalmazások a Tarantool-lal működnek a saját könyvtárunkon keresztül, amely megvalósítja a Go Tarantool illesztőprogram interfészt. Látja az összes replikát, és képes a mesterhez olvasásra és írásra is csatlakozni. Gyakorlatilag a replikakészlet modellt valósítja meg, amelybe beépítették a replikák kiválasztásának, az újrapróbálkozásnak, a megszakító és a sebességkorlátozás logikáját is.
Lehetőség van a replikaválasztási politika konfigurálására a shardok szempontjából is. Például, round-robin módszerrel.
Architektúra. 2. változat. A termék végső árának kiszámítási szolgáltatása
Néhány hónappal ezelőtt a termékek végső árának kiszámításához szükséges kérések nagy része egy új szolgáltatásra került át, amely tulajdonképpen adatbázisok nélkül működik, de egy időben a Tarantool-t használó szolgáltatás kezelte az összes 100%-ot.
A szolgáltatás adatbázisa négy mesterből áll, amelyekben a szinkronizáló gyűjti az adatokat, és ezek a mesterek replikáció révén osztják el az adatokat a readonly replikáknak. Minden mesterhez körülbelül 15 ilyen replika tartozik.
Mind a első, mind a második séma esetében, ha egy adatközpont nem elérhető, az alkalmazás a másodikból kaphat adatokat.
Meg kell jegyezni, hogy a Tarantool replikációja meglehetősen rugalmas és runtime-ban konfigurálható. Más rendszerekben korábban nehézségek adódtak. Például a PostgreSQL max_wal_senders és max_replication_slots paraméterek módosításához a mestert újra kell indítani, ami bizonyos esetekben a kapcsolat megszakadását okozhatja az alkalmazás és az adatbázis-kezelő között.
Keresd és találni fogsz!
Miért nem csináltuk úgy, ahogy a normális emberek, és választottunk egy szokatlan módszert? Attól függ, mit tekintünk normálisnak. Sokan egy Mongo klasztert csinálnak, és szétszórják három geo-elosztott adatközpont között.
Abban az időben már volt két projektünk Redis alatt. Az egyik egy cache, a másik pedig egy nem túl kritikus adatokhoz való tartós tároló volt. Ezzel viszont meglehetősen nehéz volt, részben a mi hibánkból. Néha elég nagy mennyiségek halmozódtak fel a kulcsokban, és időnként az oldalnak rosszul esett. Ezt a rendszert master-slave módon használtuk. Számos esetben előfordult, hogy valami történt a mesterrel, és a replikáció megszakadt.
Tehát a Redis jó a stateless feladatokhoz, nem pedig a stateful-hoz. Alapvetően megoldotta a legtöbb feladatot, de csak akkor, ha azok key-value megoldások voltak néhány indexszel. De a Redis ezen a ponton meglehetősen gyenge volt a tartósság és replikáció terén. Ráadásul, voltak panaszok a teljesítményére.
A MySQL és a PostgreSQL is szóba került. De az első valahogy nem terjedt el nálunk, a második pedig önmagában egy meglehetősen bonyolult termék, és egyszerű szolgáltatások létrehozása rajta nem lenne célszerű.
Próbáltuk a RIAK-ot, a Cassandrát, sőt még grafikus adatbázist is. Ezek mind elég niche megoldások voltak, amelyek nem voltak alkalmasak egy általános univerzális eszközként való szolgálatra szolgáltatások létrehozásához.
Végül a Tarantool mellett döntöttünk.
Kibővítettük, amikor a 1.6-os verziójánál járt. Az érdekelt minket benne, hogy ötvözi a key-value-t és a relációs adatbázis funkcióit. Vannak másodlagos indexek, tranzakciók és spácok, amelyek olyanok, mint a táblázatok, de nem egyszerűek, különböző számú oszlopot lehet benne tárolni. De a Tarantool gyilkos funkciója a key-value-val és tranzakcionális jellege kombinálva másodlagos indexeik voltak.
Ugyanakkor szerepet játszott a reakciós orosz nyelvű közösség, akik készen álltak a segítségnyújtásra a chaten. Ezt aktívan kihasználtuk, és szinte ott éltünk a chatben. Ne felejtsük el a megfelelő tartósságot, hibák és problémák nélkül. Ha megnézzük a Tarantool-lal kapcsolatos történetünket, sok fájdalmunk és baklövéseink voltak a replikációval, de egyszer sem veszítettünk adatokat miatta!
A bevezetés nehezen indult.
Abban az időben a fejlesztési stackünk a .NET volt, amelyhez nem volt Tarantool csatlakozó. Azonnal elkezdtünk valamit csinálni Go nyelven. A Lua-val is jól ment. A legfőbb probléma az volt, hogy a hibakeresés nehézkes volt: a .NET-ben ez kiválóan működik, de utána átkerülni az embedded Lua világába, ahol csak naplózások vannak, nem egyszerű. Ráadásul a replikáció valamiért időnként összeomlott, bele kellett ásnunk magunkat a Tarantool motor szerkezetébe. Ebben a chat segített, kisebb mértékben — a dokumentáció, néha olvastuk a kódot. Abban az időben a dokumentáció nem volt túl jó.
Így néhány hónap alatt sikerült tapasztalatokat szerezni és megfelelő eredményeket elérni a Tarantool-lal való munka során. Git-be helyeztük az etalonszerű fejlesztéseket, amelyek segítettek új mikroszolgáltatások kialakításában. Például, amikor az volt a feladat, hogy egy új mikroszolgáltatást készítsünk, a fejlesztő az etalonszerű megoldás forráskódját nézte a tárolóban, és a új létrehozása nem tartott tovább egy hétnél.
Ezek különleges idők voltak. Akkoriban nyugodtan odamehettél a szomszéd asztalhoz lévő adminisztrátorhoz, és kérhetted: „Adj egy virtuális gépet”. Harminc perc múlva már a tiéd volt a gép. Te magad csatlakoztál, mindent telepítettél, és már indulhatott is a forgalom.
Ma már nem így működik: meg kell valósítani a szolgáltatás monitorozását, naplózását, teszteket kell írni a funkcionalitásra, virtuális gépet kell rendelni, vagy csak az új Kubernetes telepítésért kell aggódni, stb. Összességében ez jobb lesz, de tovább tart és több vele a macera.
Osztani és uralkodni. Mi a helyzet a Lua-val?
Komoly dilemma merült fel: egyes csapatoknak nem sikerült megbízhatóan kigurítani a változtatásokat egy logikailag komplexebb Lua-ba írt szolgáltatásban. Gyakran ez a szolgáltatás működésképtelenségével járt.
Ezért a fejlesztők készítenek valamilyen módosítást. A Tarantool elkezdi a migrációt, míg a replika még a régi kódot használja; beérkezik valamilyen DDL replikáció által, vagy egyéb valami, és a kód egyszerűen összeomlik, mert ez nincs figyelembe véve. Ennek eredményeként az adminisztrátorok frissítési eljárása egy A4-es lapra volt felírva: leállítani a replikációt, frissíteni ezt, elindítani a replikációt, leállítani itt, frissíteni ott. Rémálom!
Végül mostanában általában próbálunk a Lua-val semmit sem csinálni. Egyszerűen az iproto (a szerverrel való kommunikációs bináris protokoll) segítségével dolgozunk, és ennyi. Lehetséges, hogy ez a fejlesztők tudásának hiánya, de ebből a szempontból a rendszer bonyolult.
Nem mindig követjük vakon ezt a forgatókönyvet. Ma már nincs fekete és fehér: vagy minden a Lua, vagy minden a Go. Már értjük, hogyan lehet kombinálni, hogy később ne legyen migrációs problémánk.
Hol található jelenleg a Tarantool?
A Tarantool-t a termékek végső árának kiszámításáért felelős szolgáltatásban használják, amely a „Promotizer”. Ahogy már említettem, mostanában háttérbe szorul: egy új katalógus szolgáltatás váltja fel, amely előre kiszámolt árakat biztosít, de még fél évvel ezelőtt minden számítás a „Promotizer”-ben zajlott. Akkoriban a logika fele Lua nyelven íródott. Két éve a szolgáltatást tárolóként használják, és a logikát Go nyelvre írták át, mivel a kedvezmények működésének mechanikája kissé megváltozott, és a szolgáltatás teljesítménye nem volt elegendő.
Az egyik legkritikusabb szolgáltatás a felhasználói profil. Ez azt jelenti, hogy a Wildberries összes felhasználóját Tarantool-ban tárolják, és körülbelül 50 millióan vannak. Az ID szerint shardingolt rendszer, amely több adatközpontban van elosztva, Go-szolgáltatásokkal összekötve.
Akár 6 ezer lekérdezést is elérte a „Promotizer” RPS (Request Per Second) mindennap, egy pillanatban 50-60 példányunk volt. Jelenleg a felhasználói profilok jelentik az RPS vezetőjét, ami körülbelül 12 ezer. Ebben a szolgáltatásban egyedi shardingot alkalmaznak, amely a felhasználói ID-k tartományai alapján van felosztva. A szolgáltatás több mint 20 gépet szolgál ki, de ez túl sok, tervezzük csökkenteni az erőforrásokat, mert 4-5 gép elegendő lenne.
A session service - ez az első szolgáltatásunk a vshard-on és a Cartridge-on. A vshard beállítása és a Cartridge frissítése bizonyos munkaidőt igényelt, de végül minden rendben lett.
A különböző bannerek megjelenítésére szolgáló szolgáltatás a weboldalon és a mobilalkalmazásban az egyik első, amelyet közvetlenül Tarantool-ra írtak. Ez a szolgáltatás figyelemre méltó, mivel körülbelül 6-7 éves, még mindig működik, és egyszer sem kellett újraindítani. Master-master replikációt alkalmaztak. Soha nem romlott el semmi.
Van példa a Tarantool használatára gyors referencia funkciók számára a raktári rendszerben, hogy szükség esetén gyorsan ellenőrizhessük az információkat. Próbáltuk kipróbálni a Redis-t erre a célra, de az adatok a memóriában több helyet foglaltak el, mint a Tarantool.
A várólistás szolgáltatások, a kliens előfizetések, a manapság divatos történetek és a késleltetett termékek szintén Tarantool-lal működnek. Az utolsó szolgáltatás a memóriában körülbelül 120 GB-ot foglal el. Ez a legnagyobb szolgáltatás az említett szolgáltatások közül.
Zárás
A másodlagos indexek és a key-value tárolás kombinációjával, valamint a tranzakcionálissággal a Tarantool kiválóan alkalmas mikroszolgáltatások alapú architektúrákhoz. Azonban nehézségekbe ütköztünk, amikor olyan szolgáltatások frissítéseit hajtottuk végre, amelyekben sok logika volt Lua nyelven — a szolgáltatások gyakran leálltak. Ezt legyőzni nem tudtuk, és idővel különböző Lua és Go kombinációkra jutottunk: tudjuk, hol érdemes használni az egyes nyelveket.
Mit érdemes még olvasni a témában
- Magas terhelésű alkalmazást készítünk a Tarantool-ra nulláról
- A Tarantool Cartridge megbízható választás a vezető számára
- Tarantool Telegram csatorna a termék híreivel
- Beszélgessünk a Tarantool-ról a közösségi chaten
Forrás: habr.com
