Une mise à jour mineure, des conséquences plus importantes
L’incident global a commencé après que nous ayons lancé une mise à jour mineure de maintenance d’Apache Pulsar (3.3.1). Elle activait un nouvel algorithme d’équilibrage pour l’optimisation du placement des bundles, qui a causé des problèmes. Nous l’avons rapidement détecté, avons conservé la version 3.3.1 et annulé la configuration défectueuse.
Le problème initial, bien que résolu, a entraîné un conflit de métadonnées. Nous avons dû arrêter tous les brokers de messagerie pour n’en démarrer qu’un seul, afin d’éviter tout conflit de métadonnées entre eux, et avons réussi à revenir à une situation nominale. Mais par la suite, notre infrastructure a subi une pression sur les entrées/sorties (E/S) et la mémoire, provoquant le plantage de certains hyperviseurs.
L’indisponibilité de la couche de messagerie Apache Pulsar a entraîné la mise en mémoire tampon de certains agents de télémétrie sur les machines virtuelles (VM) fonctionnant sur des hyperviseurs (HV). Elle a commencé alors que les endpoints du service de messagerie étaient indisponibles.
Les limites de nos plus petites machines virtuelles
Les petites machines virtuelles ont rapidement atteint une limite de mémoire, déclenchant une forte pression sur le noyau. Lorsque cela se produit, le noyau tente de vider la mémoire et les caches, de supprimer les processus de la mémoire pour les charger instruction par instruction à partir du disque. Cela génère une forte pression sur les E/S disque de l’hyperviseur sous-jacent. Quelques minutes après l’augmentation de la charge des HV, nous avons commencé à observer des “paniques” du noyau sur certains d’entre eux.
Les petites machines virtuelles étant réparties globalement entre nos zones de disponibilité, nous nous sommes retrouvés avec une infrastructure de serveurs surchargée. Alors que nous avions besoin du scheduler pour gérer la situation, le control plane ne fonctionnait pas de manière optimale et l’infrastructure avait du mal à fournir les ressources disponibles.
Nous avons donc dû arrêter tous les services non critiques et notre équipe SRE a redéployé une à une les petites machines virtuelles surchargées. Nous avons alors commencé à reprendre le contrôle de tous les hyperviseurs et avons pu ramener notre infrastructure à son état optimal.
Les prochaines étapes
Pour les versions non mineures, nous utilisons un processus de simulation qui émule un environnement complet dans lequel nous injectons des changements. Cela permet de valider les mises à jour et les changements en observant le comportement de l’infrastructure avant de passer en production. Ce processus n’était pas utilisé pour les mises à jour de maintenance mineures ou les (apparemment) petits changements du profil de configuration.
Cet incident nous a beaucoup appris et nous avons identifié quelques domaines de progrès concernant nos images, la configuration et l’intégration des outils, ou la configuration des petites machines virtuelles. Nous avons pris des mesures immédiates et travaillerons sur des sujets plus approfondis dans les semaines à venir.
Nous nous excusons sincèrement pour les désagréments que cet incident a pu causer. Votre confiance est primordiale pour nous, et nous nous engageons à vous fournir le plus haut niveau de fiabilité de service. Vous pourrez en apprendre plus sur le calendrier et l’analyse technique de l’incident dans notre post-mortem public.
Si vous avez des questions ou des inquiétudes, n’hésitez pas à contacter notre support.