Gestion de plus de 50 000 bases de données Redis sur 4 clouds publics avec une petite équipe Devops

Gestion de plus de 50 000 bases de données Redis sur 4 clouds publics avec une petite équipe Devops

managing 50k redis databases art

Les applications modernes ont une liste générale de besoins afin non seulement de survivre, mais aussi de prospérer dans l’environnement cloud au rythme effréné d’aujourd’hui. Ceux-ci incluent des temps de réponse faibles (moins de 100 millisecondes), une évolutivité illimitée, une haute disponibilité et des performances optimales, pour n’en nommer que quelques-uns. Avec une sélection d’options de base de données modernes disponibles, Redis s’est avéré être l’un des plus populaires. Redis a contribué à la création de plus de 50 000 bases de données par plus de 2 500 clients payants, avec plus de 100 nouvelles bases de données créées quotidiennement. Être un contributeur majeur à Le projet open source de Redis, de nombreux cas d’utilisation que nous voyons utiliser Redis incluent des applications sociales, des sociétés de publicité en ligne et des sociétés de jeux. Notre expérience dans l’exécution des services Redis sur les quatre principaux clouds (AWS, Azure, GCP et SoftLayer) nous a fait prendre conscience d’un certain nombre de défis rencontrés par les utilisateurs, ce qui a par conséquent conduit à nos solutions soigneusement testées, dont nous avons partagé quelques-unes ci-dessous.

https://www.youtube.com/watch?v=eymqHZaUOH4

Défi n° 1 : performances optimales stables

Alors que Redis est très rapide, avec la capacité de répondre aux demandes en moins de 1 milliseconde, son exécution dans le cloud peut entraîner une dégradation significative des performances. Cependant, avec Redis, toutes les opérations sont effectuées en arrière-plan, incorporant autant d’instances Redis que possible dans un cluster pour permettre une architecture multi-tenant pure sans dégradation des performances. Les bases de données Redis sur notre plate-forme utilisent la réplication maître-esclave, où le maître est situé sur un nœud tandis que l’esclave est situé sur un autre, avec autant d’instances que possible sur chaque nœud. De plus, le cluster est construit autour d’un nombre impair de nœuds afin d’avoir un quorum en cas de panne. Notre proxy sans latence masque tout du point de vue de l’utilisateur, de sorte que les utilisateurs ne voient qu’un seul point de terminaison, avec la possibilité d’ajouter un proxy pour recevoir plus de débit, sans visibilité des fragments, des clusters ou des nœuds.

Défi n° 2 : sélection du centre de données

Lorsque nous avons commencé notre voyage avec Redis, notre principal défi était de comprendre quel centre de données serait optimal pour chaque application. Il est important que chaque base de données Redis soit exécutée sur le même centre de données que son application respective afin d’éviter la latence du réseau. Les centres de données sont sélectionnés par les utilisateurs lorsqu’ils créent une instance dans une région, cependant, un problème se pose lors de la sélection d’une zone ou d’un centre de données à partir d’AWS, car ils sont cartographiés différemment entre les comptes. Par exemple, “us-east-1a” de Redis peut être signifié comme “us-east-1c” pour les autres utilisateurs. Bien qu’il s’agisse de centres de données complètement différents, AWS a mis en place cette méthode pour assurer un équilibrage de charge stable pour son architecture interne. Sinon, comme la plupart des utilisateurs n’ont aucune préférence concernant un centre de données spécifique, la plupart choisiront le premier, créant ainsi un niveau de demande déséquilibré. Pour fournir le service multi-cloud et multi-régions de Redis à partir de l’emplacement le plus proche possible de l’application de l’utilisateur, nous avons développé un code qui effectue une cartographie entre nos zones et celles de nos utilisateurs. En appliquant cela à notre exemple, nous avons trouvé que le code pour ‘us-east-1a’ correspondait à celui de ‘us-east-1c’. Cela nous indique que lorsqu’un utilisateur choisit de créer une base de données dans “us-east-1c”, elle doit être mappée sur notre “us-east-1a” pour garantir une latence réseau minimale.

Défi n° 3 : sélection d’instances

Décider quelle instance sélectionner lors de la création d’un nœud peut être source de confusion. Par conséquent, nous avons décidé que n’importe quel type d’instance peut être utilisé dans les clusters de Redis. Bien que chaque type d’instance ait un ensemble prédéfini, il n’y a aucune limite à la plage de tailles pouvant exister dans un cluster, qu’il s’agisse de 30 Go ou de 200 Go. Ce type de flexibilité est essentiel. Nous voulons être en mesure de faire face à une utilisation élevée de la mémoire ainsi qu’à une utilisation élevée du processeur. De plus, nous voulons tout faire fonctionner sur une infrastructure dédiée pour éviter les « voisins bruyants » et être aussi rentable que possible. L’utilisation de grandes instances fournit automatiquement des instances dédiées par conception. Ces grandes instances sont ensuite utilisées pour créer notre propre infrastructure multi-tenant contrôlée. Afin de créer une infrastructure solide pour n’importe quelle architecture, il est conseillé d’utiliser des instances spécifiques à travers les nuages : c3 (pour les performances) et r3 (pour la mémoire) dans AWS ; a4, a5, a6 et a7 en azur ; la mémoire élevée standard et le processeur élevé dans GCP ; basez les clusters sur des serveurs bare metal dans SoftLayer avec des machines virtuelles supplémentaires à mettre à l’échelle.

Défi #4 : Persistance des données

Avec des utilisateurs qui exécutent 1 million d’opérations par seconde, dont 50 % sont des demandes d’écriture, la persistance des données est extrêmement importante avec Redis. La question est de savoir comment cela peut être effectué sur l’infrastructure EBS d’AWS ? Tout d’abord, vous devez comprendre les détails de l’architecture de stockage du cloud : le stockage éphémère local est relativement rapide et le stockage en réseau, tel qu’EBS, est persistant. Les plus grands volumes EBS sur AWS fournissent un stockage sur disque EBS dédié (il en va de même pour GCP). Malheureusement, cela ne suffit pas pour faire face aux performances de Redis. En conséquence, nous avons hybride les deux, en utilisant l’éphémère pour certains besoins de stockage, incorporé avec EBS pour la persistance. En conséquence, nous avons affiné Redis pour améliorer sa vitesse lors de l’accès à un disque et utiliser des esclaves pour effectuer des activités de persistance des données lors de l’utilisation de la réplication, libérant ainsi le maître.

Défi #5 : Surveillance

Comment tout est surveillé ? ZabbixComment est utilisé pour surveiller les nœuds, et en ce qui concerne la surveillance des métriques de la base de données, nous avons cherché un projet open source en vain, ce qui nous a conduit à construire notre propre système de surveillance – Limbic – qui est basé sur Python, RRD et Redis. Avec cette plate-forme, nous sommes en mesure de surveiller 50 000 bases de données, chacune avec 100 métriques et conservant 10 000 résolutions temporelles. En temps voulu, il sera disponible en open source pour que tout le monde puisse en profiter.

Comment nous gérons le service

Nous sommes en mesure de gérer ces infrastructures complexes grâce à notre solide équipe DevOps qui, bien que de taille modeste, est soutenue par des développeurs qui connaissent parfaitement le système et peuvent être amenés à résoudre les problèmes de production en temps réel. Nous utilisons également une approche « petits pas » lors du passage à la production. Par conséquent, nous commençons toujours par une configuration manuelle, puis progressons lentement vers l’automatisation. Nous avons constaté que cette approche pratique gagne toujours.

Dans l’ensemble, Redis a pris les mesures nécessaires pour garantir des performances Redis de qualité à nos clients. Nos solutions aux défis mentionnés ci-dessus ont apporté la tranquillité d’esprit dont nos clients ont besoin pour se concentrer avec succès sur leurs propres capacités de base. Pour plus d’informations, consultez l’intégralité vidéo qui explore les défis ci-dessus ainsi que les diaporama.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *