Analyse de la Panne AWS DynamoDB et Critique des RCA

Principaux Sujets Abordés

• Compréhension réelle contre apparente : Discussion sur la pression sociale en programmation qui pousse à prétendre comprendre des sujets complexes, et l'importance de poser des questions "bêtes" pour acquérir une véritable expertise.
• La panne AWS DynamoDB d'octobre : Analyse technique détaillée de l'incident, basée sur la présentation "re:Invent" et le rapport d'analyse des causes racines (RCA) publié par AWS.
• Critique des rapports d'incident (RCA) : Argument selon lequel la plupart des RCA (y compris celui d'AWS) expliquent la chaîne d'événements logiques mais échouent à expliquer le véritable "bug" au niveau du code.

Points Clés et Arguments

• Architecture du système de répartition de charge (Load Balancing) :

  • DynamoDB utilise des points de terminaison API (ex: dynamodb.us-east-1.api.aws) qui redirigent vers un "arbre DNS" pour répartir la charge sur différentes machines.
  • Le système utilise des "Plans" (ex: plan-145, plan-146) qui sont des configurations temporaires de l'arbre DNS.
  • Le processus est divisé en deux entités :
    • Le Planner (Planificateur) : Il y en a un seul. Il génère continuellement de nouveaux plans mais ne les applique pas.
    • Les Enactors (Exécuteurs) : Il y en a trois. Ils prennent les plans du Planner et les appliquent dans Route 53 (le système DNS).

• Le mécanisme de verrouillage (Locking) :

  • Pour éviter les conflits, les Enactors utilisent un système de sérialisation via des verrous (locks).
  • Le "verrou" est lui-même un enregistrement DNS. Si un Enactor n'obtient pas le verrou, il attend (back-off).

• La séquence de l'incident (Ce que le RCA explique) :

  1. Une condition de concurrence (race condition) s'est produite. Un Enactor a tenté d'appliquer un vieux plan (ex: Plan 110) mais a été bloqué longtemps.
  2. Pendant ce temps, le système a avancé vers un plan plus récent (ex: Plan 145).
  3. L'Enactor bloqué a finalement obtenu le verrou et a appliqué le vieux Plan 110.
  4. Simultanément, un processus de nettoyage a supprimé le Plan 110 car il était considéré comme trop vieux.
  5. Résultat : Le point de terminaison principal de DynamoDB pointait vers un enregistrement DNS supprimé (Plan 110), rendant le service inaccessible.

• Le véritable bug selon Casey (Ce que le RCA n'explique pas) :

  • Le fait de pointer vers un enregistrement vide n'aurait dû causer qu'une panne temporaire jusqu'à ce qu'un autre Enactor applique un nouveau plan. Or, la panne a persisté.
  • Le problème réel réside dans le mécanisme de Rollback (Retour en arrière).
  • Avant d'appliquer un nouveau plan, un Enactor tente de mettre à jour un enregistrement de "rollback" pour qu'il pointe vers l'ancien plan actif.
  • Lorsque les Enactors ont essayé de mettre à jour le système après l'erreur, ils ont tenté de lire l'ancien plan (Plan 110, qui avait été supprimé).
  • Le code n'a pas géré l'absence de cet enregistrement. Au lieu d'échouer proprement, l'Enactor a planté complètement (hard crash).
  • Les trois Enactors ont fini par planter l'un après l'autre en rencontrant cette erreur, arrêtant toute mise à jour du système DNS.

Détails Importants et Données

• Redondance inefficace : Bien qu'il y ait trois Enactors pour la redondance, ils exécutent tous le même code. Par conséquent, ils ont tous rencontré la même exception fatale face à l'état corrompu du système.
• Nature du crash : Casey soupçonne une erreur de type "exception non gérée" (comme un unwrap en Rust sur une valeur nulle) qui fait exploser le processus lorsqu'il suppose qu'une donnée existe alors qu'elle est absente.
• Inutilité relative de la "Race Condition" : L'analyse officielle se concentre sur la condition de concurrence. Casey soutient que même sans cette condition, si un administrateur avait supprimé un enregistrement par erreur, le même bug de gestion d'erreur aurait fait tomber tout le système.

Conclusions

• Le véritable "Root Cause" n'est pas la condition de concurrence complexe qui a mené à l'état invalide, mais la fragilité du code qui a causé un crash complet des serveurs de gestion lorsqu'ils ont rencontré cet état invalide.
• Un bon RCA devrait montrer le code défaillant (ex: "nous avons supposé que X ne serait jamais null, et le programme a quitté ici") plutôt que de simplement raconter l'histoire des événements.
• L'explication officielle d'AWS semble incomplète, voire suspecte, car elle masque la mauvaise qualité du code de gestion d'erreur derrière une explication complexe sur la synchronisation des processus.