Unité 5.6 : Flux d'événements (Kafka géré)

Introduction

La décision structurante dans le flux d'événements ne réside pas dans le provisionnement du cluster, mais dans la structure du sujet. Le nombre de partitions détermine à la fois la garantie d'ordonnancement et la limite supérieure de la parallélisation des consommateurs pour toute la durée de vie de ce sujet, tandis que le facteur de réplication et la rétention déterminent ensemble le coût de la sécurisation des données et la durée de leur conservation. Si la structure du sujet est bien conçue, le cluster devient presque secondaire. Si elle est mal conçue, la limite se manifeste en production, où les partitions ne peuvent pas être réduites et où une modification de structure implique un nouveau sujet et une migration.

Cette unité traite Event Streams for Apache Kafka comme l'épine dorsale du flux pour FinCorp, une entreprise allemande de services financiers soumise aux obligations RGPD et BSI lors de sa migration et de sa nouvelle capacité IA. Nous commençons par la décision de conception du sujet, expliquons l'interaction entre les partitions, les groupes de consommateurs, la réplication et la rétention, montrons la place du flux dans l'architecture globale, puis construisons un cluster et un sujet correctement structuré dans Data Center Designer.

1. Le sujet est l'architecture : partitions, ordonnancement et parallélisme

Une partition est l'unité à la fois de l'ordonnancement et du parallélisme, et ces deux propriétés vont dans le même sens. C'est ce qui fait du nombre de partitions la décision la plus importante. Kafka maintient l'ordre des messages au sein d'une partition ; il ne fait aucune promesse d'ordonnancement entre les partitions. Ainsi, si FinCorp doit traiter tous les événements d'un compte donné dans l'ordre où ils se sont produits, tous les événements de ce compte doivent atterrir sur la même partition. La méthode standard pour garantir cela consiste à définir une clé de partition (l'identifiant du compte) afin que le producteur l'associe à une partition fixe par hachage. L'ordonnancement est donc une propriété par clé, et non par sujet : on obtient un ordre strict au sein de chaque clé et une concurrence entre les clés, ce qui est exactement ce qu'un flux de transactions à fort volume requiert.

Le parallélisme est l'autre face de la même pièce. Au sein d'un groupe de consommateurs, une partition est consommée par au plus un membre à la fois, de sorte que le nombre de partitions constitue la limite stricte du nombre de consommateurs pouvant traiter ce sujet en parallèle. Trois partitions signifient au plus trois consommateurs actifs ; un quatrième reste inactif. Un plus grand nombre de partitions permet un meilleur equilibrage de charge entre les consommateurs et améliore le débit, mais il multiplie également les descripteurs de fichiers ouverts, le trafic de réplication et le temps de rééquilibrage. Le nombre de partitions est donc dimensionné en fonction du débit réellement attendu, et non gonflé de manière spéculative. L'asymétrie à intégrer est qu'il est généralement possible d'ajouter des partitions ultérieurement, mais cela recalcule l'association clé-partition et rompt la garantie d'ordonnancement par clé pour les clés en cours de traitement. Pour un flux ordonné, il faut donc dimensionner les partitions dès le départ et ne plus y toucher.

IONOS CLOUD fournit une règle de dimensionnement concrète qui lie le nombre de partitions à la topologie des brokers du cluster. Chaque cluster Event Streams for Apache Kafka exécute trois brokers, quel que soit le modèle de taille. La recommandation est que le nombre de partitions doit être égal ou supérieur au nombre de brokers, et qu'il faut n'utiliser que des multiples du nombre de brokers (3, 6, 9, 12, etc.) afin d'éviter une répartition inégale des partitions entre les brokers. Une répartition inégale laisse un broker plus sollicité que les autres et gaspille la capacité pour laquelle on a payé. Si le haut débit est une priorité, la documentation suggère 2 fois ou 3 fois le nombre de brokers, voire plus. Pour le sujet des événements de compte de FinCorp, cela signifie commencer avec 3 partitions et passer à 6 ou 9 uniquement lorsque le débit mesuré le justifie, en restant toujours sur un multiple de trois.

Les groupes de consommateurs et les décalages (offsets) sont le moyen par lequel cette conception survit aux redémarrages et s'étend à l'échelle. Un groupe de consommateurs est un ensemble de consommateurs qui se partagent coopérativement les partitions d'un sujet ; Kafka suit, par groupe et par partition, le décalage du dernier message traité. Comme le décalage est engagé (commit) vers le cluster, un consommateur qui tombe en panne et redémarre reprend là où le groupe s'était arrêté, et non depuis le début. L'ajout d'un consommateur au groupe déclenche un rééquilibrage qui redistribue les partitions. C'est pourquoi FinCorp peut exécuter un groupe de consommateurs pour la détection de fraude en temps réel et un second groupe, indépendant, pour l'entrepôt analytique, sur le même sujet : chaque groupe conserve ses propres décalages et lit le flux complet à son propre rythme, sans que l'un bloque l'autre.

2. La réplication et la rétention comme leviers de coût et de fiabilité

Deux paramètres au niveau du sujet se traduisent directement dans votre facture de stockage et votre posture de durabilité, et les deux constituent des décisions à prendre, et non des valeurs par défaut à accepter aveuglément.

Le facteur de réplication est le nombre de copies de chaque message conservées sur des brokers distincts. IONOS CLOUD recommande un facteur de réplication de 3, ce qui, sur un cluster de trois brokers, signifie une copie complète de la partition sur chaque broker, de sorte que le sujet survit à la perte de brokers sans perte de données et que la bascule automatique et la réplication du cluster maintiennent le flux en fonctionnement. Le coût est multiplicatif : avec un facteur de réplication de 3, le stockage consommé par un sujet est trois fois supérieur à son volume brut de messages. La note de dimensionnement d'IONOS CLOUD le précise explicitement, en avertissant que la consommation finale de stockage peut être plusieurs fois supérieure au volume de données entrantes, en fonction du facteur de réplication configuré. Un facteur plus faible permet d'économiser du stockage, mais au prix de la tolérance aux pannes ; pour les données de transactions réglementées de FinCorp, 3 est le seuil minimal approprié.

La rétention détermine la durée pendant laquelle les messages sont conservés avant d'être supprimés, et c'est l'autre grand levier de stockage. La durée de rétention est définie en millisecondes, sa valeur par défaut est 604800000 (7 jours), et une valeur de -1 signifie qu'il n'y a pas de limite de temps. Il existe une taille de segment de rétention associée, exprimée en octets (la taille à laquelle un segment de journal est rouler, par défaut 1073741824, soit 1 Go, avec un seuil minimal documenté de 14 octets), ainsi qu'une limite de taille de rétention qui supprime les messages les plus anciens une fois que la limite de taille totale du sujet est atteinte. La dimensionnement du cluster est donc un problème d'arithmétique de rétention. La documentation fournit un exemple chiffré : trois sujets, chacun conservant les données pendant sept jours à un débit de 500 Ko par seconde, nécessitent un minimum d'environ 866 Go de stockage total avant même de compter la réplication. Les modèles de cluster fixent le stockage que vous obtenez :

Considérez ce tableau comme un budget, et non comme un menu de niveaux de vitesse : vous sélectionnez la taille en fonction du débit et de la rétention exigés par vos sujets, puis vous vérifiez que le stockage total du cluster dépasse confortablement le volume brut multiplié par le facteur de réplication sur la fenêtre de rétention. Le flux de transactions de FinCorp, avec une rétention de sept jours et un facteur de réplication de 3, dépasse le modèle S même à des taux d'ingestion modérés, de sorte que M est le point de départ réaliste, avec une marge pour un second sujet.

Une nuance de rétention mérite d'être mentionnée, car la plateforme la prend en charge : la compaction de journal Kafka ne conserve que la dernière valeur pour une clé donnée, au lieu de supprimer les messages en fonction de leur âge. Cela convient à un sujet qui représente l'état actuel (par exemple, le dernier solde par compte), plutôt qu'à un historique d'événements. Il s'agit d'un mode de rétention différent de la suppression basée sur le temps ou la taille ; n'utilisez ce mode que lorsque le sujet modélise réellement un état basé sur des clés, et ne supposez pas qu'il est activé par défaut.

3. Le flux comme substitut et colonne vertébrale

C'est ici que le flux d'événements justifie sa place dans le modèle de substitution native de la plateforme. Les bases de données gérées par IONOS CLOUD n'exposent pas de flux de capture des modifications de données auquel vous pouvez vous abonner, il est donc impossible de suivre le journal des transactions de la base de données pour alimenter les consommateurs en aval. Le modèle natif consiste à inverser la dépendance : au lieu d'extraire les modifications de la base de données a posteriori, l'application publie un événement de domaine dans un sujet Kafka au moment où elle effectue la modification, et chaque système en aval (l'entrepôt analytique, le modèle de détection de fraude, un index de recherche, une archive d'audit) consomme ce sujet. Le flux devient la source de vérité pour la propagation des modifications, la base de données devient une projection supplémentaire côté consommateur, et FinCorp obtient la diffusion multiple qu'un flux CDC lui aurait apportée, sans une fonctionnalité que la plateforme ne propose pas. La rigueur que cela exige est que l'écriture dans la base de données et la publication dans le sujet soient traitées comme une opération logique unique dans l'application, car la plateforme n'offre aucun pont automatique entre les deux.

Le même flux constitue la colonne vertébrale d'ingestion vers la couche IA. Les modèles de FinCorp n'appellent pas directement la base de données transactionnelle ; ils consomment les sujets d'événements, ce qui offre aux charges de travail IA une alimentation découplée et rejouable qu'ils peuvent relire à partir d'un décalage confirmé chaque fois qu'un modèle est réentraîné. Deux points de terminaison bouclent la boucle et tous deux s'appuient sur Object Storage. D'abord, l'archivage : l'exportation de données en masse est disponible, mais n'est pas en libre-service, c'est un processus via ticket de support (numéro de contrat, code PIN de support et une clé PGP, après quoi IONOS CLOUD livre une archive chiffrée vers votre bucket Object Storage), de sorte que la longue traîne d'événements ayant dépassé la fenêtre de rétention à chaud n'est exportée vers Object Storage qu'après cette demande, et une rétention courte du cluster n'est un design viable que si la cadence d'archivage tient compte de ce délai manuel. Deuxièmement, la traîne de messages en échec : les messages qu'un consommateur ne peut pas traiter sont routés vers un sujet de messages en échec distinct et, pour une rétention forensique durable, vidés vers Object Storage où le verrouillage d'objet les rend infalsifiables. Les brokers restent légers pour le trafic en direct ; le stockage lent, économique et immuable absorbe l'archive et les échecs.

La sécurité sur le plan de données est le TLS mutuel, et le modèle est strict. La communication avec le cluster est sécurisée par TLS avec authentification des deux côtés : le client vérifie le certificat du cluster et le cluster vérifie le certificat du client. Étant donné que le cluster n'utilise pas de certificats signés publiquement, les clients valident le serveur par rapport à l'autorité de certification propre au cluster, et le cluster maintient une autorité de certification client qui signe le certificat de chaque utilisateur authentifié. Chaque certificat est valide pendant 365 jours, et un certificat renouvelé devient disponible pour récupération depuis l'API des identifiants utilisateurs 30 jours avant son expiration, ce qui est la fenêtre visée par votre runbook de rotation. L'API de gestion, en revanche, est authentifiée par un jeton Bearer et est accessible publiquement sur un point de terminaison par région (kafka.<region>.ionos.com) ; seul le protocole du plan de données Kafka sur les brokers est réservé au LAN privé sans point de terminaison public, de sorte que le périmètre de sécurité du plan de données est le réseau privé plus la poignée de main mTLS, tandis que le périmètre de l'API de gestion est le contrôle par jeton Bearer (privilège IAM limité, gestion et rotation du jeton).

Déroulement de la mise en œuvre de DCD

Vous allez provisionner un cluster Event Streams for Apache Kafka à trois brokers sur le LAN privé de la couche données de FinCorp et créer un topic correctement structuré pour le flux account-event. L'objectif architectural est la colonne vertébrale d'ingestion décrite dans la section 3 : un flux privé, sécurisé par mTLS, dimensionné pour une fenêtre de rétention de sept jours avec un facteur de réplication de 3, et un nombre de partitions qui respecte à la fois l'ordonnancement et la topologie des brokers. Le cluster ne dispose d'aucun point d'accès public, si bien que l'ensemble des travaux s'effectue à l'intérieur du centre de données virtuel que vous avez créé plus tôt dans le cours.

Objectif de construction : Créer un cluster et un topic bien structuré.

Prérequis : Un centre de données virtuel provisionné contenant au moins une VM sur un LAN privé ; cette VM accède au cluster via le LAN privé et compte dans votre quota contractuel. Définissez à l'avance les adresses IP des brokers : elles doivent appartenir au même sous-réseau que le LAN sélectionné.

Étapes (dans Data Center Designer) :

1. Ouvrez la section Event Streams for Apache Kafka et cliquez sur Create cluster.
2. Définissez Cluster Name avec un nom unique et identifiable, et sélectionnez Kafka Version (la version 4.0.0 est la version prise en charge ; les versions 3.9.0 et 3.9.1 sont obsolètes, et les clusters existants sur ces versions continuent de fonctionner).
3. Choisissez la Cluster Size (de XS à XL) en fonction de vos exigences de débit et de rétention. Pour le flux de FinCorp avec une rétention de sept jours et un facteur de réplication de 3, dimensionnez à partir du tableau de stockage de la section 2 plutôt qu'en supposant ; M est la limite inférieure réaliste.
4. Sélectionnez la Location (région) pour le cluster. La région détermine l'emplacement géographique, la latence et la résidence réglementaire des données, choisissez donc le centre de données allemand pour les données réglementées de FinCorp.
5. Choisissez le Datacenter et le Datacenter LAN. Sélectionnez le LAN privé de la couche données ; le cluster ne sera accessible que sur ce réseau.
6. Configurez les broker addresses que les clients utiliseront pour se connecter. Les adresses IP doivent appartenir au même sous-réseau que le LAN sélectionné à l'étape précédente, afin que le routage à l'intérieur du cluster fonctionne. Utilisez l'indication de sous-réseau de l'écran DCD pour confirmer la plage.
7. Examinez les coûts estimés affichés pour la saisie (une estimation qui exclut des variables telles que le trafic), puis cliquez sur Save pour déployer. Suivez la progression jusqu'à ce que le cluster atteigne l'état Available.
8. Une fois le cluster disponible, ouvrez-le, sélectionnez l'onglet Topics et cliquez sur Create topic.
9. Dans la boîte de dialogue Create Topic, définissez : Name ; Replication Factor (utilisez 3) ; Number of Partitions (un multiple des trois brokers : 3 pour commencer, 6 ou 9 si le débit l'exige) ; Retention Time (ms) (604800000 pour sept jours, ou -1 pour aucune limite de temps) ; et Retention Segment Size (B) (valeur par défaut 1073741824, avec un minimum de 14 octets). Cliquez sur Create.

Pour utiliser le cluster par la suite, récupérez le certificat client par utilisateur depuis l'API des identifiants et validez le broker par rapport à l'autorité de certification du cluster ; l'API renvoie le certificat au format PEM, par exemple :

curl --location https://kafka.<region>.ionos.com/clusters/${clusterId}/users/${userId}/access \
  --header "Authorization: Bearer ${personalToken}" | yq -r '.metadata.certificate' > client-cert.pem

Cet unique appel illustre la frontière architecturale, et non un laboratoire de configuration : le plan de données utilise mTLS, de sorte qu'un client sans certificat signé par une autorité de certification ne peut tout simplement pas se connecter, et le cycle de vie des certificats (validité de 365 jours, renouvellement disponible 30 jours avant l'expiration) est une tâche opérationnelle dont l'équipe est responsable.

Erreurs courantes :

• Définir un nombre de partitions qui n'est pas un multiple du nombre de brokers. Utilisez des multiples de trois (3, 6, 9, 12) afin que les partitions soient réparties uniformément ; une répartition inégale surcharge un broker et gaspille la capacité payée.
• Considérer le nombre de partitions comme ajustable ultérieurement. L'ajout de partitions provoque un recalcul des hachages des clés et rompt l'ordre par clé pour les clés en cours de traitement, il convient donc de dimensionner les partitions d'un flux ordonné dès le départ.
• Sous-dimensionner le cluster par rapport à la rétention. Multipliez le débit d'ingestion brut par la fenêtre de rétention, puis par le facteur de réplication ; le cas d'une rétention de 7 jours avec un facteur de réplication de 3 peut représenter plusieurs fois le volume brut, et dès que la limite de stockage est atteinte, les messages les plus anciens sont purgés.
• Choisir des adresses IP de brokers en dehors du sous-réseau du LAN sélectionné. Elles doivent se trouver dans le même sous-réseau, sinon les brokers ne peuvent pas acheminer le trafic vers les clients.
• Oublier le prérequis du LAN privé : un VDC avec une VM sur un LAN privé doit exister au préalable, et il n'y a pas de point d'accès public, de sorte que la connectivité et le chemin du certificat mTLS constituent le seul moyen d'accès.
• Laisser expirer les certificats clients. Chacun est valide pendant 365 jours, avec un renouvellement disponible 30 jours avant l'expiration ; intégrez la récupération et la rotation dans le guide d'exploitation.

Résumé

La forme du sujet est l'architecture : le nombre de partitions fixe l'ordre par clé et limite la parallélisation des groupes de consommateurs, et sur IONOS CLOUD, il doit être un multiple des trois brokers ; le facteur de réplication (recommandé : 3) et la rétention (7 jours par défaut, -1 pour illimité) sont les leviers de coût et de fiabilité qui dimensionnent le cluster. Le flux est également la réponse native de la plateforme à deux lacunes : il remplace le flux de capture des modifications de base de données par la publication d'événements au niveau de l'application, et sert de colonne vertébrale d'ingestion rejouable vers la couche IA, avec Object Storage qui porte l'archive vieillie et la file des messages en échec. La construction consiste en un cluster privé, sécurisé par mTLS, sur le LAN de la couche de données, plus un unique sujet bien dimensionné, calibré à partir du tableau de stockage plutôt que par estimation.

Points clés :

• Une partition est l'unité à la fois de l'ordre (par clé) et de la parallélisation des consommateurs (un consommateur par partition par groupe) ; dimensionnez les partitions comme un multiple des trois brokers et dès le départ pour les flux ordonnés.
• Le facteur de réplication 3 est le seuil de durabilité recommandé et multiplie le stockage environ par trois ; le temps de rétention (604800000 ms / 7 jours par défaut, -1 pour aucune limite) et la taille des segments déterminent le reste de la facture de stockage.
• Les groupes de consommateurs suivent les décalages confirmés par partition, de sorte que des groupes indépendants lisent le même sujet à leur propre rythme et survivent aux redémarrages sans retraitement.
• La publication d'événements au niveau de l'application est le substitut natif au flux de capture des modifications de base de données absent, et les mêmes sujets constituent le flux rejouable vers la couche IA.
• Object Storage est l'archive (via l'export de données en masse) et la file durable des messages en échec ; les brokers restent légers pour le trafic en direct.
• Le plan de données utilise le TLS mutuel avec l'autorité de certification propre au cluster, avec des certificats de 365 jours (renouvellement 30 jours avant expiration) ; l'API de gestion utilise un jeton Bearer ; le cluster est accessible uniquement via le LAN privé.

Terminologie importante :

• Partition : L'unité d'ordre et de parallélisation au sein d'un sujet. L'ordre n'est garanti qu'au sein d'une partition ; un groupe de consommateurs affecte chaque partition à au plus un membre.
• Groupe de consommateurs : Un ensemble de consommateurs coopérants qui se partagent les partitions d'un sujet et partagent les décalages confirmés, permettant une consommation parallèle, reprenable et indépendante.
• Facteur de réplication : Le nombre de copies résidentes sur les brokers de chaque message ; recommandé : 3, et multiplicateur direct de la consommation de stockage.
• Rétention : La politique (durée, taille ou compaction de journal) qui régit la durée de persistance des messages avant leur purge ou leur compaction.
• mTLS : TLS mutuel où le client et le cluster s'authentifient mutuellement auprès de l'autorité de certification du cluster ; le seul chemin vers le plan de données privé.

Lectures complémentaires

• Unité 5.2 : Object Storage (cible pour les archives, les messages en échec et le corpus d'entraînement)
• Unité 5.3 : Bases de données relationnelles (le côté écriture qui publie les événements du domaine)
• Unité 6.5 : AI Inference - Managed Model Hub (le consommateur à l'extrémité de la colonne vertébrale d'ingestion)
• IONOS CLOUD Architecture Center