KeyDB jako [potenciální] náhrada Redis

Na Habr.ru jsem nenašel žádné recenze "rychlejší alternativy k Redis" — KeyDB. Po získání dostatečně čerstvých zkušeností s jeho používáním bych rád tuto mezeru vyplnil.

Předhistorie je dost triviální: jednou při velkém nárůstu provozu byla zaznamenána značná degradace výkonu aplikace (konkrétně — doba odezvy). V té době se bohužel nepodařilo provést řádnou diagnostiku, a proto jsme následně naplánovali sérii zátěžových testů. Po jejich provedení se podařilo odhalit úzké místo, jímž byl cache databáze v Redis. Jak to často bývá, problém nebylo možné okamžitě vyřešit správným způsobem — prostřednictvím vývojářů (změnou logiky práce). Tak se projevila zvědavost a touha řešit situaci alternativní cestou. Tak vznikl tento článek.

Problematika

O Redis obecně

Jak je mnohým známo, Redis je jednovláknová databáze. Pokud bychom to chtěli přesněji říct, je tomu tak v kontextu práce s uživatelskými daty. S verzí 4 byly totiž služební, vnitřní operace Redis převedeny na paralelní provádění. Toto změna se však dotkla jen malé části zátěže, protože hlavní práce spočívá v uživatelských datech.

O tomto tématu byly napsány nespočetné množství příspěvků, ale vývojáři Redis se neustále brání zavádění plnohodnotné paralelnosti s odůvodněním, jak by to zkomplikovalo aplikaci a zvýšilo náklady, a také přidalo na počtu chyb. Jejich názor je takový: pokud se potýkáte s problémem jednovláknovosti — máte problém s architekturou aplikace a je třeba s ní něco udělat. Mezi uživateli je však také "jiný tábor" — ti, kteří narazili na jedno jádro a tvrdí, že Redis si sama vytváří úzké hrdlo. V případě skutečně velkých zátěží se dříve či později člověk nevyhne tomuto problému, což klade značná omezení na architekturu a / nebo nutná zjednodušení v ní.

Nebudu hodnotit to nebo ono stanovisko. Místo toho se podělím o náš konkrétní případ a o tom, jak jsme ho vyřešili.

Náš případ

U jednoho z projektů jsme se setkali s tím, že vývojový tým nastavil extrémně agresivní ukládání dat z databáze (PostgreSQL) přes Redis. To byla jediná cesta, jak během náhlých návalů provozu zachránit samotnou PostgreSQL a tím i aplikaci.

Po sérii zátěžových testů jsme provedli analýzu situace a zjistili, že Redis je omezen na jedno jádro (což se nazývá "na poličce"), po čemž následovala docela rychlá degradace aplikace. "Utopenci" mělo geometrickou progresi: jakmile byl dosažen limit výkonu Redis, všechno přestalo fungovat.

Vypadalo to asi takto:

Z pohledu New Relic byla jednoznačně identifikována problém:

A tady je statistika k operaci získat v Redis:

Po tom, co byla problém podrobně předána vývoji, se ukázalo, že "právě teď není možné problém vyřešit". Tak začalo hledání řešení na straně provozu, a odpovědí se stala již zmíněná KeyDB.

Než však začneme přehled této technologie, stojí za zmínku, že projekt používá standalone Redis, protože clusterové řešení založené na Sentinel značně zaostává z hlediska latence. Jedním z očividných řešení bylo vytvořit několik replik cache: a ať aplikace běhá všude s vyvažováním! Nicméně, po konzultaci s vývojáři jsme byli nuceni tento variant odmítnout kvůli aktivnímu a složitému mechanismu invalidace cache u aplikace. Stejný problém se týkal i shardování cache.

Rychlý přehled KeyDB

Při hledání možného řešení problému jsme objevili aplikaci s názvem KeyDB. Je to fork Redis, který vyvinula kanadská společnost a je distribuován pod svobodnou licencí BSD. Projekt je velmi mladý: existuje od začátku roku 2019. Jeho historie je taková, že autoři se také v minulosti setkali s omezeními Redis… a rozhodli se vytvořit svůj fork. A nejenže vyřešil známé problémy, ale získal i další možnosti, které jsou dostupné pouze v enterprise verzi Redis.

Pro ty, kteří se chtějí podrobněji seznámit s KeyDB, je zde dobrý úvodní článek na Medium, který představuje DBMS a krátké benchmarky porovnávající ji se svým "rodičem" – Redis.

Především nás na KeyDB zaujalo potenciální řešení našich problémů, a zároveň nás zajímaly i některé další funkce. Použití KeyDB slibovalo následující výhody:

• plnohodnotná vícethreadovost;
• naprostá a úplná kompatibilita s Redis (což bylo pro nás zvlášť důležité, protože nebylo možné provádět žádné úpravy na straně aplikace), což také znamenalo bezproblémovou migraci;
• integrovaný mechanismus zálohování do úložiště S3;
• snadná implementace aktivní replikace;
• snadná klasterizace a shardování bez Sentinel a dalšího pomocného softwaru.

Více než 3000 hvězdiček a mnoho přispěvatelů na GitHubu také vypadalo povzbudivě. Aplikace se aktivně vyvíjí a je podporována, což je dobře patrné podle commitů, komunikace v issues a také uzavřených (přijatých) PR. Odpovědi od hlavního správce jsou vždy vstřícné a pohotové. Celkově se našlo dostatek argumentů.

Migrace a výsledky

I když byla migrace do projektu jakýmsi rizikem (vzhledem k novosti KeyDB), neměli jsme co ztratit. Opravit změny bylo dost rychlé a snadné — naštěstí je veškerá infrastruktura nasazena v Kubernetes a zabudované mechanismy Rolling Update skvěle řeší takové úkoly.

Připravili jsme Helm šablony, přepnuli aplikaci v testovacím prostředí na novou DB a nasadili to všechno, přičemž jsme to předali QA týmu klienta.

Začalo testování, které trvalo asi týden, a do detailů jsme se nepouštěli. Víme pouze to, že zákazník testoval standardní funkce práce s Redis pomocí PHP ovladače phpredis, a rovněž provedl QA testování uživatelského rozhraní. Po tom nám dali zelenou: nebyly zjištěny žádné vedlejší efekty při používání nového softwaru. To znamená, z pohledu aplikace se vůbec nic nezměnilo..

Je třeba poznamenat, že jsme v konfiguraci také nic nezměnili: doslova jsme jen nahradili používaný obraz. Totéž platí pro monitoring a export metrik do Prometheus: nejrozšířenější z nich skvěle funguje s KeyDB a bez jakýchkoliv úprav. Takže můžeme s jistotou říci, že z hlediska provozování je to prostě ideální přesun.

Díky tomu, po přepnutí aplikace na novou DBMS nemusíte nic měnit, a jako stabilizační opatření ji můžete na nějakou dobu nechat tak, jak je, a nechat ji pracovat v provozu. Pokud však chcete vidět nárůst výkonu (nebo jakékoliv změny), nezapomeňte, že ve výchozím nastavení parametr KeyDB zodpovědný za vícetrhání (server-threads), je roven jednomu, to znamená, že DBMS funguje přesně jako Redis.

Po přepnutí, testování a určitém čase na novém aplikaci (s KeyDB) jsme se rozhodli zopakovat zátěžové testování se stejnými parametry, které byly použity pro Redis. Jaké byly jeho výsledky?..

Z grafu spotřeby CPU bylo okamžitě patrné odstranění problémů s "stropem" na jednom jádru: proces začal využívat dostupné zdroje:

Později jsem se dost snažil "mučit" aplikaci a viděl jsem spotřebu až na třech jádrech...

Podle údajů New Relic se webová aplikace celkově, při stejné zátěži, chovala výrazně rozumněji. Nějaká degradace výkonu byla stále pozorována, avšak porovnáním s podobným grafem výše můžete sami posoudit výrazný pokrok:

Hodnota latence u nové databáze (KeyDB) se také zhoršila, nicméně zůstávala v přijatelných mezích:

Na dalším grafu je dobře vidět, že počet dotazů na KeyDB je podobný:

Shrneme-li tyto syntetické testy, lze říci, že jak Redis, tak KeyDB vykazují výraznou degradaci výkonu v latenci (40 ms+) při významném nárůstu počtu paralelních připojení (1000+). V našem případě se webové aplikaci dařilo "snižovat" latenci Redis při nižším počtu připojení (400+), i když pro KeyDB byla taková zátěž stále přijatelná.

Závěry

Na tomto příkladu je jasně vidět síla komunity Open Source v otázkách rozvoje projektů, o které má zájem. Na internetu jsem narazil na skvělý výrok, jehož obecný smysl spočíval ve zjednodušeném závěru: „Nějaká velká společnost vytvoří zajímavý produkt, zpřístupní část jeho funkcí jako otevřené, ale tu nejdůležitější část nechává placenou. Komunita využívá a pak se někdo rozčílí a vytvoří fork, ve kterém realizuje tyto placené funkce a zpřístupní je pro všechny.“ Toto je přesně případ KeyDB.

Pokud jde o samotnou migraci, která proběhla překvapivě snadno, nedostali jsme natolik významný nárůst v výkonu, jaký by se dal očekávat, když se podíváme na grafy autorů KeyDB... Nicméně, to je jen náš konkrétní případ, ve kterém může být mnoho odchylek, včetně proslulé architektury aplikace (například obrovské množství příkazů získat v Redis místo výkonnější varianty agregovaných dotazů mget…). Přesto se nám podařilo dosáhnout pozitivních výsledků, a spolu s nimi i mnoha užitečných funkcí, které ještě budeme zavádět v blízké budoucnosti.

Celkově se KeyDB jeví perspektivně: jakmile získáme praktické zkušenosti s touto DB (a ty teprve musíme nasbírat!) a během rozvoje samotného projektu, zvážíme možnost jeho použití i v dalších situacích.

Není však dobré považovat tento článek za návod (a tím méně – za výzvu) k akci k plošnému opuštění Redis ve prospěch KeyDB. I přes naše pozitivní zkušenosti je zřejmé, že to není stříbrná kulka. Případ byl velmi specifický: konkrétně pro řešení urgentního problému v situaci, kdy bylo třeba jednat rychle a s minimálními náklady, toto řešení se osvědčilo. Bude KeyDB užitečné ve vašem případě? Minimálně nyní víte, že tato potenciální možnost existuje.

P.S.

Přečtěte si také náš blog:

• «Databáze a Kubernetes (přehled a video prezentace)»;
• «Migrace Cassandry do Kubernetes: zvláštnosti a řešení»;
• «Bezproblémová migrace MongoDB do Kubernetes»;
• «Náročná migrace RabbitMQ do Kubernetes».

Zdroj: habr.com