GitHub a terminé son enquête interne sur les causes des multiples interruptions de service qui a affecté son service en février dernier pendant plus de huit heures. La cause première de cette situation était une combinaison de variations inattendues de la charge de la base de données et de problèmes de configuration de la base de données.
Tous les incidents ont affecté le cluster de base de données principal de GitHub, mysql1, qui était à l'origine le seul cluster MySQL de GitHub.
Au fil du temps, alors que mysql1 devenait plus grand et plus occupé, nous avons divisé les ensembles de tables fonctionnellement groupés en nouveaux clusters et créé de nouveaux clusters pour de nouvelles fonctionnalités. Cependant, une grande partie de notre ensemble de données de base réside toujours dans ce cluster d'origine.
Le premier incident s'est produit lorsque les ingénieurs de GitHub ont envoyé par inadvertance une requête gourmande en ressources contre le maître de la base de données au lieu de ses réplicas en lecture seule. En conséquence, ProxySQL, qui est responsable du regroupement des connexions, a été surchargé et a commencé à traiter les requêtes de manière incohérente.
Un problème similaire s'est produit deux jours plus tard en raison d'une promotion planifiée de la base de données maître visant à enquêter sur les problèmes potentiels lorsqu'un maître passe en lecture seule pendant un certain temps. Cela a également généré une charge inattendue et une défaillance similaire de ProxySQL.
Dans les deux cas, la réduction de la charge a suffi à corriger la panne.
Le troisième incident a été plus critique, car il a duré plus de deux heures. Dans ce cas encore, ProxySQL était le point d'échec en raison d'une connexion de base de données active franchissant un seuil donné.
Le problème majeur dans ce cas était lié au fait que les connexions actives sont restées au-dessus du seuil critique après la correction, ce qui a fait entrer le système dans un état de service dégradé. Il s'est avéré que ProxySQL n'était pas configuré correctement et en raison d'un conflit entre le LimitNOFILE à l'échelle du système et le processus local, la définition de sa limite de descripteur a été rétrogradée à 65536.
Le quatrième incident a été provoqué par un changement dans la logique d'applications de GitHub. Cette modification a généré des requêtes qui ont rapidement augmenté la charge sur le maître mysql1, ce qui a affecté tous les services dépendants.
Selon les ingénieurs de GitHub, tous les problèmes étaient faciles à résoudre une fois leur root cause identifiée, mais l'interaction entre les systèmes n'était pas toujours immédiate à comprendre. Par conséquent, expliquent-ils, un premier domaine d'amélioration a été l'observabilité, suivi d'une intégration plus approfondie du système et de tests de performances avant le déploiement en production.
Pour aller au cœur du problème, cependant, il faut améliorer le partitionnement des données dans le but de réduire la charge sur le maître du cluster mysql1, selon les ingénieurs de GitHub. Cela aiderait à répondre à l'exigence de zéro temps d'arrêt et de réduire l'impact sur les utilisateurs de tout incident futur.
En particulier, ils ont travaillé sur une seule table, la table abilities, qui est utilisée avec toute demande d'authentification et est donc centrale pour les performances. Après deux mois de travail, la table abilities s'exécute désormais dans son propre cluster, ce qui nécessitait auparavant de la rendre indépendante (lecture, JOIN-free) de toute autre table du système. Grâce à ce changement uniquement, la charge sur le maître du cluster mysql1 a été réduite de 20%, selon les ingénieurs de GitHub.
Alors que l'effort de partitionnement de leur base de données se poursuivra, dans le but de réduire davantage de 60% la charge d'écriture sur le cluster mysql1 et d'en retirer 12 schémas de domaines, les ingénieurs de GitHub ont également identifié un certain nombre d'autres initiatives pour améliorer les choses. Il s'agit notamment de réduire le nombre de lectures à partir d'un maître lorsque les mêmes données sont disponibles à partir de répliques; utiliser des indicateurs de fonctionnalité pour désactiver les modifications de code qui pourraient s'avérer problématiques; l'amélioration du tableau de bord interne de GitHub pour mieux identifier les problèmes de déploiement; et en utilisant sharding pour améliorer l'évolutivité horizontale.