KeyDB mint [potenciális] alternatíva a Redis helyett

A Habr nem találtak véleményeket a „Redis gyorsabb alternatívájáról” — KeyDB. Miután elegendő friss tapasztalatot szereztünk a használatából, szeretnénk pótolni ezt a hiányosságot.

A történet eléggé banális: egyszer, amikor nagy forgalom érkezett, jelentős teljesítményromlást tapasztaltunk az alkalmazás (pontosabban a válaszidő) terén. Akkor sajnos nem tudtunk normál diagnosztikát végezni, ezért később egy sor terheléses tesztet terveztünk. Ezek elvégzése után sikerült felfedezni a szűk keresztmetszetet, amely a Redis adatbázisának gyorsítótára volt. Ahogy az gyakran előfordul, a problémát nem lehetett azonnal, megfelelő módon megoldani — a fejlesztők (a működési logika megváltoztatásával). Ezért előtérbe került a kíváncsiság és a helyzet megoldásának vágya kerüljön be. Így született meg ez a cikk.

Problématika

A Redisről általánosságban

Ahogy sokan tudják, a Redis egy egy szálú adatbázis. Pontosabban, ilyen a felhasználói adatok kezelése során. A negyedik verziótól kezdve a Redis fordították párhuzamos végrehajtásra. Ennek ellenére ez a változtatás csak a terhelés egy kis részét érintette, mivel a fő munka a felhasználói adatokra hárul.

Erről a témáról számtalan vélemény született, de a Redis fejlesztői kitartóan elutasítják a teljes párhuzamosság bevezetését, említve, mennyire bonyolítaná az alkalmazást és növelné a költségeket, valamint hibák számát hozna magával. Az ő álláspontjuk: ha szembesültél az egymagos problémával — az alkalmazás architektúrájával van gondod és változtatni kell rajta. A felhasználók között azonban van egy „másik tábor” is — azok, akik egy magra szorultak és azt állítják, hogy a Redis maguknak okoznak palacknyak helyzetet. Valóban nagy terhelés esetén — előbb vagy utóbb — elkerülhetetlenül szembesülsz ezzel a problémával, ami jelentős korlátozásokkal és/vagy kényszerű bonyolításokkal jár az architektúrában.

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

A mi esetünk

Egyik projektünk során szembesültünk azzal, hogy a fejlesztőcsapat rendkívül agresszív adatcache-elést állított be az adatbázisból (PostgreSQL) Redis-en keresztül. Ez volt az egyetlen mód, ami a forgalom hirtelen megnövekedésekor megmentette magát a PostgreSQL-t, és ennek következtében az alkalmazást is.

A terhelési tesztek sorozata után elemeztük a helyzetet, és kiderült, hogy a Redis egyetlen magra korlátozódott (ahogy mondani szokták: „a polcon”), ezután pedig viszonylag gyorsan az alkalmazás teljesítménye romlani kezdett. A „fulladás” geometriai progressziót mutatott: amint elérte a Redis a teljesítményhatárt, minden leállt.

Ez körülbelül így nézett ki:

A New Relic oldaláról világosan azonosították a problémát:

Íme a statisztika a műveletről get a Redis-ben:

Miután a problémát minden részletességgel átadták a fejlesztésnek, kiderült, hogy "jelenleg nem lehet megoldani a problémát". Így megkezdődtek a megoldás keresése az üzemeltetés oldalán, és a válasz már a korábban említett KeyDB lett.

Mielőtt azonban nekiállnánk a felülvizsgálatának, érdemes megemlíteni, hogy a projektben standalone Redis-t használnak, mivel a Sentinel alapú klaszters megoldás jelentősen hátrányosabb a késleltetés (latency) szempontjából. Az egyik nyilvánvaló megoldás a cache több replikájának létrehozása volt: és a költségvetés kiegyensúlyozása mellett az alkalmazás mindenhova elmehetett! Azonban a fejlesztőkkel való konzultálás után kénytelenek voltunk elvetni ezt a lehetőséget, figyelembe véve az alkalmazás aktív és bonyolult cache-érvényesítési mechanizmusát. Ugyanez a probléma vonatkozott a cache shardingra is.

Gyors áttekintés a KeyDB-ről

A problémák lehetséges megoldásainak keresése során felfedeztük a KeyDB nevű alkalmazást. Ez a Redis fork-ja, amelyet a kanadai cég fejlesztett ki, és BSD szabad licenc alatt terjesztenek. A projekt meglehetősen fiatal: 2019 eleje óta létezik. Története szerint az alkotók szintén találkoztak a Redis korlátozásaival… és úgy döntöttek, hogy készítenek egy fork-ot. Ráadásul nemcsak a már ismert problémákat oldotta meg, hanem további lehetőségeket is kapott, amelyek csak a Redis enterprise verziójában érhetők el.

Akik részletesebben szeretnék megismerni a KeyDB-t, azok számára van egy jó bevezető cikk a Medium-on, amely bemutatja az DBMS-t és rövid benchmark-okat, amelyek összehasonlítják a „szülőjével” — a Redis-szel.

Elsősorban a KeyDB iránti érdeklődésünket a problémáink lehetséges megoldása keltette fel, és emellett néhány további funkció is érdekelt minket. A KeyDB használata a következő előnyöket ígérte:

• teljes körű multiszálú teljesítmény;
• teljes és abszolút kompatibilitás a Redis-szal (ez különösen fontos volt számunkra, mivel alkalmazásoldali módosításokat nem tudtunk végrehajtani), ami problémamentes migrációt is ígért;
• beépített biztonsági mentési mechanizmus az S3-tárolóban;
• egyszerűen megvalósítható aktív replikáció;
• egyszerű klaszterezés és sharding Sentinel és egyéb segédprogramok nélkül.

Több mint 3000 csillag és számos közreműködő a GitHub-on szintén bíztatóan hatott. Az alkalmazás aktívan fejlődik és támogatva van, ami jól látható a commitokból, az issues-ban folytatott kommunikációból, valamint a zárt (elfogadott) PR-kból. A főkarbantartó visszajelzése minden fronton mindig kedves és gyors. Összességében bőven volt érvünk mellette.

Migráció és eredmények

Annak ellenére, hogy a migrációs projekt bizonyos értelemben kaland volt (a KeyDB újdonsága miatt), különösebben nem veszítettünk semmit. Hiszen a változtatások gyorsan és egyszerűen visszaállíthatók — lévén minden infrastruktúra Kubernetesben van telepítve, és a beépített mechanizmusok Rolling Update remekül megoldják az ilyen feladatokat.

Összességében elkészítettük a Helm-sablonokat, átváltottuk az alkalmazást a tesztkörnyezetben az új adatbázisra és mindezt kiadtuk, átadva a megrendelő QA-osztályának.

Megkezdődött a tesztelés, amely körülbelül egy hétig tartott, és a részleteibe nem merültünk el. Csak annyit tudunk, hogy a megrendelő a PHP-illesztőprogrammal ellenőrizte a Redis-szal való standard funkciókat, phpredis, és QA-tesztelést végzett a felhasználói felületen. Ezt követően zöld utat kaptunk: az új szoftver használatában nem találtak mellékhatásokat. Tehát az alkalmazás szempontjából igazából semmi nem változott..

Érdemes megjegyezni, hogy a konfigurációban sem változtattunk semmit: szinte csak annyit tettünk, hogy kicseréltük a használt képet. Ugyanez igaz a monitorozásra és a metrikák exportálására a Prometheus-ba: a legelterjedtebb közülük remekül működik a KeyDB-vel és bármiféle módosítás nélkül. Így bátran mondhatjuk, hogy üzemeltetési szempontból ez egyszerűen egy tökéletes költözés.

Mindezek miatt, miután az alkalmazás átállt az új DBMS-re, semmit sem kell módosítani, és stabilizáló intézkedésként – hagyhatjuk úgy egy ideig működni a harctéren. Azonban, ha teljesítménynövekedést szeretnénk látni (vagy egyáltalán valamilyen változást), nem szabad elfelejteni, hogy alapértelmezett a KeyDB paraméter, amely a több szál kezeléséért felelős (server-threads), egyenlő az egyel, vagyis A DBMS pontosan úgy működik, mint a Redis.

Az átállás, a tesztelés és a KeyDB-vel való új alkalmazás életének eltelt ideje után úgy döntöttünk, hogy megismételjük a terheléses tesztelést ugyanazzal a beállítással, mint amit a Redisnál használtunk. Mik voltak az eredmények?

A CPU-fogyasztási grafikonon azonnal láthatóvá vált a problémák megszűnése az egy magos terhelésnél: a folyamat elkezdte kihasználni a rendelkezésre álló erőforrásokat:

Később próbáltam elég erősen „kinyúzni” az alkalmazást, és akár három magig is eljutottam a fogyasztással...

A New Relic adatai alapján a webalkalmazás összességében, ugyanolyan terhelés mellett, észrevehetően jobban viselkedett. Bár némi teljesítményromlás továbbra is megfigyelhető volt, ugyanakkor a fenti grafikonhoz hasonlítva maguk is értékelhetik a jelentős fejlődést:

Az új adatbázis (KeyDB) késleltetési mutatói is romlottak, de a megengedett határokon belül maradtak:

A következő grafikonon jól látható, hogy a KeyDB-re érkező kérések száma hasonló:

Összességében ezekből a szintetikus testekből elmondható, hogy mind a Redis, mind a KeyDB jelentős teljesítményromlást mutat latency-ben (40 ms+) a párhuzamos kapcsolatok számának jelentős növekedése mellett (1000+). A mi esetünkben a webalkalmazás képes volt „lesüllyeszteni” a Redis latency-jét, és alacsonyabb számú kapcsolódás mellett (400+) is, bár a KeyDB számára ez a terhelés még mindig elfogadható maradt.

Következtetések

E példán keresztül jól látható az Open Source közösség ereje a fejlesztés alatt álló projektek vonatkozásában. Az interneten találkoztam egy remek mondással, amelynek jelentése a következő: „Egy nagy cég érdekes terméket hoz létre, annak néhány funkcióját megnyitja, de a legfontosabbat fizetőssé teszi. A közösség használja, használja, majd valaki int egyet és forkot készít, megvalósítva a fizetős funkciókat, és megnyitja azokat mindenki számára”. Íme a KeyDB — pontosan ez az eset.

A migrációról beszélve, amely meglepően zökkenőmentesen zajlott, nem kaptunk olyan jelentős teljesítménynövekedést, amire a KeyDB szerzőinek grafikái alapján számítani lehetett… Azonban ez csak a mi esetünk, amelyben számos eltérés létezhet, többek között a hírhedt alkalmazás architektúráját illetően (például a hatalmas számú parancs get a Redis-ben a hatékonyabb aggregált lekérdezések helyett mget…). Ennek ellenére sikerült pozitív eredményeket elérni, és ezzel együtt számos hasznos funkciót is, amelyeket a közeljövőben fogunk bevezetni.

Összességében a KeyDB ígéretesen néz ki: a DBMS-sel való gyakorlati tapasztalat megszerzésével (amit még csak meg kell szereznünk!) és a projekt fejlődésével mérlegelni fogjuk alkalmazhatóságát más helyzetekben is.

Ugyanakkor ezt a cikket nem szabad útmutatóként (és pláne nem felhívásként) tekinteni a Redis általános elhagyására a KeyDB javára. A pozitív tapasztalatunk ellenére nyilvánvaló, hogy ez nem ezüst golyó. Az eset nagyon specifikus volt: kifejezetten egy pillanatnyi problémára való megoldásra, ahol gyorsan és minimális költségekkel kellett eljárni, ez a megoldás bevált. Hasznos lesz a KeyDB az Ön esetében? Legalább most már tudja, hogy létezik ilyen potenciális lehetőség.

P.S.

Olvasson további információkat a blogunkban:

• «Adatbázisok és Kubernetes (áttekintés és videóelőadás)»;
• «Cassandra migráció Kubernetesbe: jellemzők és megoldások»;
• «Kihívások nélküli MongoDB migráció a Kubernetesen»;
• «Meghibásodásmentes RabbitMQ migráció a Kubernetesben».

Forrás: habr.com