Mercredi 12 octobre, les plateformes Whaller ont été inaccessibles de 4h CET à 7h CET puis de 9h CET à 11h CET. Les sites renvoyaient à l’utilisateur une erreur HTTP 500.
Un grand nombre de demandes de suppressions automatiques de comptes asynchrones ont été exécutées à partir de 02:00 CET conduisant à une surcharge mémoire des serveurs MySQL.
Le système a automatiquement “tué” (killed) les services MySQL (OOM), puis les a redémarré. Whaller a une base de données en cluster répartie sur 5 nœuds. Il faut au moins 3 nœuds pour fonctionner.
A 03:38 CET, une majorité de noeuds sont devenus inaccessibles, et l’intégrité du cluster n'était plus assurée, ce qui a rendu inaccessible la base de données, et provoqué un arrêt de service.
A 07:10 CET, nos équipes ont remonté 3 nœuds, et le service a été à nouveau accessible. Cependant les suppressions automatiques n'étaient pas terminées, et ont repris, ce qui a provoqué des instabilités dues à la charge qui recommençait à s’appliquer de façon anormale sur les serveurs de base de données et aux désynchronisations qu’elle provoquait.
Deux heures plus tard, à 08:50 CET, le cluster est à nouveau tombé, sur le même schéma que la nuit.
Nous n’avions pas encore compris la source du problème.
L'équipe technique a alors pris la décision de reconstruire chacun des nœuds à partir de l’un des nœuds.
Cette opération de re-création (et non pas de redémarrage) a pris 2 heures de temps. Et la production a été de nouveau accessible à 11:00, avec 3 nœuds.
Entre temps, nous avons compris la source du problème et avons supprimé les instructions de suppressions automatiques de compte, qui par ailleurs étaient illégitimes et ne concernaient qu’un seul client que nous avons prévenu immédiatement. Les comptes supprimés sont en cours de restauration.
A 20:30 CET, l’ensemble des 5 nœuds étaient à nouveau opérationnels.
Par la suite, l’ensemble des données des moteurs de recherche ont été réindexées, et l’ensemble des systèmes de cache réinitialisés.
Nous avons identifié la cause profonde de la surcharge mémoire et avons pris les mesures de correction nécessaires. Il s’agit de modifier la façon dont sont stockées les indicateurs de messages non lus. En effet, cette table dans notre base est trop volumineuse (200 millions de lignes). Deux principes sont désormais appliqués : l’expiration des indications de messages non lus au bout d’un certain temps, et le découpage vertical ou partitionnement des données de cette table (“sharding”).
D’autres mesures secondaires ont également été prises : le changement de priorité de OOM afin de ne pas tuer les services MySQL au regard d’autres services, l’augmentation de la mémoire vive sur l’ensemble des 5 nœuds, la mise en place d’indicateurs d’alertes qui permettront de voir arriver un éventuel futur problème similaire.
Durant les deux dernières années, nos utilisateurs ont subi 6 heures d’interruption de service cumulées, dont 5 heures le 12 octobre 2022. C’est un incident majeur pour vous et pour nous.
Nous vous prions de bien vouloir accepter nos sincères excuses. Nous vous garantissons qu’aucune donnée n’a été perdue ou altérée et nous vous assurons de notre entier dévouement.
Pour tout renseignement complémentaire, vous pouvez nous contacter sur contact@whaller.com.