Kafka

Introduction à Apache Kafka

1. Historique et origines

   Apache Kafka a été créé en 2010 par LinkedIn pour résoudre les problèmes de gestion des données en temps réel. Son développement a été initié par Jay Kreps, Neha Narkhede et Jun Rao. Le projet a été open-sourcé en 2011 et est devenu un projet de la Fondation Apache en 2012.

   Kafka a été conçu pour répondre aux besoins spécifiques de LinkedIn en matière de traitement de données en temps réel, notamment pour la collecte de logs, les métriques, et les flux de données utilisateur.

2. Qu'est-ce que Kafka ?

   Apache Kafka est une plateforme distribuée de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel. Elle est conçue pour gérer des flux de données provenant de plusieurs sources et les fournir à plusieurs utilisateurs simultanément.

   Kafka est une solution Open Source de diffusion de données en continu, capable de publier, stocker, traiter et souscrire à des flux d'enregistrement en temps réel.

   Architecture de base

   graph LR
       P[Producteurs] -->|publient| T[Topics]
       T --> B[(Brokers
   partitions)]
       B --> C[Consommateurs]
       B --> C
   

   Schéma : les producteurs publient dans des topics, les brokers les stockent dans leurs partitions, les consommateurs les lisent.

   L'architecture de Kafka est composée de quatre composants principaux :

   • Producteurs : Envoient des données dans les topics
   • Topics : Stockent les données dans des partitions
   • Brokers : Gèrent le stockage et la distribution des données
   • Consommateurs : Reçoivent et traitent les données

3. Cas d'utilisation courants

   • Systèmes de log en temps réel : Collecte et analyse des logs d'applications et de serveurs
   • Événements utilisateur : Suivi des actions des utilisateurs dans les applications web et mobiles
   • Monitoring et métriques : Collecte et analyse des données de performance
   • Intégration de données : Synchronisation entre différents systèmes et bases de données
   • Applications IoT : Gestion des données provenant de capteurs et dispositifs connectés
   • Plateformes e-commerce : Gestion des événements de panier, commandes et recommandations

4. Architecture de base

   L'architecture de Kafka repose sur plusieurs composants clés :

   • Brokers : Les nœuds du cluster qui stockent et gèrent les données
   • Topics : Les canaux de communication entre producteurs et consommateurs
   • Partitions : Les unités de stockage dans les topics qui permettent la parallélisation
   • Producteurs : Les applications qui envoient des données
   • Consommateurs : Les applications qui lisent les données

Architecture de base

1. Vue d'ensemble

   graph TB
       subgraph Producteurs
           P1[App A]
           P2[App B]
       end
       subgraph Cluster
           B1[(Broker 1)]
           B2[(Broker 2)]
           B3[(Broker 3)]
       end
       subgraph Consommateurs
           C1[Traitement 1]
           C2[Traitement 2]
       end
       P1 --> B1
       P2 --> B2
       B1 --> C1
       B2 --> C2
       B3 --> C1
   

   Vue d'ensemble : plusieurs producteurs alimentent un cluster de brokers, réparti vers les consommateurs.

   Kafka est conçu comme une plateforme distribuée, composée de plusieurs composants interconnectés qui travaillent ensemble pour gérer les flux de données.

2. Les composants principaux

   Architecture détaillée

   graph LR
       P[Producteurs] -->|append| L[Partition leader]
       L --> F1[Réplique 1]
       L --> F2[Réplique 2]
       Z[Zookeeper / KRaft] -.coordination.-> L
   

   Composants : un topic est découpé en partitions, chaque partition est répliquée sur plusieurs brokers, un coordinateur (Zookeeper ou KRaft) maintient l'état du cluster.

   L'architecture de Kafka est composée de plusieurs composants interconnectés :

   • Broker : Serveur qui stocke et gère les données
   • Partitions : Unités de stockage qui divisent les topics
   • Producteurs : Applications qui envoient des données
   • Consommateurs : Applications qui reçoivent et traitent les données
   • Zookeeper : Service de coordination et de configuration

   Réplication

   graph LR
       L[(Partition 0 - leader)] --> R1[(Réplique 1)]
       L --> R2[(Réplique 2)]
       R1 -.réplication.-> L
       R2 -.réplication.-> L
   

   Réplication : le leader reçoit les écritures et les réplique aux followers ; en cas de panne, un follower est élu leader.

   La réplication est un mécanisme essentiel de Kafka qui assure la durabilité et la tolérance aux pannes. Chaque partition est répliquée sur plusieurs brokers, avec un broker leader et plusieurs brokers followers.

   Groupes de consommateurs

   graph LR
       T[(Topic - 3 partitions)] --> G1[Groupe A]
       T --> G2[Groupe B]
       G1 --> C1[Consommateur 1]
       G1 --> C2[Consommateur 2]
       G2 --> C3[Consommateur 3]
   

   Groupes de consommateurs : chaque partition est assignée à un seul consommateur d'un groupe ; deux groupes différents relisent donc chacun la totalité du topic.

   Les groupes de consommateurs permettent de répartir la charge de traitement entre plusieurs consommateurs. Chaque partition est assignée à un seul consommateur par groupe, garantissant ainsi une consommation exclusive des messages.

   Brokers

   • Serveurs qui stockent et gèrent les données
   • Chaque broker peut gérer plusieurs topics et partitions
   • Peuvent être répliqués pour la haute disponibilité

   Topics

   • Canaux de communication logiques
   • Organisés en partitions pour le parallélisme
   • Peuvent être répliqués pour la durabilité

   Partitions

   • Unités de stockage dans les topics
   • Chaque partition est un flux ordonné de messages
   • Permettent le parallélisme de la consommation

   Producteurs

   • Applications qui envoient des données
   • Peuvent spécifier la partition cible
   • Supportent différents modes de confirmation

   Consommateurs

   • Applications qui lisent les données
   • S'abonnent à un ou plusieurs topics
   • Peuvent faire partie de groupes de consommateurs

   Zookeeper (pour les versions < 3.0)

   • Gestionnaire de configuration et de coordination
   • Coordonne les brokers et les topics
   • Stocke les informations de cluster

3. Modèle de données

   Topics et Partitions

   graph LR
       TP[Topic commandes] --> P0[Partition 0]
       TP --> P1[Partition 1]
       TP --> P2[Partition 2]
       P0 --> M0[Messages 0-99]
       P1 --> M1[Messages 100-199]
       P2 --> M2[Messages 200-299]
   

   Topics et partitions : un topic est un découpage ordonné de partitions ; chaque partition est ordonnée mais il n'y a pas d'ordre global entre partitions.

   • Chaque topic est divisé en plusieurs partitions
   • Les messages sont distribués entre les partitions
   • Les partitions permettent le parallélisme

   Messages et Offsets

   • Les messages sont immuables
   • Chaque message a un offset unique
   • Les offsets permettent le suivi de la progression

   Organisation des données

   • Les messages sont stockés par ordre d'arrivée
   • Les offsets garantissent l'ordre des messages
   • Les données sont conservées pendant une période configurable

4. Groupes de consommateurs

   Principe de base

   • Les consommateurs appartiennent à des groupes
   • Chaque groupe peut avoir plusieurs consommateurs
   • Les messages sont distribués entre les consommateurs d'un groupe

   Répartition des partitions

   • Les partitions sont réparties entre les consommateurs
   • Un seul consommateur par partition dans un groupe
   • La répartition est gérée automatiquement

   Scénarios

   • Si moins de consommateurs que de partitions : certains consommateurs lisent plusieurs partitions
   • Si plus de consommateurs que de partitions : certains consommateurs restent inactifs
   • Les groupes différents peuvent lire les mêmes messages

5. Scalabilité et haute disponibilité

   Scalabilité horizontale

   • Ajout de nouveaux brokers
   • Augmentation du nombre de partitions
   • Équilibrage automatique des charges

   Réplication

   • Chaque partition peut être répliquée
   • Un leader par partition
   • Les followers répliquent les données

   Tolérance aux pannes

   • Les leaders peuvent changer
   • Les données sont conservées
   • Les consommateurs peuvent continuer à travailler

Les fonctionnalités clés de Kafka

1. Pub / Sub (Publication/Subscription)

   Kafka utilise le modèle pub/sub, où les producteurs envoient des messages dans un topic et les consommateurs peuvent s'abonner à ce topic pour recevoir les messages. Cela permet une communication asynchrone et découplée entre les applications.

   Avantages

   • Découplage des producteurs et consommateurs
   • Flexibilité dans l'ajout de nouveaux consommateurs
   • Communication asynchrone

   Exemples d'implémentation

   • Exemple de producteur (Java)
   • Exemple de consommateur (Java)
   • Exemple de consommateur (Scala)
   • Exemple de Kafka Streams (Scala)
   • Producteur avancé (Scala)
   • Consommateur avancé (Scala)
   • Application de comptage de mots (Scala)

   Caractéristiques avancées

   • Configuration avancée : Paramètres de performance et de fiabilité
   • Opérations asynchrones : Gestion des callbacks et des Futures
   • Transformation des données : Fonctions personnalisées et filtrage
   • Gestion des erreurs : Try et gestion des exceptions
   • Optimisations : Batch processing et mémoire tampon

   Exemple d'utilisation

   Voici un exemple d'utilisation simple :

   // Producteur
   Properties props = new Properties();
   props.put("bootstrap.servers", "localhost:9092");
   props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
   props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
   
   Producer<String, String> producer = new KafkaProducer<>(props);
   String logMessage = "[ERROR] " + new Date() + " - Une erreur s'est produite";
   ProducerRecord<String, String> record = new ProducerRecord<>("logs-topic", "server-1", logMessage);
   producer.send(record);
   
   // Consommateur
   Properties props = new Properties();
   props.put("bootstrap.servers", "localhost:9092");
   props.put("group.id", "my-group");
   props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
   props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
   
   KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
   consumer.subscribe(Collections.singletonList("logs-topic"));
   
   while (true) {
       ConsumerRecords<String, String> records = consumer.poll(100);
       for (ConsumerRecord<String, String> record : records) {
           System.out.println(record.value());
       }
       consumer.commitSync();
   }
   

2. Durabilité

   Kafka offre une haute durabilité grâce à la réplication des partitions sur plusieurs brokers. Tu peux configurer le nombre de réplicas pour chaque topic. Un des réplicas est désigné comme le leader (pour les opérations de lecture et d'écriture), et les autres sont des followers qui répliquent les données du leader. Les messages sont stockés sur disque et peuvent être archivés pour garantir la persistance des données, même en cas de redémarrage des brokers.

   Configuration

   • replication.factor : Nombre de réplicas par partition
   • min.insync.replicas : Nombre minimum de réplicas qui doivent confirmer l'écriture
   • log.retention.hours : Durée de rétention des messages

   Exemple de configuration

   // Création d'un topic avec réplication
   kafka-topics.sh --create --topic my-topic --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092

3. Tolérance aux pannes

   Kafka est conçu pour être tolérant aux pannes. En cas d'arrêt d'un broker, les partitions qu'il héberge (et qui sont leaders) sont reprises par l'un des brokers contenant une réplique à jour (un follower devient le nouveau leader). Les consommateurs et producteurs continuent à interagir avec les partitions restantes sans interruption significative.

   Stratégies de récupération

   • Élection automatique du nouveau leader
   • Redistribution des partitions
   • Reprise automatique des consommateurs

   Best practices

   • Utiliser un facteur de réplication ≥ 3 en production
   • Surveiller les métriques de latence
   • Configurer des alertes pour les pannes de brokers

4. Scalabilité

   Kafka scale horizontalement en ajoutant simplement de nouveaux brokers au cluster. De plus, la division des topics en partitions permet de distribuer la charge de travail entre plusieurs brokers et consommateurs au sein d'un même groupe, atteignant ainsi un haut débit de traitement. Le nombre de partitions peut être ajusté (avec précaution) pour répondre à l'évolution de la demande.

   Stratégies de scalabilité

   • Ajout de brokers
   • Augmentation du nombre de partitions
   • Configuration optimale des groupes de consommateurs

   Exemple de monitoring

   // Métriques importantes à surveiller
   - broker:messages-in-per-sec
   - broker:bytes-in-per-sec
   - broker:bytes-out-per-sec
   - consumer:lag

5. Temps de réponse faible

   Kafka est conçu pour offrir des temps de réponse très courts (faible latence), ce qui en fait un outil idéal pour les applications réactives et les processus en temps quasi-réel.

   Optimisations de latence

   • Configuration des timeouts
   • Optimisation des batch sizes
   • Configuration du nombre de threads

   Exemple de configuration

   // Configuration pour la latence
   Properties props = new Properties();
   props.put("linger.ms", "1");
   props.put("batch.size", "16384");
   props.put("compression.type", "gzip");

6. Sérialisation et Desérialisation

   Kafka est agnostique au format des données. Cependant, pour une interopérabilité et une évolution des schémas efficaces, l'utilisation de formats de sérialisation structurés comme Avro, Protocol Buffers ou JSON Schema est fortement recommandée. Kafka utilise des Serializers pour convertir les objets en flux d'octets avant l'envoi et des Deserializers pour effectuer l'opération inverse à la réception.

   Exemples de sérialisation

   // Avro
   public class User {
       private String name;
       private int age;
       // getters et setters
   }
   
   // Configuration
   Properties props = new Properties();
   props.put("key.serializer", "io.confluent.kafka.serializers.KafkaAvroSerializer");
   props.put("value.serializer", "io.confluent.kafka.serializers.KafkaAvroSerializer");
   

7. Garanties de livraison

   Kafka offre différentes garanties de livraison configurables :

   • At most once (au plus une fois) : Les messages peuvent être perdus mais ne sont jamais redélivrés.
   • At least once (au moins une fois) : Les messages peuvent être redélivrés, mais ne sont jamais perdus. C'est la configuration par défaut et la plus courante.
   • Exactly once (exactement une fois) : Chaque message est délivré une seule fois aux consommateurs. Ceci est plus complexe à configurer et peut impacter le débit, mais est crucial pour certains cas d'utilisation (transactions financières, par exemple).

   Configuration

   // Configuration pour exactly-once
   Properties props = new Properties();
   props.put("enable.idempotence", "true");
   props.put("transactional.id", "my-transaction-id");
   

Implémentation pratique de Kafka

1. Installation et configuration

   Prérequis

   • Java 8 ou supérieur : Kafka nécessite Java 8 ou une version plus récente
   • Zookeeper (versions < 3.0) : Gestionnaire de configuration et de coordination
   • Ports disponibles :
     • 9092 : Port par défaut pour Kafka
     • 2181 : Port par défaut pour Zookeeper
   • Espace disque : Au moins 100GB recommandé pour le stockage des données
   • Mémoire RAM : Minimum 8GB recommandé pour chaque broker

   Installation

   # Télécharger la dernière version stable
   wget https://downloads.apache.org/kafka/3.4.0/kafka_2.13-3.4.0.tgz
   
   # Décompresser
   mkdir kafka && tar -xzf kafka_2.13-3.4.0.tgz -C kafka --strip-components 1
   
   # Démarrer Zookeeper (pour les versions < 3.0)
   bin/zookeeper-server-start.sh config/zookeeper.properties
   
   # Démarrer Kafka
   bin/kafka-server-start.sh config/server.properties

   Configuration

   Les fichiers de configuration principaux sont :

   • server.properties : Configuration du broker
   • zookeeper.properties : Configuration de Zookeeper

   Exemple de configuration

   Exemple complet de configuration

   Paramètres importants

   • broker.id : Identifiant unique du broker
   • log.dirs : Répertoire de stockage des données
   • num.partitions : Nombre de partitions par défaut
   • replica.fetch.max.bytes : Taille maximale des requêtes de réplication

2. Administration

   Commandes utiles

   # Créer un topic
   bin/kafka-topics.sh --create --topic my-topic --partitions 3 --replication-factor 1 --bootstrap-server localhost:9092
   
   # Lister les topics
   bin/kafka-topics.sh --list --bootstrap-server localhost:9092
   
   # Voir les détails d'un topic
   bin/kafka-topics.sh --describe --topic my-topic --bootstrap-server localhost:9092
   
   # Produire des messages
   bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-topic
   
   # Consommer des messages
   bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic my-topic --group my-group --from-beginning

   Monitoring

   Kafka expose des métriques JMX qui peuvent être surveillées avec des outils comme Prometheus et Grafana.

   Métriques importantes

   • Broker metrics :
     • messages-in-per-sec
     • bytes-in-per-sec
     • bytes-out-per-sec
   • Consumer metrics :
     • lag
     • records-consumed-rate
     • records-lag-max

   Alertes recommandées

   • Latence élevée des requêtes
   • Partitions non répliquées
   • Brokers hors ligne
   • Retard de consommation

3. Meilleures pratiques

   Configuration des topics

   • Utiliser des topics dédiés pour différents types de données
   • Configurer correctement le nombre de partitions en fonction du débit attendu
   • Utiliser des groupes de consommateurs distincts pour des usages différents
   • Surveiller les métriques de latence et de débit
   • Mettre en place une stratégie de rétention des données adaptée

   Performance

   • Optimiser la taille des batches
   • Utiliser la compression
   • Configurer correctement les timeouts
   • Optimiser le nombre de threads

   Sécurité

   • Activer SSL/TLS pour la communication
   • Utiliser les ACLs pour contrôler l'accès
   • Configurer l'authentification
   • Protéger les données sensibles

4. Scalabilité

   Ajout de brokers

   # Ajouter un nouveau broker
   bin/kafka-server-start.sh config/server.properties

   Rebalancement des partitions

   # Créer un fichier de configuration
   bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --generate --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --broker-list "0,1,2,3"
   
   # Appliquer le rebalancement
   bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --execute --reassignment-json-file reassign.json

   Monitoring du rebalancement

   bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --verify --reassignment-json-file reassign.json

   Meilleures pratiques

   • Planifier le rebalancement pendant les heures creuses
   • Surveiller les métriques pendant le rebalancement
   • Tester le rebalancement sur un environnement de test
   • Documenter les changements

1. Télécharger la dernière version stable depuis le site officiel Apache Kafka.

       
       # Décompression de l'archive
       $ tar -xzf kafka_2.13-3.4.0.tgz
       $ cd kafka_2.13-3.4.0
   
       # Démarrage de Zookeeper (pour les versions < 3.0)
       $ bin/zookeeper-server-start.sh config/zookeeper.properties
   
       # Démarrage de Kafka
       $ bin/kafka-server-start.sh config/server.properties
       
   

2. Configuration

   Les fichiers de configuration principaux sont :

   • server.properties : Configuration du broker
   • zookeeper.properties : Configuration de Zookeeper

3. Administration

   1. Commandes utiles

          
          # Créer un topic
          $ bin/kafka-topics.sh --create --topic my-topic --bootstrap-server localhost:9092 --partitions 3 --replication-factor 1
      
          # Lister les topics
          $ bin/kafka-topics.sh --list --bootstrap-server localhost:9092
      
          # Voir les détails d'un topic
          $ bin/kafka-topics.sh --describe --topic my-topic --bootstrap-server localhost:9092
      
          # Produire des messages
          $ bin/kafka-console-producer.sh --topic my-topic --bootstrap-server localhost:9092
      
          # Consommer des messages
          $ bin/kafka-console-consumer.sh --topic my-topic --bootstrap-server localhost:9092 --from-beginning
          
      

   2. Monitoring

      Kafka expose des métriques JMX qui peuvent être surveillées avec des outils comme Prometheus et Grafana.

4. Meilleures pratiques

   1. Utiliser des topics dédiés pour différents types de données
   2. Configurer correctement le nombre de partitions en fonction du débit attendu
   3. Utiliser des groupes de consommateurs distincts pour des usages différents
   4. Surveiller les métriques de latence et de débit
   5. Mettre en place une stratégie de rétention des données adaptée