Retour d'Experience: 5 Ans de Kafka au Credit Agricole

Apres 5 annees a deployer, exploiter et faire evoluer Apache Kafka dans un contexte bancaire a grande echelle, je partage les lecons apprises, les defis surmontees et les patterns qui ont fonctionne. Ce retour d'experience couvre l'evolution d'une architecture de quelques brokers vers un ecosysteme de 47 clusters traitant 1.4 million de messages par seconde.

Contexte et Chiffres Cles

L'Ecosysteme Kafka en Production

Apres 5 ans d'evolution, voici les metriques actuelles de la plateforme :

┌─────────────────────────────────────────────────────────────────┐
│                    KAFKA @ CREDIT AGRICOLE                       │
├─────────────────────────────────────────────────────────────────┤
│  Clusters         │  47 (prod, preprod, dev, DR)                │
│  Brokers          │  180+ brokers en production                 │
│  Topics           │  2,400+ topics actifs                       │
│  Partitions       │  45,000+ partitions                         │
│  Throughput       │  1.4M messages/seconde (pic)                │
│  Data Volume      │  12 TB/jour ingestees                       │
│  Equipes          │  150+ equipes utilisatrices                 │
│  Applications     │  400+ applications connectees               │
└─────────────────────────────────────────────────────────────────┘

Evolution de l'Architecture

2019                    2021                    2024
┌────────┐         ┌────────────────┐    ┌────────────────────────┐
│1 cluster│   →    │ 5 clusters     │ → │ 47 clusters            │
│3 brokers│        │ 20 brokers     │    │ 180 brokers            │
│POC      │        │ Multi-tenant   │    │ Federated Platform     │
└────────┘         └────────────────┘    └────────────────────────┘

Phase 1 : Les Debuts (2019-2020)

Premier POC et Adoption

Le premier cas d'usage etait simple : remplacer un systeme de fichiers batch par du streaming temps reel pour la detection de fraude.

Architecture initiale :

┌──────────────────┐    ┌─────────────────┐    ┌──────────────────┐
│  Systeme         │    │     Kafka       │    │   Moteur de      │
│  Transactionnel  │───▶│   (3 brokers)   │───▶│   Detection      │
│                  │    │                 │    │   Fraude         │
└──────────────────┘    └─────────────────┘    └──────────────────┘

Resultats du POC :

• Latence reduite de 15 minutes a 200ms
• Taux de detection fraude +35%
• ROI valide en 6 mois

Premieres Erreurs Commises

Erreur 1 : Sous-dimensionnement des partitions

# Configuration initiale (ERREUR)
kafka-topics.sh --create --topic transactions \
  --partitions 3 --replication-factor 2

# Probleme : impossibilite de scaler les consumers
# On ne peut pas reduire le nombre de partitions !

Lecon apprise : Toujours prevoir la croissance. Nous avons adopte la regle :

Partitions = max(expected_throughput_MB/s * 2, consumer_instances * 3)

Erreur 2 : Pas de strategie de nommage

# Noms de topics chaotiques au debut
topic1, myTopic, FRAUD_DETECTION, fraud-detection-v2

# Convention adoptee ensuite
<domain>.<subdomain>.<entity>.<version>
banking.fraud.transactions.v1
banking.fraud.alerts.v1

Erreur 3 : Securite negligee

Au depart, pas d'authentification. Erreur critique dans un contexte bancaire.

# Configuration securisee adoptee
security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-512
ssl.client.auth=required

Phase 2 : Industrialisation (2020-2022)

Architecture Multi-Tenant

Avec l'adoption croissante, nous avons du passer d'un cluster unique a une architecture multi-tenant :

┌─────────────────────────────────────────────────────────────────┐
│                    KAFKA PLATFORM LAYER                          │
│                                                                  │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐             │
│  │ Cluster     │  │ Cluster     │  │ Cluster     │             │
│  │ FRAUDE      │  │ PAIEMENTS   │  │ MARKETING   │             │
│  │ (Critical)  │  │ (Critical)  │  │ (Standard)  │             │
│  └─────────────┘  └─────────────┘  └─────────────┘             │
│                                                                  │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │              SHARED SERVICES                                 ││
│  │  - Schema Registry (central)                                ││
│  │  - Monitoring (Prometheus/Grafana)                          ││
│  │  - Topic Catalog & Governance                               ││
│  │  - Self-Service Portal                                      ││
│  └─────────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────────┘

Mise en Place des Quotas

Un des plus grands defis : eviter qu'une equipe ne monopolise les ressources.

# quotas.properties
# Quota producer : 10 MB/s par client
quota.producer.default=10485760

# Quota consumer : 20 MB/s par client
quota.consumer.default=20971520

# Quotas specifiques par equipe
user.fraud-detection.producer_byte_rate=52428800
user.fraud-detection.consumer_byte_rate=104857600

Script de gestion des quotas :

#!/bin/bash
# set-team-quota.sh

TEAM=$1
PRODUCER_MB=$2
CONSUMER_MB=$3

kafka-configs.sh --bootstrap-server $BOOTSTRAP_SERVERS \
  --alter --add-config "producer_byte_rate=$((PRODUCER_MB * 1024 * 1024)),consumer_byte_rate=$((CONSUMER_MB * 1024 * 1024))" \
  --entity-type users --entity-name $TEAM

echo "Quotas configured for team $TEAM: Producer=${PRODUCER_MB}MB/s, Consumer=${CONSUMER_MB}MB/s"

Schema Registry et Gouvernance des Donnees

L'introduction du Schema Registry a ete un tournant majeur :

┌─────────────────────────────────────────────────────────────────┐
│                    SCHEMA GOVERNANCE                             │
│                                                                  │
│  Producer App ──▶ Schema Registry ──▶ Validation ──▶ Kafka     │
│                         │                                        │
│                         ▼                                        │
│              ┌─────────────────────┐                            │
│              │  Schema Evolution   │                            │
│              │  - BACKWARD         │                            │
│              │  - FORWARD          │                            │
│              │  - FULL             │                            │
│              └─────────────────────┘                            │
└─────────────────────────────────────────────────────────────────┘

Exemple de schema Avro adopte :

{
  "type": "record",
  "name": "Transaction",
  "namespace": "com.ca.banking.fraud",
  "fields": [
    {"name": "transaction_id", "type": "string"},
    {"name": "amount", "type": "double"},
    {"name": "currency", "type": "string", "default": "EUR"},
    {"name": "timestamp", "type": "long", "logicalType": "timestamp-millis"},
    {"name": "customer_id", "type": "string"},
    {"name": "merchant_id", "type": ["null", "string"], "default": null},
    {"name": "metadata", "type": {"type": "map", "values": "string"}, "default": {}}
  ]
}

Phase 3 : Scale et Maturite (2022-2024)

Federation des Clusters

Avec 47 clusters, la gestion centralisee est devenue critique :

┌─────────────────────────────────────────────────────────────────┐
│                    FEDERATED KAFKA PLATFORM                      │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                 CONTROL PLANE                              │  │
│  │  - Cluster Registry                                        │  │
│  │  - Topic Catalog                                           │  │
│  │  - Access Management (RBAC)                                │  │
│  │  - Quota Management                                        │  │
│  │  - Audit Logging                                           │  │
│  └──────────────────────────────────────────────────────────┘  │
│                              │                                   │
│              ┌───────────────┼───────────────┐                  │
│              ▼               ▼               ▼                  │
│         ┌────────┐     ┌────────┐     ┌────────┐              │
│         │Region 1│     │Region 2│     │Region 3│              │
│         │Paris   │     │Lyon    │     │DR Site │              │
│         │15 clusters│  │12 clusters│  │20 clusters│           │
│         └────────┘     └────────┘     └────────┘              │
└─────────────────────────────────────────────────────────────────┘

Cross-Datacenter Replication

Pour le Disaster Recovery, nous avons implemente MirrorMaker 2 :

# mm2.properties
clusters = paris, lyon, dr
paris.bootstrap.servers = paris-kafka-1:9092,paris-kafka-2:9092
lyon.bootstrap.servers = lyon-kafka-1:9092,lyon-kafka-2:9092
dr.bootstrap.servers = dr-kafka-1:9092,dr-kafka-2:9092

# Replication active-active Paris <-> Lyon
paris->lyon.enabled = true
lyon->paris.enabled = true

# DR uni-directionnel
paris->dr.enabled = true
lyon->dr.enabled = true

# Topics critiques repliques
paris->lyon.topics = banking\\.fraud\\..*,banking\\.payments\\..*
replication.factor = 3
sync.topic.configs.enabled = true

Metriques de replication :

┌─────────────────────────────────────────────────────────────────┐
│              REPLICATION METRICS                                 │
├─────────────────────────────────────────────────────────────────┤
│  Paris → Lyon    │  Lag: 50ms avg    │  Throughput: 500K msg/s │
│  Lyon → Paris    │  Lag: 55ms avg    │  Throughput: 400K msg/s │
│  Paris → DR      │  Lag: 120ms avg   │  Throughput: 800K msg/s │
│  Lyon → DR       │  Lag: 125ms avg   │  Throughput: 600K msg/s │
└─────────────────────────────────────────────────────────────────┘

Optimisations Performance

Apres 5 ans d'experience, voici les configurations optimales identifiees :

Configuration Broker (production critique) :

# server.properties - Production Banking

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

# Performance I/O
num.io.threads=16
num.network.threads=8
num.replica.fetchers=4

# Retention adaptee au contexte reglementaire
log.retention.hours=720  # 30 jours
log.retention.bytes=-1   # Pas de limite par taille
log.segment.bytes=1073741824  # 1GB

# Buffer et batch
socket.send.buffer.bytes=1048576
socket.receive.buffer.bytes=1048576
socket.request.max.bytes=104857600

# Compression
compression.type=lz4

Configuration Producer (high throughput) :

Properties props = new Properties();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);

// Durabilite maximale
props.put(ProducerConfig.ACKS_CONFIG, "all");
props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true);

// Performance
props.put(ProducerConfig.BATCH_SIZE_CONFIG, 65536);  // 64KB
props.put(ProducerConfig.LINGER_MS_CONFIG, 5);
props.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, "lz4");
props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 67108864);  // 64MB

// Retry et timeout
props.put(ProducerConfig.RETRIES_CONFIG, Integer.MAX_VALUE);
props.put(ProducerConfig.DELIVERY_TIMEOUT_MS_CONFIG, 120000);
props.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, 30000);

Defis Majeurs et Solutions

Defi 1 : Gestion des Pics de Charge

Probleme : Black Friday et fins de mois generent des pics de x10 le trafic normal.

Solution : Auto-scaling et buffer :

# Kubernetes HPA pour consumers
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: fraud-consumer-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: fraud-consumer
  minReplicas: 3
  maxReplicas: 30
  metrics:
  - type: External
    external:
      metric:
        name: kafka_consumergroup_lag
        selector:
          matchLabels:
            consumergroup: fraud-detection-group
      target:
        type: AverageValue
        averageValue: "1000"

Defi 2 : Compliance et Audit

Dans un contexte bancaire, chaque message doit etre tracable.

Solution : Audit logging complet :

# Audit logging
authorizer.class.name=kafka.security.authorizer.AclAuthorizer
log4j.logger.kafka.authorizer.logger=INFO, authorizerAppender

# Custom interceptor pour audit
producer.interceptor.classes=com.ca.kafka.audit.AuditProducerInterceptor
consumer.interceptor.classes=com.ca.kafka.audit.AuditConsumerInterceptor

// AuditProducerInterceptor.java
public class AuditProducerInterceptor implements ProducerInterceptor<String, Object> {

    private AuditLogger auditLogger;

    @Override
    public ProducerRecord<String, Object> onSend(ProducerRecord<String, Object> record) {
        auditLogger.log(AuditEvent.builder()
            .action("PRODUCE")
            .topic(record.topic())
            .key(record.key())
            .timestamp(System.currentTimeMillis())
            .principal(SecurityContextHolder.getPrincipal())
            .build());
        return record;
    }
}

Defi 3 : Migration Zero-Downtime

Migrer de Kafka 2.x vers 3.x sans interruption de service.

Strategie adoptee :

Phase 1: Upgrade brokers (rolling restart)
┌────────┐ ┌────────┐ ┌────────┐
│Broker 1│ │Broker 2│ │Broker 3│
│ v2.8   │ │ v2.8   │ │ v2.8   │
└────────┘ └────────┘ └────────┘
    │
    ▼ (restart Broker 1 with v3.0)
┌────────┐ ┌────────┐ ┌────────┐
│Broker 1│ │Broker 2│ │Broker 3│
│ v3.0   │ │ v2.8   │ │ v2.8   │
└────────┘ └────────┘ └────────┘
    ... (repeat for each broker)

Phase 2: Upgrade inter.broker.protocol
Phase 3: Upgrade clients progressivement
Phase 4: Remove deprecated configs

Metriques et KPIs

Dashboard Principal

┌─────────────────────────────────────────────────────────────────┐
│                    KAFKA PLATFORM KPIs                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Availability (SLA: 99.99%)                                     │
│  ████████████████████████████████████████████████░░  99.97%     │
│                                                                  │
│  Messages/Second                                                 │
│  Current: 1.2M/s    Peak: 1.8M/s    Avg: 850K/s                │
│  ▁▂▃▄▅▆▇█▇▆▅▄▃▂▁▂▃▄▅▆▇█▇▆▅▄▃▂▁▂▃▄▅▆▇█                          │
│                                                                  │
│  Consumer Lag (Critical Topics)                                 │
│  fraud.transactions: 120 msgs (OK)                              │
│  payments.orders: 45 msgs (OK)                                  │
│  marketing.events: 15,000 msgs (WARNING)                        │
│                                                                  │
│  Under-Replicated Partitions: 0                                 │
│  Offline Partitions: 0                                          │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Alertes Critiques Definies

# alerts.yml
groups:
  - name: kafka-critical
    rules:
      - alert: KafkaClusterUnavailable
        expr: sum(up{job="kafka"}) < 2
        for: 1m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "Kafka cluster has less than 2 brokers available"

      - alert: CriticalConsumerLag
        expr: kafka_consumergroup_lag{topic=~"banking\\.fraud\\..*"} > 10000
        for: 2m
        labels:
          severity: critical
          team: fraud
        annotations:
          summary: "Critical consumer lag on fraud detection pipeline"

Lecons Apprises : Les 10 Commandements

1. La Gouvernance Avant Tout

"Un topic sans owner est un probleme futur"

Chaque topic doit avoir :

• Un owner identifie
• Un SLA defini
• Une politique de retention documentee
• Un schema enregistre

2. Partitions : Prevoyez Large

# Formule empirique
partitions = max(
  throughput_MB_s * 3,
  max_consumers * 2,
  10  # minimum pour flexibilite future
)

3. Monitoring N'est Pas Optionnel

Metriques critiques a surveiller :
1. Under-replicated partitions (doit etre 0)
2. Consumer lag par groupe
3. Request latency p99
4. ISR shrink rate
5. Disk usage par broker

4. Testez le Disaster Recovery

Nous faisons un DR test mensuel :

• Failover complet vers le site DR
• Mesure du RPO/RTO reel
• Validation des playbooks

5. Documentation Vivante

# Template de documentation topic

## Topic: banking.fraud.transactions.v1

### Description
Flux des transactions bancaires pour detection de fraude en temps reel.

### Owner
Equipe: Fraud Detection
Contact: fraud-team@ca.fr

### SLA
- Latence: < 100ms e2e
- Disponibilite: 99.99%
- Retention: 30 jours

### Schema
Version: 3.2.1
Compatibility: BACKWARD

### Consumers Autorises
- fraud-detection-service
- compliance-audit-service
- analytics-pipeline

A Retenir

Apres 5 ans d'exploitation de Kafka a grande echelle, voici les points essentiels :

Architecture

• Commencez simple, mais avec une vision long terme
• La multi-tenancy necessite une gouvernance solide
• Prevoyez le Disaster Recovery des le debut

Operations

• Automatisez tout ce qui peut l'etre
• Le monitoring proactif evite 90% des incidents
• Les quotas protegent la plateforme entiere

Organisation

• Une equipe plateforme dediee est indispensable a partir de 10 clusters
• La formation des equipes utilisatrices reduit les incidents
• La documentation est un investissement, pas une charge

Performance

• Le tuning est specifique a chaque cas d'usage
• Les tests de charge reguliers revelent les limites
• La compression est votre amie (LZ4 recommande)

Besoin d'Accompagnement ?

Vous souhaitez deployer ou optimiser Kafka dans votre entreprise ? Fort de cette experience en environnement bancaire critique, je propose :

• Audit de votre infrastructure Kafka existante
• Accompagnement a la mise en place d'une plateforme enterprise
• Formation de vos equipes aux bonnes pratiques

Contactez-moi pour un audit gratuit de votre architecture Kafka

Cet article fait partie d'une serie sur Apache Kafka en entreprise. Consultez egalement mes guides sur le monitoring, le tuning de performance, et les patterns d'architecture avances.