Nos webinars

Alioune Sy, directeur technique de la division télécoms, médias et jeux.

C'est bon, on est en direct ?

Jordan Desnoës, architecte de solutions.

C'est parti.

Alioune Sy
Ca marche. Bonjour à tous et à toutes. Bienvenue à cette nouvelle édition des Tech Talk TME, désormais rebaptisée Let's Talk About I.T.. Aujourd'hui, on va vous parler d’Apache Kafka, de Kafka, The Good, The Bad, The Ugly. Pourquoi ce titre ? Déjà pour avoir un titre un peu catchy, cas qui attire l'œil. A priori, ça a bien marché parce que vous êtes quelques uns, vous êtes connectés ou en tout cas, vous êtes inscrits à  ce talk. Mais au delà du titre, c'est parce que Apache Kafka est une solution qu'on apprécie assez fortement sur notre BU : télé, média et jeux pour tout un tas de raisons qu'on va vous expliciter dans les prochains Slides, mais également parce que ça répond assez, assez bien finalement aux enjeux actuels de nos clients qui sont de pouvoir traiter de l'information en temps réel sans forcément en différer. Voilà les traitements. Donc voilà l'idée de ce REX là, c'est de vous faire part en fait d'une part du fonctionnement d'Apache Kafka. Pourquoi c'est bien, pourquoi beaucoup de gens en parlent, mais également de vous passer un certain nombre de messages, de vous pointer un certain nombre d'éléments sur lequel il faut faire attention.
Donc juste des éléments sur lequel on aurait aimé avoir été prévenus avant de se lancer dans cette grande aventure qui est Apache Kafka. Et donc, du coup, qui nous sommes à vos hôtes, bien moins pour commencer à Lyon. Je suis le directeur technique de la division télécoms, médias et jeux. Apache Kafka, je suis tombé là dedans il y a quelques années et je ne suis toujours pas ressorti de la marmite. Puisque comme je vous l'ai dit, c'est une solution qui marche bien, qu'on aime bien. Donc, au quotidien, j'accompagne nos équipes projets dans la mise en œuvre d'architecture, pas seulement sur Kafka, mais spécifiquement pour ceux qui feront de la page Kafka ils ont de la joie ou la malchance de me voir arriver sur leurs projets, notamment Jordan que j'en beth beaucoup en ce moment. Je te laisse la main Jordan ?

Jordan Desnoës, architecte de solutions
Oui merci Alioune. Donc Jordan Desnoës, je suis architecte de solutions. Moi j'ai découvert et je me suis intéressé à Apache Kafka il y a maintenant trois ans de cela. C'était dans le cadre d'une rénovation technique, d'un projet critique pour un opérateur télécom. Projet critique puisqu'il devait allier à la fois performances mais en même temps garantie de séquentialité des traitements, donc garantie de l'ordre. Donc c'est là que j'ai mis en place Apache Kafka sur ce projet qui est maintenant en production et qui fonctionne plutôt bien. J'interviens également de façon ponctuelle, donc sur des projets qui, un peu comme Alioune qui souhaite mettre en place Apache Kafka. Donc en tant qu'auditeur, l'idée étant de voir si, si, la configuration et la façon dont il met en place Apache Kafka correspond aux besoins du projet. Et s'ils n'ont pas omis certains éléments qui pourraient leur porter préjudice en production pour la suite notamment.

Alioune Sy
Tout à fait merci Jordan. Et donc du coup, comme vous l'avez deviné, la présentation va se structurer en trois parties. Pendant que The Good, The Bad et The Ugly et en termes de règles du jeu, n'hésitez surtout pas à nous transmettre vos questions au travers du chat. On va se réserver un temps à la fin de la présentation pour pouvoir y répondre et échanger autour de ces de ces questions que vous pouvez avoir. Apache Kafka-  The Good. Pourquoi Apache Kafka c’est bien et comment ça marche ? Mais tout simplement qu'est ce que c'est Apache Kafka ? Apache, Kafka est une plateforme de streaming qui est plutôt adaptée à la mise en œuvre en fait d'architecture événementielle. Pourquoi on évoque le fait que ce soit une plateforme de streaming ? Parce que c'est en première intention, Message broker qui permet de faire transiter des événements au sein du SI. Mais tout autour de ce broker de messages, il y a un certain nombre d'outils ou d'API de haut niveau qui permettent progressivement de mettre en place des cas d'utilisation un peu plus compliqué que juste faire transiter des événements au sein du SI.
Donc c'est vraiment ça qui est intéressant avec Apache Kafka, c'est que la prise en main et la mise en œuvre peut être faite de façon itérative au fur et à mesure que vous montez en compétences et en maturité sur la technologie. Typiquement, vous pouvez commencer par des Use Case assez simples, en fait en utilisant Kafka comme message broker tout simplement. Donc pour émettre des événements, les recevoir au niveau de deux des applications, puis faire des traitements subséquents suite à la réception de ces événements. Donc ça, c'est vraiment l'usage basique. Tout comme vous pouvez utiliser un RabbitMQ ou ce genre de choses là. Et après ça vous pouvez progresser vers d'autres Use Case un peu plus compliqué. Et typiquement vous pouvez faire ce qu'on appelle du CDC de Change Data Capture pour pouvoir capturer l'ensemble des mises à jour qui sont réalisées au niveau du data store un peu plus classique, une base de données. Publier des événements suite à ces mises à jours là et réagir en temps réel à des modifications. Donc ça, ça permet d'adresser des Use Case de transition, par exemple de traitements de type batch vers des traitements événementiels.
Là où on aurait accumulé un certain nombre de données dans une base de donnée, on les et on les aurait traitées à J+20 en faisant du CDC, en déversant des événements en temps réel dans Kafka. Vous pouvez commencer à faire une transition un peu transparente, on va dire. On a une transition simplifiée vers des architectures un peu plus de temps réel. Et si vous avez un peu plus loin, vous pouvez utiliser Apache Kafka pour des traitements vraiment purement événementiels, pour faire de la détection de fraude, etc et cetera voire brancher des outils un peu plus évolués tels que du Spark, du Hadoop. Voilà donc, c'est vraiment ça la richesse de Kafka. C'est qu'en première intention c'est juste un broker de messages et au fur et à mesure que vous gagnez en maturité, bah vous pouvez l'utiliser finalement pour des Use Case un peu plus évolués. Comment ça fonctionne Apache Kafka ? Comme je l'ai dit, c'est un broker de messages qui permet de faire transiter des événements au sein du SI, éventuellement même entre deux applications.
Première chose à savoir, c'est que chaque Apache Kafka est nativement distribuée, donc c'est une. C'est une solution qui se base sur une architecture qui est en mode cluster nativement. Contrairement à d'autres solutions où il faut activer des plugin, il faut soit prendre des licences payantes ou faire une configuration spécifique de base. Apache Kafka fonctionne de façon distribuée en cluster. Donc il suffit juste de démarrer plusieurs instances d’Apache Kafka en les faisant se découvrir les unes les autres et automatiquement, elles vont former un cluster. Première notion. Ensuite, l'élément de base qu'on va manipuler dans Apache Kafka, en fait, ce sont des topics. Donc on publie des événements au sein de topics qui vont avoir une connotation ou ont un sens fonctionnel cohérent. Donc vous pouvez avoir par exemple un topic pour gérer les l'ensemble des événements qui sont liés à une facture, un topic pour l'ensemble des événements qui sont liés en contrat etc etc. Donc de base on va manipuler des topics qui sont des autoroutes de transfert des évènements si je puis utiliser cette image là.
Et les topics sont eux mêmes subdivisés en partitions logiques et ses partitions sont elles mêmes répliquées au sein du cluster, en fait, pour assurer de la haute haute disponibilité et de la résilience au niveau d’Apache Kafka, qu'est ce qui fait que par exemple, là dans c'est dans l'illustration qu'on est là, si la partition zéro, si le broker un zéro un tombe bien, la partition zéro est toujours disponible parce qu'elle a été répliquée dans le broker un zéro deux. Donc ça c'est également une des forces de Kafka. La possibilité de répliquer automatiquement les données au sein des partitions. Ensuite, ce qui est également intéressant de noter, c'est que aussi une partition va être gérée au niveau de Kafka comme un Commit log qui persiste la donnée. Donc on publie un événement dans Kafka, il est sauvegardé sur le disque. Donc contrairement à d'autres brokers qui ne fonctionnent qu'en mémoire où, on arrête le broker, on perd l'ensemble des informations, Kafka persiste la donnée. Et ce qui est intéressant c'est que les données sont persistés en fait en fonction de leur ordre d'arrivée.
Donc vous pouvez voir en fait les partitions dans Kafka, un peu comme une grosse liste où à chaque fois on va positionner le dernier élément à la fin de la liste. Et ce qui est vraiment intéressant, c'est que chaque producer produit la donnée à son rythme. Donc il ajoute des éléments à la liste, aux logs ou encore à la partition. Et les consommateurs peuvent consommer les événements à leur rythme également. Donc, vu que les événements sont persistés et que quand un consommateur lit la donnée, il reste toujours disponible pour les autres. On peut avoir plusieurs consommateurs qui lisent la donnée à des rythmes un peu différents. Typiquement, on a le système A qui est sur l'événement quatre, le système B qui est sur l'événement dix, et cetera, et cetera. Et Kafka conserve en fait l'offset de lecture, donc l'index de lecture de chaque consommateur, pour qu’à chaque fois qu'un consommateur demande à lire des événements, on lui donne l'événement suivant par rapport à l’index sur lequel il est positionné. Qui fait qu'on peut avoir plusieurs consommateurs qui consomment la même donnée sans pour autant avoir de la perte de données.
Donc un événement dans Kafka est vraiment identifié à partir de l'offset, sa position dans la partition. Ce que je n'ai pas précisé du fait de la réplication puis des propriétés de haute disponibilité de résilience, on ne peut pas avoir un broker qui à plusieurs répliqua de la même partition en fait. Typiquement, si on définit que la partition zéro doit avoir trois replica, les réplicats doivent être sur des brokers différents. Sinon ça ne sert pas à grand chose au final. Et donc comment les événements sont ventilés dans les partitions ? Ça va dépendre de plusieurs facteurs. À un événement donné qu'on publie dans Kafka, on peut lui associer une clé et la clé va finalement être un vecteur ou un moyen de distribution des événements au sein de la partition. De base, quand vous configurez pas spécifiquement Kafka, ce que Kafka va faire pour déterminer la partition d'arrivée d'un événement, c'est un H de la clé modulo le nombre de partitions. Ce qui fait que tous les événements qui ont la même clé vont se retrouver dans la même partition.
Et ça, c'est vraiment une des bonnes pratiques à observer quand vous utilisez du Kafka. En tout cas, quand vous publiez des événements sur Kafka, c'est de pouvoir associer chaque événement à une clé fonctionnelle, de telle sorte à ce que les événements qui sont reliés à la même clé se retrouvent dans la même partition. Et ça, c'est un élément primordial. Pourquoi ? Parce que Kafka ne garantit pas l'ordre de traitement au global au sein d'un topic. Si vous avez un topic qui a trois partitions, Kafka ne garantit pas en fait que quand vous allez consommer la donnée, vous avez, vous allez consommer tous les événements de la partition zéro. Ensuite, les événements de la partition un et après les événements de la partition deux. Kafka, garanti juste que, au sein d'une même partition, vous allez recevoir les événements dans l'ordre de production. Donc typiquement là vous pouvez recevoir un deux…. les ronds, les étoiles, les carrés, mais tout en préservant l'ordre au sein de chacune des partitions. Et donc, du coup, si vous avez besoin d'avoir un mode de traitement spécifique, par exemple, vous envoyez des lignes de factures dans Kafka.
Vous devez vous assurer d'associer chaque ligne de facture à la même, au même identifiant de facture, de telle sorte que toutes ces lignes de factures se retrouvent dans la même partition. Donc vous les traitez dans le bon ordre en fait. Donc ça c'est vachement important, la clé de de partition qui est associée à chaque événement. Et à côté de ça ? Ce qui est intéressant dans Kafka, c'est la notion de Consumer Group. Un Consumer group en fait à permet de regrouper des consommateurs d'événements au sein d'un groupe logique, de telle sorte que la lecture Kafka distribue en fait les partitions à chaque membre du Consumer Group. Et le Consumer Group, on va généralement utiliser pour identifier en fait les instances d'une application. Typiquement, j'ai une application qui doit traiter des factures. J'ai démarré trois instances de mon application. Donc je vais les mettre dans le même Consumers Group, de telle sorte à ce que chacune des instances traitent une et une seule partition et qu'il n'y ait pas une partition qui soit traitée par plusieurs instances.

Alioune Sy
Donc c'est comme ça que Kafka garantit l'ordre de traitement, même en cas de multiple consommateur sur un topic. Je passe la main à Jordan.

Jordan Desnoës
Oui, merci Alioune. Donc une des forces de la page Kafka, c'est aussi son écosystème. En effet, Apache Kafka propose un écosystème qui est très très riche. Donc au-delà des simples consumer producer dont on a parlé Alioune juste avant, qui existe dans diverses langages tels que le C++, Java, DotNet et Python, on retrouve trois API de haut niveau. Donc chacune va être dédiée à un usage un peu spécifique et qui va vous faciliter la vie en fonction des traitements que vous avez à accomplir sur les événements issus ou à destination de Kafka. Donc si je prends la première API de haut niveau, c'est Kafka Stream. Donc quand on décrit sur la gauche donc une API qui permet de faire du streaming pseudo temps réel autour d'événements dans Kafka. Donc l'idée c'est de consommer des événements issus de Kafka et de les publier à nouveau dans un autre topic de Kafka. Donc vraiment du traitement de Kafka vers Kafka, Donc cette API, elle est très intéressante pour ce besoin là puisqu'en fait, elle va faire abstraction de toute la partie technique, de toute la couche technique qui permet de faire le poling et la production de données vers Kafka.
Donc tout ça, c'est géré de façon native via cette API. Donc vous allez pouvoir vous focaliser sur le code métier de votre application. Et pour ça une API, une un langage de type DSL, un domaine spécifique langage est également proposé. Il va faciliter toutes les opérations de type jointures, groupement, filtrage, mapping, et cetera. Enfin, l'API Kafka Stream propose deux types de sémantique. Donc la première type de sémantique, c'est la ALO. Cette sémantique garantit, via Kafka Stream, que tous les événements consommés depuis un topic Kafka seront traités à minima une fois. Et pour aller un peu plus loin et éviter les doublons de traitement, une seconde sémantique est proposée - la sémantique EOS. Donc avec cette sémantique qui s'active simplement via de la configuration. Donc vous n'avez pas à gérer toute la partie technique de transactionnalité, de le rollback et cetera. Vient simplement de la configuration. Vous allez pouvoir assurer qu'un événement consommé via Kafka Stream sera traité exactement une fois. Donc on a un petit exemple de code sur la gauche qui indique au fait qui permet en trois lignes de compter les mots issus de messages provenant d'un topic Kafka et pour ce qu'à chaque comptage fait de produire le résultat dans un autre topic Kafka qui sera appelé topic 2.
Second API de haut niveau - l'API KsqlDB. Donc là c'est une API qui intervient en tant que couche au-dessus de Kafka Steam. Est fourni un langage de type SQL. Donc vous avez simplement à écrire des requêtes SQL et ces requêtes vont être transformées ensuite en en code Kafka Stream. Finalement, vous n'avez plus de code à faire si ce n'est de la rédaction, l'écriture de requêtes SQL. Ce qu'il faut voir ensuite, c'est que la requête en question va être exécutée à l'infini en continu. Cette requête n'aura pas de fin et donc l'idée c'est de pouvoir, de même façon que via du Kafka Stream, produire des résultats dans un topic Kafka en continu. Les Use Case typiques pour ce pour l'usage de KsqlDB, ça va être par exemple du monitoring temps réel ou bien également de la gestion de fraude par exemple avec de l'alerting en continu. Donc si on passe maintenant sur la troisième API de haut niveau, elle s'appelle Kafka Connect. Elle permet l'intégration, que ce soit en entrée ou en sortie, de Kafka, avec d'autres systèmes que des systèmes externes et hétérogènes. Par un système externe hétérogène.
J'entends notamment des bases de données, des broker de messages ou autres tels que RabbitMQ, MQSeries ou autre, également de Elastic Search, ou même des services web tels qu'Amazon S3 par exemple. Le but de Kafka Connect est de proposer cette interface entre Kafka et l'autre système de façon très simple et rapide. L'idée, c'est que sur le marché ou sur le marché web, vous allez retrouver plein de connecteurs prêts à l'usage, prêts à l'emploi et vous pour les mettre en œuvre. Vous n'avez qu'à faire de la configuration au format Json, comme le montre l'exemple à droite. Donc pas de développement nécessaire pour interfacer Kafka avec un autre système. Ça permet d'aller très rapidement et se focaliser sur le code métier. Enfin, est-ce que Kafka Connect propose toute la partie résilience et haute disponibilité de façon native, puisque Connect peut fonctionner en mode distribué ? Et donc ça permet de s'abstraire de cette couche technique. Et dernière chose, la Kafka est configurable via une API REST.
Et donc il suffit de faire des appels REST de type curl par exemple pour pouvoir configurer à souhait et à chaud vos connecteurs Kafka. L'écosystème Kafka ne s'arrête pas là. On retrouve principalement trois distributions de la plate-forme Apache Kafka. La première qui est la licence Apache 2.0 qui est totalement open source et qui va proposer les fonctionnalités cœur d'Apache Kafka. Par les fonctionnalités cœur, on entend le broker, l'API Consumers, l’API producteur et également la partie Kafka Connect et Kafka Stream décrit précédemment. Au-dessus de cette couche gratuite et opensource, on retrouve la licence communautaire et la distribution communautaire de l'éditeur Confluent. Elle va apporter des fonctionnalités supplémentaires, notamment. Qu'est ce que le LDB ? Chemin enregistré ? Qui vont vous aider tout au long du développement. On retrouve un certain nombre de connecteurs Kafka Connect prêts à l'usage, distribués par Confluent également. Cette distribution est également gratuite et vous pouvez en plus de ça bénéficier du support Confluent au besoin. Dernier type de distribution qui est la distribution commerciale de Confluent.

Donc là, ça va être principalement l'apport d'outils qui vont vous être proposés. Donc des outils, notamment de monitoring par exemple la console, le Control Center qui vous permet d'avoir un état des lieux en état de vie de votre cluster Kafka, et d'autres outils pour assurer la résilience et la sécurité de votre cluster Kafka. Résilience et Sécurité, notamment la réplication de votre cluster vers un autre data center. Chose qui n' est pas possible de base avec les distributions gratuites. Et du coup, qui dit licence commerciale dit aussi support de la part de l'éditeur. Donc trois niveaux de support: le support Silver, le support support Gold et le support Platinium. A noter cependant sur la partie connecteurs qui sont disponibles en licence communautaire que certains sont proposés sous forme d'évaluation. Au bout de 30 jours, vous allez devoir souscrire à la version commerciale pour pouvoir continuer à les utiliser. Maintenant on va passer sur la partie Bad de Kafka. Ce qu’on entend par la partie Bad de Kafka ? C'est tout ce qui va être des choses que vous n'aviez pas prévu parce que vous ne vous étiez pas assez documentée sur le produit.
Vous, vous n'aviez pas connaissance du fonctionnement interne du produit et donc c'est des choses qui peuvent vous surprendre en production lorsque vous allez les rencontrer. Donc pour commencer, on va s'intéresser un peu plus au producer, donc le producteur de l'événement dans Kafka. Donc va voir comment il fonctionne avant de voir ce qui se cache derrière en termes de pièges. Donc, il faut savoir que le producteur Apache Kafka y veut. Il a pour but d'offrir une logique événementielle et en même temps de permettre du micro batching. On va voir cela, donc il fonctionne de façon asynchrone, nativement et par défaut. L'idée étant de ne pas aller contre ce type de fonctionnement. Pourquoi ? Principalement parce que ce fonctionnement asynchrone va vous offrir des performances meilleures que synchrone. Typiquement, tout un tas de choses va être faite en asynchrone. La première étape de la sérialisation des données. L'idée étant de pouvoir transformer les données d'entrée en sous forme de tableaux de bites afin de pouvoir les faire ingérer au broker Kafka puisqu’il ne gère que les tableaux bites.
Deuxième étape faite de façon asynchrone, c'est le partitionnement. Donc décrit par Alioune juste avant afin de choisir la partition concernée par notre événement. Et enfin, et non des moindres, la dernière étape l'étape de batching qui consiste à accumuler pour une partition et un topic donné les événements qui sont dédiés à ce même topic et partitions. Derrière ça se cache vraiment un aspect d'optimisation de performances puisqu'on souhaite, pour limiter les requêtes réseau entre le producer de données et le broker Kafka. Qui dit limitée dit batching, donc accumulation de données pour les envoyer sous forme de lots au broker Kafka et donc limiter les requêtes et gagner en rapidité et en temps. Enfin, il faut savoir que le producer, de façon native, donc sans même avoir à implémenter cette partie là, devient du code ou de la technique. Il va proposer tout ce qui est une gestion de retry de façon automatique. Cette gestion d'héritage est configurable soit via un certain nombre de retry que vous avez paramétrer, soit via un délai à ne pas dépasser.
Donc elle va permettre principalement cette gestion des retry automatiques de couvrir des cas d'erreurs, notamment liés à des glitch réseau, par exemple la perte de communication entre le broker et le producteur. Donc ce retry va pouvoir de façon transparente, pallier ces problèmes là. Si le nombre de retry est configuré ou le délai configuré expire, une exception va être remontée au producteur qui a, au choix, pouvoir la gérer ou la renvoyer ou l'ignorer. Voilà concernant l'anatomie du producer. Donc maintenant qu'on a vu un peu comment il fonctionnait, on va voir quel piège peut se cacher derrière ce fonctionnement. Donc pour ça, on va se focaliser un peu sur le fonctionnement des replica. Donc comment les données sont répliquées d'un broker à un autre. Donc pour chaque partition, on a ce qu'on appelle un leader et un follower. L'idée étant que le leader va être le premier à persister la donnée et que les followers vont ensuite pouvoir aller chercher la donnée auprès de ce leader. Donc ils vont venir se synchroniser par rapport à ce leader au fur et à mesure.
Dans notre exemple, on a trois brokers. On a défini un facteur de réplication de trois, ce qui indique qu’on souhaite que notre donnée soit persisté à trois entre trois endroits différents. Donc le broker 101, le broker 102 et le broker 103. Le producer va écrire la donnée dans le broker 101 et les brokers 101, 102 et 103 vont venir se synchroniser pour récupérer cette nouvelle donnée. Donc on a vu ce mode de fonctionnement des répliques. On va s'intéresser aux garanties qu'il offre qu'offre le produit producer, qui sont notamment au niveau des équipements. Il en existe trois niveaux, trois types d'aliments différents. Donc le premier mode d'acquittement qu'on a appelé YOLO. Vous allez vite comprendre pourquoi. L'idée étant qu'au fait, le producteur ne vérifie pas. Il ne s'attend pas à avoir un acquittement de la part du broker. Donc c'est vraiment un mode Fire and Forget. Le producer envoie la donnée. On n'a pas de garantie que la donnée a été persisté côté broker, mais on continue nos traitements.
Donc du coup, c'est le mode le plus performant puisqu'on passe à la suite des traitements sans manches sans même attendre. Mais par contre, c'est aussi le mode le plus risqué puisqu'on n'a pas de garantie que la donnée était persistée. Donc le cas d'usage, ça va être par exemple des événements qui vont être auto porteurs et qui vont et pour lesquels, du coup, la perte d'un événement intermédiaire ne va pas influer sur le résultat final des traitements. Le deuxième mode qui offre un compromis entre performance et résilience, c'est le mode Leader Ack. Donc, dans ce mode, le producer va attendre l'acquittement seulement du broker leader de la partition. Dès que le leader de la partition a fourni l'acquittement, il a indiqué avoir persisté la donnée, le producer va pouvoir passer à la suite. Donc ça, ça offre un bon compromis. Mais il faut savoir que ce n'est pas un mode exempté de défaut. Il faut bien avoir en tête que l'on peut toujours avoir des pertes de données avec ce mode.
Je m'explique. Dans notre cas, notre producer va envoyer la donnée au broker 101, le broker 101 va la  persister et à la suite, le producer va pouvoir passer à la suite puisqu'on a reçu l'acquittement. Cependant, en cas de crash du broker 101, donc du broker leader avant que les synchros, que les que les followers, donc que les deux autres brokers soient venus se synchroniser et récupérer la donnée pour la persister chez eux. Si le broker 101 crash entre temps, la donnée n'étant présente qu'à cet endroit, elle sera définitivement perdue jusqu'au redémarrage de ce broker. C'est un mode qu'il faut bien avoir en tête. Il peut entraîner des d'événements également. Donc ceci étant dit, on va pouvoir passer au mode le plus sûr, le plus résilient qui est le mode In Sync Replicas Ack ! Donc, contrairement au modèle Leader Ack, on va attendre dans ce mode d'acquittement que la donnée soit répliquée à la fois sur le broker leader mais également sur les brokers followers. Donc pour ça. Le broker 101 donc le broker leader qui est le seul avec qui on communique…
…Va nous renvoyer l'acquittement, seulement une fois qu'il est certain que les brokers followers auront récupéré la donnée également. Attention cependant, intervient à ce moment une notion qui indique le nombre minimum de replicas qui doivent synchroniser la donnée. Donc on a indiqué que nous, on voulait un facteur de réplication de trois. Mais s'ajoute à ça la configuration du nombre minimum, dit SR qui par défaut est à un. Ce qui indique que si mes deux autres brokers - followers sont K.O, mon nombre minimum d’ISR étant un 1, je vais quand même avoir un acquittement puisque je remplis ce contrat. Donc si on veut rendre ce mode au plus résistant possible, il faut configurer un nombre minimum de replicas synchronisés supérieur à un. Donc dans notre cas compris entre deux et trois. Donc ce mot étant donné que c'est le plus sûr, il intervient surtout dans des Use Case où on ne veut pas perdre de données ou par exemple des transactions bancaires ou des données métiers très importantes. 
Il est indispensable de bien avoir ça en tête et du coup, de paramétrer son équipement en fonction de nos besoins, à la fois sur la partie producer, mais également sur les brokers et topics qui sont également porteurs de configuration. Je pense notamment au nombre de replicas minimum. Le min ISR qui va pouvoir se configurer au niveau broker et topics et pas au niveau producer. Ça donc bien avoir une notion de ces trois niveaux de configuration pour obtenir les garanties souhaitées.

Alioune Sy
Donc merci Jordan. Effectivement, il y a pas mal de pièges dans lesquels on peut tomber si on ne configure pas correctement ou si on ne prend pas garde à la configuration du producer de données. Et il en est de même pour la partie consommateur de données. Ce qu'il faut également garder en tête, c'est que les Consumer API Consumer de Kafka fonctionnent un peu comme l’API producer, dans le sens où ça va fonctionner par batch. Donc quand vous consommez des événements dans Kafka, vous ne les consommez pas un à un. En fait, vous récupérez un batch d'événements, que vous traitez. Vous commitez l'offset de dernier événement que vous avez traité, et ainsi de suite. Donc, si on regarde comment ça fonctionne finalement avec une sorte de timeline à trois temps. En T0, imaginons que le dernier offset qui avait été commité c’est Offset 2. Donc dans le code qu'on va faire en consumer pool pour récupérer un certain nombre d'événements à traiter. Kafka va à vous, va nous envoyer un batch, donc là, en occurrence, il nous envoie les événements 2, 3, 4 et 5.OK, donc tout va bien. On a récupéré quatre événements, on va faire une boucle pour les traiter. Ce que vous ne savez pas ? En tout cas, on ne sait pas forcément quand on démarre sur du Kafka. C'est que dans l'API consumer par défaut quand on démarre un consommateur d'événement, Kafka démarre en Thread, également en tâche de fond pour faire de l'auto commit des offset. Donc en gros ce Thread là qu'est ce qu'il va faire ? Et il va regarder le dernier batch d'événements qu'on a reçus. Il prend le dernier événement et toutes les cinq secondes il va commiter automatiquement dans Kafka en disant - positionne les offset de mon consumer à 6. Parce qu'il a déjà récupéré deux, trois, quatre et cinq. Ça peut être assez intéressant parce que finalement, ça nous décharge de tout ce travail de gestion un peu fine des Offset. Sauf que ça, c'est dangereux parce que qu'est ce qu'il peut se passer ? Donc en T0, on a récupéré les événements deux, trois, quatre cinq en t0 + cinq secondes…
…Donc on a un casque en tâche de fond qui va commiter l'offset. OK, ça c'est transparent pour moi. Sauf que nous, on en est toujours par exemple dans notre boucle de traitement des événements. Donc on a traité l'événement deux et trois, donc on va continuer. On va essayer de traiter quatre et cinq. Donc en t0 + sept secondes, donc le dernier, on avait traité deux, trois, on est en train de traiter quatre et boum - une erreur. Qu'est ce qu'on va faire sortir de notre boucle ? Éventuellement ce qu'on fait, un try catch, et donc on va revenir au niveau du consumer policy pour demander à Kafka de nous renvoyer les événements. Car on pourrait s'attendre, si on ne comprend pas bien le fonctionnement de Kafka, à ce qu'il nous renvoie le même batch d'événements, vu qu'on n'a pas commité l’offset, mais vu qu'il a été commité automatiquement par Kafka juste avant, à t0 plus cinq, est ce que ça va faire ? En fait, c'est que quand on va refaire un consumer poll, ici dans le code, Kafka va nous renvoyer un batch d'événements à partir de l’offset 6 qui a été comité automatiquement par le consumer.
Ce qui va faire finalement qu'on va se retrouver dans une situation où on a perdu des événements parce que les événements deux et trois, on les a traités. Quatre - on était en train de le traiter, mais on en a craché. Cinq - on n'en parle même pas et au prochain Consumer Poll, on reçoit six, sept, huit et neuf. Moralité - on aura perdu deux évènements qu'on n'aurait pas traités et de façon totalement arbitraire et transparente. Donc il faut vraiment faire très attention lorsque vous consommez des événements avec Apache Kafka parce qu'il a ce comportement d'auto commit toutes les cinq secondes. Donc il faut toujours penser à désactiver l'auto commit des offset au niveau de l'API Consumer pour pouvoir gérer vous même les offset, une fois que vous êtes sûr que vous allez traiter tout le batch que vous avez récupéré de Kafka. Ou alors si vous laissez cette configuration là, faut vraiment savoir pourquoi vous le faites et s'il est vraiment adapté à votre Use Case. Est ce qu'il faut également garder en tête que la plupart des librairies, un peu au niveau que vous allez trouver sur GitHub, sur je ne sais pas quel dépôt public fonctionnent également de cette manière de la même manière.
En fait, il ne désactive pas l'auto commit par défaut. Donc faites vraiment attention à cette configuration qui peut vous entraîner dans des situations un peu bizarre. Et de façon un peu similaire aussi, si vous ne comprenez pas bien comment fonctionnent les transactions dans Kafka, vous pouvez vous retrouver dans des situations un peu bizarroïdes. Parce que depuis les dernières versions de Kafka, elle gère la notion de transaction. Sauf que les transactions dans Kafka, ça ne fonctionne pas comme des transactions en base de données. En fait, c'est pas des transactions acides au sens relationnel du terme. Donc typiquement là je vous ai matérialisé en fait une partition dans Kafka où on lit un certain nombre d'événements. Donc comment ça se lit ? On va considérer que les événements qui sont noirs, ce sont des événements qui ne font pas partie d'une transaction. Les événements qui sont bleus, ce sont des événements qui font partie d'une transaction et les événements en rouge, on va le voir en détail. Globalement, dans Kafka, quand vous voulez activer les transactions, c'est au niveau de l’API.
Ben vous faites Int transaction, Begin transaction. Un peu comme ce que vous auriez fait dans une base de données. Et ensuite là par exemple on fait une boucle ou on va envoyer cinq événements qui correspondent à un, deux, trois, quatre et cinq, ici en bleu. Et donc dans le cas d'usage, là juste à la fin de la boucle, en faire un abord de transaction. Donc typiquement naïvement, quand on voit ce code là, on pourrait se dire finalement, on a fait cinq fois, on a fait un abord de la transaction. Donc il n'y a aucun événement dans Kafka. Sauf que dans la vraie vie, quand vous activez les transactions dans Kafka, qu'est ce que ça fait ? Rappelez vous ce que j'ai dit. Les événements qu'on envoie dans Kafka sont persistés sur le disque. Donc, une fois qu'on est un événement, il est écrit, il est écrit, on ne peut pas le supprimer, on ne réécrit pas le passé. Ce que fait Kafka et que quand vous activez les transactions, c'est que finalement, il va envoyer des événements un peu spéciaux dans les partitions qui sont des événements qui vont délimiter des frontières transactionnelles.
Typiquement, quand on a fait un Begin transactions ici, Kafka a rajouté un événement de début de transaction. Ensuite, chacun des événements qui ont été publiés dans la boucle sont vraiment émis dans Kafka, mais avec une métadonnées qui les rattache à une transaction pour dire qu'ils sont rattachés à ce marqueur transactionnel qui est là. Ça suit son cours et avec le Abort Transactions finalement, Kafka a publié un événement également qui délimite la fin de la première transaction, mais en précisant que la transaction a été abordée. Donc, ce qui va se passer si vous utilisez un consumer qui n'est pas configuré de façon spécifique, si vous utilisez juste la configuration de base, quand vous allez faire consumer poll, et cetera, et cetera, vous allez vous retrouver à lire tout ça en fait. Donc y compris les événements non transactionnels X, Y, Z et les événements qui faisaient partie de la transaction, même s' ils avaient été abordés. Donc vous allez lire un, deux, trois, quatre, cinq à tort et donc pour éviter ce genre de problématique….
En fait, il faut configurer explicitement le consommateur pour lui dire qui doit être en read committed qui ne doit lire que les événements non transactionnels, typiquement les événements en noir dans ce schéma là ou les événements qui font partie d'une transaction mais pour lequel on a un événement marqueur de fin de la transaction qui est non pas Abort mais Commit. Donc en l'occurrence, si on configure le contenu mais en read committed, on va dire x, y et z uniquement. Donc moralité - les transactions c'est bien mais ça ne fonctionne pas comme les transactions en base de données. Faut vraiment faire gaffe à ça. Et dès lors que vous utilisez quelque part dans votre récit des transactions, il faut que tous les consommateurs d'événements en aval de cette application là. Donc, ils vont lire des événements qui sont produits par l'application qui a activé les transactions. Il faut qu'ils soient en read committed. Sinon, vous vous exposez au risque de lire des événements qui ont été rollback. Et du coup je te repasse la main Jordan.

Jordan Desnoës
Tout à fait. Donc maintenant nous allons entamer la partie The Ugly d'Apache Kafka. Donc qu'est ce qu'on entend par la partie The Ugly ? Finalement, ça va être toutes les notions que vous avez vu dans la documentation que vous avez mis en œuvre, avec peut être des choses qui vous ont échappé et qui amènent à de drôles de comportements en production par exemple. Alors pour illustrer ça, un premier exemple, donc il faut savoir que les crashs ça n'arrive pas qu'aux autres. Alioune et moi même avons rencontré plusieurs crashs de nos applications, de nos clusters Kafka. Et donc ceci est un exemple dont nous allons vous parler. Donc dans mon cas, j'ai deux data center : data center 1, data center 2. Chacun de ces data centers contient deux brokers Kafka avec un seul topic constitué de quatre partitions. Donc j'ai vu qu' avoir des replicats c’est bien. Je suis là, je suis un peu le Tech Talk. Et au niveau des processeurs, je peux configurer un facteur de réplication et un facteur minimum de replica.
Donc j'ai positionné ces de ces deux configurations à la valeur deux, ce qui me garantit que ma donnée sera persistée deux fois au minimum. Donc ça pour moi tout est ok. Là intervient mon premier crash de data center, donc je perds mon data center numéro un, ce qui implique la perte de mon broker numéro un et de mon broker numéro deux. Donc jusque là je suis plutôt confiant parce que j'ai bien suivi la doc, j'ai mis, j'ai configuré tout comme il fallait, je sais que j'ai des répliques dans tout, donc tout devrait fonctionner. Sauf que, en regardant un peu dans le détail bien fait, il n'y a plus rien qui fonctionne. Alors pourquoi ? Donc si je prends l'exemple de mon topic 1 partition numéro 1, là je me rends compte que finalement cette partition numéro 1 était présente dans le broker 1 et également dans le broker 2. Donc deux répliquas comme je l'avais indiqué, mais manque de pot, ces deux brokers se trouvent dans le même data center. Donc finalement boum, j’ai pu les données associées donc je ne peux plus continuer à produire sur cette partition.
Bon, passons donc on va s'intéresser maintenant dans la partition zéro du topic 1. Donc là j'ai un peu plus de chance. Elle était répliquée à la fois sur le broker 1 et également sur broker 3. Donc j'ai encore le bon broker 3 dans data center 2 donc finalement super. Je vais pouvoir continuer à me servir de cette partition à minima et sauf que boum encore. Pourquoi ? Tout simplement parce qu'en fait j'ai défini un facteur de réplication à deux et un nombre de répliques minimum à deux. Sauf que là, je viens de perdre un replica, donc je ne satisfait plus mon nombre de répliques à minimum, puisque je n'ai qu'un seul répliqua en data center 2. Mon producer, par conséquent ne peut plus écrire de données dans cette partition. Donc finalement c'est comme si la partition est également hors service. Donc j'ai pourtant j'avais tout bien fait. J'avais configuré des replica. Donc ce qu'on a dit que c'est qu'avoir des répliques c'est bien savoir où ils sont, c'est encore mieux. Donc pour éviter dans le premier cas d'usages qu'on l'on de voir, pour éviter d'avoir une partition répliquée dans deux brokers qui se trouvent dans le même datacenter…
La notion de rack awareness a été inventée et elle a été positionnée dans la plateforme Apache Kafka. Donc finalement, le rack awareness est une notion qui va permettre de disperser la donnée dans différents brokers qui se trouvent, eux, dans des rack, dans des data centers, dans des salles machines différentes, ce que vous voulez. Mais l'idée étant de disperser la donnée selon une configuration que vous allez mettre en place. Donc en l'occurrence, j'aurais pu définir un rack pour mon data center 1, un rack pour mon data center 2. Ce qui garantit que Kafka va disperser la donnée dans ces deux data centers et éviter d'avoir tout dans le même. Donc ça, ça répond à la première problématique que j'ai rencontrée. Et pour la seconde problématique rencontrée de non satisfaction du nombre minimum de réplicants. Le mieux finalement, c'est encore d'avoir un facteur de réplication qui va être supérieur au nombre de répliques minimum que je veux avoir à tout moment. Donc c'est pour ça que la configuration facteur de réplication doit être supérieur au facteur minimum de réplique.
Tout ça pour dire qu'avoir un plan de reprise d'activité et d'avoir ça en tête, c'est pas mal. Comme je l'avais là. Sauf que le mieux, c'est encore de tester en conditions réelles avant de rencontrer des problèmes en production. Et ça nous permet finalement d’éviter ce genre de maladresses et de choses qui peuvent arriver si on n'était pas bien informé du fonctionnement. Donc Kafka, c'est quand même une plateforme qui propose des performances assez intéressantes. Je vous en parlait tout au début en introduction. C'est comme ça que j'ai mis en place, que je me suis intéressé à cette plateforme. Sauf que c’est pas exempté de tout problème de performance, que ce soit au niveau de la plateforme elle-même ou au niveau de l'écosystème de son environnement d'exécution. On peut rencontrer des problèmes de perf comme sur tout système en fait. Et donc, si on rencontre des problèmes de perfs, l'idéal c'est de pouvoir dire où est ce qu'ils sont quoi. Donc sur une chaîne qui va du producer en passant par les broker Kafka pour aller jusqu'au consumer ?
Ça fait quand même pas mal d'événements, d'éléments à analyser pour trouver la raison de nos problèmes de performances. Donc typiquement au niveau du producteur, ça peut être des problèmes de latence réseau entre le broker et le producer. Ça peut être au niveau de la deuxième étape au niveau des brokers, ça peut être un problème de réplication, de synchronisation des répliques qui fait que je verrais pas mon acquittement suffisamment rapidement. Et enfin, au niveau du consumer, ça peut être soit mon traitement applicatif lui même qui est trop long, qui fait que du coup j'ai de la latence dans les évènements. Ça peut également être finalement des problèmes réseau entre le broker Kafka ou des problèmes de disque qui ralentissent mon polling au niveau des brokers. Pour ça, pour pouvoir analyser et trouver la source, la source de ces lenteurs, le mieux est de monitorer via des métriques GMX puisque la plateforme Kafka étant basée sur JVM, tout un tas de métriques GMX sont exposées et le mieux c'est d'utiliser, de pouvoir visualiser où se trouvent nos latences, nos erreurs.
Dans notre cas d'usage, on devrait faire un petit exemple avec trois broker Kafka, un facteur de réplication à trois que je cherche à répliquer m'a donné tout sur les trois brookers et un acquittement à all. J'ai constaté que je méttais un peu de temps pour produire des événements. En effet, à la production d'événements qui prend un temps total de 2,3 secondes. C'est ce que m'indique les métriques GMX et ce que je peux dire. Ce que je constate, c'est que je passe 1,5 secondes au niveau de la partie réplication. Donc pour savoir quel est le motif de cette lenteur niveau réplication, je peux faire un zoom sur la partie broker. Donc la partie qui se trouve au milieu. Donc pas le pas des consumers, pas les producers. Donc c'est le graphe d'en dessous et qui m'indique que c'est au niveau de mon broker Kafka deux que je passe ce temps là et que je peux du coup suspecter raisonnablement une contention au niveau du CPU ou des input output disque ram, et cetera.
Donc il faut savoir qu'il y a tout un tas de maîtrise GMX qui permet de faire ces analyses là. Le combo ultime c’est l'utilisation de prometheus grafana qui permet d'avoir des dashboard très jolis, de facilement identifier les root causes. Par contre, il faut également faire le tri dans ces métriques parce qu'elles sont tellement nombreuses que certaines peuvent noyer et ne sont pas pertinentes dans l'analyse de ces problèmes-là. Donc à utiliser avec parcimonie, bien faire le tri pour ne garder que les pertinentes. Maintenant que j'ai mis en place des métriques GMX, c'est bien beau, je peux les visualiser dans grafana. Du coup, je suis capable de monitorer ma plateforme, mais avoir des alertes, finalement, c'est encore mieux. Parce que avoir un grafana et des graphiques qu'on utilisera que le jour ou d'autres plateformes a craché, à part de constater que finalement à la belle et bien effectivement craché, ça ne va pas servir à grand chose. Donc le mieux pour ça, c'est de mettre en place des alertes sur les sur les métriques les plus pertinentes, sur les éléments les plus pertinents qui peuvent indiquer toute défaillance avant le crash.
On pense notamment au niveau des réplications, à vérifier que toutes nos répliques sont en phase. Vérifier qu’on a un seul actif contrôleur et qu'on n'a pas de réplicats qui serait désynchronisés, et cetera. Donc tout ça pour dire qu'un monitoring, derrière, il faut mettre en place des alertes pour pouvoir prévenir ce genre de problèmes et pas seulement les constater une fois que ça arrive.

Alioune Sy
Merci Jordan. Qu'est ce qui se passe si on suit tout ce qu'on vient de voir ? On a bien configuré ces acquittements, l’auto commit, on l’a désactivé, on est en monitoring, et cetera et cetera On peut se dire que raisonnablement on a quand même fait des efforts. Ça devrait bien se passer. Et bien non. Qu'est ce qui se passe finalement quand on se retrouve dans des cas d'erreurs lors de la consommation de données ? Rappelez vous le consumer va fonctionner par batch, donc en fait un consumer poll, vous récupérez dix évènements et ensuite vous désactivez l’auto commit. Il faut qu'à la fin du traitement de ces dix événements, vous commitez l’offset de Kafka dans cas pour que la prochaine fois que vous faites consumer poll, vous récupérez un autre batch d'événements. Qu'est ce qui se passe si vous avez ce qu'on appelle un poison pill. Ça va être un événement qui est planqué en plein milieu de votre topic, là qui lui entraîne une erreur quasi systématique. Donc si vous n'avez pas de stratégie spécifique de gestion des erreurs et que vous fonctionnez en mode par défaut en mode YOLO, ce qui va se passer, c'est que vous allez avec consumer poll...
Récupérer ce batch de messages là, vous allez traiter un deux, vous arrivez sur le poison pill boum - vous crachez. Vous commitez, pas les offsets. Vous repartez dans Kafka, vous faites poll, vous récupérez le batch, le même batch et ainsi de suite. Rebelotte. Donc vous allez boucler indéfiniment. Et Apache  Kafka ne fonctionne pas comme certains brokers que peut être vous connaissez. Ou il y a des stratégies ou automatiquement le broker va écarter un messagen au bout d'un certain temps, nombre de jeux. Ça ça n'existe pas dans Kafka en fait. Et donc du coup de base, si vous vous retrouvez dans cette situation là, vous allez boucler indéfiniment et vous n'allez plus avancer, vous n’ allez plus pouvoir empiler les événements. Donc du coup, ce qu'il faut faire, c'est définir en fait une stratégie de gestion d'erreur. Donc il y a plusieurs stratégies qui sont possibles, dont Kafka gère automatiquement la purge de données. Donc, par défaut, au bout de sept jours, les événements sont purgés.
Donc ça, ça peut être configuré. Vous pouvez mettre six ou sept jours, même trois mois si vous voulez. Mais une des premières stratégies qu'il est possible de mettre en place, c'est de ne rien faire et d'attendre la purge de données. Donc attendre que ce batch de message soit purgé et donc du coup vous n'aurez plus à faire aux poison pills, vous pouvez épiller. Ca c'est bien, sauf que vous aurez perdu tout un tas de données, ce qui n'est pas forcément ce que vous vouliez faire. Une autre possibilité, c'est de changer l'identifiant de votre consumer groupe vu que, en fait, l'offset de lecture est lié au consumer group pour que plusieurs consumer groupes puissent consommer sur le même topic. Vous pouvez modifier le d'identifiant du consumer groupe de votre application de telle sorte qu'elle soit considérée comme une nouvelle application. Donc, par défaut, Kafka va commencer à lire à partir de la fin du topic ou au début ça dépend de la configuration auto offset reset. 
Si vous changez les dimensions du consumer groupe, vous allez recommencer à consommer de la donnée à partir du dernier événement. Vous pouvez changer manuellement l'offset du consumer groupe également. Il y a des API, Il y a une ligne de commande dans Kafka qui permet de faire ça, mais bon, c'est un peu fastidieux, c'est long à faire extra, c'est complexe. Ou alors une stratégie beaucoup plus vertueuse, c'est de définir, de configurer dans Kafka et Handler d'erreur. Donc vous pouvez spécifier Kafka, qu'il va utiliser à chaque fois qu'il a rencontré une erreur, ce qui va permettre en fait de la gérer applicativement dans votre code. En fait, plutôt que de décharger ça côté broker et donc à partir de là, vous pouvez définir un certain nombre de stratégies un peu classiques qu'on retrouve quand on met en place des architectures événementielles. Donc j'évoquais tout à l'heure les dead letter queue. Bah, vous pouvez mettre en place des dead letter topics par exemple pour isoler le présent pill dans un topic d'erreur pour pouvoir le traiter manuellement plus tard.
Voilà donc moralité. Kafka c'est bien, mais faites attention, mettez en place des stratégies de gestion d'erreur parce que Kafka ne va pas le faire pour vous, tout simplement. Dernier point d'attention. C'est ce que Kafka permet de faire beaucoup de choses. C'est très intéressant comme Jordan l’a évoqué, c'est assez rapide en termes de performances, c'est top, etc. Pour autant, il faut faire des choix. Typiquement avec Kafka, en fait vous pouvez le configurer pour faire de la latence, donc faire des traitements ultra rapide et très véloce pour être durable pour pouvoir nous assurer une non-perte de données. Vous pouvez le configurer également pour qu'il soit hautement disponible. Ou alors vous pouvez le configurer pour qu'il puisse faire du traitement en masse, donc pouvoir traiter un maximum d'événements à la seconde. Et donc bien évidemment on ne peut pas tout avoir. Donc vous ne pouvez pas configurer Kafka pour avoir toutes ces propriétés là. Au maximum, vous pouvez avoir deux ou trois, mais pas toutes les propriétés. Donc il faut bien identifier vos Use Case et configurer Kafka de façon adéquate de façon adaptée à vos Use Case.
Sinon, finalement, vous allez vous retrouver à vous dire, Kafka ne répond pas à mon besoin. C'est pas adapté. Mais c'est peut être que vous n'avez pas bien configuré Kafka par rapport à vos Use Case en fait. Donc là, on vous a juste présenté un aperçu de quelques points d'attention issus de de nos retours d'expérience, il y en a tout un tas d'autres qu'on pourrait évoquer. Mais globalement, le message qu'on voulait vous faire passer, c'est Kafka est assez bien, mais ne vous lancez pas dans l'aventure Kafka juste comme ça, en faisant juste les POC. Étudier vraiment la chose. Informez vous et posez vous les bonnes questions. Typiquement, là, on va lister quatre huit thématiques sur lesquelles il nous paraît important de se pencher avant toute mise en place d'une architecture à base de Kafka. Typiquement, la gestion des topics. Est ce que vous utilisez les bonnes API pour faire vos traitements ce qu'il ne faut pas faire du Kafka stream plutôt que faire des producteurs à la main. Le dimensionnement, le monitoring, et cetera reste donc plein de choses à étudier avant de se lancer juste à corps perdu, à faire du Kafka.
Et donc, à ce sujet, Jordan a un petit message à vous passer.

Jordan Desnoës
Oui, tout à fait. Donc, comme vous le disait Alioune, on intervient en tant que de façon ponctuelle sur des projets qui souhaitent mettre en place Kafka. Et donc pour intervenir, on s’est construit une grille d'audit qui regroupe plusieurs points de contrôle, que ce soit sur les OS, hardware, topic, broker, Kafka. Vraiment on vise très très large. On a 190 points de contrôle et l'idée c'est de s'assurer que rien n'a été oublié et qu'en plus de ça, la configuration qui a été mise en place correspond aux besoins du projet et aux exigences vues avec les clients. Donc, au-delà d'une simple grille d'audit, on s'en sert en plus comme outil pour construire, pour mettre en place le broker Kafka et sa configuration sur notre projet et non pas juste en dernier recours avant de partir en production. L'idée est vraiment de fonctionner de façon itérative pour résoudre les différents points abordés dans cette grille d'audit et arriver en production le jour J avec quelque chose qui correspond vraiment à nos attentes.
Et donc dernier point pour continuer la montée en compétence sur Kafka. Il existe trois grands types de moyens finalement. La première, c'est des formations, donc il en existe des gratuites, notamment une, la Kafka concepts fondamentals, qui est proposée  directement par l'éditeur confluent qui est gratuite et quatre autres qui sont payantes et sur trois jours. Parmi ces quatre autres, il y en a deux qui sont plutôt orientées développement et deux autres qui sont orientées administration, exploitation, ops autour de clusters Apache Kafka. Et il y a également des certifications que vous pouvez vous faire certifier sur ces deux aspects là. Donc à l'issue de ces formations, vous pouvez vous faire certifier en tant que développeur Kafka ou bien en tant qu'opérateur administrateur Kafka. Et enfin, vous pouvez vous appuyer sur les communautés, les communautés à chaque fois qui sont riches, notamment avec le blog de confluent auquel vous avez trouvé des exemples de Use Case, par exemple de gestion de priorités ou ce genre de choses. Certains l'ont déjà mis en place.
Vous allez pouvoir avoir des exemples de mise en œuvre. Et on a un autre exemple de projet communautaire, donc, chez Sopra Steria, on a Sylvain Le Gouellec, qui intervient et qui propose une implémentation de Kafka Stream pour le langage dot dead, puisque celle de par confluent et Apache est à la base fonctionnelle uniquement sur le langage Java. Et enfin, il y a certains événements dédiés à Apache Kafka, comme le Kafka Summit Europe qui va avoir lieu au mois de mai prochain et qui est totalement gratuit et qui se fait cette année de façon virtuelle à cause des conditions sanitaires. Donc vous pouvez y participer comme vous voulez. Donc voilà, on est en train de répondre à certaines de vos questions. N'hésitez pas déjà, si on n'a pas le temps ou si des questions vous viennent de post tech talk, n'hésitez pas à nous contacter sur nos adresses mail. Nous pourrons vous répondre au besoin.

AliouneSy 
Mouais. Côté question, du coup, il y a quelques questions. Merci à vous déjà d'avoir participé. Donc Jordan a répondu à quelques questions…
Notamment. Qui supporte SQL db. Donc ce n'est pas Apache, c'est bien confluent dans la version Community. Donc jetez un coup d'oeil au fichier licence sur GitHub. Je pense que ça ne fait pas de mal. Mais globalement d'un point de vue utilisation, ça ne devrait pas poser de problème si vous êtes pas Amazon.
À partir de quelle version supporte les transactions dans Kafka ? C'est la version 0.11. Côté broker. Kafka.
Comment on gère la purge des données qui sont persistés sur le disque dur ? Là, il y a plusieurs manières de le configurer et Jordan a répondu aussi suivant la taille ou le délai.
Une petite question technique où tournent les traitements Kafka connect ? Est ce que ça tombe sur les brokers ? 

Jordan Desnoës
Pas nécessairement, car il faut savoir que Kafka Connect c'est un procès de sa part, un peu comme vos clients produits sur consumers. Donc libre à vous de le déployer où vous voulez. Donc vous pouvez le déployer sur une machine externe sur le cloud, vraiment comme vous voulez. L'idée étant que cette machine, l'endroit où tournent les traitements ou tournent Kafka Connect, puisse communiquer avec le broker Kafka de destination. 

Alioune Sy
OK, très bien. Pour terminer on prend un peu de hauteur. C'est une question qui est arrivée au tout début de talk. C'est concrètement un événement, ça correspond à quoi le coup peut être derrière ou donner quelques exemples ? Et puis concrètement, ça se traduit comment un body, des metadata ? Qu'est ce qu'on transmet finalement quand on émet un événement ? 

Jordan DesnoësDu coup, je vais prendre la question. Un événement finalement, faut faire le parallèle avec un message pour un broker de messages type RabbitMQ. C'est tout simplement un message, donc une donnée qui va transiter dans Kafka. De quoi est constitué un événement ? Comme tu disais Jérôme, y a en effet des metadata qui vont permettre de définir notamment le timestamp du message de l'événement et la partition cible, par exemple, de cet événement là. Donc c'est pour la partie metadata. Et ensuite, il y a une seconde partie qu'on appelle le body, le body de l'événement ou du message, qui est constitué de deux champs. Le premier, c'est la clé. Donc la clé qui est utilisée, notamment pour le partitionnement, comme vous l'a expliqué Alioune précédemment. Etl'autre champ du body, finalement c'est vraiment la value. Donc la value ça va être le corps de message, la donnée qu'on souhaite manipuler et qui peut être du Json qui peut être du XML ou du texte. Tout ce que vous voulez. 

Alioune Sy
OK, merci, mais je vous laisse le mot de la fin. 

Jordan Desnoës
À ton honneur Alioune.

Alioune Sy

Est ce que je suis en direct ? Je ne sais pas. Oui, je suis en direct. Voilà. Merci déjà pour votre participation. J'espère que vous aurez au moins appris deux ou trois trucs ou en tout cas que vous aurez compris que Apache Kafka comporte son lot d'avantages, d'inconvénients, mais surtout son lot de pièges également et qu'il faut sérieusement se pencher sur le sujet. Si vous devez le mettre en place quelque part, je pense que ça résume bien la complexité et puis la puissance de cette plateforme. Donc voilà ce qu'il y avait à dire. On a fait une sélection qui nous paraissait pertinente, mais on aurait beaucoup de choses à dire sur Apache Kafka. Donc n'hésitez pas à parcourir la doc et puis à vous informer sur le sujet. Et puis voilà. Et puis on vous dit à bientôt pour de nouveaux épisodes. Let's talk about IT ! Maintenant, c'est plus tech talks. Merci à vous