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

Kafka, une plateforme de streaming d'événements distribuée, est réputée pour son débit élevé, sa tolérance aux pannes et son architecture évolutive. Au cœur de son fonctionnement, Kafka traite toutes les données entrantes comme un journal immuable d'événements, ajoutant continuellement de nouveaux messages. Cependant, cette nature d'ajout uniquement soulève une question cruciale : combien de temps ces données doivent-elles persister ? Cet article explore les politiques de rétention des données de Kafka, expliquant les mécanismes cruciaux qui dictent la durée de stockage de vos précieux flux d'événements et comment les gérer efficacement pour optimiser le stockage, les performances et la conformité.

Comprendre et configurer correctement la rétention des données est primordial pour tout déploiement Kafka. Des paramètres inappropriés peuvent entraîner un épuisement rapide du disque, une dégradation des performances ou, inversement, une perte prématurée de données qui affecte les consommateurs en aval, l'analytique ou les exigences de conformité. Nous examinerons les principales stratégies que Kafka emploie pour la rétention des données — basées sur le temps et basées sur la taille — et fournirons des conseils pratiques sur la manière de configurer et de surveiller ces paramètres pour garantir que vos clusters Kafka fonctionnent de manière efficace et fiable.

L'importance de la rétention des données dans Kafka

La rétention des données n'est pas seulement un paramètre technique ; c'est une décision stratégique ayant des implications significatives pour l'ensemble de votre écosystème de données. Sa gestion efficace implique de trouver un équilibre entre plusieurs facteurs critiques :

• Coûts de stockage : Stocker indéfiniment de grandes quantités de données historiques peut devenir prohibitif, en particulier dans les environnements cloud où le stockage est facturé. Des politiques de rétention efficaces garantissent que vous ne conservez les données que le temps où elles sont réellement nécessaires.
• Performance et stabilité : Bien que Kafka soit conçu pour l'échelle, des fichiers journaux excessivement volumineux peuvent affecter les temps de démarrage des brokers, les processus de récupération après des pannes et la stabilité globale du système. Une rétention appropriée aide à maintenir des tailles de journaux gérables.
• Conformité et gouvernance : Les exigences réglementaires (par exemple, RGPD, HIPAA) dictent souvent la durée pendant laquelle certains types de données doivent être conservés ou, inversement, la rapidité avec laquelle elles doivent être purgées. Les politiques de rétention de Kafka sont un outil clé pour répondre à ces obligations.
• Besoins des consommateurs : Les applications en aval, les entrepôts de données ou les outils analytiques peuvent nécessiter un accès aux données historiques pour le retraitement, la récupération d'erreurs ou l'analytique par lots. Les paramètres de rétention doivent correspondre à la fenêtre de retraitement maximale attendue par vos consommateurs.

Bases de la gestion des journaux de Kafka

Kafka stocke les messages dans des topics (sujets), qui sont logiquement divisés en partitions. Chaque partition est une séquence ordonnée et immuable de messages, semblable à un journal d'engagement. De nouveaux messages sont toujours ajoutés à la fin du journal de la partition. Physiquement, le journal de chaque partition est décomposé en segments de journal — des fichiers sur le disque du broker. Lorsqu'un segment de journal atteint une certaine taille ou un certain âge, Kafka le « roule », créant un nouveau segment actif pour les messages entrants et marquant l'ancien comme fermé. Les politiques de rétention des données fonctionnent principalement en supprimant ces segments de journal fermés et plus anciens.

Kafka offre deux stratégies principales pour la rétention des données :

1. Rétention basée sur le temps : Supprime les messages plus anciens qu'une durée spécifiée.
2. Rétention basée sur la taille : Supprime les messages les plus anciens une fois que la taille totale d'une partition dépasse une limite définie.

Ces politiques sont appliquées par partition. Lorsque les deux sont configurées, la politique de rétention qui déclenche la suppression en premier l'emporte.

Rétention des données basée sur le temps (log.retention.ms)

La rétention basée sur le temps est la stratégie la plus couramment utilisée. Elle stipule que tout message plus ancien qu'une durée spécifiée sera éligible à la suppression. Cela garantit que les données historiques ne s'accumulent pas indéfiniment.

Paramètres de configuration :

• log.retention.ms : Cette propriété au niveau du broker définit la période de rétention par défaut en millisecondes pour tous les topics qui ne la remplacent pas. La valeur par défaut est de 604800000 ms (7 jours).
• retention.ms : Cette propriété au niveau du topic vous permet de remplacer la valeur par défaut du broker pour un topic spécifique. Elle spécifie également la période de rétention en millisecondes.

Comment cela fonctionne :

Les brokers Kafka vérifient périodiquement les segments de journal dans chaque partition. Si tous les messages d'un segment sont plus anciens que le seuil retention.ms (ou log.retention.ms), l'intégralité du fichier de segment est supprimée du disque.

Considérations pratiques :

• Décalage du consommateur (Consumer Lag) : Assurez-vous que la période de rétention est suffisamment longue pour que tous les consommateurs puissent traiter les messages. Si un consommateur prend trop de retard, il pourrait perdre des données si elles sont supprimées avant d'être lues.
• Fenêtres de récupération : Jusqu'où avez-vous besoin de pouvoir retraiter les données en cas d'erreurs d'application ou de déploiements de nouveaux consommateurs ?
• Développement vs Production : Les environnements de développement peuvent utiliser des périodes de rétention plus courtes (par exemple, 24 heures) pour économiser des ressources, tandis que la production peut nécessiter plusieurs jours ou semaines.

Exemple : Configurer un topic pour conserver les données pendant 3 jours

Pour configurer un topic nommé my-important-topic afin qu'il conserve les données pendant 3 jours (72 heures), vous utiliseriez l'outil kafka-configs.sh :

# Calculer 3 jours en millisecondes : 3 * 24 * 60 * 60 * 1000 = 259200000 ms
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-important-topic --alter --add-config retention.ms=259200000

# Vérifier le paramètre
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-important-topic --describe

Rétention des données basée sur la taille (log.retention.bytes)

La rétention basée sur la taille garantit que le journal d'une partition ne dépasse pas une taille totale donnée sur le disque. Lorsque cette limite est atteinte, Kafka supprime les segments de journal les plus anciens jusqu'à ce que la taille totale soit inférieure au seuil.

Paramètres de configuration :

• log.retention.bytes : Cette propriété au niveau du broker définit la taille maximale par défaut en octets pour le journal d'une partition. La valeur par défaut est -1, ce qui signifie qu'aucune limite de taille n'est appliquée par défaut (seule la rétention basée sur le temps est active).
• retention.bytes : Cette propriété au niveau du topic vous permet de remplacer la valeur par défaut du broker pour un topic spécifique, spécifiant la taille maximale en octets pour le journal d'une seule partition.

Comment cela fonctionne :

Semblable à la rétention basée sur le temps, Kafka vérifie périodiquement la taille totale du journal de chaque partition. Si la taille totale dépasse retention.bytes (ou log.retention.bytes), les segments de journal les plus anciens sont supprimés jusqu'à ce que la taille soit dans la limite configurée.

Considérations pratiques :

• Capacité du disque : C'est crucial lorsque vous disposez d'un espace disque limité. Cela garantit qu'un topic ne remplira pas vos disques, quel que soit le débit de messages.
• Variabilité du débit de messages : Si votre taux de production de messages fluctue, la rétention basée sur la taille peut supprimer les données plus rapidement pendant les périodes de pointe, affectant potentiellement les consommateurs qui ont besoin d'une fenêtre de consultation cohérente.
• Limite par partition : N'oubliez pas que retention.bytes s'applique par partition. Ainsi, un topic avec 10 partitions et retention.bytes=1Go peut stocker jusqu'à 10 Go de données au total.

Exemple : Configurer un topic pour conserver un maximum de 1 Go par partition

Pour configurer un topic nommé high-volume-logs afin qu'il conserve un maximum de 1 Go (1 073 741 824 octets) par partition :

# Calculer 1 Go en octets : 1 * 1024 * 1024 * 1024 = 1073741824 octets
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name high-volume-logs --alter --add-config retention.bytes=1073741824

# Vérifier le paramètre
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name high-volume-logs --describe

Configuration de la rétention des données dans Kafka

Les paramètres de rétention peuvent être appliqués au niveau du broker (par défaut pour tous les topics) ou remplacés au niveau du topic pour un contrôle granulaire.

Configuration au niveau du broker

Pour définir des politiques de rétention par défaut pour tous les topics de votre cluster, modifiez le fichier server.properties sur chaque broker Kafka :

# Rétention par défaut basée sur le temps pour tous les topics : 7 jours
log.retention.ms=604800000

# Rétention par défaut basée sur la taille pour tous les topics : Aucune limite (-1)
# Décommentez et définissez une valeur si vous souhaitez une limite de taille globale
# log.retention.bytes=10737418240 # Exemple : 10 Go par partition

# À quelle fréquence Kafka vérifie les segments de journal à supprimer (défaut : 5 minutes)
log.retention.check.interval.ms=300000

Après avoir modifié server.properties, vous devez redémarrer les brokers Kafka pour que les changements prennent effet. Soyez prudent avec log.retention.bytes au niveau du broker ; il s'applique par partition, ce qui peut s'additionner rapidement sur de nombreux topics et partitions.

Substitutions au niveau du topic

Les configurations au niveau du topic ont la priorité sur les valeurs par défaut au niveau du broker. C'est l'approche recommandée pour gérer la rétention, car différents topics ont souvent des exigences de durée de vie des données différentes.

Définir une politique de rétention pour un nouveau topic :

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-new-topic \n    --partitions 3 --replication-factor 3 \n    --config retention.ms=172800000 `# 2 jours` \n    --config retention.bytes=536870912 `# 512 Mo par partition`

Modifier la politique de rétention d'un topic existant :

# Changer la rétention temporelle à 5 jours
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --add-config retention.ms=432000000

# Changer la rétention de taille à 2 Go
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --add-config retention.bytes=2147483648

# Pour supprimer une substitution au niveau du topic et revenir à la valeur par défaut du broker :
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --delete-config retention.ms

Décrire les configurations de topic :

Pour visualiser les configurations actuelles d'un topic, y compris les paramètres de rétention :

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --describe

Rétention des données par rapport à la compaction de journal (log.cleanup.policy)

Il est important de distinguer la rétention des données (suppression) de la compaction de journal. La log.cleanup.policy de Kafka détermine la manière dont les anciens segments de journal sont traités :

• delete (par défaut) : Il s'agit de la stratégie de rétention que nous avons examinée, où des segments de journal entiers sont supprimés en fonction de limites de temps ou de taille.
• compact : Cette politique conserve le dernier message pour chaque clé de message. Elle convient aux topics qui représentent un journal des modifications ou un état actuel (par exemple, le journal des modifications d'une base de données, les profils d'utilisateurs). Avec la compaction, les anciennes versions d'un message pour la même clé sont éventuellement supprimées, mais la dernière valeur pour chaque clé n'est jamais supprimée en fonction de l'âge ou de la taille totale du journal (sauf configuration spécifique avec retention.ms pour les tombstones).

Bien que cet article se concentre sur la politique delete, il est vital de connaître compact comme stratégie alternative pour différents cas d'utilisation.

Bonnes pratiques et considérations

1. Comprendre vos consommateurs : Avant de définir la rétention, analysez pendant combien de temps vos applications en aval ont besoin d'accéder aux données. Tenez compte de leur vitesse de traitement, de leur potentiel d'interruption et de leurs exigences de retraitement.
2. Surveiller l'utilisation du disque : Surveillez activement l'utilisation du disque sur vos brokers Kafka. Si les disques se remplissent plus rapidement que prévu, examinez vos politiques de rétention et votre débit de messages.
3. Commencer avec des valeurs par défaut raisonnables : Commencez avec une période de rétention conservatrice (par exemple, 7 jours) et ajustez en fonction de l'observation et des exigences. Il est plus facile d'étendre la rétention que de récupérer des données perdues.
4. Configuration au niveau du topic : Privilégiez toujours la définition des politiques de rétention au niveau du topic. Cela offre une flexibilité et évite des conséquences imprévues pour les autres topics.
5. Calculer le stockage requis : Estimez votre taux d'ingestion de données et multipliez-le par la période de rétention souhaitée (pour la base de temps) ou la taille de journal souhaitée par partition (pour la base de taille) pour vous assurer d'avoir une capacité disque adéquate.
6. log.retention.check.interval.ms : Ce paramètre contrôle la fréquence à laquelle Kafka vérifie les segments à supprimer. Une valeur plus petite signifie des vérifications plus fréquentes, mais aussi une surcharge CPU plus importante. La valeur par défaut de 5 minutes est généralement suffisante.
7. Tester minutieusement : Testez toujours les modifications de rétention dans un environnement de staging avant de les appliquer en production, surtout si vous réduisez les périodes de rétention.

Conclusion

Les politiques de rétention des données de Kafka sont un mécanisme puissant et essentiel pour gérer le cycle de vie de vos flux d'événements. En comprenant et en configurant efficacement retention.ms (basé sur le temps) et retention.bytes (basé sur la taille) aux niveaux du broker et du topic, vous obtenez un contrôle précis sur l'empreinte de stockage de votre cluster, ses performances et sa posture de conformité. N'oubliez pas que la rétention des données n'est pas une tâche que l'on définit et que l'on oublie ; elle nécessite une surveillance et des ajustements continus à mesure que vos volumes de données, les besoins des consommateurs et les exigences commerciales évoluent. Maîtriser ces concepts garantit que votre déploiement Kafka reste robuste, rentable et aligné sur vos objectifs organisationnels.