🥇KeyDB som [potentiell] ersättning för Redis

Det finns inga recensioner av "snabbare alternativ till Redis" på Habré — KeyDB. Efter att ha fått tillräckligt med färsk erfarenhet av dess användning vill jag fylla denna lucka.

KeyDB som [potentiell] ersättning för Redis

Bakgrunden är ganska banal: en gång, när vi hade en stor trafikökning, registrerades en betydande prestationsdegradering av applikationen (specifikt svarstiden). Vid den tidpunkten lyckades vi tyvärr inte genomföra en ordentlig diagnos av vad som hände, så vi planerade senare att utföra flera belastningstester. Efter dessa tester upptäckte vi flaskhalsen, som visade sig vara Redis databasens cache. Som det ofta är fallet, kunde problemet inte lösas omedelbart och på rätt sätt — med hjälp av utvecklarna (genom att ändra logiken). Därför satte nyfikenheten och viljan att (oväntat) lösa situationen igång. Så här föddes denna artikel.

Problemområdet

Om Redis i allmänhet

Som många vet är Redis en enda trådad databas. För att vara mer exakt, är den så i sammanhanget med användardata. Från och med version fyra klarar Redis översatte av parallell exekvering. Ändå påverkade denna förändring bara en liten del av belastningen, eftersom det mesta av arbetet handlar om användardata.

Det har skrivits otaliga artiklar om detta ämne, men Redis-utvecklarna vill envist inte införa riktig parallellitet, med hänvisning till hur mycket det skulle komplicera applikationen och öka overhead-kostnaderna, samt leda till fler buggar. Deras ståndpunkt är att om du stöter på single-core problemet — har du problem med applikationens arkitektur och det finns något som behöver ändras. Bland användarna finns det dock också "den andra sidan" — de som fastnat i en kärna och hävdar att Redis själva skapar flaskhalsar. Vid verkligt stora belastningar — kommer man раtt раtt att раtt stötas mot detta problem, vilket sätter betydande begränsningar på arkitekturen och/eller tvingar till kompliceringar i den.

Jag kommer inte att ge någon bedömning av olika åsikter. Istället vill jag dela med mig av vårt specifika fall och hur vi löste det.

Vår case study

Vid ett av projekten stötte vi på problemet att utvecklingsteamet hade konfigurerat extremt aggressiv cachelagring av data från databasen (PostgreSQL) via Redis. Detta var den enda vägen som under kraftiga trafiktoppar räddade PostgreSQL från att krascha och därmed även applikationen.

Efter en serie belastningstester genomförde vi en analys av situationen och upptäckte att Redis kördes på en enda kärna (det som kallas "i kö"), vilket snabbt ledde till en försämring av applikationen. "Kvävningen" hade en geometrisk progression: så fort prestandagränsen för Redis nåddes, slutade allt att fungera.

Det såg ungefär ut så här:

KeyDB som [potentiell] ersättning för Redis

Enligt New Relic identifierades problemet entydigt:

KeyDB som [potentiell] ersättning för Redis

Här är statistiken för operationen hämta i Redis:

KeyDB som [potentiell] ersättning för Redis

Efter att problemet hade redogjorts för utvecklarna i detalj framkom det att "problemet inte kan lösas just nu". Så började letandet efter en lösning på driftssidan, och svaret blev den redan nämnda KeyDB.

Innan vi går vidare med en översikt måste vi nämna att projektet använder standalone Redis, eftersom en klusterlösning baserad på Sentinel har betydligt längre fördröjningar (latency). En uppenbar lösning var att skapa flera repliker av cachen: och låt applikationen sprida sig överallt med lastbalansering! Men efter att ha diskuterat med utvecklarna tvingades vi överge detta alternativ på grund av den aktiva och komplexa cacheinvalidationsmekanismen i applikationen. Samma problem gällde även shardningen av cachen.

En snabb översikt av KeyDB

I jakten på en möjlig lösning av problemet upptäckte vi en applikation kallad KeyDB. Detta är en fork av Redis, utvecklad av ett kanadensiskt företag och distribueras under en öppen BSD-licens. Projektet är ganska ungt: det har funnits sedan början av 2019. Historien är att dess skapare också en gång stötte på begränsningar hos Redis… och beslutade att göra sin egen fork. Dessutom har den inte bara löst kända problem utan också fått ytterligare funktioner som bara är tillgängliga i enterprise-versionen av Redis.

För den som vill lära sig mer om KeyDB finns det en bra introduktionsartikel på Medium, som presenterar databashanteringssystemet och korta benchmarkingresultat som jämför det med sin "förälder" — Redis.

Först och främst drogs vi till KeyDB som en potentiell lösning på våra problem, och vi var också intresserade av några ytterligare funktioner. Användningen av KeyDB lovade följande fördelar:

att få riktig multitrådad bearbetning;
full och absolut kompatibilitet med Redis (för oss var detta särskilt viktigt, eftersom det inte var möjligt att göra några ändringar från applikationen), vilket lovade en problemfri migration;
inbyggd backupmekanism till S3-lagring;
enkel att implementera aktiv replikering;
enkel klustring och sharding utan Sentinel eller annan stödprogramvara.

Över 3000 stjärnor och många bidragsgivare på GitHub såg också lovande ut. Applikationen utvecklas och underhålls ganska aktivt, vilket tydligt märks genom commit, kommunikation i issues, samt stängda (godkända) PR. Svaren från den huvudsakliga underhållaren är alltid vänliga och snabba. Sammanfattningsvis var argumenten tillräckligt många.

Migration och resultat

Även om migrationsprojektet var en sorts äventyr (på grund av nyheten i KeyDB), hade vi inte mycket att förlora. Att rulla tillbaka förändringar är ganska snabbt och enkelt – tack vare att hela infrastrukturen är distribuerad i Kubernetes, och de inbyggda mekanismerna Rolling Update lösar sådana uppgifter utmärkt.

Sammanfattningsvis förberedde vi Helm-mallar, bytte applikationen i testmiljön till den nya databasen och rullade ut allt detta, vilket gavs till kundens QA-avdelning.

Testningen började och pågick i cirka en vecka, och vi gick inte in på detaljerna. Vi vet bara att kunden testade de standardfunktioner som Redis erbjuder med hjälp av PHP-drivrutinen phpredis, och genomförde också QA-testning av användargränssnittet. Efter detta fick vi grönt ljus: inga biverkningar upptäcktes vid användningen av den nya programvaran. Det vill säga i applikationens perspektiv förändrades ingenting överhuvudtaget..

Det är värt att nämna att vi inte heller ändrade något i konfigurationen: bokstavligen – vi bytte bara den använda imagen. Detsamma gäller för övervakning och export av mätdata till Prometheus: den mest använda av dem fungerar utmärkt med KeyDB utan några ändringar. Således kan vi tryggt säga att det ur driftsynpunkt är en perfekt övergång.

Tack vare allt detta, efter att ha växlat applikationen till den nya databashanteraren kan man låta den vara som den är som en "stabiliseringsåtgärd" och låta den arbeta i realtid en tid. Men om du vill se en prestandaförbättring (eller överhuvudtaget några förändringar) får du inte glömma att standard parametern KeyDB, som ansvarar för flerkörning (server-threads), är inställd på ett, vilket innebär att databashanteraren fungerar precis som Redis..

Efter att ha bytt, testat och haft en viss tid på det nya programmet (med KeyDB) bestämde vi oss för att upprepa belastningstestningen med samma parametrar som användes för Redis. Vad blev resultaten?..

Utifrån CPU-användningsgrafen blev det snabbt tydligt att problemen med "taket" vid ett kärn har försvunnit: processen började använda de tillgängliga resurserna:

KeyDB som [potentiell] ersättning för Redis

Jag försökte sedan att verkligen "quästa" applikationen och såg konsumtion upp till tre kärnor...

Enligt New Relic uppträdde webbapplikationen i stort sett, med samma belastning, betydligt mer adekvat. Viss prestandaförsämring observerades ändå, men jämfört med den motsvarande grafen ovan kan du själv bedöma den betydande framsteg:

KeyDB som [potentiell] ersättning för Redis

Förseningsmåttet på den nya databasen (KeyDB) försämrades också, men förblev inom acceptabla gränser:

KeyDB som [potentiell] ersättning för Redis

Den följande grafen visar tydligt att antalet förfrågningar till själva KeyDB är likadant:

KeyDB som [potentiell] ersättning för Redis

Sammanfattningsvis av dessa syntetiska tester kan man säga att både Redis och KeyDB visar betydande prestandaförsämringar i latens (40 ms+) vid en avsevärd ökning av antalet parallella anslutningar (1000+). I vårt fall lyckades webbapplikationen "pressa" latensen hos Redis även vid ett lägre antal anslutningar (400+), även om denna belastning förblev acceptabel för KeyDB.

Slutsatser

I det här exemplet syns tydligt styrkan hos Open Source-gemenskapen när det gäller utvecklingen av projekt som den är intresserad av. På internet har jag stött på ett utmärkt uttalande vars huvudsakliga budskap går ut på följande: "Ett stort företag skapar en intressant produkt, gör en del av dess funktioner öppna, men håller den viktigaste delen betalad. Gemenskapen använder det, och sedan släpper någon på ett kort och gör en fork, där de implementerar just de betalade funktionerna och öppnar dem för alla." Här är KeyDB - det är det här fallet.

När det gäller själva migreringen, som gick förvånansvärt enkelt, fick vi inte så mycket en betydande ökning av prestanda, som man kan förvänta sig, baserat på KeyDB:s författares diagram... Men detta är bara vårt specifika fall, där det kan finnas många avvikelser, även när det gäller den beryktade applikationsarkitekturen (till exempel ett stort antal kommandon hämta i Redis istället för det mer prestandaeffektiva alternativet med aggregerade förfrågningar mget…). Trots detta har vi lyckats uppnå positiva resultat, och tillsammans med dem - många användbara funktioner som vi fortfarande bara kommer att implementera inom kort.

Övergripande verkar KeyDB lovande: när vi får praktisk erfarenhet av att arbeta med denna databas (som vi fortfarande bara ska samla på oss!) och projektet själv utvecklas, kommer vi att överväga möjligheten att använda den i andra situationer.

Men den här artikeln bör inte ses som en vägledning (och än mindre som en uppmaning) till att överallt avskaffa Redis till förmån för KeyDB. Trots vår positiva erfarenhet är det uppenbart att det inte är en silverkula. Fallet var mycket specifikt: specifikt för att lösa ett akut problem i en situation där det behövdes göras snabbt och med minimala kostnader, har detta alternativ visat sig vara giltigt. Kommer KeyDB att vara användbart i ditt fall? Åtminstone vet du nu att denna potentiella möjlighet finns.

P.S.

Läs även i vår blogg:

Källa: habr.com