AdaRaft

AdaRaft est une implémentation en Ada du protocole Raft : un algorithme de consensus distribué qui permet à un cluster de serveurs de convenir d’un historique ordonné de modifications, même lorsque certaines machines tombent en panne.

Le dépôt est disponible sur GitHub : frett27/Ada-Raft.

Pourquoi le consensus ?

Dans un système distribué, plusieurs replicas doivent souvent partager une même vérité — configuration, état applicatif, décisions de coordination — sans diverger silencieusement. Raft répond à ce besoin en garantissant :

• une source de vérité unique répliquée sur le cluster ;
• la continuité de service tant qu’une minorité de nœuds seulement est indisponible ;
• une élection automatique de leader et une réplication de journal sans intervention manuelle.

C’est le modèle derrière les magasins de configuration (etcd, Consul), les plans de contrôle des bases distribuées et, plus largement, les architectures autoconfigurantes où le cluster se réorganise face aux pannes.

Vue d’ensemble

AdaRaft vise des cas où l’on veut un noyau de consensus lisible, typé et testable — notamment dans des environnements sensibles (embarqué, edge, systèmes industriels) où Ada apporte structure explicite, typage fort et possibilité de preuves partielles (SPARK).

Le projet a démarré comme expérimentation ; la démarche est volontairement protocole d’abord : verrouiller les cas limites Raft dans un harness de tests reproductible, avant d’empiler les aléas du monde réel (réseau, disque, charge).

  Commande client  →  Leader  →  AppendEntries  →  Followers
                         ↓
              Appliquer les entrées commitées sur l'état applicatif
                         ↓
              Compacter le journal (snapshot + rétention optionnelle)
                         ↓
              InstallSnapshot si un follower est en retard

Fonctionnalités principales

• Rôles Raft : follower, candidate, leader — avec élection et réplication de journal.
• Journal décalé (Shifted_Log) : indices logiques illimités dans un nombre borné de slots physiques — base pour la compaction.
• Compaction et snapshots : InstallSnapshot, état applicatif inclus dans les snapshots, rétention post-compaction pour le rattrapage des followers.
• Machine à états applicative : hook Apply_Command, snapshot / restore via Raft.State_Machine.Application_State.
• Harness de tests déterministe : timers par époque (pas de sleep en test), buffer de messages, simulation de partitions, reset de nœuds — 35 tests couvrant états, protocole, stockage, compaction et scénarios multi-nœuds (jusqu’à 11 nœuds en stress).
• Exemples réseau : transport UDP inter-nœuds Raft et API client TCP (register, send, reconnect, watchdog, expiration de session).
• SPARK (partiel) : contrats sur une partie des chemins de communication et des buffers.

Le cœur Raft couvre la réplication jusqu’à la compaction (§7 du papier). Les changements d’appartenance au cluster (membership changes) ne sont pas encore implémentés.

Avancées majeures — juillet 2026

Les travaux récents portent sur la maturité du noyau et les premiers scénarios réseau :

Ces évolutions rapprochent AdaRaft d’usages prototype et banc de test HIL : cluster à petit quorum (3–5 nœuds) capable de survivre à une panne unitaire ou à une coupure réseau, avec reprise automatique via élection et rattrapage par snapshot.

Validation de la correction

Les bugs de consensus se cachent souvent dans le timing : votes partagés, leaders obsolètes, partitions, trous dans le journal. AdaRaft contrôle explicitement le temps et la messagerie :

Documentation associée dans le dépôt : doc/conception.md, doc/tests.md, doc/library_api.md.

Cas d’usage visés

État du projet

Qualité recherche / apprentissage — utile pour l’étude, les prototypes et les environnements contrôlés ; pas prêt pour la production en l’état.

AdaRaft n’est pas un remplacement drop-in d’etcd, ZooKeeper ou Consul. Pour un déploiement terrain, il reste à ajouter transport sécurisé (TLS), persistance durable, monitoring, chaos testing et couche ops — comme pour tout noyau de consensus nu.

Bon fit : apprendre Raft, équipes Ada explorant l’état répliqué sans runtime étranger, contributeurs voulant figer les corner cases avant la production.

Mauvais fit : charge client très élevée ou exploitation enterprise clé en main dès aujourd’hui.

Technologies

• Ada (~93 %) — GNAT, Alire, AUnit
• Shell — lancement de cluster d’exemples
• Licence : MIT OR Apache-2.0 WITH LLVM-exception

Démarrage rapide

cd tests
eval "$(alr printenv)"
gprbuild -P tests_raft.gpr
./bin/tests_raft

Attendu : 35 routines, zéro assertion en échec.

Cluster d’exemples :

cd examples
./launch.sh start
./bin/raft_client -c cluster.toml --name client send 42

Roadmap

Directions possibles (sans calendrier fixe) : changements d’appartenance au cluster, pre-vote, persistance durable du journal et des snapshots, couverture SPARK élargie, améliorations du scheduling sous forte charge.

Contributions

Le projet est open-source. Retours de terrain, tests de charge, durcissement transport et ops sont les bienvenues — sans promesse de support enterprise.