KeyDB ako [potenciálna] náhrada za Redis

Na platforme Habr sa nenašli recenzie na „rýchlejšiu alternatívu k Redis“ — KeyDB. Po získaní čerstvých skúseností s jeho používaním sa chcem pokúsiť vyplniť túto medzeru.

Predhistória je dosť banálna: raz, pri veľkom návale premávky, došlo k výraznej degradácii výkonu aplikácie (konkrétne — k dobe odozvy). V tom čase, žiaľ, nebolo možné správne diagnostikovať situáciu, a preto sme neskôr naplánovali sériu testov zaťaženia. Po ich vykonaní sa podarilo odhaliť úzke miesto, ktorým bol cache databázy v Redis. Ako to už býva, problém nešlo vyriešiť okamžite a správne — zmenou logiky práce vývojármi. Preto sa prejavilo zvedavosť a túžba bojovať so situáciou obchádzajúcim spôsobom. Tak vznikol tento článok.

Problém

O Redis vo všeobecnosti

Ako je mnohým známe, Redis je jednovláknová databáza. Ak by sme to mali presnejšie, tak je taká v kontexte práce s užívateľskými údajmi. Od štvrté verzie sa však interné operácie Redis preložili vykonávajú paralelne. Napriek tomu sa táto zmena týkala len malej časti zaťaženia, pretože hlavná práca spočíva na užívateľských údajoch.

Na túto tému bolo napísaných nespočetné množstvo článkov, ale vývojári Redis sa neúnavne odmietajú zaviesť plnú paralelnosť, pričom uvádzajú, aké to skomplikuje aplikáciu a zvýši prevádzkové náklady, ako aj pridá množstvo chýb. Ich postoj je, že ak máte problém s jedným jadrom — máte problémy s architektúrou aplikácie a treba niečo zmeniť. Medzi užívateľmi však existuje aj „druhý tábor“ — tí, ktorí narazia na jedno jadro a tvrdia, že Redis si vytvárajú fľaškový krk. Pri skutočne veľkých zaťaženiach — skôr či neskôr — nevyhnutne narazíte na tento problém, čo kladie značné obmedzenia na architektúru a/alebo nútené zložitosti v nej.

Nebudem hodnotiť to alebo ono stanovisko. Namiesto toho sa podelím o našu konkrétnu záležitosť a o tom, ako sme to vyriešili.

Naša kauza

V jednom z projektov sme sa stretli s tým, že vývojový tím nastavil mimoriadne agresívne kešovanie dát z databázy (PostgreSQL) cez Redis. Toto bol jediný spôsob, ktorý počas nárazov návštevnosti chránil samotnú PostgreSQL a, ako následok, aj aplikáciu.

Po sérii záťažových testov sme vykonali analýzu situácie a zistili sme, že Redis sa obmedzoval na jedno jadro (takzvané „v polku“), po čom nasledovala dosť rýchla degradácia aplikácie. „Zahynutie“ malo geometrickú progresiu: akonáhle sa dosiahol limit výkonu Redis, všetko prestalo fungovať.

Vyzeralo to približne takto:

Zo strany New Relic bola jednoznačne identifikovaná problém:

A štatistika týkajúca sa operácie get v Redis:

Po tom, čo bola problém predložený vývojárom vo všetkých podrobnostiach, sa zistilo, že „túto situáciu nemôžeme vyriešiť hneď“. Tak sa začali hľadania riešenia na strane prevádzky a odpoveďou bol už spomínaný KeyDB.

Avšak predtým, ako začneme s jej prehľadom, treba spomenúť, že v projekte sa používa standalone Redis, keďže klastra založeného na Sentineli je veľmi pomalé (latencia). Jedným z očividných riešení bolo vytvorenie niekoľkých replik kešovania: a nech aplikácia chodí všade s load balancing! Avšak, po konzultáciách s vývojármi, sme museli tento variant zamietnuť kvôli aktívnemu a zložitomu mechanizmu invalidácie kešovania v aplikácii. Ten istý problém sa vzťahoval aj na shardovanie kešovania.

Rýchly prehľad KeyDB

V hľadaní možného riešenia problému sme objavili aplikáciu s názvom KeyDB. Je to fork Redis, ktorý vyvinula kanadská spoločnosť a je šírený pod voľnou licenciou BSD. Projekt je pomerne mladý: existuje od začiatku roku 2019. Jeho príbeh je taký, že autori sa tiež raz stretli s obmedzeniami Redis... a rozhodli sa urobiť svoj fork. Navyše nielenže vyriešil známe problémy, ale získal aj dodatočné možnosti, ktoré sú k dispozícii iba v enterprise verzii Redis.

Pre tých, ktorí si chcú dôkladnejšie prečítať o KeyDB, existuje dobrý úvodný článok na Medium, ktorý predstavuje DBMS a stručné benchmarky porovnávajúce ju s jej „rodičom“ — Redis.

Predovšetkým nás na KeyDB zaujalo potenciálne riešenie našich problémov, ale boli sme zvedaví aj na niektoré ďalšie funkcie. Použitie KeyDB sľubovalo nasledujúce výhody:

• získanie plného viacvláknového spracovania;
• úplná a absolútna kompatibilita s Redis (pre nás to bolo obzvlášť dôležité, pretože vykonať nejaké úpravy na strane aplikácie nebolo možné), čo tiež sľubovalo bezproblémovú migráciu;
• zabudovaný mechanizmus zálohovania do S3 úložiska;
• jednoduchá implementácia aktívnej replikácie;
• jednoduchá klastrovanie a shardovanie bez Sentinel a ďalšieho podporného softvéru.

Viac ako 3000 hviezd a množstvo prispievateľov na GitHube tiež vyzerali sľubne. Aplikácia sa dostatočne aktívne vyvíja a podporuje, ako je zrejmé z commitov, komunikácie v issues a takisto uzavretých (prijatých) PR. Odpovede hlavného správcov sú vždy priateľské a rýchle. Celkovo argumentov predsa len bolo dosť.

Migrácia a výsledky

Aj keď projekt migrácie bol akousi aventúrou (vzhľadom na novosť KeyDB), nemali sme čo stratiť. Veď vrátiť zmeny bolo celkom rýchle a jednoduché — našťastie, celá infraštruktúra je nasadená v Kubernetes a zabudované mechanizmy Rolling Update skvele riešia takéto úlohy.

Celkovo sme pripravili Helm šablóny, prepli aplikáciu v testovacom prostredí na novú databázu a všetko to nasadili, odovzdali do QA oddelenia klienta.

Začalo testovanie, ktoré trvalo asi týždeň a do detailov sme sa neponorili. Vieme len o tom, že zákazník preveril štandardné funkcie práce s Redis pomocou PHP ovládača phpredis, a takisto vykonal QA testovanie používateľského rozhrania. Po tom nám dali zelenú: žiadne vedľajšie efekty v používaní nového softvéru sa nezistili. To znamená, z pohľadu aplikácie sa vôbec nič nezmenilo..

Je potrebné poznamenať, že ani v konfigurácii sme nič nezmenili: doslova — jednoducho sme vymenili používaný obraz. To isté platí pre monitorovanie a export metrík do Prometheus: najrozšírenejší z nich výborne funguje s KeyDB aj bez akýchkoľvek úprav. Takže môžeme smelo povedať, že aj z pohľadu prevádzky je to jednoducho ideálny presun.

Vďaka tomu je po prechode aplikácie na novú databázovú službu možné nič nemeniť a ako "stabilizačné opatrenie" ju nechať fungovať tak, ako je, nejaký čas. Ak však chcete zaznamenať zvýšenie výkonu (alebo aspoň nejaké zmeny), musíte si pamätať, že predvolene parameter KeyDB, zodpovedajúci za viacvláknovosť (server-threads), je nastavený na jednotku, t.j. databázová služba funguje presne tak, ako Redis.

Po prechode, testovaní a nejakom čase skúšania na novej aplikácii (s KeyDB) sme sa rozhodli zopakovať záťažové testovanie s tými istými parametrami, ktoré sa používali pre Redis. Aké boli výsledky?

Na grafe spotreby CPU bolo okamžite vidieť odstránenie problémov s "stropom" na jedinom jadre: proces začal využívať dostupné zdroje:

Následne som sa snažil dosť výrazne "mučiť" aplikáciu a videl som spotrebu až na troch jadrách...

Podľa ukazovateľov New Relic sa webová aplikácia celkovo, pri rovnakej záťaži, správala výrazne rozumnejšie. Istá degradácia výkonu sa aj tak pozorovala, avšak v porovnaní s podobným grafom vyššie, môžete sami posúdiť podstatný pokrok:

Ukazovateľ latencie novej databázy (KeyDB) sa tiež zhoršil, ale zostával v prijateľných hodnotách:

Na nasledujúcom grafe je dobre vidieť, že množstvo požiadaviek na samotnú KeyDB je podobné:

Zhrnutím týchto syntetických testov môžeme říct, že Redis aj KeyDB vykazujú výraznú degradáciu výkonu v latencii (40 ms+) pri výraznom náraste počtu paralelných pripojení (1000+). V našom prípade sa webovej aplikácii darilo "znižovať" latenciu Redis-a pri nižšom počte pripojení (400+), hoci pre KeyDB taká záťaž zostávala prijateľná.

Zhrnutie

Na tomto príklade je jasne vidieť silu komunity Open Source v rozvoji projektov, o ktoré sa zaujímajú. Na internete som narazil na vynikajúci výrok, ktorého zmysel spočíva v nasledovnom: „Nejaká veľká spoločnosť vytvorí zaujímavý produkt, sprístupní niektoré jeho funkcie, ale tú najdôležitejšiu časť si necháva platenú. Komunita ho využíva, a potom niekto jednoducho zdvihne ruku a vytvorí forknutú verziu, ktorá implementuje tie platené funkcie a sprístupní ich pre všetkých.“ Tu je KeyDB — presne tento prípad.

Pokiaľ ide o samotnú migráciu, ktorá prebehla pre údiv jednoducho, nedostali sme tak významný nárast výkonu, aký by sa dal očakávať na základe grafov autorov KeyDB… Avšak, toto je len náš špecifický prípad, v ktorom môže byť množstvo odchýlok, vrátane známej architektúry aplikácie (napríklad obrovské množstvo príkazov get v Redis miesto výkonnejšej možnosti agregovaných dotazov mget…). Napriek tomu sa podarilo dosiahnuť pozitívne výsledky, a k nim patrí množstvo užitočných funkcií, ktoré ešte len budeme zavádzať v blízkej budúcnosti.

Celkovo sa zdá, že KeyDB má potenciál: ako získavame praktické skúsenosti s touto DBMS (a tie ešte len musíme získať!) a ako projekt postupuje, zvážime jeho použitie aj v iných situáciách.

Napriek tomu by sa táto článok nemal považovať za návod (a už vôbec nie — výzvu) k tomu, aby sme masovo preniesli od Redis k KeyDB. Napriek našim pozitívnym skúsenostiam je zrejmé, že to nie je strieborná guľka. Prípad bol veľmi špecifický: konkrétne pre riešenie okamžitého problému v situácii, kde bolo potrebné to rýchlo urobiť a s minimálnymi nákladmi, sa takéto riešenie osvedčilo. Bude KeyDB užitočný vo vašom prípade? Aspoň teraz viete, že takáto potenciálna možnosť existuje.

P.S.

Prečítajte si tiež na našom blogu:

• «Databázy a Kubernetes (prezentácia a video prednášky)»;
• «Migrácia Cassandra do Kubernetes: špecifiká a riešenia»;
• «Bezproblémová migrácia MongoDB do Kubernetes»;
• «Zložitá migrácia RabbitMQ do Kubernetes».

Zdroj: habr.com