Contexte et observation
L’auteur utilise des animations pour rendre visibles des comportements métastables dans des systèmes distribués. Un exemple clé montre qu’un cluster Raft peut perdre des écritures dès qu’un seul des membres fournit une réponse fausse à l’appel fsync(). Cette perte n’est pas théorique : les traces proviennent d’un environnement de test réel, capturées avec les outils Kiro et KiroCrew (version Opus 5.5).
Mécanisme de perte d’écritures dans Raft
Raft repose sur la réplication synchrone : chaque entrée de journal doit être confirmée par un quorum avant d’être considérée comme committée. Si un nœud indique que l’opération fsync() a été persistée alors qu’elle ne l’est pas, le leader peut avancer le commit malgré l’absence de garantie de durabilité. Le résultat est une perte de données lorsque le nœud fautif redémarre ou subit une panne d’alimentation. Le problème découle d’une incohérence entre la couche de stockage et le protocole de consensus, et il apparaît même avec des implémentations conformes aux spécifications de Raft.
Illustrations avec PostgreSQL et etcd
Dans un test réalisé sur PostgreSQL 16 exécuté dans une micro‑VM, le système supporte 20 requêtes / s tant que l’ensemble du jeu de données reste en cache page. Chaque requête consomme environ 12 Mo de mémoire. Un pic de charge remplit la RAM disponible, contraint le moteur à évincer des pages vers le disque et augmente le temps de latence d’écriture. Cette transition du cache vers le disque montre que même un SGBD monolithique peut entrer dans un état métastable où les performances se dégradent brutalement.
Un scénario similaire est reproduit avec etcd. Le service gère 500 lectures / s avant un pic qui porte la charge à 1000 reads / s. L’augmentation du travail de garbage collection (GC) allonge la durée moyenne des cycles de GC, ce qui augmente la «tenure» des objets en mémoire et réduit la part de CPU disponible pour le traitement des requêtes. Le résultat est une boucle d’auto‑renforcement : plus de GC ralentit le service, ce qui génère davantage de requêtes en attente, ce qui alourdit encore le GC. Sans intervention manuelle, le système ne retrouve pas son état initial.
Implications et limites
Ces observations soulignent que les tests de charge doivent inclure des scénarios de saturation de la mémoire et de falsification de la persistance. La perte d’écritures dans Raft indique que la robustesse du consensus dépend de la fiabilité de la couche de stockage sous‑jacente. De même, les effets de la GC sur etcd démontrent que les systèmes sans GC ne sont pas immunisés ; l’allocation dynamique peut produire des effets analogues, bien que l’auteur n’ait pas encore reproduit ce phénomène. Les animations générées offrent une visualisation claire, mais la reproductibilité exacte reste conditionnée par l’accès aux traces brutes, qui ne sont pas publiées dans l’article.
