Réplication Kafka : Comprendre la Haute Disponibilité

La réplication est le mécanisme qui rend Kafka fiable. Sans elle, la perte d'un broker signifierait la perte de données. Ce guide explique comment Kafka réplique les données et maintient la disponibilité.

Le Problème : Perte de Données

Imaginons un cluster Kafka sans réplication :

┌─────────────────┐
│    Broker 1     │
│  ┌───────────┐  │
│  │ Topic A   │  │
│  │ Partition │  │
│  │    0      │  │
│  └───────────┘  │
└─────────────────┘
        │
        │  ❌ Broker crash
        ▼
   DONNÉES PERDUES

Risque : Si le broker tombe, toutes les données de cette partition sont perdues.

La Solution : Réplication

Kafka copie chaque partition sur plusieurs brokers :

┌─────────────────┐    ┌─────────────────┐    ┌─────────────────┐
│    Broker 1     │    │    Broker 2     │    │    Broker 3     │
│  ┌───────────┐  │    │  ┌───────────┐  │    │  ┌───────────┐  │
│  │ Partition │  │    │  │ Partition │  │    │  │ Partition │  │
│  │  0 (L)    │◄─┼────┼──│  0 (F)    │  │    │  │  0 (F)    │  │
│  └───────────┘  │    │  └───────────┘  │    │  └───────────┘  │
└─────────────────┘    └─────────────────┘    └─────────────────┘
     LEADER               FOLLOWER             FOLLOWER

L = Leader (reçoit les écritures) F = Follower (copie du leader)

Concepts Clés

Replication Factor (RF)

Le nombre de copies d'une partition.

# Créer un topic avec RF=3
kafka-topics.sh --create \
  --topic orders \
  --partitions 6 \
  --replication-factor 3 \
  --bootstrap-server localhost:9092

Leader et Followers

Chaque partition a un seul leader :

• Leader : Reçoit toutes les lectures et écritures
• Followers : Répliquent les données du leader

  Producer                    Consumer
     │                           ▲
     │ write                     │ read
     ▼                           │
┌─────────┐                ┌─────────┐
│ Leader  │───replicate───►│ Leader  │
│(Broker1)│                │(Broker1)│
└─────────┘                └─────────┘
     │
     │ replicate
     ▼
┌─────────┐    ┌─────────┐
│Follower │    │Follower │
│(Broker2)│    │(Broker3)│
└─────────┘    └─────────┘

In-Sync Replicas (ISR)

L'ISR est la liste des replicas synchronisées avec le leader.

Partition 0:
  Leader: Broker 1
  ISR: [Broker 1, Broker 2, Broker 3]  ✅ Tous synchronisés

Partition 1:
  Leader: Broker 2
  ISR: [Broker 2, Broker 1]            ⚠️ Broker 3 en retard

Un follower sort de l'ISR s'il est trop en retard (configurable via replica.lag.time.max.ms).

Processus de Réplication

1. Écriture d'un Message

1. Producer envoie message au Leader
2. Leader écrit dans son log
3. Followers récupèrent le message (fetch)
4. Followers écrivent dans leur log
5. Followers confirment au Leader
6. Leader confirme au Producer (si acks=all)

2. Configuration acks

Le producer contrôle le niveau de durabilité :

// Configuration producer pour durabilité maximale
props.put("acks", "all");
props.put("enable.idempotence", "true");

3. min.insync.replicas

Nombre minimum de replicas qui doivent confirmer :

# Configuration broker/topic
min.insync.replicas=2

Avec RF=3 et min.insync.replicas=2 :

• Au moins 2 replicas doivent être synchronisées
• Si seulement 1 replica disponible → erreur d'écriture

Failover Automatique

Quand le Leader Tombe

AVANT:                           APRÈS:
┌─────────┐                      ┌─────────┐
│Broker 1 │ ◄── Leader           │Broker 1 │ ❌ DOWN
└─────────┘                      └─────────┘
┌─────────┐                      ┌─────────┐
│Broker 2 │ ◄── Follower   ═══►  │Broker 2 │ ◄── NOUVEAU LEADER
└─────────┘                      └─────────┘
┌─────────┐                      ┌─────────┐
│Broker 3 │ ◄── Follower         │Broker 3 │ ◄── Follower
└─────────┘                      └─────────┘

Le Controller (broker spécial) élit un nouveau leader parmi l'ISR.

Élection du Leader

1. Controller détecte la perte du leader
2. Sélectionne un nouveau leader dans l'ISR
3. Met à jour les métadonnées
4. Notifie les producers/consumers

Temps de failover : Généralement < 1 seconde

Unclean Leader Election

Que faire si tous les ISR sont down ?

# Option 1: Attendre qu'un ISR revienne (données intactes)
unclean.leader.election.enable=false  # RECOMMANDÉ

# Option 2: Élire un replica non-synchronisé (perte de données possible)
unclean.leader.election.enable=true

Conseil : En production, gardez unclean.leader.election.enable=false pour éviter la perte de données.

Vérifier la Réplication

État des Partitions

# Voir le détail d'un topic
kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092

# Output:
Topic: orders   Partition: 0    Leader: 1    Replicas: 1,2,3    Isr: 1,2,3
Topic: orders   Partition: 1    Leader: 2    Replicas: 2,3,1    Isr: 2,3,1
Topic: orders   Partition: 2    Leader: 3    Replicas: 3,1,2    Isr: 3,1,2

Partitions Sous-Répliquées

# Lister les partitions avec ISR < RF
kafka-topics.sh --describe \
  --under-replicated-partitions \
  --bootstrap-server localhost:9092

Si cette commande retourne des résultats → problème à investiguer.

Bonnes Pratiques

Configuration Recommandée

# Broker
default.replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false

# Producer
acks=all
enable.idempotence=true
retries=2147483647

Règles de Distribution

Pour une résilience optimale :

1. Brokers sur différents racks : Les replicas doivent être sur des racks différents
2. Au moins 3 brokers : Pour supporter la perte d'un broker avec RF=3
3. Monitoring ISR : Alerter si ISR < RF

# Voir la distribution des replicas
kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092

Résumé

Prochaine Étape

→ Exactly-Once Semantics : Garantir qu'un message n'est traité qu'une seule fois.