- Discord a entièrement repensé son architecture autour de Kubernetes pour dépasser les limites de son infrastructure de recherche existante basée sur Elasticsearch, améliorant radicalement les performances et la fiabilité de l’indexation des messages
- L’ancienne file Redis présentait un risque de perte de messages, mais son remplacement par PubSub garantit une transmission fiable, tout en classant les messages par cluster et par index pour un traitement plus efficace
- Une architecture en « cellules » (
cell) a été introduite pour répartir la charge sur de nombreux petits clusters Elasticsearch, résolvant les problèmes de surcharge des nœuds et d’impossibilité de mise à jour
- Les messages DM individuels et les messages de serveur (
guild) sont indexés dans des cellules distinctes, ce qui constitue la base de la nouvelle fonction de recherche globale dans les DM
- Les communautés ultra-massives (BFGs) peuvent passer à l’échelle au-delà de la limite maximale de messages de Lucene grâce à des cellules dédiées et des index multi-shards
Limites de l’infrastructure existante
- La file de messages basée sur Redis créait des goulets d’étranglement lors des pannes de nœuds Elasticsearch, avec un risque de perte de messages
- Dans les grands clusters (plus de 200 nœuds), une seule panne de nœud pouvait faire grimper le taux d’échec global de l’indexation à 40 %
- Les index atteignant la limite
MAX_DOCS de Lucene (2 milliards de messages) entraient dans un arrêt complet de l’indexation
- En raison du vieillissement du système, même un correctif log4shell ne pouvait être appliqué qu’après mise hors ligne complète de l’ensemble du système
Stratégie de résolution
Reconstruction sur Kubernetes
- Automatisation de l’exploitation des clusters Elasticsearch grâce à Elastic Kubernetes Operator (ECK)
- Redémarrages progressifs, mises à niveau de l’OS et du logiciel possibles en toute sécurité
Répartition des clusters avec une architecture en « cellules » (cell)
- Au lieu d’un unique grand cluster, plusieurs petits clusters sont regroupés dans une même cellule
- Dans chaque cellule, le nombre d’index est limité, et la taille des shards est maintenue à 50 GB et à moins de 200 millions de messages
- Amélioration des performances d’indexation et de requête, avec une charge réduite pour maintenir l’état des clusters
File de messages basée sur PubSub
- Le passage de Redis → PubSub permet de maintenir la file sans perte de messages
- L’usage de PubSub est aussi en cours d’extension à d’autres fonctions, comme la planification de tâches
Indexation par lots par cluster
- Les messages reçus via PubSub sont triés selon le cluster cible et l’index, puis traités en parallèle comme des tâches distinctes
- Une architecture de traitement distribué des messages a été mise en place avec les
task et channel de tokio en Rust
Améliorations de la recherche
Recherche DM basée sur l’utilisateur
- Auparavant, les DM étaient indexés par canal, ce qui rendait la recherche globale dans les DM inefficace
- Désormais, les messages DM sont indexés en double dans des index par utilisateur, ce qui permet de rechercher tous les DM en une seule fois
Prise en charge des BFG (Big Freaking Guilds)
- Des index multi-shards ont été introduits pour les communautés ultra-massives dépassant la limite du nombre de messages de Lucene
- Les BFG sont traitées dans des cellules Elasticsearch dédiées avec une structure à multiples primary shards
- Après une double indexation simultanée dans l’ancien et le nouvel index, les requêtes sont progressivement basculées vers le nouveau
Résultats
- Indexation de milliers de milliards de messages, avec un débit d’indexation doublé par rapport à l’ancienne architecture
- Temps de réponse des requêtes : moyenne de 500 ms → 100 ms, p99 de 1 s → moins de 500 ms
- Plus de 40 clusters et des milliers d’index en production
- Les mises à niveau des clusters et les redémarrages progressifs sont entièrement automatisés, sans interruption de service
4 commentaires
Le fait de faire tourner ce genre d’opération en production... tout mon respect.
L’ingénierie de Discord est toujours exemplaire. Je les envie.
Je me demandais ce qu’était pubsub, et il s’avère que c’était un IaaS fourni par GCP.
https://cloud.google.com/pubsub?hl=en
Impressionnant. Et aussi le fait de tout refondre pour résoudre le problème.