Un effondrement de système distribué peut commencer par une erreur qui semble limitée, mais se transformer rapidement en une série de pannes lorsque de nombreux composants dépendent les uns des autres. Lors d’une présentation donnée par Sam Newman, consultant indépendant en ingénierie logicielle, celui-ci établit un lien entre le concept d’effondrement progressif (Progressive Collapse) dans le génie civil et les problèmes de résilience des systèmes numériques. Il conclut qu’il est impossible d’empêcher toutes les erreurs, mais qu’il est possible de réduire les risques de propagation et leur impact.
Du bâtiment de Ronan Point aux services cloud
Newman revient sur l’effondrement partiel d’une tour de Ronan Point, dans le quartier de Canning Town à Londres, en 1968. Une explosion de gaz limitée dans l’appartement de Mrs. Ivy Hodge a arraché un mur extérieur qui soutenait une partie du bâtiment. Les quatre étages situés au-dessus du lieu de l’explosion se sont effondrés, puis une partie de l’angle de la tour est tombée par effet en cascade. Quatre personnes sont mortes, et l’heure de l’accident, peu avant six heures du matin en 1968, a contribué à limiter le nombre de victimes.
Pour les logiciels, l’intérêt ne réside pas dans la ressemblance matérielle entre un bâtiment et un service numérique, mais dans le schéma de défaillance : une petite panne initiale perturbe un composant dont dépendent d’autres composants, ce qui étend le cercle des dommages. Cette chaîne est difficile à comprendre dans les systèmes distribués, car les relations entre les services, les bases de données, les équilibreurs de charge et les systèmes DNS ne sont pas toujours visibles comme une rangée de dominos.
Exemples numériques de défaillances en cascade
Lors de la panne de la région us-east-1 d’AWS en octobre, un sous-composant de DynamoDB a rencontré un problème lors de la mise à jour des routes DNS au sein de l’infrastructure AWS. Une défaillance du processus de mise à jour des plans a entraîné la suppression de routes dans Route 53. Des services dépendant de ces routes ont alors commencé à tomber en panne, notamment les équilibreurs de charge réseau, le calcul, les files d’attente et EKS. Comme ces services fondamentaux sont utilisés par d’autres services, le problème s’est propagé à des produits et à des entreprises destinés aux utilisateurs, parmi lesquels Alexa, Ring, Slack, Snapchat, Zoom et Shopify, certains étant partiellement touchés et d’autres totalement indisponibles.
Selon l’explication de Newman fondée sur le rapport d’AWS, le système comprenait un planificateur qui créait des plans de modification DNS ainsi que plusieurs exécuteurs chargés de les appliquer. L’un des plans a pris plus de temps que d’habitude, puis un autre plan, exécuté par un exécuteur différent, a été créé et appliqué rapidement. Lorsque l’ancien plan a finalement été appliqué, il a supprimé les routes que le nouveau plan avait créées. Le résultat a été une condition de concurrence (Race Condition) qui a entraîné la suppression d’entrées DNS.
Le deuxième exemple concernait un site de vente de voitures d’occasion, de motos et de remorques, qui fonctionnait au moyen d’une application portant le nom de code Sauron sur dix serveurs. L’application traitait habituellement entre 30 et 60 requêtes simultanées, mais elle en a reçu plus de 800. L’un des sites dépendants acceptait les connexions puis se bloquait sans répondre, tandis que l’application attendait 30 secondes avant de mettre fin à la requête. Le pool de connexions a été épuisé, puis les threads se sont accumulés et les processeurs ont consacré leur temps à les gérer, ce qui a entraîné l’arrêt complet du système. Les utilisateurs ont aggravé la pression en appuyant à plusieurs reprises sur le bouton d’actualisation.
Trois voies pour réduire l’effondrement
Newman estime que se concentrer sur une seule « cause racine » conduit à une simplification excessive. Empêcher l’étincelle peut être utile, mais cela ne traite pas toutes les conditions qui permettent au feu de se propager. L’ingénierie de la résilience consiste donc à accepter la possibilité de pannes et à se préparer à en limiter les effets au moyen de trois catégories interdépendantes :
- Réduire les risques : éliminer les sources de danger ou limiter leur capacité à épuiser les ressources. Dans le cas d’AWS, cela a notamment consisté à suspendre temporairement la gestion automatisée du DNS jusqu’à la résolution du problème et à ajouter de meilleurs tests pour le composant. Dans l’application Sauron, il aurait été possible d’utiliser le délestage de charge (Load Shedding) afin d’accepter un nombre déterminé de requêtes et de refuser celles qui dépassaient la capacité du système, plutôt que de les laisser s’accumuler jusqu’à l’effondrement.
- Renforcer les composants : accroître la capacité du service à supporter la défaillance d’une partie de celui-ci grâce à la redondance, à la surveillance, aux tests et à l’amélioration de l’implémentation. Cela peut signifier exécuter plusieurs instances du service derrière un équilibreur de charge, mais la décision dépend de l’importance du composant et de son coût. L’application Sauron était alors en cours de retrait et ne représentait qu’une partie des revenus, ce qui rendait l’exploitation d’instances de secours supplémentaires commercialement peu attrayante à ce moment-là.
- Réduire les interdépendances : empêcher la panne d’un composant de se propager au reste du système. Cela comprend l’utilisation de compartiments (Bulkheads), de limites de délai, de chemins alternatifs et de conceptions locales par défaut lorsque cela est possible. Moins une partie du système dépend d’une autre, plus il est possible de contenir la panne au lieu de la propager.
Qu’est-ce qui change concrètement pour les équipes techniques ?
La résilience ne signifie pas automatiquement faire fonctionner le système dans deux régions ou deux clouds. Newman explique que les options vont de la sauvegarde et de la restauration à l’architecture Pilot Light, qui réplique les données sans exécuter l’intégralité de l’infrastructure, puis à la reprise à chaud, jusqu’à l’exploitation simultanée de deux sites actifs. Ces options réduisent progressivement le temps d’arrêt et la perte de données, mais elles augmentent le coût et la complexité.
Il met également en garde contre l’idée que la synchronisation bidirectionnelle entre les sites serait simple, en particulier lorsqu’elle est ajoutée à une application existante qui n’a pas été conçue pour cela. Il en va de même pour le multicloud : celui-ci peut réduire la dépendance à un seul fournisseur, mais il exige des compétences et une exploitation différents pour chaque plateforme. Il ne suffit pas de déployer le même code sur AWS et Azure pour garantir l’indépendance, car le même défaut logiciel peut mettre les deux environnements hors service.
Conclusion
La leçon essentielle est que la résilience ne consiste pas à rechercher un environnement qui ne tombe jamais en panne, mais à concevoir le système de façon qu’une partie reste opérationnelle lorsqu’une autre partie tombe en panne. Il faut donc évaluer les risques, les limites de capacité, les points d’étranglement, les chemins de dépendance, puis trouver un équilibre entre redondance, isolation et coût. Les décisions telles que l’exploitation multirégion ou multicloud restent des choix techniques et commerciaux liés à l’importance du service, et non une recette générale applicable à tous les systèmes.