Le 8 mars dernier, Datadog a subi une panne sévère qui a rendu son service d'observabilité délivré en mode SaaS indisponible pendant environ 24 heures. L'incident a coûté 5 M$ à l'éditeur, soit le chiffre d'affaires d'environ une journée pour la société fondée en 2010 par deux centraliens, Olivier Pomel et Alexis Lê-Quôc. Reste à savoir comment ce qui reste aujourd'hui comme la seule panne globale du service a pu se produire, alors que Datadog repose sur une architecture massivement multicloud (le service tourne sur cinq régions hébergées chez les trois principaux hyperscalers, AWS, GCP et Azure). C'est ce que tente de décrypter la newsletter The Pragmatic Engineer dans sa dernière édition, suivie quelques heures après par un billet de blog posté sur le site de l'éditeur par son co-fondateur, Alexis Lê-Quôc.

La panne trouve son origine dans l'application d'une mise à jour système appliquée à Ubuntu, OS installé sur des dizaines de milliers de noeuds Kubernetes. Des machines qui, mystérieusement, disparaissent du réseau une fois le patch appliqué. Une demi-heure après le début de cette mise à jour, le 8 mars, la panne est officialisée sur le site de support de l'éditeur. Les services seront restaurés le lendemain, près de 27 heures après, même si l'intégralité du service ne sera en réalité opérationnel que le lendemain, près de 48 heures après le début de l'incident.

Une architecture présentant une dépendance circulaire

Dans le détail, le déploiement de la dernière version d'Ubuntu se traduit par une mise à jour de sécurité de systemd, le premier processus à être lancé après le chargement du noyau Linux. Mais, selon l'analyse de The Pragmatic Engineer, la panne trouve son origine non pas dans la nature des patchs, mais dans son application automatique, impliquant un redémarrage de Linux, du processus systemd et de tous ses sous-processus, dont celui gérant le réseau. L'application automatique de la mise à jour de sécurité de systemd « a provoqué une interaction négative avec la pile réseau », reconnaît Alexis Lê-Quôc dans son billet de blog, le redémarrage du processus systemd-networkd se traduisant par l'effacement des routes réseau gérées un plugin CNI (Container Network Interface) de Cilium, utilisé par Datadog pour gérer les communications entre conteneurs. C'est cet effacement qui a mécaniquement entraîné la mise hors ligne des noeuds. Un mécanisme que Datadog a manifestement eu du mal à caractériser. « Le facteur aggravant est que ni un noeud neuf ni un noeud redémarré ne présente ce comportement car, lors d'une séquence de démarrage normale, systemd-networkd démarre toujours avant que les règles de routage ne soient installées par le plugin CNI. En d'autres termes, en dehors du scénario de mise à jour de systemd-networkd sur un noeud en fonctionnement, aucun test ne reproduisait la séquence exacte », écrit le co-fondateur de l'éditeur pour justifier la durée de la panne.

Ce problème initial a ensuite provoqué une réaction en chaîne. « Dans une forme de dépendance circulaire, la réinitialisation a également mis hors ligne le plan de contrôle du routage réseau », écrit The Pragmatic Engineer. Tout simplement parce que parmi les environnements virtuels mis hors ligne par le bug figuraient ceux gérant le plan de contrôle (Control Plane), basés sur Cilium. « La plupart des clusters Kubernetes que nous utilisons pour faire fonctionner notre plateforme étaient donc incapables de lancer de nouveaux workloads, de les réparer automatiquement et de les mettre à l'échelle automatiquement », reconnaît Datadog dans son analyse post-mortem. Un autre facteur expliquant la durée de l'interruption de service subie par les clients de l'éditeur. « Si le plan de contrôle n'avait pas été affecté, la panne aurait probablement été brève. Dans ce cas, Datadog aurait pu simplement remonter les noeuds disparus en utilisant le plan de contrôle », écrit The Pragmatic Engineer.

Les failles du plan de résilience

Reste une question essentielle : pourquoi cette panne s'est-elle étendue à l'ensemble de l'infrastructure alors que Datadog prend des mesures pertinentes en matière de résilience ? En particulier une politique d'application progressive des patchs, « région par région, cluster par cluster et noeud par noeud », et l'emploi de plusieurs prestataires de cloud (les trois principaux en l'occurrence). Pour la newsletter spécialisée, cette propagation rapide résulte du choix de l'éditeur d'utiliser ses prestataires cloud comme une couche IaaS et d'employer la même image OS sur l'ensemble de ces environnements. Une image renfermant « un canal Legacy de mise à jour de sécurité, qui a provoqué l'application automatique des patchs », selon l'analyse postmortem de l'éditeur. Un détail qui a fini de rendre inopérantes les précautions prises par Datadog, l'update provoquant l'effondrement de l'architecture Kubernetes s'étant de ce fait déployé sur toutes les machines virtuelles en moins d'une heure, malgré l'absence de lien réseau direct entre les régions cloud. De façon intéressante, le choix de miser sur plusieurs hyperscalers a d'ailleurs plutôt compliqué le redémarrage de Datadog, celui-ci devant gérer les logiques différentes des prestataires (en particulier dans la gestion des noeuds affectés par la panne).

Dans son billet de blog, le co-fondateur de l'éditeur détaille les mesures qui ont été prises pour éviter qu'un tel incident ne se reproduise. A commencer, évidemment, par la désactivation du canal de mise à jour automatique dans l'image Ubuntu. Datadog a également modifié la configuration de systemd-networkd afin de ne pas réinitialiser la table de routage lors des redémarrages. « Nous avons construit les régions de Datadog avec l'objectif explicite d'être autonomes et résilients aux défaillances locales. [...] Pourtant, nous n'avons pas réussi à imaginer comment ces services pouvaient rester indirectement liés, et cette lacune influencera la manière dont nous continuons à renforcer notre infrastructure », reconnaît Alexis Lê-Quôc.