A KeyDB [potenciális] helyettesítője a Redisnek

Nem érkezett vélemény a „Redis gyorsabb alternatívájáról” a Habrén - KeyDB. Miután viszonylag friss tapasztalatokra tettem szert a használat során, ezt a hiányt szeretném pótolni.

A háttér meglehetősen banális: egy napon, nagy forgalom beáramlása mellett, az alkalmazás teljesítményében (nevezetesen a válaszidőben) jelentős romlást észleltek. Ekkor sajnos nem lehetett normális diagnózist felállítani, hogy mi történik, ezért utólag terheléses vizsgálatok sorozatát tervezték. Lebonyolításuk után sikerült egy szűk keresztmetszetet felfedeznünk, ami a Redisben található adatbázis-gyorsítótár volt. Mint gyakran előfordul, a problémát nem tudták azonnal és a megfelelő módon megoldani - a fejlesztők (a munka logikájának megváltoztatásával). Ezért bekapcsolódott a kíváncsiság és a vágy, hogy a helyzetet körkörös módon leküzdjük. Így jelent meg ez a cikk.

Problémák

Redisről általában

Amint azt sokan tudják, a Redis egy egyszálú adatbázis. Pontosabban, ez a felhasználói adatokkal való munka összefüggésében ilyen. Végül is a Redis negyedik verziója óta a szolgáltatás, a belső műveletek lefordított párhuzamos végrehajtáshoz. Ez a változás azonban a munkaterhelésnek csak egy kis részét érintette, mivel a munka nagy része a felhasználói adatokon történik.

Számtalan példány tört meg ebben a témában, de a Redis fejlesztői makacsul elutasítják a teljes párhuzamosság megvalósítását, megemlítve, hogy ez mennyivel bonyolítja az alkalmazást és növeli a rezsiköltségeket, valamint további hibákat ad hozzá. Álláspontjuk a következő: ha egymagos problémával szembesül, akkor problémái vannak az alkalmazás architektúrával, és valamit változtatni kell rajta. A felhasználók között azonban van „egy másik tábor” is – azok, akik egy magon ragadtak, és azt állítják, hogy a Redis szűk keresztmetszetet hoz létre magának. Valójában nagy terhelések esetén - előbb-utóbb - elkerülhetetlen ezzel a problémával találkozni, ami jelentős korlátokat szab az architektúrára és/vagy kényszerű bonyodalmakra.

Nem értékelem ezt vagy azt a véleményt. Ehelyett megosztom a konkrét esetünket és azt, hogyan oldottuk meg.

A mi esetünk

Az egyik projektben azzal találkoztunk, hogy a fejlesztőcsapat rendkívül agresszív gyorsítótárazást állított be az adatbázisból (PostgreSQL) a Redis segítségével. Ez volt az egyetlen módja annak, hogy a hirtelen beáramló forgalom során magát a PostgreSQL-t, és ennek eredményeként az alkalmazást is megmentette a haláltól.

A terhelési tesztek sorozata után elemeztük a helyzetet, és megállapítottuk, hogy a Redis egy magra korlátozódott (ez az úgynevezett „polc”), amit az alkalmazás meglehetősen gyors leépülése követett. A „fulladás” exponenciális volt: amint elérte Redis teljesítményhatárát, minden leállt.

Valahogy így nézett ki:

Az új ereklye egyértelműen azonosította a problémát:

Íme a művelet statisztikája: get Redisben:

Miután a problémát részletesen jelentették a fejlesztőcsapatnak, kiderült, hogy „a probléma jelenleg nem megoldható”. Így kezdődött a megoldás keresése az üzemeltetési oldalon, és a már említett KeyDB volt a válasz.

Áttekintésünk megkezdése előtt azonban érdemes megemlíteni, hogy a projekt önálló Redis-t használ, mivel a Sentinel alapú fürtmegoldás sokkal gyengébb a késleltetés szempontjából. Az egyik kézenfekvő megoldás a gyorsítótár több másolatának létrehozása volt: és az alkalmazást mindenhová kiegyensúlyozva hagyjuk! A fejlesztőkkel való egyeztetés után azonban kénytelenek voltunk elvetni ezt a lehetőséget az alkalmazás aktív és összetett gyorsítótár érvénytelenítési mechanizmusa miatt. Ugyanez a probléma a gyorsítótár felosztására is kiterjedt.

Gyors pillantás a KeyDB-re

Miközben a probléma lehetséges megoldását kerestük, rájöttünk KeyDB nevű alkalmazás. Ez egy Redis villa által kifejlesztett kanadai cég és ingyenes BSD licenc alatt terjesztik. A projekt nagyon fiatal: 2019 eleje óta létezik. Története az, hogy a szerzők is találkoztak a Redis korlátaival... és úgy döntöttek, hogy saját villát készítenek. Sőt, nemcsak az ismert problémákat oldotta meg, hanem olyan további funkciókat is kapott, amelyek csak a Redis vállalati verziójában érhetők el.

Azok számára, akik szeretnének részletesebben megismerkedni a KeyDB-vel, van egy jó bevezető cikk a Médiumon, amely bemutatja a DBMS-t és rövid benchmarkokat, összehasonlítva a „szülővel” - a Redis-szel.

Mindenekelőtt a problémáink lehetséges megoldása vonzott minket a KeyDB-hez, ugyanakkor néhány további funkció is érdekelt bennünket. A KeyDB használata a következő előnyöket ígérte:

• teljes többszálúság elérése;
• teljes és abszolút kompatibilitás a Redis-szel (ez különösen fontos volt számunkra, mivel az alkalmazás oldalon nem lehetett módosítani), ami szintén problémamentes migrációt ígért;
• beépített biztonsági mentési mechanizmus az S3 tárolóban;
• könnyen megvalósítható aktív replikáció;
• egyszerű fürtözés és felosztás Sentinel és más támogató szoftverek nélkül.

A GitHubon több mint 3 ezer sztár és sok közreműködő is biztatónak tűnt. Az alkalmazást meglehetősen aktívan fejlesztik és támogatják, ami jól látható a commitokban, a kérdésekben történő kommunikációban, valamint a zárt (elfogadott) PR-okban. A fő karbantartó válasza minden fronton mindig barátságos és gyors. Általában sok volt az érv.

Migráció és eredmények

Annak ellenére, hogy a migrációs projekt egy kicsit szerencsejáték volt (a KeyDB újdonsága miatt), nem volt vesztenivaló. Végül is a változások visszagörgetése meglehetősen gyors és egyszerű – szerencsére a teljes infrastruktúra a Kubernetesben telepítve van, és a beépített mechanizmusok Gördülő frissítés Nagyon jól megoldják az ilyen problémákat.

Általánosságban elmondható, hogy Helm sablonokat készítettünk, a tesztkörnyezetben lévő alkalmazást átállítottuk egy új adatbázisra, majd az egészet bevezettük, átadtuk az ügyfél minőségbiztosítási osztályának.

Megkezdődött a tesztelés, amely körülbelül egy hétig tartott, és a részletekbe nem merültünk bele. Csak annyit tudunk, hogy az ügyfél PHP-illesztőprogram segítségével tesztelte a Redis-szel való munka standard funkcióit phpredis, és elvégezte a felhasználói felület minőségbiztosítási tesztelését is. Ezt követően zöld utat kaptunk: semmilyen mellékhatást nem találtak az új szoftver használatában. Azaz Alkalmazási szempontból semmi sem változott.

Érdemes megjegyezni, hogy a konfiguráción nem változtattunk semmit: szó szerint egyszerűen lecseréltük a használt képet. Ugyanez vonatkozik a mutatók figyelésére és Prometheusba való exportálására is: a leggyakoribb közülük tökéletesen működik a KeyDB-vel és minden módosítás nélkül. Így nyugodtan kijelenthetjük, hogy működési szempontból ez egyszerűen ideális lépés.

Mindezeknek köszönhetően az alkalmazás új DBMS-re váltása után semmit sem változtathat meg, de „stabilizációs intézkedésként” egy ideig ebben a formában hagyhatja, hogy harcban működjön. Ha azonban teljesítménynövekedést (vagy egyáltalán bármilyen változást) szeretne látni, ezt nem szabad elfelejtenie alapértelmezés szerint A többszálú kulcsadatbázis paramétere (server-threads), egyenlő eggyel, azaz A DBMS pontosan ugyanúgy működik, mint a Redis.

Az új alkalmazáson (KeyDB-vel) való váltás, tesztelés és némi élettartam után úgy döntöttünk, hogy megismételjük a terhelési tesztelést ugyanazokkal a paraméterekkel, mint a Redisnél. mik voltak az eredményei?...

A CPU-fogyasztási grafikon szerint az egyik mag „plafonjával” kapcsolatos problémák kiküszöbölése azonnal észrevehetővé vált: a folyamat elkezdte felhasználni a rendelkezésre álló erőforrásokat:

Később pedig megpróbáltam elég erősen „kínozni” az alkalmazást és akár három mag fogyasztását láttam...

A New Relic szerint a webalkalmazás egésze, ugyanolyan terhelés mellett, észrevehetően megfelelőbben kezdett viselkedni. Némi teljesítményromlást továbbra is megfigyeltek, azonban a fenti hasonló grafikonnal összehasonlítva saját maga értékelheti a jelentős előrehaladást:

Az új adatbázis (KeyDB) késleltetése is romlott, de az elfogadható értékeken belül maradt:

A következő grafikon egyértelműen mutatja, hogy a KeyDB-hez intézett kérések száma hasonló:

Összefoglalva ezeket a szintetikus teszteket, azt mondhatjuk, hogy mind a Redis, mind a KeyDB jelentős teljesítménycsökkenést mutat a késleltetésben (40 ms+), a párhuzamos kapcsolatok számának jelentős növekedésével (1000+). Esetünkben a webalkalmazás még kisebb kapcsolatszámmal (400+) is képes volt „elpazarolni” Redis késleltetését, bár a KeyDB esetében ez a terhelés elfogadható maradt.

Álláspontja

Ez a példa egyértelműen mutatja a nyílt forráskódú közösség erejét az őt érdeklő projektek fejlesztésében. Az interneten egy kiváló kijelentésre bukkantam, melynek általános jelentése a következőben csapódott le: „Valamelyik nagy cég érdekes terméket hoz létre, egyes funkcióit megnyitja, de a legfontosabb részét fizetve hagyja. A közösség használja és használja, majd valaki feladja és elkészít egy villát, ugyanazokat a fizetős funkciókat implementálja benne, és mindenki számára megnyitja azokat.” Itt a KeyDB ugyanaz az eset.

Magáról a migrációról szólva, ami meglepően egyszerű volt, nem kaptunk annyira jelentős teljesítménynövekedés, amire a KeyDB szerzőinek grafikonjait nézve számíthatunk... Ez azonban csak a mi speciális esetünk, amelyben sok eltérés lehet, többek között az alkalmazás notórius architektúrája (pl. , hatalmas számú parancs get a Redisben az összesített lekérdezések hatékonyabb opciója helyett mget...). Ennek ellenére sikerült pozitív eredményeket elérni, és ezzel együtt számos hasznos funkciót megvalósítani, amelyeket a közeljövőben megvalósítunk.

Általában véve a KeyDB ígéretesnek tűnik: amint gyakorlati tapasztalatokat szerezünk ezzel a DBMS-sel (és még meg kell szereznünk!), és magát a projektet fejlesztjük, megfontoljuk annak lehetőségét, hogy más helyzetekben is felhasználhassuk.

Ez a cikk azonban nem tekinthető útmutatónak (pláne felhívásnak) a Redis széles körben elterjedt elhagyása érdekében a KeyDB javára. Pozitív tapasztalataink ellenére egyértelmű, hogy ez nem egy ezüstgolyó. Az eset nagyon konkrét volt: kifejezetten egy pillanatnyi probléma megoldására olyan helyzetben, amikor azt gyorsan és minimális költséggel kellett megtenni, ez a megoldás indokolt volt. Hasznos lesz a KeyDB az Ön esetében? Most legalább tudja, hogy ez a lehetséges lehetőség létezik.

PS

Olvassa el blogunkon is:

• «Adatbázisok és Kubernetes (áttekintés és videóriport)";
• «Cassandra migrációja Kubernetesre: funkciók és megoldások";
• «A MongoDB zökkenőmentes migrációja a Kubernetesbe";
• «A RabbitMQ zökkenőmentes áttelepítése Kubernetesre".

Forrás: will.com