Unité 5.6 : Diffusion d'événements (Managed Kafka)

Introduction

La décision porteuse dans le streaming d'événements ne concerne pas la mise à disposition du Cluster ; il s'agit de la forme du sujet. Le nombre de partitions définit à la fois la garantie d'ordre et le plafond de la parallélisme du consommateur pour la durée de vie de ce sujet, et le facteur de réplication et la rétention déterminent ensemble combien vous payez pour conserver les données en toute sécurité et pour combien de temps. Obtenir la bonne forme de sujet et le Cluster est presque accessoire. Obtenir cela incorrectement et vous découvrirez la limite en production, où les partitions ne peuvent pas être réduites et une réorganisation signifie un nouveau sujet et une migration.

Cette unité traite le Event Streams for Apache Kafka comme la colonne vertébrale du streaming pour FinCorp, la société financière allemande qui transporte les obligations GDPR et BSI à travers sa migration et sa nouvelle capacité d'intelligence artificielle. Nous commençons par la décision de conception de sujet, expliquons comment les partitions, les groupes de consommateurs, la réplication et la rétention interagissent, montrons où le flux est situé dans l'architecture plus large, puis construisons un Cluster et un sujet correctement formé dans le 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 tirent dans le même sens, ce qui fait que le nombre de partitions est la décision qui compte le plus. Kafka maintient l'ordre des messages au sein d'une partition ; il ne fait aucune promesse d'ordre entre les partitions. Donc, si FinCorp doit traiter tous les événements pour un compte donné dans l'ordre où ils se sont produits, chaque événement pour ce compte doit atterrir sur la même partition. La façon standard de garantir cela est de définir une clé de partition (l'identifiant de compte) afin que le producteur la hache sur une partition fixe. L'ordonnancement est donc une propriété par clé, et non par sujet : vous obtenez 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 à haute Volume veut.

Le parallélisme est l'autre face de la même médaille. Au sein d'un groupe de consommateurs, une partition est consommée par au plus un membre à la fois, donc le nombre de partitions est le plafond dur de la façon dont les consommateurs peuvent travailler sur ce sujet en parallèle. Trois partitions signifient au plus trois consommateurs actifs ; un quatrième reste inactif. Plus de partitions permettent un meilleur équilibrage de charge entre les consommateurs et améliorent le débit, mais ils multiplient également les poignées de fichiers ouvertes, le trafic de réplication et le temps de rééquilibrage, donc le nombre est dimensionné en fonction du débit que vous attendez réellement, et non gonflé de manière spéculative. L'asymétrie à internaliser est que vous pouvez généralement ajouter des partitions plus tard, mais l'ajout de partitions réorganise la mise en correspondance clé-partition et brise la garantie d'ordre par clé pour les clés en cours, donc pour un flux ordonné, vous dimensionnez les partitions à l'avance et les laissez inchangées.

IONOS donne une règle de dimensionnement concrète qui relie le nombre de partitions à la topologie du courtier Cluster. Chaque Event Streams for Apache Kafka Cluster exécute trois courtiers, quelle que soit la taille du modèle. Les conseils sont que le nombre de partitions doit être égal ou supérieur au nombre de courtiers, et que vous devez utiliser uniquement des multiples du nombre de courtiers (3, 6, 9, 12, etc.) pour éviter une répartition inégale des partitions entre les courtiers. Une répartition inégale laisse un courtier plus chaud que les autres et gaspille la capacité que vous avez payée. Si un débit élevé est une priorité, la documentation suggère 2x ou 3x le nombre de courtiers ou 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 sont la façon dont cette conception survive aux redémarrages et s'étend. 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é. Puisque le décalage est renvoyé au Cluster, un consommateur qui plante et redémarre reprend à partir de l'endroit où le groupe s'est arrêté plutôt que du début, et 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 le scoring de fraude en temps réel et un deuxième groupe, indépendant, pour l'entrepôt d'analyse contre le même sujet : chaque groupe conserve ses propres décalages et lit le flux complet à son propre rythme, et aucun ne bloque l'autre.

2. Réplication et 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 sont des décisions, 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 courtiers distincts. IONOS recommande un facteur de réplication de 3, ce qui sur un courtier Cluster à trois courtiers signifie une copie complète de la partition sur chaque courtier, de sorte que le sujet survive à la perte de courtiers sans perte de données et que la bascule automatique et la réplication de Cluster maintiennent le pipeline. Le coût est multiplicatif : à un facteur de réplication de 3, le stockage qu'un sujet consomme est trois fois sa charge brute de message Volume. La note de taille de IONOS le rend explicite, avertissant que la consommation finale de stockage peut être plusieurs fois supérieure à la charge brute de données Volume en fonction du facteur de réplication configuré. Un facteur inférieur économise du stockage, mais échange la tolérance aux défauts ; pour les données de transactions réglementées de FinCorp, 3 est le plancher correct.

La rétention décide de la durée pendant laquelle les messages restent avant d'être purgés, et c'est l'autre grand levier de stockage. Le temps de rétention est défini en millisecondes, par défaut à 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 en octets (la taille à laquelle un segment de journal est déroulé, par défaut 1073741824, qui est de 1 Go, avec un plancher documenté de 14 octets), et une limite de taille de rétention qui purge les messages les plus anciens une fois que la limite de taille totale du sujet est atteinte. La taille de Cluster est donc un problème d'arithmétique de rétention. La documentation donne un exemple de travail : trois sujets, chacun conservant sept jours à 500 Ko par seconde, nécessitent un minimum d'environ 866 Go de stockage total avant que la réplication ne soit même comptabilisée. Les modèles Cluster fixent le stockage que vous obtenez :

Lisez cette table comme un budget, et non comme un menu de notes de vitesse : vous sélectionnez la taille en fonction du débit et de la rétention que vos sujets exigent, puis vérifiez que le stockage total Cluster dépasse confortablement la charge brute Volume multipliée par le facteur de réplication sur la fenêtre de rétention. L'alimentation de transactions de sept jours de FinCorp, avec un facteur de réplication de 3, la pousse au-delà du modèle S, même à des taux d'ingestion modestes, donc M est le point de départ réaliste avec une marge pour un second sujet.

Une nuance de rétention qui vaut la peine d'être nommée car la plateforme la prend en charge : la compaction des journaux Kafka conserve uniquement la dernière valeur pour une clé donnée plutôt que de purger par âge, ce qui convient à un sujet qui représente l'état actuel (le dernier solde par compte, par exemple) plutôt qu'un historique d'événements. Il s'agit d'un mode de rétention différent de la purge basée sur le temps ou la taille ; n'y recourez qu'à condition que le sujet modélise réellement l'état clé, et ne supposez pas qu'il est activé par défaut.

3. Le flux en tant que substitut et colonne vertébrale

C'est ici que le streaming d'événements trouve sa place dans le modèle de substitution natif de la plateforme. Les bases de données gérées par IONOS n'exposent pas un flux de capture de données de modification que vous pouvez souscrire, vous ne pouvez donc pas 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 après coup, l'application publie un événement de domaine sur un sujet Kafka au moment où elle effectue la modification, et chaque système en aval (l'entrepôt d'analyse, le modèle de fraude, un index de recherche, un 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 de consommateur supplémentaire, et FinCorp obtient le éventail qu'un flux CDC lui aurait donné sans une fonctionnalité que la plateforme ne vend pas. La discipline que cela exige est que l'écriture dans la base de données et la publication sur le sujet soient traitées comme une opération logique unique dans l'application, puisque la plateforme n'offre pas de pont automatique entre eux.

Le même flux est la colonne vertébrale d'ingestion dans le niveau 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 donne aux charges de travail IA une alimentation découplée et relecture qui peut être relue à partir d'un décalage commité chaque fois qu'un modèle est réentraîné. Deux points de terminaison ferment la boucle et s'appuient tous deux sur Object Storage. Premièrement, l'archive : l'exportation de données en bloc est disponible mais n'est pas en libre-service, c'est un processus de ticket de support (numéro de contrat, code PIN de support et une clé PGP, après quoi IONOS livre une archive chiffrée à votre seau Object Storage), donc la longue traîne d'événements qui a vieilli au-delà de la fenêtre de rétention chaude est exportée vers Object Storage uniquement après cette demande, et une rétention courte Cluster est une conception praticable uniquement si le rythme d'archive tient compte de ce délai de traitement manuel. Deuxièmement, la queue de lettres mortes : les messages qu'un consommateur ne peut pas traiter sont acheminés vers un sujet de lettres mortes distinct et, pour une rétention forensique durable, drainés vers Object Storage où le verrouillage d'objet les rend inviolables. Les courtiers restent minces pour le trafic en direct ; le stockage lent, bon marché et immuable absorbe l'archive et les défaillances.

La sécurité sur le plan de données est une authentification mutuelle TLS, et le modèle est strict. La communication avec Cluster est sécurisée TLS avec les deux côtés s'authentifiant : le client vérifie le certificat de Cluster et Cluster vérifie le certificat du client. Puisque Cluster n'utilise pas de certificats signés publiquement, les clients valident le serveur contre l'autorité de certification de Cluster, et 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 à partir des informations d'identification de l'utilisateur API 30 jours avant l'expiration, ce qui est la fenêtre que votre livre de rotation cible. La gestion API, en revanche, est authentifiée avec un jeton Bearer et est accessible publiquement à un point de terminaison par région (Kafka.<région>.ionos.com) ; seul le protocole de plan de données Kafka sur les courtiers est privé-LAN uniquement avec aucun point de terminaison public, donc le périmètre de sécurité pour le plan de données est le réseau privé plus la poignée de main mTLS, tandis que le périmètre de gestion API est le contrôle du jeton Bearer (privilège IAM étendu, gestion et rotation de jeton).

DCD Déploiement étape par étape

Vous allez mettre en place un Event Streams for Apache Kafka Cluster à trois courtiers sur le centre de données privé de FinCorp et créer un sujet correctement configuré pour l'alimentation d'événements de compte. L'objectif architectural est l'ingestion de la colonne vertébrale de 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 3, et un nombre de partitions qui respecte à la fois l'ordre et la topologie des courtiers. Le Cluster n'a pas de point de terminaison public, donc le travail se déroule entièrement à l'intérieur du VDC que vous avez construit plus tôt dans le cours.

Objectif de construction : Créer un Cluster et un sujet bien configuré.

Prérequis : Un centre de données virtuel provisionné contenant au moins un VM dans un centre de données privé LAN ; ce VM accède au Cluster via le centre de données privé LAN et compte dans votre quota de contrat. Déterminez les adresses IP des courtiers à l'avance : elles doivent appartenir au même sous-réseau que le LAN que vous sélectionnez.

Étapes (dans le Data Center Designer) :

1. Ouvrez la section Event Streams for Apache Kafka et cliquez sur Créer Cluster.
2. Définissez Nom de Cluster sur un nom unique et identifiable, et sélectionnez Version Kafka (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 à fonctionner).
3. Choisissez la Taille de Cluster (XS à XL) en fonction de vos besoins en débit et de rétention. Pour l'alimentation de sept jours, avec un facteur de réplication 3, de FinCorp, sélectionnez une taille à partir du tableau de stockage de la section 2, plutôt que de deviner ; M est le plancher réaliste.
4. Sélectionnez l'Emplacement (région) pour le Cluster. La région détermine le placement géographique, la latence et la résidence réglementaire, donc choisissez le centre de données allemand pour les données réglementées de FinCorp.
5. Choisissez le Centre de données et le Sous-réseau de centre de données LAN. Sélectionnez le centre de données privé LAN ; le Cluster sera accessible uniquement sur ce réseau.
6. Configurez les adresses de courtier 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'indice de sous-réseau de l'écran DCD pour confirmer la plage.
7. Examinez les coûts estimés affichés pour l'entrée (une estimation qui exclut les variables telles que le trafic), puis cliquez sur Enregistrer pour déployer. Suivez la progression jusqu'à ce que le Cluster atteigne l'état Disponible.
8. Une fois le Cluster disponible, ouvrez-le, sélectionnez l'onglet Sujets, et cliquez sur Créer un sujet.
9. Dans la boîte de dialogue Créer un sujet, définissez : Nom ; Facteur de réplication (utilisez 3) ; Nombre de partitions (un multiple des trois courtiers : 3 pour commencer, 6 ou 9 si le débit l'exige) ; Temps de rétention (ms) (604800000 pour sept jours, ou -1 pour aucune limite de temps) ; et Taille de segment de rétention (B) (par défaut 1073741824, avec un minimum de 14 octets). Cliquez sur Créer.

Pour utiliser le Cluster par la suite, récupérez le certificat client par utilisateur à partir des informations d'identification API et validez le courtier contre l'autorité de certification Cluster ; le API retourne 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

Cette seule appel illustre la limite architecturale, et non un laboratoire de configuration : le plan de données est mTLS, donc un client sans certificat signé par une autorité de certification ne peut pas se connecter du tout, et le cycle de vie des certificats (validité de 365 jours, renouvellement disponible 30 jours à l'avance) est une tâche opérationnelle que l'équipe possède.

Erreurs courantes :

• Définir un nombre de partitions qui n'est pas un multiple du nombre de courtiers. Utilisez des multiples de trois (3, 6, 9, 12) afin que les partitions soient réparties de manière égale ; une répartition inégale surcharge un courtier et gaspille la capacité payée.
• Considérer le nombre de partitions comme ajustable plus tard. L'ajout de partitions réorganise les clés et brise l'ordre des clés pour les clés en cours de route, donc dimensionnez les partitions d'un flux ordonné à l'avance.
• Sous-estimer la Cluster par rapport à la rétention. Multipliez l'ingestion brute par la fenêtre de rétention, puis par le facteur de réplication ; le cas de 7 jours, facteur de réplication 3, peut être plusieurs fois supérieur à l'ingestion brute Volume, et une fois que la limite de stockage est atteinte, les messages les plus anciens sont purgés.
• Choisir les adresses du courtier IP en dehors du sous-réseau sélectionné LAN. Elles doivent être dans le même sous-réseau, ou les courtiers ne peuvent pas router vers les clients.
• Oublier le prérequis de LAN privé : un centre de données virtuel avec un VM sur un LAN privé doit exister au préalable, et il n'y a pas de point de terminaison public, donc la connectivité et le chemin du certificat mTLS sont les seules voies d'accès.
• Laisser les certificats clients expirer. Chacun est valable pendant 365 jours, avec un renouvellement disponible 30 jours avant l'expiration ; intégrez la récupération et la rotation dans le carnet de route.

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 il devrait être un multiple des trois courtiers ; 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, se substituant à un flux de capture de données de modification de base de données via la publication d'événements au niveau de l'application et servant de colonne vertébrale d'ingestion relecture dans le niveau AI, avec Object Storage transportant l'archive vieillie et la queue de lettres mortes. La construction est un Cluster privé, sécurisé par mTLS, sur le LAN de niveau données plus un sujet bien conçu, dimensionné à partir de la table de stockage plutôt que par des suppositions.

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 courtiers et à l'avance pour les flux ordonnés.
• Le facteur de réplication 3 est le plancher de durabilité recommandé et multiplie le stockage d'environ trois fois ; le temps de rétention (7 jours par défaut, -1 pour aucune limite) et la taille de segment déterminent le REST de la facture de stockage.
• Les groupes de consommateurs suivent les décalages validés par partition, donc les groupes indépendants lisent le même sujet à leur propre rythme et survivent aux redémarrages sans retraiter.
• La publication d'événements au niveau de l'application est le substitut natif du flux de capture de données de modification de base de données absent, et les mêmes sujets sont l'alimentation relecture dans le niveau AI.
• Object Storage est l'archive (via l'exportation de données en bloc) et la queue de lettres mortes durable ; les courtiers restent minces pour le trafic en direct.
• Le plan de données est une authentification mutuelle TLS contre le CA du Cluster avec des certificats de 365 jours (renouvellement 30 jours avant) ; le API de gestion utilise un jeton Bearer ; le Cluster est privé-LAN uniquement.

Terminologie importante :

• Partition : L'unité d'ordre et de parallélisme au sein d'un sujet. L'ordre est garanti à l'intérieur d'une partition uniquement ; un groupe de consommateurs attribue chaque partition à au plus un membre.
• Groupe de consommateurs : Un ensemble de consommateurs coopératifs qui divisent les partitions d'un sujet et partagent les décalages validés, permettant une consommation parallèle, reprise et indépendante.
• Facteur de réplication : Le nombre de copies de chaque message résidant sur les courtiers ; recommandé 3, et un multiplicateur direct de la consommation de stockage.
• Rétention : La politique (temps, taille ou compaction de journal) régissant la durée de persistance des messages avant leur purge ou compaction.
• mTLS : Authentification mutuelle TLS où le client et le Cluster s'authentifient mutuellement contre l'autorité de certification du Cluster ; le seul chemin vers le plan de données privé.

Lecture supplémentaire

• Unité 5.2 : Object Storage (l'archive, la cible de lettres mortes et le corpus de formation)
• Unité 5.3 : Bases de données relationnelles (le côté d'écriture qui publie des événements de domaine)
• Unité 6.5 : Inférence IA - Hub de modèles gérés (le consommateur à l'extrémité de la colonne d'ingestion)
• Centre d'architecture IONOS Cloud