Meilleures pratiques de configuration Kafka pour les environnements de production

Kafka est indulgent en développement et beaucoup moins indulgent en production. Un sujet avec une seule réplique fonctionne bien jusqu'à ce qu'un broker tombe en panne. Un producteur avec des accusés de réception faibles semble rapide jusqu'à ce que des messages disparaissent lors d'une défaillance. Un consommateur qui valide automatiquement les offsets semble simple jusqu'à ce qu'il valide un travail qu'il n'a pas réellement terminé. La configuration de Kafka en production consiste principalement à décider quelles défaillances vous êtes prêt à tolérer, puis à rendre ces décisions explicites.

Ce guide couvre les meilleures pratiques de configuration Kafka pour les environnements de production sans prétendre qu'il existe un fichier de configuration parfait. Les bons réglages dépendent de la charge de travail, des besoins en latence, des exigences de durabilité, de la maturité opérationnelle et de la version de Kafka. Les exemples ci-dessous sont des points de départ que vous devez tester sous votre propre trafic.

Comprendre les composants clés de Kafka et leur configuration

Avant de plonger dans les configurations spécifiques, il est crucial de comprendre les composants principaux de Kafka et comment leurs paramètres impactent le comportement global du système.

Brokers : Les serveurs Kafka qui stockent les données et répondent aux requêtes des clients. La configuration du broker dicte les performances, l'utilisation des ressources et la tolérance aux pannes.
Sujets : Catégories ou flux de messages qui sont publiés.
Partitions : Les sujets sont divisés en une ou plusieurs partitions, permettant le parallélisme dans le traitement et le stockage.
Réplication : Le processus de copie des partitions sur plusieurs brokers pour garantir la durabilité et la disponibilité des données en cas de panne d'un broker.
Groupes de consommateurs : Un groupe de consommateurs qui coopèrent pour consommer des messages d'un sujet. Kafka garantit que chaque message d'un sujet est livré à au plus un consommateur au sein de chaque groupe de consommateurs.

Stratégies de sujets et de partitionnement

Une configuration efficace des sujets et des partitions est fondamentale pour l'évolutivité et les performances de Kafka.

Nombre de partitions

Choisir le bon nombre de partitions est une décision critique. Plus de partitions permettent un parallélisme plus élevé du côté du consommateur, ce qui signifie que davantage d'instances de consommateurs peuvent traiter les données simultanément. Cependant, trop de partitions peuvent solliciter les ressources du broker (mémoire, E/S disque) et augmenter la latence. Une règle empirique courante consiste à commencer avec un nombre de partitions qui reflète votre débit de consommation maximal attendu, en considérant que vous pourriez vouloir ajouter plus de partitions plus tard si nécessaire.

Considération : Le nombre maximum de partitions qu'un broker peut gérer est limité par sa mémoire. Chaque partition nécessite de la mémoire pour ses répliques leader et suiveuse.
Recommandation : Visez un nombre de partitions qui correspond à vos besoins de parallélisme de consommation, mais évitez un partitionnement excessif. Surveillez l'utilisation des ressources du broker pour trouver un équilibre optimal.

Clé de partitionnement

Lors de la production de messages, une clé de partitionnement (souvent une clé d'enregistrement) détermine dans quelle partition un message sera écrit. Un partitionnement cohérent est essentiel pour un traitement ordonné au sein d'un groupe de consommateurs.

partitioner.class : Cette configuration du producteur peut être définie sur org.apache.kafka.clients.producer.internals.DefaultPartitioner (par défaut, utilise un hachage de la clé) ou un partitionneur personnalisé.
Meilleure pratique : Utilisez une clé qui distribue les messages uniformément entre les partitions. Si les messages avec la même clé doivent être traités dans l'ordre, Kafka garantit l'ordre uniquement au sein d'une partition.

Réplication et tolérance aux pannes

La réplication est le mécanisme principal de Kafka pour garantir la durabilité et la disponibilité des données.

Facteur de réplication

Le facteur de réplication détermine combien de copies de chaque partition sont maintenues dans le cluster. Pour les environnements de production, un facteur de réplication minimum de 3 est fortement recommandé.

Avantage : Avec un facteur de réplication de 3, Kafka peut généralement tolérer une panne de broker tout en gardant une autre réplique disponible. La disponibilité exacte dépend de min.insync.replicas, des acks du producteur, des paramètres d'élection du leader et des brokers qui tombent en panne.
Configuration : Ceci est défini au niveau du sujet, soit lors de la création du sujet, soit via les commandes kafka-topics.sh.

# Exemple : Créer un sujet avec un facteur de réplication de 3
kafka-topics.sh --create --topic mon-sujet-de-production --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

Ce paramètre de configuration du broker dicte le nombre minimum de répliques qui doivent accuser réception d'une opération d'écriture avant qu'elle ne soit considérée comme réussie. Pour les sujets avec un facteur de réplication de N, définir min.insync.replicas=M (où M < N) garantit qu'une écriture est accusée réception seulement après que M répliques l'ont confirmée. Pour éviter la perte de données, min.insync.replicas doit généralement être défini sur N-1 ou N/2 + 1 en fonction de vos compromis entre disponibilité et durabilité.

Recommandation : Pour les sujets critiques, définissez min.insync.replicas sur facteur_de_réplication - 1. Cela garantit qu'au moins deux répliques (dans une configuration à 3 répliques) ont les données avant d'accuser réception de l'écriture, empêchant ainsi la perte si le leader tombe en panne.
Configuration : Il s'agit d'une configuration au niveau du broker et peut également être définie par sujet.

# broker.properties
min.insync.replicas=2

# Configuration au niveau du sujet (remplace le paramètre du broker)
# kafka-configs.sh --alter --topic mon-sujet-critique --bootstrap-server ... --add-config min.insync.replicas=2

Élection du leader et contrôleur

Kafka utilise un broker contrôleur pour gérer l'état du cluster, y compris la direction des partitions. Des configurations robustes du contrôleur sont essentielles.

controller.quorum.voters : Dans les clusters basés sur KRaft, cela spécifie les électeurs du quorum du contrôleur. Les clusters basés sur ZooKeeper utilisent une configuration de plan de contrôle différente, donc ne copiez pas ce paramètre aveuglément entre les architectures.
num.io.threads et num.network.threads : Ces paramètres du broker contrôlent le nombre de threads dédiés à la gestion des E/S et des requêtes réseau. Ajustez en fonction de la charge de travail et du CPU disponible.

Configurations du producteur et du consommateur

L'optimisation des paramètres du producteur et du consommateur est essentielle pour atteindre un débit élevé et une faible latence.

Configurations du producteur

acks : Contrôle le nombre d'accusés de réception requis des répliques. Définir acks=all (ou -1) offre la garantie de durabilité la plus forte. Combiné avec min.insync.replicas, c'est crucial pour la production.
retries : Définissez une valeur élevée (par exemple, Integer.MAX_VALUE) pour garantir que les défaillances transitoires n'entraînent pas de perte de messages. Utilisez max.in.flight.requests.per.connection efficacement avec les tentatives.
max.in.flight.requests.per.connection : Contrôle le nombre maximum de requêtes non accusées réception qui peuvent être envoyées à un broker. Les anciens clients utilisaient souvent 1 pour éviter le réordonnancement avec les tentatives. Les producteurs idempotents modernes peuvent préserver l'ordre avec des limites de sécurité plus élevées, mais vérifiez votre version client et vos paramètres.
batch.size et linger.ms : Ces paramètres contrôlent le regroupement des messages. Des lots plus grands peuvent améliorer le débit mais augmentent la latence. linger.ms ajoute un petit délai pour permettre à plus de messages d'être regroupés.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

Configurations du consommateur

auto.offset.reset : Pour la production, latest est souvent préféré pour éviter de retraiter les anciens messages au redémarrage. earliest peut être utilisé si vous devez retraiter les messages depuis le début.
enable.auto.commit : Définissez sur false pour un traitement fiable. Les validations manuelles vous donnent le contrôle sur le moment où les offsets sont validés, empêchant la redistribution ou la perte de messages. Utilisez commitSync() ou commitAsync() pour les validations explicites.
max.poll.records : Contrôle le nombre maximum d'enregistrements retournés dans un seul appel poll(). Ajustez pour gérer la charge de traitement et éviter les rééquilibrages des consommateurs.
isolation.level : Définissez sur read_committed lors de l'utilisation de transactions Kafka pour garantir que les consommateurs ne lisent que les messages validés.

# consumer.properties
group.id=mon-groupe-consommateur
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

Considérations de sécurité

Sécuriser votre cluster Kafka est incontournable dans les environnements de production.

Authentification et autorisation

SSL/TLS : Chiffrez la communication entre les clients et les brokers, et entre les brokers eux-mêmes. Cela nécessite la génération et la distribution de certificats.
SASL (Simple Authentication and Security Layer) : Utilisez des mécanismes SASL comme GSSAPI (Kerberos), PLAIN ou SCRAM pour authentifier les clients.
Autorisation (ACL) : Configurez des listes de contrôle d'accès (ACL) pour définir quels utilisateurs ou principaux peuvent effectuer des opérations spécifiques (lire, écrire, créer un sujet, etc.) sur quelles ressources (sujets, groupes de consommateurs).

Chiffrement

ssl.enabled.protocols : Assurez-vous d'utiliser des protocoles sécurisés comme TLSv1.2 ou TLSv1.3.
ssl.cipher.suites : Configurez des suites de chiffrement robustes.

Exemple de configuration (Producteur avec SASL sur TLS)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="monutilisateur" password="monmotdepasse";
ssl.truststore.location=/chemin/vers/truststore.jks
ssl.truststore.password=motdepasse

Réglage des performances et surveillance

Une surveillance et un réglage continus sont essentiels pour maintenir des performances optimales.

Réglage du broker

num.partitions : Bien qu'il s'agisse d'un paramètre au niveau du sujet, le broker doit gérer le nombre total de partitions. Surveillez le CPU, la mémoire et les E/S disque.
log.segment.bytes et log.roll.hours : Contrôlent la taille et la fréquence de roulement des segments de journal. Des segments plus petits peuvent entraîner plus de descripteurs de fichiers ouverts et une surcharge accrue. Des segments plus grands peuvent consommer plus d'espace disque par segment mais réduisent la surcharge.
message.max.bytes : La taille maximale d'un message en octets. Assurez-vous qu'elle est suffisamment grande pour votre cas d'utilisation, mais pas excessivement.
replica.fetch.max.bytes : Contrôle le nombre maximum d'octets par requête de récupération par une réplique suiveuse. Ajustez pour équilibrer l'efficacité de la récupération et l'utilisation de la mémoire.

Réglage JVM

Taille du tas : Allouez suffisamment de mémoire de tas pour la JVM exécutant Kafka. Surveillez l'utilisation du tas et l'activité du GC.
Garbage Collector : Choisissez un algorithme GC approprié (par exemple, G1GC est souvent recommandé pour Kafka).

Surveillance

Mettez en œuvre une surveillance complète à l'aide d'outils comme Prometheus/Grafana, Datadog ou des solutions de surveillance spécifiques à Kafka.

Métriques clés : Surveillez la santé du broker, le débit des sujets, le retard des consommateurs, l'état de la réplication, la latence des requêtes et l'utilisation des ressources (CPU, mémoire, disque, réseau).
Alertes : Configurez des alertes pour les conditions critiques comme un retard élevé des consommateurs, une absence de réponse du broker ou l'épuisement de l'espace disque.

Rééquilibrages des groupes de consommateurs

Les rééquilibrages des groupes de consommateurs se produisent lorsque des consommateurs rejoignent ou quittent un groupe, ou lorsque des partitions sont réaffectées. Des rééquilibrages fréquents peuvent perturber le traitement.

session.timeout.ms : Combien de temps un broker attend qu'un consommateur envoie un battement de cœur avant de le considérer comme mort. Des valeurs plus basses signifient une détection plus rapide mais peuvent entraîner des rééquilibrages prématurés en raison de problèmes réseau.
heartbeat.interval.ms : À quelle fréquence les consommateurs envoient des battements de cœur. Doit être nettement inférieur à session.timeout.ms.
max.poll.interval.ms : Le temps maximum entre les appels poll d'un consommateur. Si un consommateur prend plus de temps que cela pour traiter les messages et rappeler poll, il sera considéré comme mort, déclenchant un rééquilibrage. Assurez-vous que vos consommateurs peuvent traiter les messages dans cet intervalle.
Astuce : Optimisez la logique de traitement du consommateur pour terminer le travail dans max.poll.interval.ms et évitez les rééquilibrages inutiles dus à des consommateurs lents.

Paramètres par défaut de production que je déciderais explicitement

Ne laissez pas un comportement important de Kafka aux paramètres par défaut accidentels. Certains paramètres par défaut sont raisonnables pour un usage général, mais les systèmes de production ont besoin de décisions qui correspondent aux données.

Pour les flux d'événements critiques, utilisez un facteur de réplication de 3 ou plus lorsque le cluster a suffisamment de brokers et de racks pour le supporter. Associez cela à acks=all sur les producteurs et min.insync.replicas=2 sur un sujet à trois répliques. Cette combinaison signifie qu'une écriture n'est accusée réception que lorsque le leader et au moins un suiveur en synchronisation l'ont. Si trop de répliques se désynchronisent, les producteurs reçoivent des erreurs au lieu d'accepter silencieusement une durabilité plus faible.

Ce compromis est intentionnel. Lors d'une défaillance, un sujet hautement durable peut rejeter les écritures plutôt que d'accuser réception de données qui ne se trouvent que sur un seul broker. Certains systèmes préfèrent la disponibilité à la durabilité pour certaines données de télémétrie ou de clics. C'est acceptable si c'est un choix conscient. C'est dangereux lorsque personne ne réalise que le sujet a été configuré de cette façon.

Désactivez l'élection de leader non propre pour les sujets où la perte de données n'est pas acceptable. Une élection non propre peut ramener une partition en ligne en élisant une réplique désynchronisée, mais cette réplique peut manquer des enregistrements accusés réception en fonction de l'historique des défaillances et des paramètres du producteur. Pour les données critiques, rester indisponible est souvent mieux que de perdre ou de rembobiner des enregistrements sans avertissement.

Nombre de partitions : Choisissez pour le débit et les opérations

Le nombre de partitions contrôle le parallélisme, mais plus de partitions ne sont pas gratuites. Chaque partition ajoute des métadonnées, des descripteurs de fichiers, du travail de réplication, du travail d'élection du leader et une surcharge de récupération. Cela affecte également le comportement du groupe de consommateurs. Un sujet avec 200 partitions peut supporter plus de parallélisme de consommateurs qu'un sujet avec 12, mais il crée également plus de pièces mobiles lors des redémarrages de broker et des rééquilibrages.

Commencez par estimer le parallélisme et le débit des consommateurs. Si le service consommateur fonctionnera avec au plus 12 instances, 48 partitions peuvent être suffisantes. Si vous attendez des centaines de threads de traitement indépendants, vous pourriez en avoir besoin de plus. Laissez de la place pour la croissance, car augmenter les partitions plus tard peut modifier la distribution des clés et le comportement d'ordre pour les messages avec clé.

L'ordre n'est garanti qu'au sein d'une partition. Si tous les événements pour client_id=123 doivent être traités dans l'ordre, utilisez une clé stable basée sur cet ID client. Ne vous attendez pas à un ordre sur l'ensemble du sujet. Surveillez également les clés chaudes. Si un client, un locataire ou un appareil produit une grande part du trafic, le partitionnement basé sur les clés peut surcharger une partition tandis que d'autres restent inactives.

Pour les systèmes multi-locataires, demandez-vous s'il est plus facile d'exploiter un sujet partagé ou plusieurs sujets par locataire. De nombreux petits sujets peuvent créer une surcharge de métadonnées. Un énorme sujet partagé peut compliquer la rétention, le contrôle d'accès et la réponse aux incidents. Le meilleur choix dépend des exigences d'isolement et de la forme du trafic.

La rétention est une décision produit, pas seulement un paramètre du broker

La rétention Kafka détermine combien de temps les données restent disponibles pour une relecture. Une rétention courte économise le disque mais limite la récupération. Une rétention longue permet les rechargements et les workflows d'audit mais augmente le coût de stockage et le temps de récupération.

Définissez la rétention par sujet en fonction de la façon dont les données sont utilisées. Un sujet de commande peut n'avoir besoin que d'une courte fenêtre. Un sujet d'historique d'événements peut avoir besoin de jours ou de semaines. Un sujet compacté qui représente le dernier état utilise un modèle différent : Kafka conserve la valeur la plus récente par clé après compactage, plus les pierres tombales pour les suppressions jusqu'au nettoyage.

Les paramètres courants incluent :

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

Pour les sujets compactés :

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

Soyez prudent avec les gros messages. Kafka peut gérer des enregistrements plus volumineux lorsqu'il est configuré de manière cohérente, mais augmenter message.max.bytes implique de vérifier max.request.size du producteur, fetch.max.bytes du consommateur, les paramètres de récupération des répliques du broker et l'impact sur la mémoire. Dans de nombreux systèmes, stocker les charges utiles volumineuses dans un stockage d'objets et envoyer une référence via Kafka est plus simple et plus fiable.

Paramètres du producteur qui évitent la douleur

Pour la plupart des producteurs de production, activez l'idempotence sauf si vous avez une raison spécifique de ne pas le faire. La production idempotente aide à prévenir les écritures en double causées par les tentatives après des défaillances transitoires. De nombreux clients Kafka modernes l'activent automatiquement sous certaines configurations, mais il vaut la peine de rendre la décision visible dans votre configuration de producteur.

Exemple de base de producteur :

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

Le choix de la compression dépend du budget CPU et de la version de Kafka. zstd offre souvent une forte compression, tandis que lz4 et snappy sont des choix courants à faible latence. Testez avec vos charges utiles. Les logs JSON, les enregistrements Avro, les messages protobuf et les données binaires déjà compressées se comportent différemment.

Le regroupement est un autre compromis. Un petit linger.ms donne au producteur une courte fenêtre pour regrouper les enregistrements, ce qui peut améliorer le débit et la compression. Le définir trop haut ajoute de la latence. Pour les chemins de requêtes orientés utilisateur, gardez à l'esprit les budgets de latence. Pour l'ingestion en arrière-plan, un peu plus de temps de latence peut être acceptable.

N'ignorez pas les erreurs du producteur. Si acks=all et min.insync.replicas rejettent une écriture en cas de problème de broker, c'est une contre-pression utile. L'application doit décider de réessayer, de mettre en mémoire tampon, d'échouer la requête ou de la rediriger vers un repli. Journaliser l'erreur et abandonner l'événement n'est pas une stratégie de durabilité.

Paramètres du consommateur qui correspondent à la sémantique de traitement

Les validations d'offset du consommateur définissent ce que signifie "traité". Avec enable.auto.commit=true, le client peut valider les offsets avant que votre application n'ait terminé le travail en toute sécurité. Cela peut être acceptable pour des analyses jetables, mais c'est risqué pour les paiements, les commandes, les déploiements ou tout ce où manquer un événement fait mal.

Pour un traitement fiable, désactivez la validation automatique et validez après que le travail est terminé :

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

La stratégie de validation dépend de l'application. commitSync() est plus simple et donne un comportement d'échec clair, mais peut ajouter de la latence. commitAsync() peut améliorer le débit, mais vous devez gérer soigneusement les échecs de rappel. De nombreux services valident périodiquement après des lots réussis et rendent les écritures en aval idempotentes afin que la relecture soit sûre.

Si le traitement d'un message peut prendre beaucoup de temps, réduisez max.poll.records, augmentez max.poll.interval.ms, ou déplacez le travail lent derrière une file d'attente interne pendant que la boucle de sondage continue de manière responsable. Un consommateur qui arrête de sonder trop longtemps déclenche un rééquilibrage, et des rééquilibrages répétés donnent l'impression que tout le groupe est instable.

Utilisez l'appartenance statique pour les consommateurs qui redémarrent fréquemment mais reviennent avec des identités stables. Cela peut réduire les rééquilibrages inutiles lors des déploiements progressifs. Le rééquilibrage coopératif peut également réduire les perturbations par rapport au rééquilibrage impatient, selon le support client.

Sécurité que les équipes peuvent exploiter

Kafka en production doit utiliser le chiffrement en transit lorsque le trafic traverse des réseaux non fiables ou transporte des données sensibles. La plupart des organisations devraient utiliser TLS pour la communication client-broker et inter-broker. L'authentification peut être TLS mutuel, SASL/SCRAM, Kerberos, OAuth ou un autre mécanisme pris en charge selon l'environnement.

Les ACL doivent être suffisamment spécifiques pour éviter les dommages accidentels. Un producteur pour commandes.créées n'a pas besoin d'autorisation pour écrire sur chaque sujet. Un groupe de consommateurs pour la facturation n'a pas besoin d'autorisation pour modifier les configurations du broker. Utilisez des conventions de nommage qui rendent les ACL lisibles et maintenez les principaux de service liés aux applications plutôt qu'à des humains individuels.

Les secrets ont besoin de rotation. Si les identifiants SASL ou les magasins de clés sont copiés manuellement sur les serveurs, la rotation devient douloureuse et finit par ne plus se produire. Utilisez le gestionnaire de secrets de votre plateforme lorsque c'est possible. Testez la rotation en staging, y compris les redémarrages progressifs des clients.

Décidez également qui peut créer des sujets. La création automatique de sujets est pratique en développement et dangereuse en production. Une faute de frappe dans un nom de sujet peut créer un nouveau sujet avec des partitions par défaut, une réplication par défaut et une rétention par défaut. De nombreux clusters de production désactivent la création automatique de sujets et gèrent les sujets via du code d'infrastructure ou un workflow approuvé.

Vérifications du broker et du stockage

Kafka est sensible au disque. Utilisez un stockage avec une latence prévisible, surveillez agressivement l'utilisation du disque et conservez suffisamment d'espace libre pour la rétention, le rattrapage de réplication et les erreurs opérationnelles. Un broker avec un disque plein peut créer un incident beaucoup plus important qu'un broker avec un CPU élevé.

Séparez les logs Kafka des charges de travail bruyantes non liées. Évitez de placer les données Kafka sur des disques partagés où un autre processus peut soudainement consommer des E/S. Dans les environnements cloud, comprenez les limites de débit du volume, les crédits de rafale et le comportement de récupération. Un disque qui donne de bons résultats pendant une minute peut encore avoir du mal sous une réplication et un compactage soutenus.

La conscience des racks est importante lorsque vous avez plusieurs zones de disponibilité ou racks. Configurez les ID de rack des brokers et le placement des sujets afin que les répliques ne soient pas toutes dans le même domaine de défaillance. Un facteur de réplication de 3 est moins utile si les trois répliques disparaissent avec un seul problème de rack ou de zone.

Surveillance et alertes qui détectent les vraies défaillances

Une configuration de surveillance Kafka utile surveille à la fois les éléments internes de Kafka et l'expérience client. Les métriques du broker seules ne vous disent pas si les consommateurs suivent le rythme ou si les producteurs voient des erreurs.

Surveillez les partitions sous-répliquées, les partitions hors ligne, le nombre de contrôleurs actifs, la latence des requêtes, les taux d'erreur de production et de récupération, le débit réseau, l'utilisation du disque, la latence des E/S disque, les taux de rétrécissement et d'expansion de l'ISR, le temps de file d'attente des événements du contrôleur, le retard des consommateurs, le taux de rééquilibrage et les nombres de tentatives/erreurs des clients.

Le retard des consommateurs a besoin de contexte. Un retard de 100 enregistrements peut être acceptable sur un sujet qui reçoit des millions par heure. Un retard de 100 peut être grave sur un sujet à faible volume de commandes. Alertez sur l'âge du retard ou le temps de rattrapage lorsque vous le pouvez, pas seulement sur le nombre brut d'enregistrements.

Testez les redémarrages de broker pendant les fenêtres de maintenance avant la première vraie défaillance. Un cluster Kafka de production devrait survivre à un redémarrage planifié de broker sans perte de données et sans surprendre les clients. Si un redémarrage de broker crée un incident majeur, le cluster était déjà fragile.

Un passage en revue de la préparation à la production

Avant de déclarer un cluster Kafka prêt pour la production, je vérifierais ces éléments :

Les sujets critiques ont des partitions explicites, un facteur de réplication, une rétention, une politique de nettoyage et min.insync.replicas.
Les producteurs pour les sujets critiques utilisent acks=all, l'idempotence là où elle est prise en charge, les tentatives et une gestion claire des erreurs.
Les consommateurs ne valident les offsets qu'après que l'application a atteint son point de traitement prévu.
TLS, l'authentification et les ACL sont activés et testés.
La création automatique de sujets est désactivée ou strictement contrôlée.
La surveillance couvre la santé du broker, les erreurs client, le retard des consommateurs, le disque et la réplication.
Les attentes de sauvegarde ou de relecture sont documentées. La rétention Kafka ne remplace pas tous les besoins de sauvegarde.
Les procédures de redémarrage de broker, de déploiement client et de rotation des identifiants ont été testées.

L'essentiel pratique

La configuration de Kafka en production est un ensemble de compromis, pas une recette universelle. Rendez les choix de durabilité, d'ordre, de relecture, de sécurité et de latence explicites par sujet et par application. Ensuite, testez ces choix avec des redémarrages de broker, des défaillances client, des consommateurs lents et des scénarios de disque plein avant que le trafic de production ne vous donne la leçon.