Rétention des données Kafka : comprendre et gérer vos flux d'événements

La rétention des données Kafka répond à une question pratique : combien de temps vos flux d'événements doivent-ils rester sur le disque avant que Kafka puisse les supprimer ? Si vos paramètres sont trop laxistes, les courtiers peuvent manquer d'espace. S'ils sont trop agressifs, un consommateur lent peut perdre la possibilité de rejouer les données.

Kafka stocke les enregistrements dans des journaux de partitions. Ces journaux sont divisés en fichiers de segments, et le nettoyage de la rétention supprime les anciens segments fermés. Ce détail compte car Kafka ne supprime généralement pas un enregistrement à la fois dès qu'il devient ancien. Un segment devient éligible uniquement lorsqu'il répond aux règles de rétention configurées.

Pourquoi les paramètres de rétention sont importants

La rétention est un compromis entre le stockage, les besoins de rejeu et le risque opérationnel.

Coût de stockage : Une rétention longue sur des sujets à fort volume peut consommer beaucoup d'espace disque du courtier.
Récupération des consommateurs : Votre fenêtre de rétention doit être plus longue que la plus longue panne réaliste d'un consommateur ou la fenêtre de retraitement.
Stabilité : Des disques pleins peuvent empêcher les courtiers d'accepter des écritures et peuvent déclencher des problèmes plus larges dans le cluster.
Conformité : Certaines données doivent être conservées pendant une période minimale, tandis que d'autres doivent être supprimées rapidement.

Un sujet de paiements peut nécessiter plusieurs jours d'historique de rejeu. Un sujet de journaux de débogage dans un cluster de développement peut n'avoir besoin que de quelques heures.

Comment Kafka supprime les anciennes données

Les sujets Kafka sont divisés en partitions. Chaque partition est un journal ordonné en ajout seul. Kafka écrit les nouveaux enregistrements dans le segment actif et passe à un nouveau segment lorsque le segment actuel atteint une taille ou un âge configuré.

La rétention s'applique par partition. Si vous définissez retention.bytes=1073741824, cela représente environ 1 Gio par partition, pas 1 Gio pour l'ensemble du sujet. Un sujet avec 12 partitions peut donc conserver environ 12 Gio avant que les répliques ne soient comptées.

Lorsque la rétention basée sur le temps et celle basée sur la taille sont toutes deux configurées, Kafka peut supprimer les anciens segments éligibles lorsque l'une ou l'autre limite nécessite un nettoyage.

Rétention basée sur le temps

La rétention basée sur le temps conserve les enregistrements pendant une période configurée.

Au niveau du courtier, log.retention.ms définit la valeur par défaut pour les sujets qui ne la remplacent pas. Au niveau du sujet, retention.ms remplace cette valeur par défaut pour un sujet.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --alter \
  --add-config retention.ms=259200000

Cet exemple définit orders à trois jours. Vérifiez-le avec :

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --describe

Utilisez la rétention temporelle lorsque votre exigence principale est une fenêtre de rejeu, par exemple "les consommateurs doivent pouvoir récupérer après une panne de week-end".

Rétention basée sur la taille

La rétention basée sur la taille limite la quantité de données de journal que chaque partition peut conserver.

Au niveau du courtier, log.retention.bytes définit la limite par défaut par partition. Au niveau du sujet, retention.bytes la remplace pour un sujet. Une valeur de -1 signifie aucune limite de taille de ce paramètre.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name high-volume-logs \
  --alter \
  --add-config retention.bytes=1073741824

Cela définit une limite de 1 Gio par partition. Utilisez la rétention par taille lorsque la protection du disque est plus importante qu'une fenêtre temporelle fixe. Soyez prudent avec les sujets à rafales, car un pic de trafic peut raccourcir la fenêtre de rejeu effective.

Valeurs par défaut du courtier et surcharges de sujets

Les valeurs par défaut du courtier se trouvent dans server.properties et s'appliquent aux sujets qui ne définissent pas leurs propres valeurs de rétention.

log.retention.ms=604800000
log.retention.bytes=-1
log.retention.check.interval.ms=300000

Modifier les valeurs par défaut du courtier nécessite généralement un redémarrage du courtier ou une modification dynamique de la configuration du courtier, selon votre version de Kafka et vos outils de déploiement. Les modifications au niveau du sujet via kafka-configs.sh sont souvent plus sûres car différents sujets ont rarement besoin de la même fenêtre de rétention.

Pour un nouveau sujet, définissez la rétention lors de sa création :

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic audit-events \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=2147483648

Pour un sujet existant, modifiez la configuration du sujet :

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --add-config retention.ms=1209600000

Pour revenir à la valeur par défaut du courtier, supprimez la surcharge du sujet :

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --delete-config retention.ms

Rétention et compaction des journaux

Le nettoyage Kafka est contrôlé par cleanup.policy. Les valeurs courantes sont delete, compact, ou les deux comme compact,delete.

delete supprime les anciens segments de journal en fonction du temps ou de la taille de rétention.
compact conserve la dernière valeur pour chaque clé et supprime les valeurs plus anciennes pour cette clé au fil du temps.
compact,delete permet aux règles de compaction et de suppression de s'appliquer.

La compaction est utile pour les sujets de type journal des modifications, comme les mises à jour de profils clients indexées par ID client. Ce n'est pas un remplacement général de la rétention. Les pierres tombales et la rétention de suppression ont leur propre comportement temporel, alors testez les sujets compactés avant de compter sur eux pour le nettoyage.

Liste de contrôle pratique pour la rétention

Commencez par la plus longue panne de consommateur que vous pouvez tolérer. Si un groupe de consommateurs peut être hors ligne pendant 48 heures, une fenêtre de rétention de 24 heures est trop courte.

Estimez les besoins en disque avant de modifier les sujets de production :

taux d'ingestion par seconde x secondes conservées x nombre de partitions x facteur de réplication

Ce n'est qu'une estimation car la compression, la taille des enregistrements, les index et la surcharge des segments affectent le nombre réel. Néanmoins, cela vous donne un point de départ utile.

Surveillez ensemble l'utilisation du disque du courtier, le taux de croissance des sujets, les partitions sous-répliquées et le retard des consommateurs. La pression sur le disque associée à un retard croissant est un avertissement que les consommateurs peuvent sortir de la fenêtre de rétention.

La valeur par défaut la plus sûre est simple : utilisez la rétention au niveau du sujet, documentez pourquoi chaque sujet à fort volume a son paramètre, et testez une rétention plus courte en préproduction avant de l'appliquer à la production.