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

Na Habré neboli žiadne recenzie na „rýchlejšiu alternatívu k Redis“ - KeyDB. Po získaní pomerne nedávnych skúseností s jeho používaním by som chcel túto medzeru vyplniť.

Pozadie je dosť banálne: jedného dňa s veľkým prílevom prevádzky bolo zaznamenané výrazné zníženie výkonu aplikácie (konkrétne doba odozvy). V tom čase, žiaľ, nebolo možné vykonať normálnu diagnostiku toho, čo sa deje, a tak bola následne naplánovaná séria záťažových testov. Po ich vykonaní sa nám podarilo objaviť úzke miesto, ktorým bola vyrovnávacia pamäť databázy v Redis. Ako sa často stáva, problém sa nepodarilo vyriešiť okamžite a správnym spôsobom - vývojármi (zmenou logiky práce). Preto sa zapla zvedavosť a túžba prekonať situáciu okružným spôsobom. Takto sa objavil tento článok.

Problémy

O Redis vo všeobecnosti

Ako mnohí vedia, Redis je jednovláknová databáza. Presnejšie povedané, je to takto v kontexte práce s používateľskými dátami. Koniec koncov, od štvrtej verzie, servis, interné operácie Redis prenesené pre paralelné vykonávanie. Táto zmena však ovplyvnila iba malú časť pracovného zaťaženia, pretože väčšina práce sa vykonáva na používateľských údajoch.

Na túto tému bolo rozbitých nespočetné množstvo kópií, no vývojári Redis tvrdošijne odmietajú implementovať úplný paralelizmus a spomínajú, ako veľmi to skomplikuje aplikáciu a zvýši režijné náklady, ako aj pribudnú ďalšie chyby. Ich pozícia je takáto: ak stojíte pred jednojadrovým problémom, máte problémy s architektúrou aplikácie a treba v nej niečo zmeniť. Medzi používateľmi však existuje aj „iný tábor“ – tí, ktorí sú prilepení na jednom jadre a tvrdia, že Redis si vytvára úzke miesto. V prípade skutočne veľkých záťaží - skôr či neskôr - je nevyhnutné naraziť na tento problém, ktorý kladie značné obmedzenia na architektúru a/alebo si v nej vynucuje komplikácie.

Nebudem hodnotiť ten či onen názor. Namiesto toho sa podelím o náš konkrétny prípad a o tom, ako sme ho vyriešili.

Náš prípad

V jednom z projektov sme sa stretli s tým, že vývojový tím mal nakonfigurované extrémne agresívne cachovanie dát z databázy (PostgreSQL) cez Redis. Len tak sa pri náhlych prílevoch návštevnosti zachránil samotný PostgreSQL a v dôsledku toho aj aplikácia pred smrťou.

Po sérii záťažových testov sme analyzovali situáciu a zistili sme, že Redis bol obmedzený na jedno jadro (čo sa nazýva „polica“), po čom nasledovala pomerne rýchla degradácia aplikácie. „Dusenie“ bolo exponenciálne: akonáhle sa dosiahol limit výkonu Redis, všetko prestalo fungovať.

Vyzeralo to nejak takto:

New Relic jasne identifikoval problém:

Tu sú štatistiky pre operáciu: get v Redis:

Po podrobnom nahlásení problému vývojovému tímu sa ukázalo, že „problém sa momentálne nedá vyriešiť“. Začalo sa tak hľadanie riešenia na strane prevádzky a odpoveďou bol už spomínaný KeyDB.

Skôr než začneme s našou recenziou, stojí za zmienku, že projekt používa samostatný Redis, pretože klastrové riešenie založené na Sentineli je z hľadiska latencie oveľa horšie. Jedno zrejmé riešenie bolo vytvoriť niekoľko replík vyrovnávacej pamäte: a nechať aplikáciu ísť všade s vyvážením! Po konzultácii s vývojármi sme však boli nútení túto možnosť zahodiť z dôvodu aktívneho a zložitého mechanizmu znehodnocovania vyrovnávacej pamäte aplikácie. Rovnaký problém sa rozšíril aj na zdieľanie vyrovnávacej pamäte.

Rýchly pohľad na KeyDB

Pri hľadaní možného riešenia problému sme zistili aplikácia s názvom KeyDB. Toto je vidlica Redis vyvinutá spoločnosťou Kanadská spoločnosť a distribuované pod bezplatnou licenciou BSD. Projekt je veľmi mladý: existuje od začiatku roku 2019. Jeho história je taká, že aj autori kedysi narazili na obmedzenia Redis... a rozhodli sa vyrobiť si vlastný fork. Okrem toho nielen vyriešil známe problémy, ale získal aj ďalšie funkcie, ktoré sú dostupné iba v podnikovej verzii Redis.

Pre tých, ktorí sa chcú s KeyDB zoznámiť podrobnejšie, je tu dobrá úvodný článok o médiu, ktorý predstavuje DBMS a stručné benchmarky porovnávajúce ho s jeho „rodičom“ – Redis.

V prvom rade nás na KeyDB zaujalo potenciálne riešenie našich problémov a zároveň nás zaujali niektoré funkcie navyše. Používanie KeyDB sľubovalo nasledujúce výhody:

• získanie plného multithreadingu;
• plná a absolútna kompatibilita s Redis (to bolo pre nás obzvlášť dôležité, keďže na strane aplikácie nebolo možné robiť žiadne úpravy), čo tiež sľubovalo bezproblémovú migráciu;
• vstavaný zálohovací mechanizmus v úložisku S3;
• jednoduchá implementácia aktívnej replikácie;
• jednoduché klastrovanie a zdieľanie bez Sentinelu a iného podporného softvéru.

Povzbudivo vyzeralo aj viac ako 3 tisíc hviezdičiek a veľa prispievateľov na GitHub. Aplikácia je pomerne aktívne vyvíjaná a podporovaná, čo je jasne viditeľné na záväzkoch, komunikácii v otázkach, ako aj uzavretých (akceptovaných) PR. Reakcia hlavného správcu na všetkých frontoch je vždy priateľská a rýchla. Vo všeobecnosti bolo veľa argumentov.

Migrácia a jej výsledky

Aj keď bol projekt migrácie tak trochu hazardom (vzhľadom na novosť KeyDB), nebolo veľmi čo stratiť. Koniec koncov, vrátenie zmien je pomerne rýchle a jednoduché – našťastie je celá infraštruktúra nasadená v Kubernetes a vstavané mechanizmy Rolujúca aktualizácia Takéto problémy riešia veľmi dobre.

Vo všeobecnosti sme pripravili šablóny Helm, prepli aplikáciu v testovacom prostredí na novú databázu a všetko sme spustili a odovzdali oddeleniu QA klienta.

Začalo sa testovanie, ktoré trvalo asi týždeň a do podrobností sme sa neponárali. Vieme len, že zákazník testoval štandardné funkcie práce s Redis pomocou PHP ovládača phpredisa tiež vykonal testovanie kvality používateľského rozhrania. Potom sme dostali zelenú: pri používaní nového softvéru sa nezistili žiadne vedľajšie účinky. Teda Z aplikačného hľadiska sa nezmenilo vôbec nič.

Stojí za zmienku, že v konfigurácii sme nič nezmenili: doslova sme jednoducho nahradili použitý obrázok. To isté platí pre monitorovanie a exportovanie metrík do Prometheus: najčastejšie z nich funguje perfektne s KeyDB a bez akýchkoľvek úprav. Môžeme teda pokojne povedať, že z prevádzkového hľadiska je to jednoducho ideálny ťah.

Vďaka tomu všetkému po prepnutí aplikácie na nový DBMS nemôžete nič zmeniť, no ako „stabilizačné opatrenie“ ju môžete v tejto podobe nechať nejaký čas pôsobiť v boji. Ak však chcete vidieť nárast výkonu (alebo vôbec nejaké zmeny), nesmiete na to zabúdať v predvolenom nastavení Parameter KeyDB zodpovedný za multithreading (server-threads), sa rovná jednej, tj DBMS funguje presne rovnako ako Redis.

Po prepnutí, testovaní a nejakom čase života na novej aplikácii (s KeyDB) sme sa rozhodli zopakovať záťažové testovanie s rovnakými parametrami, aké boli použité pre Redis. Aké boli jej výsledky?...

Podľa grafu spotreby CPU sa okamžite prejavilo odstránenie problémov so „stropom“ jedného jadra: proces začal využívať dostupné zdroje:

A neskôr som skúsil aplikáciu dosť silno „potrápiť“ a videl som spotrebu až troch jadier...

Podľa New Relic sa webová aplikácia ako celok s rovnakou záťažou začala správať výrazne adekvátnejšie. Určité zníženie výkonu bolo stále pozorované, ale v porovnaní s podobným grafom vyššie môžete sami zhodnotiť významný pokrok:

Latencia novej databázy (KeyDB) sa tiež zhoršila, ale zostala v prijateľných hodnotách:

Nasledujúci graf jasne ukazuje, že počet požiadaviek na samotný KeyDB je podobný:

Aby sme zhrnuli tieto syntetické testy, môžeme povedať, že Redis aj KeyDB vykazujú výrazné zhoršenie výkonu v latencii (40 ms+) s výrazným zvýšením počtu paralelných pripojení (1000+). V našom prípade dokázala webová aplikácia „premárniť“ Redisovu latenciu aj pri nižšom počte pripojení (400+), hoci pre KeyDB zostala takáto záťaž akceptovateľná.

Závery

Tento príklad jasne ukazuje silu Open Source komunity pri vývoji projektov, o ktoré má záujem. Na internete som natrafil na výborný výrok, ktorého všeobecný význam sa scvrkol do nasledovného: „Nejaká veľká firma vytvorí zaujímavý produkt, otvorí niektoré funkcie, no najdôležitejšiu časť nechá zaplatenú. Komunita to používa a používa a potom to niekto vzdá a urobí fork, implementuje do neho tie isté platené funkcie a otvorí ich všetkým.“ Tu je KeyDB rovnaký prípad.

Keď už hovoríme o samotnej migrácii, ktorá bola prekvapivo jednoduchá, nedostali sme ju toľko výrazný nárast výkonu, ktorý možno pri pohľade na grafy autorov KeyDB očakávať... Toto je však len náš špeciálny prípad, v ktorom môže nastať veľa odchýlok, vrátane notoricky známej architektúry aplikácie (napr. , obrovské množstvo príkazov get v Redis namiesto výkonnejšej možnosti súhrnných dopytov mget...). Napriek tomu sa nám podarilo dosiahnuť pozitívne výsledky a spolu s nimi mnoho užitočných funkcií, ktoré budeme implementovať v blízkej budúcnosti.

Vo všeobecnosti vyzerá KeyDB sľubne: keď získame praktické skúsenosti s týmto DBMS (a stále ich musíme získať!) a vyvinieme samotný projekt, zvážime možnosť jeho použitia v iných situáciách.

Tento článok by sa však nemal považovať za návod (nehovoriac o výzve) k akcii za rozsiahle opustenie Redis v prospech KeyDB. Napriek našim pozitívnym skúsenostiam je jasné, že to nie je žiadna strieborná strela. Prípad bol veľmi špecifický: konkrétne pre riešenie momentálneho problému v situácii, keď to bolo potrebné urobiť rýchlo a s minimálnymi nákladmi, bolo toto riešenie opodstatnené. Bude KeyDB užitočný vo vašom prípade? Teraz aspoň viete, že táto potenciálna možnosť existuje.

PS

Prečítajte si aj na našom blogu:

• «Databázy a Kubernetes (recenzia a video správa)»;
• «Migrácia Cassandry na Kubernetes: funkcie a riešenia»;
• «Bezproblémová migrácia MongoDB do Kubernetes»;
• «Bezproblémová migrácia RabbitMQ do Kubernetes".

Zdroj: hab.com