KeyDB comme [potentielle] alternative à Redis

Il n'y a pas eu de critiques sur Habr concernant « une alternative plus rapide à Redis » — KeyDB. Ayant acquis une expérience suffisamment récente dans son utilisation, je souhaite combler cette lacune.

L'histoire est suffisamment banale : un jour, avec une grande afflux de trafic, une dégradation significative des performances de l'application (à savoir — le temps de réponse) a été constatée. À ce moment-là, malheureusement, il n'a pas été possible de mener un diagnostic normal de la situation, c'est pourquoi par la suite, une série de tests de charge a été planifiée. Après leur réalisation, il a été possible de détecter le goulet d'étranglement, à savoir le cache de la base de données dans Redis. Comme c’est souvent le cas, le problème ne pouvait pas être résolu immédiatement et de manière correcte — par les développeurs (en changeant la logique de fonctionnement). Ainsi, la curiosité et le désir de résoudre la situation par un autre moyen se sont manifestés. C’est ainsi que cet article est né.

Problématique

Sur Redis en général

Comme beaucoup le savent, Redis est une base de données monoprocédurale. Pour être plus précis, c'est le cas dans le contexte du traitement des données utilisateur. En effet, à partir de la quatrième version, les opérations internes et de service de Redis ont été transférées à une exécution parallèle. Cependant, ce changement n’a touché qu’une petite partie de la charge, car la majeure partie du travail concerne les données utilisateur.

De ce sujet, d'innombrables débats ont eu lieu, mais les développeurs de Redis refusent obstinément d’implémenter une vraie parallélisation, mentionnant combien cela compliquerait l'application et augmenterait les frais généraux, tout en ajoutant des bogues. Leur position est la suivante : si vous êtes confronté au problème de la monocore — vous avez des problèmes d'architecture d'application et il faut changer quelque chose à ce sujet. Cependant, il existe parmi les utilisateurs un « autre camp » — celui qui est bloqué sur un seul cœur et affirme que Redis crée eux-mêmes un goulot d'étranglement. En cas de charges réellement importantes — tôt ou tard — on est inévitablement confronté à ce problème, ce qui impose des restrictions significatives sur l'architecture et/ou des complications forcées au sein de celle-ci.

Je ne vais pas évaluer l'un ou l'autre avis. À la place, je vais partager notre cas spécifique et comment nous l'avons résolu.

Notre cas

Dans l'un de nos projets, nous avons rencontré un problème où l'équipe de développement avait mis en place un cache des données de la base de données (PostgreSQL) via Redis de manière extrêmement agressive. C'était le seul moyen qui, lors des pics soudains de trafic, sauvait la PostgreSQL de la défaillance, et par conséquent, l'application.

Après une série de tests de charge, nous avons analysé la situation et découvert que Redis était limité à un seul cœur (ce qu'on appelle « au point mort »), après quoi il y avait une dégradation assez rapide de l'application. Le « ralentissement » avait une progression géométrique : dès que la limite de performance était atteinte pour Redis, tout cessait de fonctionner.

Cela ressemblait à peu près à ceci :

Du côté de New Relic, le problème était clairement identifié :

Voici les statistiques de l'opération obtenir dans Redis :

Après que le problème ait été expliqué en détail à l'équipe de développement, il s'est avéré que « le problème ne pouvait pas être résolu immédiatement ». Ainsi commencèrent les recherches de solutions du côté des opérations, et la réponse fut l'utilisation de KeyDB déjà mentionnée.

Cependant, avant de commencer son examen, il convient de mentionner que le projet utilise Redis en mode autonome, car la solution en cluster basée sur Sentinel est très inférieure en termes de latence. L'une des solutions évidentes aurait été de créer plusieurs répliques du cache : et faire en sorte que l'application s'y connecte avec un équilibrage de charge ! Cependant, après discussion avec les développeurs, nous avons été contraints d'écarter cette option en raison du mécanisme complexe et actif d'invalidation du cache de l'application. Le même problème s'appliquait également au sharding du cache.

Aperçu rapide de KeyDB

En quête d'une solution possible au problème, nous avons découvert une application appelée KeyDB. C'est un fork de Redis, développé par une société canadienne et diffusé sous la licence libre BSD. Le projet est assez jeune : il existe depuis début 2019. Son histoire est telle que ses auteurs ont également été confrontés à des limitations de Redis un jour… et ont décidé de créer leur propre fork. De plus, il ne s'est pas seulement attaqué aux problèmes connus, mais a également ajouté des fonctionnalités qui ne sont disponibles que dans la version entreprise de Redis.

Pour ceux qui souhaitent se familiariser plus en détail avec KeyDB, il existe un bon article d'introduction sur Medium, qui présente le SGBD et des benchmarks comparant son « père » — Redis.

Tout d'abord, ce qui nous a attirés vers KeyDB était la solution potentielle à nos problèmes, et certaines fonctionnalités supplémentaires étaient également intéressantes. L'utilisation de KeyDB promettait les avantages suivants :

• une véritable multi-threading ;
• une compatibilité complète et absolue avec Redis (ce qui était particulièrement important pour nous, car il n'était pas possible d'apporter des modifications au niveau de l'application), ce qui annonçait également une migration sans problème ;
• un mécanisme de sauvegarde intégré dans un stockage S3 ;
• une réplication active facile à mettre en œuvre ;
• une clustering et sharding simples sans Sentinel ni autres logiciels auxiliaires.

Plus de 3000 étoiles et de nombreux contributeurs sur GitHub semblaient également prometteurs. L'application est activement développée et maintenue, ce qui est bien visible dans les commits, les échanges dans les issues, ainsi que dans les PR fermées (acceptées). La réponse de l'un des principaux mainteneurs est toujours bienveillante et rapide. En somme, il y avait suffisamment d'arguments.

Migration et résultats

Même si le projet de migration était une sorte d'aventure (en raison de la nouveauté de KeyDB), nous n'avions pas grand-chose à perdre. En effet, il est assez rapide et facile de revenir en arrière — d'autant plus que toute l'infrastructure est déployée sur Kubernetes, et les mécanismes intégrés Mise à jour en continu résolvent parfaitement ce genre de tâches.

En gros, nous avons préparé des modèles Helm, avons basculé l'application dans l'environnement de test vers la nouvelle base de données et avons déployé le tout, le confiant au département QA du client.

Les tests ont commencé, et cela a duré environ une semaine, dont nous ne sommes pas allés dans les détails. Nous savons seulement que le client a vérifié les fonctions standards de travail avec Redis à l'aide du driver PHP phpredis, et a également réalisé des tests QA de l'interface utilisateur. Après cela, nous avons obtenu le feu vert : aucun effet secondaire dans l'utilisation du nouveau logiciel n'a été détecté. Autrement dit, du point de vue de l'application, rien n'a vraiment changé..

Il convient de noter qu'il n'y a eu aucun changement dans la configuration non plus : littéralement — nous avons simplement remplacé l'image utilisée. Il en va de même pour le monitoring et l'exportation des métriques vers Prometheus : le plus répandu parmi eux fonctionne parfaitement avec KeyDB et sans aucune modification. Ainsi, on peut dire sans hésitation que du point de vue de l'exploitation, c'est tout simplement un déménagement idéal.

Grâce à tout cela, après le passage de l'application à la nouvelle SGBD, il n'est pas nécessaire de changer quoi que ce soit, et en tant que « mesure de stabilisation », il peut rester dans cet état et fonctionner en production pendant un certain temps. Cependant, si vous souhaitez voir un gain de performance (ou même quelques modifications), n'oubliez pas que par défaut le paramètre KeyDB, responsable du multitâche (server-threads), est égal à un, c'est-à-dire que la SGBD fonctionne exactement comme Redis..

Après le passage, le test et un certain temps de fonctionnement avec la nouvelle application (avec KeyDB), nous avons décidé de répéter le test de charge avec les mêmes paramètres utilisés pour Redis. Quels en ont été les résultats ?..

Sur le graphique de consommation CPU, il est immédiatement apparu qu'il n'y avait plus de problème de « plafond » sur un seul cœur : le processus a commencé à utiliser les ressources disponibles :

Plus tard, j'ai essayé de « stresser » considérablement l'application et j'ai observé une consommation allant jusqu'à trois cœurs…

D'après New Relic, l'application web, ayant la même charge, s'est comportée de manière sensiblement plus adéquate. Une certaine dégradation des performances a toutefois été observée, mais en comparant avec le graphique similaire ci-dessus, vous pouvez évaluer le progrès significatif :

Le temps de latence de la nouvelle base de données (KeyDB) a également empiré, mais est resté dans des limites acceptables :

Le graphique suivant montre clairement que le nombre de requêtes à KeyDB est similaire :

Pour conclure ces tests synthétiques, on peut dire que tant Redis que KeyDB montrent une dégradation significative des performances en latence (40 ms+) avec une augmentation substantielle du nombre de connexions simultanées (1000+). Dans notre cas, l'application web a réussi à « faire chuter » la latence de Redis même avec un nombre de connexions plus faible (400+), bien que pour KeyDB, cette charge restait acceptable.

Conclusions

Cet exemple illustre magnifiquement la puissance de la communauté Open Source en matière de développement de projets qui l'intéressent. Sur Internet, j'ai rencontré une excellente citation dont le sens général peut se résumer ainsi : « Une grande entreprise crée un produit intéressant, rend une partie de ses fonctionnalités ouvertes, mais laisse la partie la plus importante payante. La communauté en profite, puis quelqu'un finit par lever la main et faire un fork, intégrant ces fonctionnalités payantes et les rendant accessibles à tous ». Voici KeyDB — c'est ce cas particulier.

En parlant de la migration elle-même, qui s'est étonnamment bien déroulée, nous n'avons pas reçu autant d'augmentation significative des performances que l'on pourrait attendre en regardant les graphiques des auteurs de KeyDB… Cependant, c'est juste notre cas particulier, qui peut présenter de nombreuses variations, notamment en ce qui concerne l'architecture de l'application (par exemple, un grand nombre de commandes obtenir dans Redis au lieu d'options plus performantes de requêtes agrégées mget…). Néanmoins, des résultats positifs ont été obtenus, accompagnés de nombreuses fonctionnalités utiles que nous allons encore implémenter dans un avenir proche.

Dans l'ensemble, KeyDB semble prometteur : au fur et à mesure de l'expérience pratique avec cette SGBD (qui doit encore être acquise !) et du développement du projet lui-même, nous envisagerons son utilisation dans d'autres situations.

Cependant, il ne faut pas considérer cet article comme un guide (et encore moins comme un appel) à un abandon généralisé de Redis au profit de KeyDB. Malgré notre expérience positive, il est évident que ce n'est pas une solution miracle. Le cas était très spécifique : particulièrement pour résoudre un problème urgent dans une situation où cela devait être fait rapidement et à moindre coût, cette solution s'est révélée justifiée. KeyDB sera-t-il utile dans votre cas ? Au moins, vous savez maintenant qu'une telle possibilité existe.

P.S.

Lisez aussi dans notre blog :

• «Bases de données et Kubernetes (aperçu et vidéo de la présentation)»;
• «Migration de Cassandra vers Kubernetes : caractéristiques et solutions»;
• «Migration complexe de MongoDB vers Kubernetes.»;
• «Migration sans tracas de RabbitMQ vers Kubernetes».

Source : habr.com