KeyDB comme remplacement [potentiel] de Redis

Il n'y a eu aucun avis sur une "alternative plus rapide à Redis" sur Habré - Base de données de clés. Ayant acquis une expérience assez récente dans son utilisation, je souhaite combler cette lacune.

Le contexte est assez banal : un jour, avec un afflux important de trafic, une dégradation importante des performances des applications (à savoir le temps de réponse) a été enregistrée. Malheureusement, à cette époque, il n'était pas possible d'effectuer un diagnostic normal de ce qui se passait, c'est pourquoi une série de tests de charge a ensuite été planifiée. Après les avoir réalisés, nous avons pu découvrir un goulot d'étranglement, à savoir le cache de la base de données dans Redis. Comme cela arrive souvent, le problème n'a pas pu être résolu immédiatement et de la bonne manière - par les développeurs (en changeant la logique de travail). Par conséquent, la curiosité et le désir de surmonter la situation de manière détournée se sont réveillés. C’est ainsi qu’est apparu cet article.

Problèmes

À propos de Redis en général

Comme beaucoup de gens le savent, Redis est une base de données monothread. Pour être plus précis, c'est le cas dans le contexte du travail avec les données utilisateur. Après tout, depuis la quatrième version, service, opérations internes de Redis transféré pour une exécution parallèle. Cependant, ce changement n’a affecté qu’une petite partie de la charge de travail, puisque l’essentiel du travail est effectué sur les données des utilisateurs.

D'innombrables copies ont été brisées sur ce sujet, mais les développeurs Redis refusent obstinément d'implémenter un parallélisme complet, mentionnant à quel point cela compliquerait l'application et augmenterait les frais généraux, ainsi qu'ajouterait davantage de bogues. Leur position est la suivante : si vous êtes confronté à un problème monocœur, vous avez des problèmes avec l'architecture de l'application et quelque chose doit y être modifié. Parmi les utilisateurs, cependant, il existe également « un autre camp » : ceux qui sont coincés sur un seul noyau et prétendent que Redis se crée un goulot d'étranglement. Dans le cas de charges très importantes - tôt ou tard - il est inévitable de rencontrer ce problème, qui impose des restrictions importantes sur l'architecture et/ou des complications forcées.

Je n'évaluerai pas telle ou telle opinion. Au lieu de cela, je partagerai notre cas spécifique et comment nous l'avons résolu.

Notre cas

Dans l'un des projets, nous avons constaté que l'équipe de développement avait configuré une mise en cache extrêmement agressive des données de la base de données (PostgreSQL) via Redis. C'était le seul moyen qui, lors d'afflux soudains de trafic, sauvait PostgreSQL lui-même et, par conséquent, l'application de la mort.

Après une série de tests de charge, nous avons analysé la situation et constaté que Redis était limité à un seul cœur (ce qu'on appelle une « étagère »), suivi d'une dégradation assez rapide de l'application. L’« étouffement » a été exponentiel : dès que la limite de performances de Redis était atteinte, tout cessait de fonctionner.

Cela ressemblait à quelque chose comme ceci:

New Relic a clairement identifié le problème :

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

Après que le problème ait été signalé en détail à l’équipe de développement, il s’est avéré que « le problème ne peut pas être résolu pour le moment ». C'est ainsi qu'a commencé la recherche d'une solution du côté des opérations, et la KeyDB déjà mentionnée était la réponse.

Cependant, avant de commencer notre examen, il convient de mentionner que le projet utilise Redis autonome, car la solution de cluster basée sur Sentinel est bien inférieure en termes de latence. Une solution évidente était de créer plusieurs répliques du cache : et de laisser l'application aller partout avec équilibrage ! Cependant, après avoir consulté les développeurs, nous avons été contraints d'abandonner cette option en raison du mécanisme d'invalidation du cache actif et complexe de l'application. Le même problème s’est étendu au partage du cache.

Un aperçu rapide de KeyDB

En cherchant une solution possible au problème, nous avons découvert application appelée KeyDB. Il s'agit d'un fork Redis développé par entreprise canadienne et distribué sous la licence gratuite BSD. Le projet est très jeune : il existe depuis début 2019. Son histoire est que les auteurs ont également rencontré les limites de Redis... et ont décidé de créer leur propre fork. De plus, il a non seulement résolu des problèmes connus, mais a également reçu des fonctionnalités supplémentaires 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 de brefs benchmarks le comparant à son « parent » - Redis.

Tout d'abord, nous avons été attirés par KeyDB par la solution potentielle à nos problèmes, et en même temps nous étions intéressés par quelques fonctionnalités supplémentaires. L'utilisation de KeyDB promettait les avantages suivants :

• obtenir un multithreading complet ;
• compatibilité totale et absolue avec Redis (c'était particulièrement important pour nous, car il n'était pas possible d'apporter de modifications côté application), ce qui promettait également une migration sans problème ;
• mécanisme de sauvegarde intégré dans le stockage S3 ;
• réplication active facile à mettre en œuvre ;
• clustering et partitionnement simples sans Sentinel et autres logiciels de support.

Plus de 3 XNUMX étoiles et de nombreux contributeurs sur GitHub semblaient également encourageants. L'application est développée et prise en charge de manière assez active, ce qui est clairement visible dans les commits, la communication dans les problèmes, ainsi que dans les PR fermés (acceptés). La réponse du responsable principal sur tous les fronts est toujours amicale et rapide. En général, les arguments étaient nombreux.

Migration et résultats

Même si le projet de migration était un peu un pari (en raison de la nouveauté de KeyDB), il n'y avait pas grand chose à perdre. Après tout, annuler les modifications est assez rapide et simple - heureusement, toute l'infrastructure est déployée dans Kubernetes et les mécanismes intégrés Mise à jour continue Ils résolvent très bien ces problèmes.

En général, nous avons préparé des modèles Helm, basculé l'application dans l'environnement de test vers une nouvelle base de données et tout déployé, en le confiant au service d'assurance qualité du client.

Les tests ont commencé, qui ont duré environ une semaine et dont nous n'avons pas approfondi les détails. Nous savons seulement que le client a testé les fonctions standards de travail avec Redis à l'aide d'un pilote PHP phpredis, et a également effectué des tests d'assurance qualité de l'interface utilisateur. Après cela, nous avons reçu le feu vert : aucun effet secondaire n’a été constaté lors de l’utilisation du nouveau logiciel. C'est Du point de vue applicatif, rien n'a changé du tout.

A noter que nous n'avons rien changé dans la config : littéralement, nous avons simplement remplacé l'image utilisée. Il en va de même pour la surveillance et l’exportation des métriques vers Prometheus : le plus courant d'entre eux fonctionne parfaitement avec KeyDB et sans aucune modification. Ainsi, nous pouvons affirmer avec certitude que d’un point de vue opérationnel, il s’agit tout simplement d’une décision idéale.

Grâce à tout cela, après avoir basculé l'application vers un nouveau SGBD, vous ne pouvez rien changer, mais comme « mesure de stabilisation », vous pouvez la laisser sous cette forme pour travailler au combat pendant un certain temps. Cependant, si vous souhaitez voir une augmentation des performances (ou un quelconque changement), vous ne devez pas oublier que par défaut Paramètre KeyDB responsable du multithreading (server-threads), est égal à un, c'est-à-dire Le SGBD fonctionne exactement de la même manière que Redis.

Après le basculement, les tests et un certain temps de vie sur la nouvelle application (avec KeyDB), nous avons décidé de répéter les tests de charge avec les mêmes paramètres que ceux utilisés pour Redis. Quels ont été ses résultats ?..

Selon le graphique de consommation du processeur, l'élimination des problèmes de « plafond » d'un cœur est immédiatement devenue perceptible : le processus a commencé à utiliser les ressources disponibles :

Et plus tard, j'ai essayé de « torturer » l'application assez fortement et j'ai constaté une consommation allant jusqu'à trois cœurs...

Selon New Relic, l'application Web dans son ensemble, ayant la même charge, a commencé à se comporter de manière nettement plus adéquate. Une certaine dégradation des performances a encore été observée, cependant, par rapport au graphique similaire ci-dessus, vous pouvez évaluer par vous-même les progrès significatifs :

La latence de la nouvelle base de données (KeyDB) s'est également aggravée, mais est restée dans des valeurs acceptables :

Le graphique suivant montre clairement que le nombre de requêtes adressées à KeyDB lui-même est similaire :

Pour résumer ces tests synthétiques, nous pouvons dire que Redis et KeyDB montrent tous deux une dégradation significative des performances en termes de latence (40 ms+) avec une augmentation significative du nombre de connexions parallèles (1000+). Dans notre cas, l'application Web a pu « gaspiller » la latence de Redis même avec un nombre de connexions inférieur (400+), bien que pour KeyDB, une telle charge reste acceptable.

résultats

Cet exemple montre bien la force de la communauté Open Source dans le développement des projets qui l'intéressent. Je suis tombé sur une excellente déclaration sur Internet, dont le sens général se résumait à ceci : « Une grande entreprise crée un produit intéressant, rend certaines de ses fonctions ouvertes, mais laisse la partie la plus importante payée. La communauté l’utilise et l’utilise, puis quelqu’un abandonne et crée un fork, y implémentant les mêmes fonctionnalités payantes et les ouvrant à tout le monde. Ici, KeyDB est le même cas.

Parlant de la migration elle-même, qui était étonnamment simple, nous n'avons pas reçu si une augmentation significative des performances, à laquelle on peut s'attendre en regardant les graphiques des auteurs de KeyDB... Cependant, ce n'est que notre cas particulier, dans lequel il peut y avoir de nombreux écarts, y compris l'architecture notoire de l'application (par exemple , un grand nombre de commandes get dans Redis au lieu de l'option plus performante des requêtes agrégées mget...). Néanmoins, nous avons réussi à obtenir des résultats positifs et avec eux de nombreuses fonctions utiles que nous mettrons en œuvre dans un avenir proche.

En général, KeyDB semble prometteur : au fur et à mesure que nous acquerrons une expérience pratique avec ce SGBD (et nous devons encore l'acquérir !) et développerons le projet lui-même, nous envisagerons la possibilité de l'utiliser dans d'autres situations.

Cependant, cet article ne doit pas être considéré comme un guide (et encore moins un appel) à l’action pour l’abandon généralisé de Redis au profit de KeyDB. Malgré notre expérience positive, il est clair que ce n’est pas une solution miracle. Le cas était très concret : précisément pour résoudre un problème momentané dans une situation où il fallait le faire rapidement et à moindre coût, cette solution était justifiée. KeyDB sera-t-il utile dans votre cas ? Au moins maintenant, vous savez que cette possibilité potentielle existe.

PS

A lire aussi sur notre blog :

• «Bases de données et Kubernetes (présentation et rapport vidéo)";
• «Migration de Cassandra vers Kubernetes : fonctionnalités et solutions";
• «Migration transparente de MongoDB vers Kubernetes";
• «Migration transparente de RabbitMQ vers Kubernetes».

Source: habr.com