Et si l’on pouvait reconstruire Kafka depuis zéro ?

• Les discussions autour d’un Kafka optimisé pour le cloud s’intensifient avec le KIP-1150 (Kafka sans disque) et le projet de fork Kafka d’AutoMQ
• Si l’on reconstruisait Kafka, la proposition serait de supprimer la structure en partitions existante et d’adopter une approche centrée sur les clés
• Il devient nécessaire d’ajouter des fonctions de contrôle de concurrence et de prise en charge des schémas côté broker
• Le besoin d’intégrer des caractéristiques de systèmes modernes comme la scalabilité, les snapshots et le multi-tenant est également mis en avant
• Une réflexion, à partir de Kafka, sur un véritable système de journal d’événements cloud native dépassant les limites du Kafka actuel

---

Et si l’on reconstruisait Kafka ?

• Le KIP-1150 (Kafka sans disque) et le fork Kafka d’AutoMQ ont récemment été annoncés, avec pour objectif d’intégrer Kafka à un stockage objet comme S3 afin d’améliorer l’élasticité en environnement cloud et de réduire les coûts
• L’auteur imagine un système de journal d’événements cloud native allant au-delà des limites du Kafka existant et propose plusieurs pistes d’amélioration

Proposition d’une architecture sans partitions

• Comme le stockage objet dans le cloud se comporte comme un stockage quasi illimité, la nécessité des partitions de topic diminue
• Dans de nombreux cas, seul l’ordre global des messages ou l’ordre des messages partageant la même clé importe
• Il serait possible de masquer le concept de partition aux utilisateurs et d’offrir une expérience plus simple

Approche centrée sur les clés

• La proposition est de concevoir le système non pas pour scanner des partitions, mais pour accéder rapidement à tous les messages d’une clé donnée et les rejouer
• Cela permettrait de prendre en charge des flux au niveau de millions d’entités et d’ajuster dynamiquement le nombre de consommateurs selon la demande
• Les défaillances étant isolées au niveau de la clé, l’efficacité globale du traitement du système s’en trouverait améliorée
• Ce serait une architecture idéale pour l’event sourcing ou les systèmes basés sur le modèle acteur

Prise en charge d’une hiérarchie de topics

• Comme dans des systèmes tels que Solace, il faudrait promouvoir une partie de la payload du message en identifiant de topic structuré sous forme de chemin, afin de permettre des abonnements basés sur des motifs
• Le broker pourrait ainsi prendre en charge efficacement le filtrage des abonnements sans devoir parser le message complet

Fonction de contrôle de concurrence

• Kafka ne propose actuellement aucun moyen d’empêcher les conflits de concurrence à l’écriture
• Avec un verrouillage optimiste (optimistic locking) par clé, il serait possible de vérifier qu’un message a bien été écrit après lecture de l’état le plus récent
• Cela permettrait d’éviter les problèmes de perte de mise à jour

Prise en charge des schémas côté broker

• Aujourd’hui, Kafka traite les messages comme de simples tableaux d’octets et dépend d’un registre de schémas externe
• Pour garantir la cohérence des schémas, il est proposé d’intégrer nativement au niveau du broker des informations de schéma comme les métadonnées AsyncAPI
• Cela faciliterait aussi l’intégration avec des formats de table open source comme Apache Iceberg

Scalabilité et architecture à plugins

• Une architecture offrant scalabilité et extensibilité par plugins, à l’image de Postgres ou Kubernetes, est proposée
• Il devrait être possible d’implémenter facilement des filtres ou des transformations au niveau du broker, sans proxy conscient du protocole (comme Kroxylicious)
• Des fonctions comme la limitation de débit, le chiffrement des topics ou un backend fondé sur des tables Iceberg devraient pouvoir être implémentées sous forme de plugins

Callbacks de commit synchrones

• Kafka ne garantit actuellement qu’une cohérence éventuelle
• La proposition souligne le besoin d’une architecture dans laquelle un producteur, après avoir envoyé un message, peut vérifier immédiatement si les données dérivées correspondantes ont été mises à jour
• En prenant en charge la garantie de lecture de ses propres écritures (read-your-own-writes), Kafka pourrait être utilisé comme un véritable journal de base de données

Fonction de snapshot

• La compaction actuelle de Kafka ne conserve que le dernier message, ce qui n’est pertinent que si celui-ci contient l’état complet
• Si seuls les changements sont enregistrés, il faut rejouer tous les événements par clé, ce qui allonge le temps de traitement
• Il faudrait une fonction de compaction logique capable de résumer les événements en snapshots au niveau de la clé

Prise en charge native du multi-tenant

• Tous les systèmes de données modernes devraient intégrer le multi-tenant dès leur conception
• Il faut pouvoir créer de nouveaux environnements de tenant à coût réduit et instantanément, tout en séparant strictement ressources, sécurité et contrôle d’accès

Autres remarques

• Certaines fonctions sont déjà présentes dans des systèmes comme S2 (flux à haute cardinalité), Waltz (verrouillage optimiste) ou Apache Pulsar (multi-tenant)
• En revanche, aucun système open source ne prend actuellement en charge l’ensemble des fonctions proposées simultanément
• Cet article reflète l’opinion personnelle de son auteur, employé chez Confluent, et ne constitue pas une position officielle
• Il est également indiqué que, sur le plan théorique, une architecture basée sur un arbre LSM serait probablement un choix solide

[kaydash]

On appelle déjà ça Redis.

[GN⁺]

Avis Hacker News

• D'accord. Pour certains cas d'usage, cela vaut la peine de résoudre le problème de blocage en tête de file

  • Mais aujourd'hui, tous les systèmes de streaming (ou leurs contournements) engendrent un coût en O(n^2) pour les acquittements par clé de message
  • Des systèmes comme Pulsar sont souvent utilisés pour cette fonctionnalité
  • Cette complexité ne se manifeste peut-être pas tous les jours, mais lorsqu'elle apparaît, il faut attendre
  • Après avoir étudié ce problème pendant longtemps avec des collègues, nous sommes arrivés à la conclusion qu'un changement architectural fondamental est nécessaire pour prendre en charge des acquittements évolutifs par clé de message
  • L'architecture nécessite un index trié, ce qui signifie traiter n messages en O(n log n)
  • Je voulais écrire un billet de blog sur ce sujet, mais je n'en ai pas eu le temps
  • Si vous comptez dépendre des acquittements par clé de message, il faut s'attendre à des interruptions ou des ralentissements intermittents

• NATS.io est plus facile à utiliser que Kafka et a déjà résolu plusieurs points, comme la suppression des partitions, la prise en charge de flux basés sur des clés et une hiérarchie de sujets flexible

• Mon parcours avec Kafka est globalement similaire

  • Au début, je me suis dit : "Oh, un journal append-only évolutif, génial et simple"
  • Mais en l'utilisant, on se rend compte que c'est extrêmement complexe

• Dans certains cas d'usage, il serait utile de pouvoir garantir que les vues de données dérivées ont été mises à jour au moment où la requête de création est acquittée

  • Il ne faut pas utiliser Kafka, mais écrire directement dans le stockage de données sous-jacent
  • On sait alors que les données ont bien été validées et on dispose d'une base de données interrogeable

• J'ai posé cette question il y a 6 ans

  • Et si on l'écrivait en Rust et qu'on exploitait WASM ?
  • J'y travaille depuis 6 ans
  • Depuis 2 ans, je construis Flink avec Rust et WASM

• Un stockage objet pour Kafka ? Cela multiplierait la latence et le coût par 10

  • Kafka est victime de son succès
  • Son design est simple et élégant, si bien qu'il est utilisé pour toutes sortes d'usages pour lesquels il n'avait pas été conçu à l'origine
  • Bien sûr, il n'est pas parfait pour ces cas d'usage

• À propos de la "suppression des partitions" et des "flux au niveau des clés"

  • Si le backend de stockage repose sur un partitionnement physique, cela revient simplement à renommer les partitions en clés, et les clés en événements

• Il faut garder un œil sur Northguard

  • C'est le nom de la réécriture de Kafka par LinkedIn, présentée il y a environ une semaine lors d'une rencontre sur le stream processing

• Je me demande quelle part des problèmes d'Apache Kafka serait résolue en passant à Apache Pulsar

  • J'ai sauté l'apprentissage de Kafka et suis passé directement à Pulsar
  • Cela correspond bien à notre cas d'usage
  • Aucune plainte
  • Mais je me demande pourquoi si peu de gens l'utilisent

• Expérience de pensée utile

  • Les réponses qui suggèrent en silence la conclusion selon laquelle Kafka devrait être remplacé par quelque chose de nouveau sont parlantes
  • La plus grande force de Kafka est le vaste écosystème utile construit autour de lui
  • C'est aussi sa faiblesse
  • Il faut conserver certaines décisions de conception qu'on ne prendrait plus aujourd'hui si on repartait de zéro
  • Sinon, il faut abandonner la rétrocompatibilité et reconstruire l'écosystème dont on dispose déjà