Kafka Summit, c’est l’évènement où se réunissent les contributeurs, utilisateurs et passionnés d’Apache Kafka, une plateforme de streaming de données. Il a lieu trois fois par ans (New York, Londres et San Francisco). La conférence est organisée par Confluent Inc, et est une de ses nombreuses contributions à l’animation de la formidable communauté de développeurs / DevOps réunis autour de l’idée d’une entreprise ou d’un business basé sur des événements temps réel.

J’ai eu la chance (merci @XebiaFr) d’assister à l’édition 2019 de Londres et je vous résume ici les talks qui m’ont le plus marqué.

Lundi

Les Keynotes sont de 20 minutes et la première a été réaliséepar Neha Narkhede, la CTO de Confluent, qui retrace une partie de l’évolution du service Confluent Cloud. Sont ensuite venues les conférences qui sont toutes de quarante minutes et se répartissent autour des thèmes suivants : Core Kafka, Event-Driven, Stream Processing et Use Case.

Event Streaming: Our Cloud-Native Journey Lessons – Neha Narkhede

La mission des contributeurs à Apache Kafka est de tracer les grandes lignes du paradigme Event Streaming. L’idée est de couvrir à la fois l’intégration de données (ETL) et d’assurer le rôle de messaging system. Après avoir expérimenté ces idées combinées aux tendances Cloud, la CTO de Confluent nous livre quelques conclusions :

• Les schémas de vos différents flux sont les annuaires de service des applications Event Streaming. C’est pourquoi un Schema Registry centralisé sera proposé. Avec de nouvelles fonctionnalités de discovery, versionning et enforcement pour un fonctionnement hybride et multi cloud ;
• Pour monitorer vos jobs de Stream processing, rien de mieux, qu’une application de Stream Processing. Une observation qui a donné naissance au KSQL Processing log ;
• L’élasticité est un incontournable du Cloud et Confluent Cloud annonce aujourd’hui être capable de faire passer vos traitements de 0 à 100 Mbps en quelques secondes ;
• La vie, c’est mieux quand on n’a pas à se soucier de la taille de son cluster. Confluent Cloud propose donc de séparer le prix et la taille avec un nouveau pricing sur la consommation, qualifié de pay as you stream.

Toutes ces annonces viennent de l’expérience acquise en tant que premier fournisseur de la Stream Data Platform as a service. Mais le reste de la communauté a également joué son rôle. C’est pourquoi ce summit a aussi été l’occasion d’annoncer l’ouverture du programme catalyst qui récompense les contributeurs Kafka à différents niveaux.

Experiences Operating Apache Kafka at Scale – Noa Resare

Pour cette présentation, Noa Resare aborde les challenges posés par l’administration d’un cluster Kafka à très grande échelle. Il est ingénieur logiciel à Apple et tire de son expérience quelques points de douleurs sur le management d’une stream data plateform dans une très grande entreprise: les rolling restarts, l’équilibre entre les racks et les pertes de disques.

Lors des rolling restarts pour un cluster avec un très grand nombre de partitions et un débit conséquent, l’équipe observe l’apparition de partitions sous répliquées. Force est de constater que le server controller a une charge de travail trop importante pour se rendre compte qu’un des leaders est en état de restart, l’équipe augmente le temps minimal de restart pour résoudre le problème.

Pour assurer une tolérance aux pannes, Kafka propose une configuration boker.rack. Mais cette propriété n’est pas infaillible et il faut être prêt à rebalancer les partitions dans le cas d’une erreur humaine sur la distribution des racks. Noa Resare nous livre alors une anecdote dans laquelle numéro de baie et numéro de serveur sont confondus, ce qui donne lieu à une pagaille sans nom.

Everything You Always Wanted to Know About Kafka’s Rebalance Protocol but Were Afraid to Ask – Matthias J. Sax

Matthias, ingénieur logiciel à Confluent, a réalisé à mon sens la meilleure conférence du summit en décrivant le rebalance protocol. Décrivons ce principe. Avec Kafka, le parallélisme est assuré par le nombre de partitions. Les membres d’un groupe de consommation se voient attribuer les différentes partitions d’un topic et si un crash arrive à l’un d’entre eux alors les partitions sont redistribuées. On dit qu’il y a rebalance. Mais ce rebalance est aujourd’hui régit par deux contraintes principales qui nous sont expliquées dans cette présentation : le Group Membership & les Resources Assignment.

Group Membership : en phase de rebalance, un jeu de requêtes / réponses a lieu pour faire le point sur les clients encore actifs. Le problème est que tous les membres sont concernés et peuvent se voir attribuer des partitions différentes après un rebalance sans vraie raison. Pour palier à cela, l’identifiant group.instance.id permettra bientôt d’identifier les différents membres des groupes de consommation, c’est l’idée du static membership qui est en cours de développement.

Resources Assignment : Une fois que l’appartenance à un groupe de consommation est de nouveau confirmée, les partitions doivent être réattribuées. Cette tâche est en partie réalisée par le consumer group leader qui est lui-même élu par le broker qui assume le rôle de group coordinator. En attendant que tout ce beau monde se mette d’accord… nous subissons un downtime ^^. C’est pour cela que l’idée d’un rebalance incrémentale sera bientôt adoptée.

Les propositions d’implémentation vous amèneront bien plus en profondeur sur ce sujet: [KIP-345], [KIP-415], [KIP-429], [KIP-441]

Mardi

Show Me Kafka Tools That Will Increase My Productivity! – Stéphane Maarek

Tout est dans le titre! Les outils de base de Kafka sont très peu instinctifs et leur utilisation demande beaucoup d’efforts de mémorisation. C’est pourquoi on peut facilement compter plus d’une cinquantaine d’outils développés par des tiers. Ce talk fait donc le tour des outils les plus intéressants selon Stéphane en partant des outils ligne de commande jusqu’aux interfaces d’administration.

Parmi les CLI, c’est Kafkacat qui attirera le plus notre attention, avec des petits plus comme :

• L’indication des broker id et leur DNS;
• Précision du dernier offset consommé;
• Possibilité de limiter les messages à consommer

Pour les outils d’administration, on notera principalement kafka-utils, kafka-tool, cruise-control. Burrow et Remora vous aideront dans le suivi de vos différents consommateurs. Grâce à kafka-security-manager vous pourrez gérer les ACL de votre cluster.

Même après cette liste impressionnante, il reste un angle mort dans l’outillage autour de Kafka. En effet, aucune application desktop ne permet de faire tout ce qui a été indiqué précédemment. C’était donc l’occasion parfaite de présenter Conduktor, un client desktop pour Apache Kafka. Un simple exécutable qui permet de visualiser son cluster, ses brokers et les topics. De simples consommateurs et producteurs peuvent aussi y être créés.

Conduktor est disponible en alpha sur https://www.conduktor.io/. Je vous invite donc vivement à l’essayer! Téléchargez ici et faites vos retours à l’équipe de Datacumulus qui développe cet outil qui révolutionnera certainement le cadre de développement des Kafka Lovers.

Performance Analysis and Optimizations for Kafka Streams Applications – Guozhang Wang

Guozhang Wang, Lead Engineer à Confluent et un des créateurs de Kafka Streams, évoque les optimisations liées à la génération de topologie de stream. La topologie d’une application Kafka Streams correspond à l’enchaînement des processing steps par lesquels passent les événements des flux. Cette topologie peut être construite manuellement via la Processor API, mais est plus souvent générée avec le Stream DSL. Lors de cette génération, aucun plan logique n’était établi entre le parsing et la compilation de la topologie.

Depuis la version 2.1, la mise en place d’un plan logique permet de pallier à quelques problèmes d’optimisation :

• La création de topics de répartitions en doublon;
• La conservation de champs inutiles dans les agrégats;
• Matérialisations inutiles d’états internes

Ces optimisations peuvent maintenant être activées via la StreamingConfig : topology.optimization. Mais la roadmap est encore longue. Les questions de compatibilité au fil des versions et le nombre d’optimisations possibles sont à l’ordre du jour. Vous retrouverez ces points sur les pages suivantes : [KIP-372], [KIP-307] et [KAFKA-6034] .

Un article du même auteur vous permettra d’aller plus loin sur le sujet.

Deep Dive Into Kafka Streams (and the Distributed Stream Processing Engine) – Jacek Laskowski

Jacek Laskowski nous offre une fois de plus un Deep Dive sur un moteur d’exécution. Mais cette fois-ci, il sort de sa zone de confort et laisse Spark de côté pour donner son premier talk sur Kafka Streams.

Les topologies créées par les utilisateurs sont utilisées par un certain nombre de stream threads (par défaut 1 par instance). Dans cette StreamThread vie un TaskManager en charge de StreamTasks actives. Les tâches actives dépendent du nombre de partitions des input topics. En plus de cela, il faut compter deux instances de KafkaConsumer et une instance KafkaProducer utilisées en interne par Kafka Streams (ces nombres peuvent varier avec l’utilisation des StanbyReplicas et de l’exactly once semantics).

Les consumers, suite à chaque poll de messages Kafka remplissent des priority queues type first-in/first-out appellées RecordQueue. Une fois dans cette queue, les messages sont récupérés un à un, par les StreamsTask, pour être passés au travers de la topologie créée par l’utilisateur. Il vont alors de processeur en processeur.

Voilà, c’est une petite partie de l’exécution de vos applications Kafka Streams.

Fermeture

Entre deep dives, retours d’expérience et conseils pratiques, la conférence a tout pour inspirer l’assistance. Les connaisseurs trouvent de nouvelles choses à essayer / investiguer et les nouveaux entrants sur ces technos n’ont plus d’excuses pour ne pas s’y mettre sérieusement.

Toutes aussi excellentes, voici le reste des présentations auxquelles j’ai assisté et que je vous encourage à aller voir :

• Growing a Great Engineering Culture with Apache Kafka, by Keith Davidson
• Is Kafka a Database?, by Martin Kleppmann
• hello-streams :: Introducing the Stream First Mindset, by Rene Parra
• Using Machine Learning to Understand Kafka Runtime Behavior, by Shivnath Babu, and Nate Snapp
• Using Location Data to Showcase Keys, Windows, and Joins in Kafka Streams DSL and KSQL, by Neil Buesing
• Industry-ready NLP Service Framework Based on Kafka, by Bernhard Waltl and Georg Bonczek
• One Key to Rule them All, by Richard Noble, and Francesco Nobilia
• Modern Cloud-Native Streaming Platforms: Event Streaming Microservices with Kafka on Kubernetes, by Kamala Dasika and Michael Ng
• The Awakening of the New Event-Driven (Beast), by Viktor Gamov
• When to KSQL & When to Live the KStream, by Dani Traphagen
• Apache Kafka vs. Integration Middleware (MQ, ETL, ESB) – Friends, Enemies or Frenemies?, by Kai Waehner

Vous retrouverez les présentations sur confluent.io

Notez bien que sur ce super panel de speakers, trois d’entre eux seront présents au DataXDay’2019! Kai, Jacek et Stéphane seront parmi nous le 27 Juin et donneront chacun un autre talk. Rien que pour vous la DataXTeam dresse une scène de niveau international à Paris !

Enfin je vous laisse sur une petite sélection des tweets / photos de l’évènement.

Arrivé au #kafkasummit pic.twitter.com/mhtl2wk0oO

— LoïcMDivad (@LoicMDivad) May 13, 2019

Getting ready to give a keynote at #KafkaSummit London. Big room for over 1,000 attendees! pic.twitter.com/UojFS5e9bV

— Dr Martin Kleppmann (@martinkl) May 13, 2019