- Alors que le volume de stockage des messages de Discord passait de dizaines de milliards à des milliers de milliards, l’équipe ne pouvait plus absorber le poids opérationnel ni la latence imprévisible de son cluster Cassandra de 177 nœuds au début de 2022
- La conception Cassandra centrée sur
channel_idet des buckets temporels créait des partitions chaudes sous l’effet du trafic de lecture concentré des grands serveurs, et les lectures/écritures en quorum propageaient cette latence à un plus grand nombre d’utilisateurs - Discord a intercalé un data service en Rust entre l’API et la base de données, fusionnant les requêtes simultanées sur une même ligne et réduisant la charge sur la base via un routage à hachage cohérent basé sur l’ID du canal
- La migration vers ScyllaDB a été menée avec un nouveau cluster et un migrateur Rust, ramenant un travail estimé à 3 mois avec Spark à 9 jours, avec un pic à 3,2 millions de messages migrés par seconde
- Après la bascule de mai 2022, le nombre de nœuds est passé de 177 sous Cassandra à 72 sous ScyllaDB, le p99 de lecture des anciens messages est passé de 40~125 ms à 15 ms, et le p99 d’insertion des messages de 5~70 ms à 5 ms
Une charge opérationnelle devenue trop lourde avec Cassandra
- En 2017, Discord avait publié sa manière de stocker des milliards de messages, en expliquant sa migration de MongoDB vers Cassandra
- L’objectif à l’époque était d’avoir une base de données scalable, tolérante aux pannes et relativement simple à maintenir, mais à mesure que le volume stocké augmentait, le cluster Cassandra lui-même est devenu une lourde charge opérationnelle
- Le cluster
cassandra-messages, dédié au stockage des messages, est passé de 12 nœuds en 2017 à 177 nœuds au début de 2022, pour stocker des milliers de milliards de messages - L’équipe d’exploitation était souvent appelée pour des problèmes de base de données, la latence était imprévisible, et il fallait réduire des opérations de maintenance devenues trop coûteuses
Schéma des messages et partitions chaudes
- Le schéma simplifié des messages comprenait
channel_id,bucket,message_id,author_id,content, avec pour clé primaire((channel_id, bucket), message_id) - Les identifiants de Discord reposaient sur Snowflake, ce qui permettait un tri chronologique, et les messages étaient partitionnés par canal et par fenêtre temporelle statique, le bucket
- Dans Cassandra, tous les messages d’un canal et d’un bucket donnés étaient stockés ensemble, puis répliqués sur plusieurs nœuds selon le facteur de réplication
- Les petits serveurs d’amis et les serveurs de plusieurs centaines de milliers de membres présentaient des volumes de messages très différents, et cet écart se traduisait par des différences de charge à l’échelle des partitions
- Les écritures étaient ajoutées au commit log et à la structure mémoire appelée memtable avant d’être flushées sur disque, mais les lectures pouvaient devoir interroger la memtable et plusieurs SSTable, ce qui les rendait plus coûteuses
- Quand des lectures simultanées affluaient sur de grands serveurs, certaines partitions devenaient des partitions chaudes, la latence augmentait sur les nœuds concernés et finissait par affecter d’autres requêtes
- Comme Discord utilisait un niveau de cohérence en quorum pour les lectures et les écritures, la hausse de latence sur les nœuds responsables de ces partitions chaudes touchait un périmètre d’utilisateurs plus large
Les goulots d’étranglement de maintenance de Cassandra
- La compaction de Cassandra était elle aussi une source récurrente d’incidents
- Les SSTable devaient être compactées sur disque pour améliorer les performances en lecture, mais si la compaction prenait du retard, le coût des lectures augmentait
- Pendant qu’un nœud exécutait sa compaction, la latence pouvait croître en chaîne
- Discord effectuait fréquemment une opération qu’elle appelait la « gossip dance »
- Retirer un nœud du trafic pour exécuter la compaction
- Le réintégrer ensuite pour qu’il rattrape les hints de Cassandra hinted handoff
- Répéter le processus jusqu’à disparition du backlog de compaction
- Beaucoup de temps était aussi consacré au réglage du garbage collector de la JVM et de la heap, et les GC pauses provoquaient de gros pics de latence
Pourquoi migrer vers ScyllaDB
- Discord exploitait plusieurs clusters Cassandra au-delà des seuls messages, et des problèmes similaires apparaissaient sur chacun d’eux
- ScyllaDB, qui avait déjà retenu l’attention de Discord dans un précédent article, est une base compatible Cassandra écrite en C++, offrant de meilleures performances, des repairs plus rapides, une isolation des charges de travail fondée sur une architecture shard-per-core, et une conception sans garbage collection
- ScyllaDB n’était pas exempt de défauts, mais le fait qu’il soit écrit en C++ plutôt qu’en Java, donc sans garbage collector, contrastait directement avec les problèmes d’exploitation rencontrés avec Cassandra
- Après avoir confirmé les gains via des expérimentations et des tests, Discord a décidé de migrer toutes ses bases vers ScyllaDB et, d’ici 2020, avait déjà migré toutes ses bases sauf
cassandra-messages - Le cluster de messages est resté le dernier, car il s’agissait d’un très gros cluster avec des milliers de milliards de messages et près de 200 nœuds
- Les performances des requêtes inversées dans ScyllaDB ne répondaient pas aux besoins lors des premiers tests
- Une requête inversée consiste à parcourir une table dans le sens opposé à son ordre de tri, par exemple en scannant les messages dans l’ordre croissant
- L’équipe ScyllaDB a priorisé cette amélioration de performance, levant ainsi le dernier obstacle à la migration finale
Un data service en Rust
- Discord estimait qu’un simple changement de base de données ne résoudrait pas automatiquement tous les problèmes, et a donc aussi revu la couche au-dessus de la base
- Un data service a été placé entre le monolithe API et le cluster de base de données afin de contrôler les requêtes simultanées envoyées à la base
- Ce data service a été écrit en Rust
- Discord avait déjà utilisé Rust dans plusieurs projets
- Rust offre des performances de niveau C/C++ sans renoncer à la sûreté
- Le Tokio ecosystem a servi de base pour construire le système d’I/O asynchrone, avec un support disponible pour les drivers Cassandra et ScyllaDB
- Le data service exposait en gros un endpoint gRPC par requête de base de données, et ne contenait volontairement aucune logique métier
- Son point clé était la fusion de requêtes
- Si plusieurs utilisateurs demandaient simultanément la même ligne, la base n’était interrogée qu’une seule fois
- La première requête créait une worker task dans le service, puis les suivantes détectaient son existence et s’y abonnaient
- La worker task interrogeait la base de données puis renvoyait la ligne obtenue à tous les abonnés
Améliorer la fusion grâce au routage
- Un routage à base de hachage cohérent a été appliqué en amont du data service
- Chaque requête adressée au data service disposait d’une routing key, et pour les messages cette routing key était l’ID du canal
- Toutes les requêtes d’un même canal arrivaient ainsi sur la même instance du service, ce qui améliorait fortement la fusion de requêtes
- Par exemple, lorsqu’une notification
@everyonepartait sur un grand serveur, de nombreux utilisateurs ouvraient l’application et lisaient les mêmes messages, ce qui pouvait faire exploser le trafic vers la base - Dans l’ancienne architecture, ce type de situation pouvait produire des partitions chaudes et nécessiter l’intervention de l’équipe d’exploitation, mais le data service réduisait fortement ces pics de trafic vers la base
- Cette amélioration n’a pas entièrement éliminé les partitions chaudes ni la latence sur le cluster Cassandra, mais elle a fait gagner le temps nécessaire pour préparer le nouveau cluster ScyllaDB et mener la migration
Migration de milliers de milliards de messages
- Les exigences de la migration étaient claires
- Il fallait migrer des milliers de milliards de messages
- Il ne devait y avoir aucun downtime
- Il fallait aller vite, car Cassandra continuait à provoquer de fréquentes interventions liées aux incidents
- Discord a d’abord mis en place un nouveau cluster ScyllaDB utilisant une super-disk storage topology
- Des SSD locaux assuraient la vitesse
- Un RAID miroir répliquait les données vers des persistent disks
- La configuration combinait ainsi la vitesse des disques locaux et la durabilité des persistent disks
- Le plan initial consistait à utiliser ScyllaDB pour les nouvelles données à partir d’un temps de bascule, puis à migrer l’historique en arrière-plan
- Discord a commencé les double writes vers Cassandra et ScyllaDB pour les nouvelles données, tout en préparant le migrateur Spark de ScyllaDB
- Le migrateur Spark demandait beaucoup de tuning, et une fois configuré, le temps estimé pour finir était de 3 mois
- Discord a alors étendu sa bibliothèque rapide d’accès aux bases de données existante pour réécrire le migrateur en Rust
- Lecture des token ranges depuis la base
- Enregistrement de checkpoints locaux dans SQLite
- Envoi des données en masse vers ScyllaDB
- Avec ce nouveau migrateur Rust, le temps estimé est tombé à 9 jours, et cette vitesse a permis d’effectuer une bascule complète d’un seul coup plutôt qu’une approche plus complexe basée sur le temps
Bascule et validation
- La migration a atteint un pic de 3,2 millions de messages par seconde
- La progression est restée bloquée à 99,9999 %, car les derniers token ranges contenaient dans Cassandra d’énormes plages de tombstones non compactées
- Une fois ces token ranges compactées, la migration s’est terminée quelques secondes plus tard
- Discord a procédé à une validation automatique des données en envoyant une petite fraction des requêtes de lecture vers les deux bases pour comparer les résultats, sans anomalie détectée
- Le cluster ScyllaDB a bien tenu sous l’ensemble du trafic de production, tandis que Cassandra connaissait des problèmes de latence de plus en plus fréquents
- L’équipe a alors basculé ScyllaDB comme base de données primaire directement en production
Performances et échelle après la bascule
- La bascule de la base de données des messages a eu lieu en mai 2022
- Depuis, l’exploitation est restée calme et stable, sans week-ends entiers passés à gérer des incidents ni nécessité d’ajuster sans cesse les nœuds du cluster pour préserver l’uptime
- Le nombre de nœuds est passé de 177 nœuds Cassandra à 72 nœuds ScyllaDB
- L’espace disque par nœud ScyllaDB était de 9 To, contre 4 To en moyenne pour un nœud Cassandra
- La tail latency s’est elle aussi nettement améliorée
- p99 de lecture des anciens messages : Cassandra 40~125 ms → ScyllaDB 15 ms
- p99 d’insertion des messages : Cassandra 5~70 ms → ScyllaDB 5 ms
- Grâce à ces gains de performance, Discord a pu ouvrir de nouveaux cas d’usage produit en s’appuyant sur une plus grande confiance dans sa base de données des messages
Une résistance à la charge confirmée pendant la Coupe du monde
- À la fin de 2022, pendant la World Cup, alors que des utilisateurs du monde entier regardaient les matchs, les buts se reflétaient aussi dans les graphiques d’envoi de messages de Discord
- Le graphique d’envoi de messages de la finale montrait plusieurs pics correspondant aux événements du match
- Le penalty de Messi et l’avantage 1-0 de l’Argentine
- Le deuxième but de l’Argentine
- Un plateau de 15 minutes pendant la mi-temps
- Le but de Mbappé pour la France, puis un nouveau but 90 secondes plus tard pour égaliser
- La fin du temps réglementaire et le passage à la prolongation
- Les discussions pendant la pause de la première période de prolongation
- Le nouveau but de Messi
- L’égalisation de Mbappé
- La fin de la prolongation et le passage à la séance de tirs au but
- Le tir manqué de la France et le sacre de l’Argentine
- Même avec une forte hausse du volume de messages, le data service en Rust et ScyllaDB ont absorbé le trafic
- Le système final a ainsi été consolidé pour gérer des milliers de milliards de messages
1 commentaires
Avis de Hacker News
Cet article semble surtout incriminer le garbage collection, mais à la lecture du billet précédent [0], cela ressemble plutôt à une limite dans la manière d’utiliser Cassandra, dans le traitement des suppressions massives par Cassandra, ou les deux
Un utilisateur avait supprimé des millions de messages via l’API, ne laissant qu’un seul message dans le canal ; comme Cassandra traite les suppressions au moyen de tombstones, lorsque l’utilisateur ouvrait ce canal, même s’il n’y avait en réalité qu’un seul message, Cassandra devait scanner des millions de tombstones. L’explication est que, dans ce processus, les déchets étaient générés plus vite que la JVM ne pouvait les collecter
On parle aussi de réglage du GC, mais d’après [1], il ne semble pas y avoir eu beaucoup de tuning, et Cassandra — et probablement la JVM aussi — semblaient être dans des versions anciennes. Le fait qu’ils venaient tout juste de quitter CMS a aussi beaucoup joué
0) https://discord.com/blog/how-discord-stores-billions-of-messages
Même si la solution initiale était mal utilisée, je pense qu’une solution difficile à mal utiliser est préférable
En 2022, s’ils étaient sur Java 11, ils utilisaient un runtime vieux de 4 ans ; s’ils étaient sur Java 8, un runtime vieux de 8 ans. Il est donc très probable qu’ils passaient à côté d’une quantité non négligeable de performances
Needs (2023)
Cette couche de service ressemblait à une grande et sophistiquée Varnish Cache distribuée. Le fait qu’ils aient choisi le mot « coalesce » sans parler de cache laisse penser qu’ils ne font sans doute pas beaucoup de cache réel, mais cela m’a rappelé le « grace mode » de Varnish et son usage pour éviter les stampedes, c’est-à-dire le contexte dans lequel j’ai entendu parler pour la première fois de « fusion de requêtes » (request coalescing) https://varnish-cache.org/docs/6.1/users-guide/vcl-grace.htm...
C’est aussi agréable de voir revenir sans cesse le hachage cohérent. C’est une excellente technique de type ruban adhésif, dont l’utilité a été prouvée dans des situations similaires. Quand on sait où une chose doit se trouver, on sait aussi où tout le monde viendra la chercher
proxy_cache_use_stale updating;Un cofondateur de ScyllaDB a ajouté quelques éléments : Discord ne parvenait pas à terminer le repair avec Cassandra, alors que ce n’était pas le cas avec Scylla ; Scylla a beaucoup de points communs avec Cassandra, comme les arbres LSM et la compaction, mais son propre ordonnanceur CPU/IO permet de donner aux requêtes une priorité plus élevée qu’à la compaction
Il indique qu’on peut repousser la compaction vers des demi-millisecondes où il y a suffisamment de bande passante inutilisée, et qu’il existe de nombreux articles à ce sujet. Scylla dispose d’un mode plus sûr, vieux d’un an et demi, appelé
tombstone_gc=repair, et la nouvelle architecture basée sur Raft et les tablets récemment sortie constituerait le prochain grand changement pour les utilisateursCe genre de problème n’aurait tout simplement pas existé si l’on avait utilisé IRC, un protocole de chat distribué qui existe depuis plus de 40 ans
Il a aussi l’avantage de disposer d’une spécification publique et de plusieurs implémentations. Ce n’est pas non plus un jardin clos. Si vous pensez qu’IRC est trop daté pour l’époque actuelle, regardez Matrix ou XMPP. Il est difficile de comprendre comment Discord a fini par dominer, et c’est presque une tragédie
IRC exige en pratique un bouncer pour suivre une conversation sur plusieurs appareils. Il ne chiffre pas les messages, et ne chiffre éventuellement que la connexion entre le client et le serveur. Sans chiffrement de bout en bout, il n’y a pas de confidentialité vis-à-vis du serveur ou de ses opérateurs, et ce serveur devient un point de défaillance unique facile à cibler
Le protocole Matrix est encore en évolution, et les implémentations n’arrivent pas à suivre la spécification. Si vous n’utilisez pas Element, vous prenez du retard en fonctionnalités comme en sécurité. XMPP, comme IRC, s’appuie sur des extensions optionnelles pour des fonctionnalités de base comme le chiffrement de bout en bout, et les clients peuvent ne pas les prendre en charge complètement et correctement
Je recommande de lire l’analyse de soatok : https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
Les révélations Snowden de 2013 remontent à 11 ans. Le chiffrement de bout en bout devrait désormais être une fonctionnalité de base, presque une commodité, et il faudrait l’exiger avec autant d’insistance qu’on a exigé HTTPS. Bien sûr, Discord n’implémente pas le chiffrement de bout en bout
Récemment, un groupe très technique auquel j’appartiens est passé de Telegram à Matrix, et l’expérience utilisateur n’est pas bonne. L’application est buggée et peu agréable visuellement, et la nouvelle application “Element” ne prenant pas en charge le SSO, je n’ai pas pu utiliser mon compte. Pour quelqu’un comme moi qui accepte de mettre les mains dedans, ce sont de petits désagréments supportables, mais je ne pourrais pas convaincre mes amis de l’utiliser
On télécharge un exe, on l’installe, on crée un compte, et ça démarre. N’importe qui peut le faire. Il existe beaucoup de logiciels utiles et excellents, mais la plupart ne sont pas faciles d’accès pour le grand public, et certains, voire beaucoup, n’ont même pas d’interface graphique. Les gens préfèrent vendre leur identité, et même payer, plutôt que de subir trop d’étapes
La conclusion que je tire de cet article est peut-être un peu différente de l’intention de l’auteur
« Le dernier ? Notre ami cassandra-messages. [...] C’était un gros cluster dès le départ. Avec des milliers de milliards de messages et près de 200 nœuds, toute migration était forcément une opération complexe. »
Vu l’échelle de Discord, moins de 200 nœuds pour le stockage des messages paraît étonnamment peu. Je m’attendais à une architecture complexe, visant une scalabilité bien plus rapide et comportant davantage de pièces mobiles. La complexité réelle est sans doute plus élevée que ce qui est décrit dans l’article, mais en repensant à mon expérience, où j’ai été partiellement responsable de plus de 200 nœuds physiques faisant beaucoup moins de choses, je me demande à quel point les architectures cloud modernes sont surconçues
Pour avoir stocké des milliards d’enregistrements avec un ensemble de nœuds Cassandra bien plus petit, Cassandra était vraiment pénible en astreinte et a été la cause de plusieurs grosses pannes
[0] https://news.ycombinator.com/item?id=34950843
L’article est très bien écrit. Je suis content qu’une partie de la solution n’ait pas été d’introduire quelque chose de complètement différent, mais de passer à ScyllaDB, utilisable comme un remplaçant de Cassandra
Discord rend quasiment impossible la suppression des anciens messages. C’est un cauchemar pour la vie privée, et on peut se demander pourquoi l’UE n’est pas intervenue.
La question centrale se résume à savoir s’il faut considérer Matrix comme plus proche de l’e-mail ou de Facebook. S’il s’agit d’e-mail, les gens seraient horrifiés à l’idée que l’expéditeur puisse supprimer ses messages de mon spool de courrier ; s’il s’agit de Facebook, ils seraient horrifiés qu’une publication reste visible quelque part même après l’exercice du droit à l’effacement.
Pour résoudre cela, il faut porter un jugement, et l’explication est qu’ils ont abordé le sujet en se demandant d’abord ce que l’esprit du RGPD cherche réellement à accomplir.
https://matrix.org/blog/2018/05/08/gdpr-compliance-in-matrix...
Le problème, du point de vue du RGPD, est que Discord rend cela difficile à supprimer. Lorsqu’il détecte l’intention de supprimer les données d’un compte, il oriente vers une « anonymisation » ; publiquement, le nom d’utilisateur est dissocié des messages, mais ceux-ci peuvent toujours être rattachés à une personne donnée. Si c’est aussi traité ainsi côté serveur, faire appliquer une demande de suppression des données personnelles d’un utilisateur impliquerait de parcourir un nombre énorme de messages ou de supprimer massivement d’anciens messages.
Le Parlement européen n’est pas un vrai parlement, dans la mesure où seules les commissions peuvent proposer de nouvelles lois et où les élus se contentent généralement de voter ; et, à mon avis, ce n’est pas le public qui contrôle les commissions, mais le département d’État américain. Newsguard, les grandes entreprises tech américaines autres que Musk, et Discord font partie du même réseau d’intérêts politiques et financiers établis, avec beaucoup d’anciens du département d’État.
Sans colère populaire, les institutions au niveau de l’UE risquent fortement d’être capturées, et l’opinion publique est elle aussi contrôlée par un establishment cyberpunk qui entraîne des LLM sur des données Discord illégales et cible la publicité électorale. Au final, il faut s’inquiéter de la possibilité d’un état orwellien où l’on ne peut jamais échapper à un establishment permanent.
Cela dit, je n’estime la probabilité que la plupart de tout cela soit vrai au sens large qu’à un peu plus de 50 %, donc il faut le prendre avec beaucoup de recul.
Cassandra est, par nature, assez proche d’une table de hachage distribuée tolérante aux pannes où l’on fait surtout des ajouts. Si c’est exactement ce dont on a besoin, avec un débit d’écriture élevé, c’est un bon choix.
Je ne comprends pas pourquoi les gens l’utilisent comme une base de données. On se heurte très vite à ses limites, et la douleur liée au fait de vouloir l’utiliser comme une base de données ne fait qu’augmenter avec l’échelle.
Dans ce cas, cela n’a aucun sens comme stockage de messages pour un serveur de chat, à mon avis. Cela semble adapté à une destination de collecte de logs dans un système distribué, où de nombreux clients déversent des données mais où l’on n’a généralement même pas besoin d’auditer les logs, si bien que le nombre de lectures d’un élément donné est inférieur à 1. Les messages Discord ne relèvent clairement pas de ce cas.
D’après mon expérience, je n’ai jamais vu un projet qui commence à utiliser Cassandra continuer à l’utiliser un an plus tard. Il faut environ un an pour atteindre ses limites, puis on finit par le remplacer par une base de données comme Postgres.
Je ne comprends pas pourquoi ils ne peuvent pas simplement faire du sharding. Chaque « serveur » Discord n’est-il pas isolé des autres ? S’ils ne peuvent pas s’envoyer de messages entre eux, pourquoi ne pas répartir ces billions de messages sur des milliers de shards, chacun en gérant quelques milliards ?
« L’équipe ScyllaDB a donné la priorité à ces améliorations et implémenté des requêtes inverses performantes, supprimant ainsi le dernier obstacle lié à la base de données dans le plan de migration », dit l’article.
Je me demande combien ils ont payé pour obtenir cela avant même d’utiliser ScyllaDB.