La mise à l’échelle des datastores de Slack avec Vitess

• Récit du passage de Slack, d’une architecture de clusters Active-Active, à Vitess, le système de mise à l’échelle horizontale pour MySQL

• La migration a commencé en 2017, et Vitess traite désormais 99 % de l’ensemble des requêtes, avec une migration complète prévue d’ici la fin de l’année

→ Actuellement, au pic, 2,3 millions de QPS (2 millions en lecture, 300 000 en écriture)

→ La latence médiane des requêtes est de 2 ms, la latence p99 est de 11 ms

• Slack a démarré avec une stack LAMP (Linux, Apache, MySQL, PHP)

• 3 clusters de base de données

→ Shard : toutes les données utilisateur, comme les messages, canaux, DM, etc. Le partitionnement se fait par ID d’espace de travail, de sorte qu’un espace de travail appartient à un seul shard

Autrement dit, l’application Slack n’a besoin de se connecter qu’à une seule base de données

→ Cluster de métadonnées : table de lookup pour relier les espaces de travail aux shards

→ Cluster « kitchen sink » : stocke toutes les données non spécifiques à un espace de travail particulier, comme l’annuaire des applications

• Le sharding était géré et orchestré par le monolithe webapp

• Chaque cluster est composé d’un ou plusieurs shards, et chaque shard est provisionné avec au moins deux instances MySQL situées dans des datacenters différents

• Avantages de la configuration Active-Active

→ Haute disponibilité

→ Développement produit rapide

→ Débogage simple

→ Mise à l’échelle facile

Mais à mesure que l’organisation a grandi et que les équipes produit ont créé de nouvelles fonctionnalités, la vitesse de développement a ralenti

• Inconvénients de l’Active-Active

→ Limites de montée en charge : avec l’arrivée de clients plus grands, ils ont atteint les limites de ce que des hôtes plus puissants pouvaient absorber

→ Enfermement dans un seul modèle de données :

L’arrivée de fonctionnalités comme Enterprise Grid et Slack Connect allait à l’encontre du paradigme consistant à se connecter à un seul serveur

→ Hotspots : mauvaise utilisation de la flotte de bases de données. Il était difficile de découper les shards et de déplacer des équipes, l’usage de Slack était difficile à prévoir, et la plupart des shards étaient donc surprovisionnés, ce qui rendait difficile de tirer parti de la longue traîne

→ Problèmes de disponibilité entre espaces de travail et shards : si un shard rencontrait un problème, tous les clients présents sur ce shard ne pouvaient plus utiliser Slack

→ Exploitation : ce n’était pas une configuration MySQL standard, donc de nombreux outils internes ont dû être développés

• À l’automne 2016, ils géraient des centaines de milliers de requêtes MySQL par seconde et des milliers d’hôtes MySQL shardés

• Ils rencontraient régulièrement des problèmes de montée en charge et de performances, ce qui les a conduits à réfléchir à une nouvelle approche

• Ils ont envisagé soit de faire évoluer l’existant, soit d’adopter un nouveau produit, mais

→ ils voulaient continuer à utiliser MySQL exécuté dans leur cloud privé

→ ils avaient des milliers de requêtes uniques, dont certaines s’appuyaient sur des configurations MySQL particulières

→ le déploiement, les sauvegardes, l’ETL vers le data warehouse, la conformité, etc., reposaient tous sur MySQL

• Pourquoi Vitess ? : cela répondait à la plupart des exigences applicatives et opérationnelles

→ MySQL Core : Vitess est basé sur MySQL

→ Scalability : combine les fonctions majeures de MySQL avec la scalabilité des bases NoSQL. Grâce au sharding intégré, il est possible de s’étendre de manière flexible sans ajouter de logique spécifique

→ Operability : gère automatiquement des éléments comme le basculement et les sauvegardes. Suit les métadonnées de configuration du cluster pour maintenir la cohérence

→ Extensibility : open source, basé sur Go, avec une large couverture de tests et une communauté de développeurs ouverte

• Mise en production progressive avec Vitess, en commençant par de petites fonctionnalités

→ En 2017, ils ont testé la création d’une fonctionnalité intégrant des flux RSS dans les canaux Slack

→ En 2018, toutes les nouvelles tables ont été créées uniquement sur Vitess

→ Mi-2019, il y avait davantage d’écritures sur Vitess que sur la base de données legacy

→ Et Slack a continué à contribuer au projet open source Vitess

→ Sur trois ans, 99 % ont été migrés vers Vitess. Le 1 % restant doit être terminé cette année

• L’adoption de Vitess par Slack a-t-elle été un succès ?

→ Plusieurs clusters Vitess, répartis dans différentes régions du monde, exploitent des dizaines de keyspaces

→ Les keyspaces sont des collections logiques qui évoluent en fonction du nombre d’utilisateurs, d’équipes et de canaux

→ Le sharding flexible a permis à Slack de passer à l’échelle

→ Avec le COVID-19, le nombre de requêtes de Slack a augmenté de 50 % en une semaine

→ Ils ont étendu horizontalement leur keyspace le plus chargé à l’aide du workflow de split de Vitess

→ Avec l’ancienne architecture, la montée en charge aurait été impossible et aurait provoqué une interruption de service.

[xguru]

https://vitess.io/

Vitess : « Middleware de sharding pour MySQL »

• Une solution conçue pour déployer, faire monter en charge et gérer facilement MySQL et MariaDB dans le cloud

• Exploite et administre des shards MySQL sur Docker (en local) et sur Kubernetes

• L’application peut l’utiliser comme si elle communiquait avec MySQL via un proxy appelé VTGate, qui se connecte ensuite en interne à d’autres serveurs via gRPC

[xguru]

Le service d’e-mail Hey utilise aussi Vitess

La stack technique de Hey https://fr.news.hada.io/topic?id=2355