Consensus (Raft)

Comment N nœuds se mettent d'accord sur une suite ordonnée d'opérations malgré pannes et délais réseau, sans rester bloqués.

Problème

Plusieurs nœuds maintiennent une même state machine répliquée (registre clés-valeurs, journal métier, leader election table). Il faut s'accorder sur l'ordre exact des écritures pour éviter divergence, et survivre à la panne d'une minorité. Paxos résout ce problème depuis 1989 (Lamport) mais reste réputé incompréhensible. Raft a été conçu pour être implémenté correctement par des équipes ordinaires.

Forces

• FLP impossibility — pas de consensus parfait en présence d'asynchronie ; il faut un timeout.
• Plus on a de nœuds dans le quorum, plus la sûreté est forte mais plus la latence d'écriture monte.
• Une panne réseau peut isoler le leader ; il faut détecter et réélire vite.
• L'algorithme doit être implémentable par des humains sans crampes au cerveau (Paxos a posé problème).

Solution

Raft décompose le consensus en trois sous-problèmes : (1) élection de leader — un seul leader par terme, élu à la majorité quand le précédent ne renouvelle plus son heartbeat ; (2) réplication du log — le leader reçoit toutes les écritures, les fait valider par une majorité (quorum N/2+1) avant de les committer ; (3) sûreté — un log committé ne peut être perdu ; un nouveau leader doit avoir le log le plus à jour parmi le quorum. La séparation rend l'algorithme didactique et chaque module testable séparément.

Structure

           ┌───────── Term 7 ─────────┐
Client ───► Leader (Node A) ───► Followers (B, C, D, E)
              │                       │
              │ AppendEntries(log[i])  │
              │ ◄─────── ack ──────────┤
              │                       │
              │ when majority ack      │
              │   ──► commit index = i │
              │                       │
              ▼
        State machine apply(log[i])

If leader A goes silent:
  Followers wait election_timeout (150-300ms randomised)
  First to time out becomes candidate, requests votes
  Wins if majority votes ──► becomes leader for term 8

Implémentation EDI

On n'écrit pas un Raft soi-même pour un hub EDI ; on consomme du Raft. Cas type : etcd Raft pour la persistance du registre Kubernetes qui héberge le hub. Ou bien CockroachDB (Raft per range) comme base transactionnelle multi-région d'un hub EDI mondial — chaque commande survit à la perte d'un datacenter. Pour les architectes EDI, comprendre Raft permet de dimensionner correctement les quorums et de calibrer le timeout d'élection en fonction de la latence inter-DC.

Anti-patterns

• Quorum à 2 nœuds — n'importe quelle panne suspend les écritures (toujours 3, 5 ou 7).
• Timeout d'élection trop court vs RTT — l'élection ne converge jamais.
• Bande passante saturée par la réplication — les heartbeats ne passent plus, on déclenche des élections inutiles.
• Mise à jour de configuration (membership change) sans le protocole joint consensus — split brain garanti.
• Croire que Raft fournit exactly-once de bout en bout — il faut combiner avec idempotence applicative.

Patterns liés

• Leader Election — sous-problème de Raft surfacé séparément.
• Partition Tolerance (CAP) — Raft choisit CP en cas de partition.
• Event Sourcing — log Raft est lui-même un journal d'évènements.
• Guaranteed Delivery — garantie offerte au-dessus de Raft.

Sources

• Ongaro D., Ousterhout J. — In Search of an Understandable Consensus Algorithm, USENIX ATC 2014. raft.github.io/raft.pdf
• etcd documentation — Raft implementation. etcd.io/docs/v3.5/learning/why
• Kleppmann M. — Designing Data-Intensive Applications, O'Reilly 2017, chap. 9.