Support technique
Documentation
Connexion
Nous contacter
TuxCare BlogL'infrastructure en tant que code : Une épée à double tranchant
par Joao Correia
27 juin 2023 - Évangéliste technique
Dans un paysage technologique en constante évolution, la gestion d'environnements complexes est loin d'être une promenade de santé. Des équipes d'exploitation plus importantes et plus coûteuses à une normalisation plus stricte du matériel et des logiciels, de nombreuses stratégies ont été mises à l'épreuve. L'automatisation et les mots à la mode du moment ont tous eu leur heure de gloire.
Depuis un certain temps déjà, nous adoptons le paradigme de l'"infrastructure en tant que code" (IaC). Cette approche est évolutive, demande moins de ressources, s'intègre de manière transparente à d'autres outils et processus tels que le contrôle des sources et le suivi des modifications, et constitue un moyen plus efficace de gérer les exigences sans cesse croissantes du monde numérique d'aujourd'hui.
Cependant, comme toute chose, l'IaC n'est pas sans défaut. Nous avons des dizaines d'années d'expérience dans la gestion de l'infrastructure, mais c'est au niveau du "code" que les problèmes se posent. Si l'on en juge par le nombre de bogues, de correctifs, d'exploits, de primes aux bogues et d'autres activités connexes, il est clair que nous pouvons encore améliorer nos prouesses en matière de codage.
Lorsque, de manière anecdotique, différents progiciels sont comparés non pas pour leur performance ou leur fiabilité, mais pour le fait qu'ils sont tout aussi bogués que d'autres progiciels ou versions. par le fait qu'ils sont tout aussi bogués que d'autres progiciels ou d'autres versionsen traitant l'infrastructure comme du code, on introduit inévitablement ces mêmes bogues et problèmes dans l'infrastructure elle-même. Le récent incident survenu chez Azure en est un bon exemple.
La panne d'Azure : Une étude de cas dans l'IaC
Il y a quelques jours, un incident survenu chez Azure a touché des clients dans le sud du Brésil. En tant que fournisseur majeur de services en nuage, Azure souscrit à la devise "everything is code" (tout est du code), permettant à la configuration des services, des serveurs, des bases de données, des points de terminaison, des sauvegardes, etc. d'être gérée comme du code. Cette philosophie s'étend à l'aspect gestion d'Azure, et pas seulement au nuage orienté client, où les administrateurs système traitent tout comme du code, permettant l'automatisation de chaque opération.
Il y a quelques jours, Azure a testé un changement dans les composants de gestion. L'objectif était de remplacer certains anciens composants par des plus récents, ce qui impliquait de supprimer certains paquets NuGet et d'en installer de nouveaux. Dans le cadre de la modification des paquets NuGet, le code qui y fait référence a également dû être légèrement modifié - les noms des paquets étaient différents et certaines conventions d'appel ont été modifiées. Il ne s'agissait pas exactement d'un remplacement immédiat.
Les changements ont été scénarisés, validés, revus, testés, puis déployés dans un environnement de test connu sous le nom de "Ring 0" chez Azure-land, un peu comme le nom du mode avec les privilèges les plus élevés. Une fois que tout s'est bien passé dans l'anneau 0, les changements ont été déployés dans l'anneau 1, l'environnement de production visible par les clients.
Cependant, Ring 0, comme de nombreux environnements de laboratoire ou de test, est une version réduite de l'environnement de production, sans la même charge, la même base d'utilisateurs ou les mêmes interactions complexes entre les systèmes.
Il est intéressant de noter qu'une tâche relativement routinière que les administrateurs Azure effectuent en production consiste à créer des instantanés de bases de données en cours d'exécution afin de les déboguer sans affecter les charges de travail ou les clients réels. Étant donné qu'il n'est pas nécessaire de créer des instantanés dans un environnement de laboratoire dépourvu de bases de données et de problèmes de production réels, l'anneau 0 était exempt d'instantanés.
L'une des modifications apportées aux paquets NuGet concerne les fonctions de gestion des instantanés.
En interne, Azure exécute une tâche d'arrière-plan pour supprimer périodiquement les anciens clichés. Comme il n'y avait pas d'instantanés dans l'anneau 0, il n'a jamais tenté d'en supprimer pendant la phase de test. Cependant, dans l'environnement de production, où des snapshots existaient, la tâche d'arrière-plan s'est exécutée avec les modifications du paquet NuGet, et ce qui était auparavant un appel à la suppression d'un instantané s'est transformé en un appel à la suppression d'une base de données serveur.
À l'instar d'un accident de voiture à évolution lente, lorsque la tâche a été exécutée, tous les serveurs de base de données disposant d'un instantané suffisamment ancien ont été supprimés, tandis que tous les services ne répondaient plus à la demande.
Les conséquences de la panne d'Azure
La suppression du serveur a déclenché une chaîne d'événements tangentiellement liés :
- Dans Azure, un client ne peut pas restaurer lui-même un serveur supprimé. Cette opération doit être effectuée par l'équipe d'assistance d'Azure.
- Tous les serveurs concernés n'avaient pas le même type de sauvegarde, ce qui a entraîné des variations dans la vitesse de restauration. Certains étaient stockés dans la même région (lire : centre de données), tandis que d'autres étaient géographiquement redondants, ce qui signifie qu'ils étaient stockés dans différentes régions Azure. Les données devaient être transférées avant la restauration. Cela a augmenté le temps de récupération.
- Il a été découvert que certains serveurs web qui dépendaient des serveurs de base de données supprimés effectuaient un test au démarrage pour déterminer quelles bases de données étaient disponibles et accessibles. Ces requêtes étaient adressées à tous les serveurs de base de données et avaient pour effet involontaire d'interférer avec le processus de récupération des serveurs de base de données. En outre, lorsque le test échouait, les serveurs web déclenchaient immédiatement un redémarrage. Ce qui s'est produit. Et cela s'est reproduit. Et encore, car ces bases de données n'étaient pas disponibles pendant une période prolongée.
- Par mesure de précaution, une technique appelée backoff est employée lorsqu'un test échoue. Cela signifie que lorsqu'un test est tenté et qu'il échoue, la période de temps avant la prochaine tentative continue d'augmenter. Cette augmentation peut être linéaire ou exponentielle, et l'idée est de donner suffisamment de temps à l'autre partie pour se remettre de la situation qu'elle vit sans avoir à gérer de telles demandes de test. Dans ce cas précis, cela a eu pour conséquence involontaire de faire durer les redémarrages plus d'une heure, alors qu'ils ne prendraient normalement que quelques secondes.
- La restauration des sauvegardes était lente car l'infrastructure était submergée de demandes.
- Dès que quelques serveurs ont été rétablis, ils ont été rapidement submergés par le trafic des clients.
Pour permettre à tous les serveurs de revenir en ligne, tout le trafic a dû être interrompu jusqu'à ce que tous les serveurs soient rétablis. Ce pic de trafic a rendu la panne (pour les clients des locataires Azure concernés) plus longue qu'elle ne l'aurait été autrement.
Le résultat ? Environ 10 heures de temps d'arrêt, des interruptions d'activité et une foule de clients frustrés.
Et tout cela est né de la mise à jour de quelques paquets de code. Ce n'est pas un piratage, ou un incendieou d'un autre risque.
Apports et leçons tirées de l'expérience
Il est essentiel de disposer d'un environnement de test robuste, capable de reproduire la production aussi fidèlement que possible. Les répliques exactes sont difficiles à réaliser, se désynchronisent facilement et sont difficiles à maintenir. Mais les environnements de test trop simplistes sont essentiellement inutiles, car ils ne présentent pas les défis nécessaires auxquels l'environnement de production est confronté.
Des stratégies efficaces de sauvegarde et de restauration sont cruciales. Les sauvegardes doivent non seulement être disponibles, mais aussi avoir été testées dans des scénarios de restauration réels.
L'erreur humaine est un défi permanent dans le développement de codes. Nous devons reconnaître qu'il est possible de négliger des interactions critiques et des bogues potentiels dans des systèmes très complexes. En fait, il n'est même pas nécessaire que les systèmes soient aussi complexes pour que les humains n'aient pas la capacité d'en saisir toutes les subtilités et les interactions. Le codage dans cette situation conduit inévitablement à des problèmes.
Le nuage, bien que révolutionnaire, n'est pas à l'abri des défaillances. Les erreurs humaines, les pépins logiciels et les défaillances matérielles peuvent se produire et se produisent effectivement. De manière répétée et inattendue. Et si Murphy a son mot à direau pire moment possible.
Sur une note plus positive, l'incident a mis en évidence la ténacité des équipes d'assistance et d'exploitation d'Azure, qui sont parvenues à restaurer les ressources supprimées sans perte de données dans un délai relativement court. Cela souligne que si la gestion de grandes infrastructures, en particulier sous forme de code, est un défi, la véritable mesure d'un service est la rapidité avec laquelle il réagit et corrige un problème après un faux pas.
En conclusion, il est toujours judicieux d'automatiser autant que possible, en veillant à ce que l'environnement de test reflète le plus fidèlement possible l'environnement de production. De tels incidents nous rappellent qu'il faut prendre en compte les vulnérabilités potentielles de nos environnements avant qu'elles ne conduisent à des défaillances.
Il est également important d'automatiser d'abord les tâches triviales - par exemple, le déploiement automatique des correctifs, le déploiement automatique de correctifs - ce qui permet de se concentrer sur des opérations plus complexes qui exigent un niveau d'attention plus élevé. Cela permet de libérer la seule ressource que l'informatique en nuage ne peut pas moduler (la matière grise) pour des tâches plus importantes.
