Meilleures pratiques pour des stratégies de batching Kafka efficaces

Le batching Kafka contrôle le nombre d'enregistrements que vos clients envoient ou récupèrent par requête. Si les lots sont trop petits, vous gaspillez du CPU et des allers-retours réseau ; s'ils sont trop grands, vous ajoutez de la latence et rendez les échecs plus coûteux à relancer.

Les principaux paramètres sont batch.size et linger.ms pour le producteur, ainsi que fetch.min.bytes, fetch.max.wait.ms et max.poll.records pour le consommateur.

Comprendre le batching Kafka et les surcharges

Dans Kafka, la transmission des données se fait via TCP/IP. Envoyer des enregistrements un par un entraîne une surcharge significative liée aux accusés de réception TCP, à la latence réseau pour chaque requête et à une utilisation accrue du CPU pour la sérialisation et le cadrage des requêtes. Le batching atténue cela en accumulant localement les enregistrements avant de les envoyer sous forme d'une unité plus grande et contiguë. Cela améliore considérablement l'utilisation du réseau et réduit le nombre de trajets réseau nécessaires pour traiter le même volume de données.

Batching côté producteur : maximiser l'efficacité d'envoi

Le batching du producteur est sans doute le domaine le plus impactant pour l'optimisation des performances. L'objectif est de trouver le point idéal où la taille du lot est suffisamment grande pour amortir les coûts réseau, mais pas trop grande pour ne pas introduire une latence de bout en bout inacceptable.

Paramètres de configuration clés du producteur

Plusieurs paramètres critiques dictent la manière dont les producteurs créent et envoient les lots :

1. batch.size : Cela définit la taille maximale du tampon en mémoire du producteur pour les enregistrements en attente, mesurée en octets. Une fois ce seuil atteint, un lot est envoyé.

   • Meilleure pratique : Commencez près de la valeur par défaut du client, puis testez des valeurs plus grandes comme 64 Ko ou 128 Ko. De très grands lots peuvent améliorer le débit, mais seulement si vos enregistrements, partitions et objectifs de latence le permettent.

2. linger.ms : Ce paramètre spécifie le temps (en millisecondes) que le producteur attendra pour que d'autres enregistrements remplissent le tampon après l'arrivée de nouveaux enregistrements, avant d'envoyer un lot incomplet.

   • Compromis : Un linger.ms plus élevé augmente la taille du lot (meilleur débit) mais augmente également la latence pour les messages individuels.
   • Meilleure pratique : Pour les charges de travail orientées débit, testez de petites attentes comme 5-20 ms. Pour les applications à faible latence, gardez cette valeur basse et acceptez des lots plus petits.

3. buffer.memory : Cette configuration définit la mémoire totale allouée pour la mise en tampon des enregistrements non envoyés sur tous les sujets et partitions pour une seule instance de producteur. Si le tampon se remplit, les appels send() suivants seront bloqués.

   • Meilleure pratique : Gardez-le suffisamment grand pour les pics de charge sur toutes les partitions actives. S'il se remplit, send() peut bloquer jusqu'à max.block.ms puis échouer.

Exemple de configuration de batching pour le producteur (Java)

Properties props = new Properties();
props.put("bootstrap.servers", "kafka-broker:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

// Paramètres d'optimisation des performances
props.put("linger.ms", 10); // Attendre jusqu'à 10ms pour plus d'enregistrements
props.put("batch.size", 65536); // Cibler une taille de lot de 64 Ko
props.put("buffer.memory", 33554432); // 32 Mo d'espace tampon total

KafkaProducer<String, String> producer = new KafkaProducer<>(props);

Batching côté consommateur : extraction et traitement efficaces

Alors que le batching du producteur se concentre sur l'envoi efficace, le batching du consommateur optimise la charge de travail de réception et de traitement. Les consommateurs extraient les données des partitions par lots, et optimiser cela réduit la fréquence des appels réseau aux courtiers et limite les changements de contexte nécessaires au thread de l'application.

Paramètres de configuration clés du consommateur

1. fetch.min.bytes : C'est la quantité minimale de données (en octets) que le courtier doit retourner dans une seule requête de récupération. Le courtier retardera la réponse jusqu'à ce qu'au moins cette quantité de données soit disponible ou que le délai d'attente fetch.max.wait.ms soit atteint.

   • Avantage : Cela force le consommateur à demander des morceaux de données plus grands, similaire au batching du producteur.
   • Meilleure pratique : Augmentez-le lorsque le débit est plus important que la latence. Associez-le à fetch.max.wait.ms pour que le courtier n'attende pas trop longtemps pendant les périodes calmes.

2. fetch.max.bytes : Cela définit la quantité maximale de données (en octets) que le consommateur acceptera dans une seule requête de récupération. Cela agit comme un plafond pour éviter de submerger les tampons internes du consommateur.

3. max.poll.records : C'est crucial pour le débit de l'application. Cela contrôle le nombre maximal d'enregistrements retournés par un seul appel à consumer.poll().

   • Contexte : Lors du traitement des enregistrements dans une boucle de votre application consommateur, ce paramètre limite la portée du travail effectué lors d'une itération de votre boucle de sondage.
   • Meilleure pratique : Si vous avez de nombreuses partitions et un volume élevé, augmenter cette valeur (par exemple, de 500 à 1000 ou plus) permet au thread consommateur de traiter plus de données par cycle de sondage avant de devoir rappeler poll(), réduisant ainsi la surcharge de sondage.

Exemple de boucle de sondage du consommateur

Lors du traitement des enregistrements, assurez-vous de respecter max.poll.records pour maintenir un équilibre entre le travail accompli par sondage et la capacité à réagir rapidement aux rééquilibrages.

while (running) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));

    // Si max.poll.records est défini à 1000, cette boucle s'exécute au maximum 1000 fois
    for (ConsumerRecord<String, String> record : records) {
        process(record);
    }
    // Valider les offsets après le traitement du lot
    consumer.commitSync();
}

Avertissement sur max.poll.records : Définir cette valeur trop élevée peut causer des problèmes lors du rééquilibrage du consommateur. Si un rééquilibrage se produit, le consommateur doit traiter tous les enregistrements obtenus dans le poll() actuel avant de pouvoir quitter le groupe avec succès. Si le lot est excessivement grand, cela peut entraîner des délais d'attente de session longs et une instabilité inutile du groupe.

Considérations avancées sur le batching

L'optimisation du batching est un processus itératif dépendant des caractéristiques spécifiques de votre charge de travail (taille des enregistrements, objectif de débit et latence acceptable).

1. Variation de la taille des enregistrements

Si vos messages ont des tailles très variables, un batch.size fixe peut produire un batching inégal. Quelques grands enregistrements peuvent remplir rapidement les lots, tandis que les petits enregistrements peuvent nécessiter linger.ms pour se regrouper efficacement.

• Astuce : Si les messages sont constamment grands, testez un linger.ms plus bas et surveillez la latence des requêtes, la disponibilité du tampon et les métriques de requêtes du courtier.

2. Compression

Le batching et la compression fonctionnent bien ensemble. Compresser un lot plus grand donne généralement une meilleure compression que de compresser de petites requêtes. Envisagez snappy, lz4 ou zstd, puis mesurez le coût CPU sur les clients et les courtiers.

3. Idempotence et nouvelles tentatives

Bien que cela ne soit pas strictement du batching, assurez-vous que enable.idempotence=true est vital. Lorsque vous envoyez de grands lots, la probabilité que des erreurs réseau transitoires affectent un sous-ensemble d'enregistrements augmente. L'idempotence garantit que si le producteur réessaie d'envoyer un lot en raison d'un échec temporaire, Kafka déduplique les messages, empêchant ainsi la duplication lors d'une livraison réussie.

Objectifs d'optimisation du batching

Configuration	Objectif	Impact sur le débit	Impact sur la latence
Producteur batch.size	Maximiser les données par requête	Augmentation élevée	Augmentation modérée
Producteur linger.ms	Attendre brièvement le remplissage	Augmentation élevée	Augmentation modérée
Consommateur fetch.min.bytes	Demander des morceaux plus grands	Augmentation modérée	Augmentation modérée
Consommateur max.poll.records	Réduire la surcharge de sondage	Augmentation modérée	Changement minimal

Commencez avec une charge de travail de producteur et un groupe de consommateurs, modifiez un paramètre de batching à la fois, et comparez le débit, la latence p95, les nouvelles tentatives et le retard du consommateur. Un batching Kafka efficace est un exercice de mesure, pas un bloc de configuration à définir une fois pour toutes.