Postmortem de la panne de 73 heures subie par Roblox l’an dernier

Résumé de la panne

• La panne a duré 72 heures

• Deux causes racines ont été identifiées

  • L’activation de la nouvelle fonctionnalité de streaming de Consul dans une situation de charge anormalement élevée en lecture/écriture a provoqué une contention excessive et une dégradation des performances

  • Dans certaines conditions de charge, un problème de performances est apparu dans l’open source BoltDB, utilisé par Consul pour gérer le write-ahead-log servant à l’élection du leader et à la réplication des données

• Un cluster Consul unique a aggravé l’impact de ces problèmes

• La panne s’est prolongée parce qu’il a fallu identifier ces deux problèmes apparemment sans lien, cachés dans l’implémentation de Consul

• Il a aussi été plus difficile d’en trouver la cause parce que le système de monitoring, qui aurait dû offrir une meilleure visibilité, dépendait de systèmes touchés comme Consul

Environnement du cluster et HashiStack

• Roblox exploite 18 000 serveurs et 170 000 conteneurs

• L’entreprise utilise Nomad, Consul et Vault, généralement appelés HashiStack

À l’époque, Roblox a mis à niveau Consul de la version 1.9 à la 1.10 pour pouvoir utiliser la fonctionnalité de streaming.

Première détection (28/10 13:37)

Le 18 octobre dans l’après-midi, les performances de Vault ont chuté et la charge CPU d’un serveur Consul a augmenté.

Classification initiale (28/10 13:37 – 29/10 02:00)

• Une hausse de la latence d’écriture a été observée dans les métriques du cluster Consul

• Une dégradation matérielle a d’abord été soupçonnée, et l’un des nœuds du cluster Consul a commencé à être remplacé

• Des employés de HashiCorp se sont joints aux opérations pour collaborer

• Même après le remplacement du matériel, les performances de Consul ont continué de se dégrader, et à 16:35 le nombre de joueurs est tombé à 50 % de la normale

• Consul servait à la service discovery, et comme Nomad et Vault en dépendaient aussi, Consul constituait un SPoF.

• Une nouvelle hypothèse a alors émergé : le trafic serait en cause. L’équipe a estimé que Consul n’était plus en mesure de supporter la charge due à un trafic élevé

• Tous les nœuds du cluster Consul ont été remplacés par des systèmes plus puissants (nombre de cœurs doublé, NVMe SSD plus rapides)

• La migration de Consul était presque terminée, mais le cluster ne revenait pas à un état normal

Tentative de restauration du service n°1 (29/10 02:00 – 04:00)

• Il a été décidé de revenir à un snapshot du cluster Consul datant d’avant la panne

• Les données utilisateur étaient intactes, et l’équipe a jugé acceptable de perdre une partie des données système

• Après la restauration du snapshot, l’accès a été bloqué via iptables, de peur qu’une charge provenant de systèmes communiquant en continu avec Consul ne provoque de nouveaux problèmes

• Après la restauration, les indicateurs semblaient meilleurs, mais dès que le blocage iptables a été levé, le système est retombé dans le même état de panne

Tentative de restauration du service n°2 (29/10 04:00 – 30/10 02:00)

• Le trafic externe a été bloqué et les usages non essentiels supprimés, si bien que des services qui tournaient sur des centaines d’instances ont été ramenés à un nombre à un chiffre

• Une nouvelle tentative de restauration a été effectuée, mais Consul est de nouveau entré dans un état anormal

• L’équipe a compris qu’il existait autre chose que les seuls facteurs de dégradation de performances initialement envisagés, et a commencé à regarder non plus Consul du point de vue de Roblox, mais l’intérieur même de Consul

Analyse de la contention (30/10 02:00 – 30/10 12:00)

• Après 10 heures d’analyse supplémentaires, il est apparu que les écritures Consul étaient bloquées pendant de longues périodes

• La cause de la contention restait inconnue, mais l’équipe a estimé que le passage initial de 64 à 128 cœurs CPU l’avait encore aggravée

• Il a été décidé de revenir à 64 cœurs, mais cela n’a pas aidé

Découverte de la cause racine (30/10 12:00 – 30/10 20:00)

• La fonctionnalité de streaming de Consul était activée depuis plusieurs mois et faisait l’objet d’un déploiement progressif, car elle réduisait l’utilisation CPU et la bande passante réseau.

• La veille de la panne, le 27 à 14:00, cette fonctionnalité a été activée sur le backend de routage du trafic.

• Comme elle avait bien fonctionné pendant une journée après son activation, elle n’a pas été considérée immédiatement comme la cause

• L’analyse des performances a ensuite montré des éléments prouvant que le code de streaming provoquait une forte charge CPU

• Après désactivation du streaming et fin du déploiement, il a été constaté que la latence d’écriture du KV de Consul diminuait (enfin !)

• Selon HashiCorp, le streaming est plus efficace, mais son implémentation utilisait moins d’éléments de contrôle de concurrence (canaux Go) que le long polling -> sous forte charge, cela a aggravé la contention sur un seul canal Go et réduit l’efficacité

• Une percée avait été obtenue, mais des élections de leader intermittentes continuaient d’être observées, et certains leaders présentaient encore des problèmes de latence comparables à ceux d’avant

• L’équipe a estimé que le cluster pouvait fonctionner normalement tant que certains leaders particuliers n’étaient pas élus, et s’est donc concentrée sur le retour du service à un état normal

• Par la suite, HashiCorp a poursuivi l’enquête sur la cause racine et a découvert que la lenteur de certains leaders était due à BoltDB

Restauration du service de cache (30/10 20:00 – 31/10 05:00)

• Au bout de 54 heures de panne, tout était prêt pour restaurer le service

• Pendant la panne, la base de données était restée intacte, mais le système de cache, qui traite 1 milliard de requêtes par seconde, était dans un état anormal.

• Une fois ce cache restauré et son bon fonctionnement confirmé, 61 heures s’étaient écoulées depuis le début de la panne.

Retour des utilisateurs (31/10 05:00 – 31/10 16:00)

• La préparation du retour du service a commencé le 31 à 5 heures et s’est terminée à 10 heures.

• Le nombre de joueurs accédant au service a été contrôlé via le DNS, puis augmenté progressivement sous surveillance

• Au bout de 73 heures, tous les joueurs ont de nouveau pu accéder au service.

Analyse complémentaire et changements apportés à la suite de la panne

• HashiCorp et Roblox ont développé un processus de « compression » pour résoudre les problèmes de performances

• Amélioration de la télémétrie : il existait une dépendance circulaire entre le système de télémétrie et Consul, ce qui entraînait un manque de données quand Consul rencontrait des problèmes. Cette dépendance circulaire a été supprimée afin que le système de télémétrie ne dépende plus des systèmes qu’il surveille

• Extension des zones de disponibilité et des data centers

• Nettoyage des données KV inutiles ou stockées dans Consul alors qu’il existait d’autres solutions de stockage.

• Test d’une nouvelle version de Consul remplaçant BoltDB par son successeur, bbolt

• La récupération a été retardée par le processus de bootstrap ; son automatisation est donc en cours, avec le développement de nouveaux outils et processus

[xguru]

Merci pour la traduction.

Une panne de 72 heures à cette échelle, c’est vraiment effrayant.