Kafka, une plateforme de data streaming
Aujourd'hui, pour définir ce qu'est Kafka, on utilise souvent le terme de “plateforme de data streaming” qui décrit probablement le mieux ce que fait Kafka : proposer une plateforme permettant de stocker et mettre à disposition des messages dans des “compartiments logiques” appelés topics (chaque topic contenant une donnée différente) et présentant les caractéristiques suivantes :
- Disponibilité et durabilité grâce à la réplication
- Scalabilité grâce au partitionnement
- Ordre des messages garanti, au sein d'une même partition
Ce qui caractérise Kafka, par rapport à d'autres brokers de messages, c'est principalement cette notion d'ordre. Pour une partition donnée, et un producteur donné, les messages sont écrits et stockés dans l'ordre. Pour un partition donnée, et un consumer donné, les messages sont consommés dans l'ordre. L'ordre est ainsi conservé de bout en bout.
Pour quels usages Kafka n'est-il pas adapté ?
Dans certaines architectures orientées data streaming, lorsque l'on a un usage de message queuing, et parce que l'on ne souhaite pas introduire d'autre broker de messages, il n'est pas rare de voir Kafka utilisé comme une solution de message queuing. On peut alors se poser les questions suivantes :
- Mais en quoi le message queuing diffère-t-il du data streaming ? 🤔
- En quoi est-ce un problème d'utiliser Kafka comme une solution de message queuing ?
Le message queuing consiste simplement à mettre des messages dans une file d'attente, avant qu'elles soient traitées par un processus. Dans le cas du message queuing, on ne se soucie pas du fait que les messages respectent un ordre quelconque, on souhaite simplement découpler un producteur de messages de son/ses consommateur(s) de manière à ce que les producteurs produisent à leur rythme, les consommateurs consomment à leur rythme, et avoir une certaine garantie de delivery :
- Tant qu'un message n'a pas été livré, il est disponible
- Les messages sont indépendants, le fait qu'un message ne soit pas livrable n'affecte pas la capacité des autres messages à être livrés
Pour faire du message queuing, Kafka est particulièrement mal adapté du fait de son fonctionnement intrinsèque. En effet, étant donné que dans un topic Kafka, l'ordre est important, le modèle de consommation des messages utilise un simple offset, similaire à une tête de lecture. Il s'agit en fait de l'index du dernier message qui a été effectivement traité par un consommateur.
De ce fait, lorsqu'un consommateur tombe sur un message qu'il ne peut pas traiter, pour une raison quelconque, il est malgré tout obligé de faire un choix entre :
- Avancer l'offset au message suivant. Dans ce cas, le message en erreur ne sera jamais traité à nouveau (à moins d'implémenter une dead letter queue, mais ce n'est pas un mécanisme natif à Kafka)
- Ne pas avancer l'offset. Dans ce cas, le message en erreur fera l'objet d'un rejeu jusqu'à ce que le traitement réussisse. Le risque étant que le traitement ne réussisse jamais et bloque par conséquent la consommation des messages suivants indéfiniment. C'est la fameuse poison pill.
On voit donc que la contrainte du message queuing qui concerne l'indépendance des messages est très difficile à respecter avec Kafka, car dans un topic Kafka (une partition pour être plus exact), les messages forment une chaîne et l'état d'un consommateur est matérialisé par une position (un offset) dans cette chaîne.
Ce que la KIP-932 va changer
Dans la gouvernance du projet Apache Kafka, le terme KIP désigne les “Kafka improvement proposal”. Il s'agit de propositions de spécifications de nouvelles fonctionnalités (généralement accompagnées d'une ébauche de conception).
La KIP-932 propose un nouveau mode de consommation des messages dans un topic Kafka: les share groups.
Les share groups diffèrent des consumer groups sur plusieurs aspects :
- Dans le cas d'un consumer group, un consumer est le seul à consommer le contenu de la/les partition(s) qui lui est/sont assignée(s). Dans le cas d'un share group, le contenu d'une partition peut être fourni à plusieurs consumers différents, permettant par la même occasion de pouvoir scale les consumers d'un share group indépendamment du nombre de partitions d'un topic (dans le cas des consumer groups, le nombre de consumers “utiles” est limité par le nombre de partitions)
- Pour un share group, les messages sont acquittés de manière individuelle, et le nombre d'essais de livraison est compté pour chacun d'entre eux, de manière à pouvoir rejouer les messages en erreur tout en limitant le nombre d'essais.
Ce nouveau modèle de consommation des messages Kafka s'accompagne d'un changement fondamental dans la matérialisation de l'état d'un share group (par rapport au consumer group). En effet, étant donné que les messages et leur état de livraison devient géré “par message”, l'offset ne suffit plus, et chaque message porte alors son propre état parmi les quatre états suivants :
- Available : disponible à la consommation
- Acquired : verrouillé par un consommateur, mais pas encore traité (le verrou est libéré quoi qu'il arrive lorsqu'il dépasse une certaine durée)
- Acknowledged : traité et acquitté par un consommateur
- Archived : non disponible à la consommation
Cette KIP est au statut accepted, ce qui veut dire qu'elle verra probablement le jour dans une prochaine version de Kafka. Elle est à surveiller de très près car elle devrait élargir les usages possibles de Kafka, pour notre plus grand bonheur 😊.