La v2.0 est le dernier volet du cursus. Elle ajoute quatre modules - schema-registry, authorization, share-groups et capstones - ainsi que trois scénarios sur les topics diskless dans le module storage, un exercice de DR active-active dans le module dr et le partitionnement sensible au rack dans le module producer, soit 24 nouveaux scénarios au total. Elle débloque les paliers gouvernance et diskless dans le free play, et complète le cursus du Kafka Simulator à 136 sur 136.

C’est aussi la version où le playground autour de ces scénarios a été reconstruit. Depuis la v1.9, presque tout y a changé : le canevas propose trois vues, la frise chronologique est devenue lisible, les inspecteurs répondent à des questions au lieu d’énumérer des champs, et le terminal ne cache plus le canevas.

Ce que contient la v2.0

Schema Registry (schema-registry, 3 scénarios). Les subjects et leurs versions, ce que vérifient les compatibilités backward, forward et full, et un changement cassant rejeté avant même d’être enregistré.

Autorisation (authorization, 2 scénarios). Le contrôle d’accès sur le chemin des données - comment une ACL, ou un role binding RBAC, autorise ou refuse une production quand l’autorisateur refuse par défaut.

Les deux arrivent dans le free play avec le nouveau palier gouvernance : Schema Registry, commandes ACL et RBAC, et kafka-acls dans le terminal, pour reconstruire et casser à la main tout ce que montrent les scénarios.

Share groups (share-groups, 9 scénarios). La sémantique de file d’attente de Kafka, introduite par la KIP-932 :

Les share groups changent la façon dont Kafka est consommé, et les voir à côté des groupes de consommateurs classiques montre ce qui diffère.

Capstones (capstones, 5 scénarios). Des scénarios de bout en bout qui combinent durabilité, transactions, stockage, multi-DC et gouvernance, avec plusieurs choses qui se passent en même temps : un pipeline de paiements exactly-once qui survit à la perte d’une région, un failover régional sans perte de données, une migration sans interruption avec Cluster Linking, une dorsale multi-DC actif/actif, et un pipeline réglé à la fois pour le débit et pour la latence.

Reprise après sinistre (dr, 1 scénario de plus). Un exercice de DR active-active : on perd la région west, on bascule son producteur et son groupe de consommateurs vers east et on continue d’écrire, puis on redémarre west et on les ramène. Rien n’est promu, et les enregistrements que west n’a jamais répliqués sont le prix à payer.

Producteur (producer, 1 scénario de plus). Le partitionnement sensible au rack, nouveau dans Kafka 4.4 : un producteur garde ses enregistrements sans clé dans sa propre zone de disponibilité, jusqu’à ce que cette zone perde ses leaders. Plus de détails ci-dessous, dans Apache Kafka 4.4.

Topics diskless (orientation KIP-1150, brouillon KIP-1163/1164)

Un topic diskless conserve les données de ses partitions dans le stockage objet plutôt que sur les disques des brokers. Un broker met en tampon les enregistrements de nombreuses partitions et les envoie sous forme d’un seul objet WAL ; un coordinateur diskless attribue les offsets lorsqu’il valide cet objet, et la production est acquittée à cette validation. Les réplicas construisent leur log en relisant l’objet depuis le stockage plutôt qu’en le récupérant auprès du leader, et producteurs comme consommateurs utilisent un réplica de leur propre zone de disponibilité.

L’état des lieux : la KIP-1150 est acceptée comme orientation, tandis que la KIP-1163 et la KIP-1164, qui définissent son fonctionnement, sont toujours Under Discussion (KAFKA-19161 suit l’implémentation). Nous modélisons le brouillon actuel et l’indiquons « KIP draft » partout dans le simulateur. Les noms et le comportement peuvent changer avant que quoi que ce soit n’arrive dans Kafka.

Trois scénarios (storage, 05.4.1-05.4.3) :

  • Diskless : le chemin d’écriture - deux producteurs et deux partitions partagent un même objet WAL, aucun offset n’existe tant que le coordinateur ne l’a pas validé, et les réplicas relisent les données depuis le stockage objet.
  • Pas de réplication entre AZ - les 3 mêmes enregistrements vont vers un topic classique et vers un topic diskless répartis sur trois AZ ; la carte Cross-AZ traffic termine à 7 sauts pour le classique et 0 pour le diskless.
  • Le prix, c’est la latence - la même production acks=all est acquittée en 300 ms sur un topic classique et en 1300 ms sur un topic diskless, tandis qu’une rafale qui remplit le tampon est acquittée en 800 ms. Les durées sont agrandies pour que chaque étape soit visible.

Dans le free play : un preset Diskless 3 AZ, un interrupteur diskless par topic et des curseurs pour les durées diskless. Le canevas gagne une voie de stockage objet sur son propre axe temporel, des bacs WAL sous chaque broker et un badge de coordinateur, et le panneau de métriques une carte Cross-AZ traffic. Dans le terminal, kafka-topics --create --config diskless.enable=true crée un topic diskless et kafka-diskless-metadata (lui-même un outil du brouillon, absent d’Apache Kafka pour l’instant) affiche les offsets par partition et liste les objets WAL présents dans le stockage.

Le compromis en bref : moins de trafic de réplication entre AZ, des productions plus lentes - le brouillon vise une latence de production d’environ 500 ms au P50 et de 1 à 2 s au P99. Kafka classique sait déjà lire depuis un follower de la même AZ (KIP-392) ; ce que le diskless apporte, c’est l’absence de réplication de broker à broker et une production qui n’a pas besoin d’atteindre le leader.

Apache Kafka 4.4

Le modèle suit désormais Apache Kafka 4.4, sorti cette semaine. Nous avons comparé 4.3.0 et 4.4.0 sans trouver de valeur par défaut, de sortie de la CLI ni de message d’erreur sur lesquels s’appuie le simulateur qui aient changé : tout se comporte comme avant dans les scénarios.

La v2.0 modélise une nouveauté de la 4.4 : le partitionnement sensible au rack côté producteur (KIP-1123). Avec partitioner.rack.aware=true et un client.rack, le partitionneur par défaut envoie les enregistrements sans clé vers les partitions dont le leader se trouve dans la zone de disponibilité du producteur, et vers n’importe quelle partition quand cette zone n’a pas de leader, ce qui garde le trafic de production dans la zone. Le nouveau scénario Partitionnement sensible au rack montre les deux cas. En free play, l’inspecteur du producteur a l’interrupteur, et les producteurs de départ d’un sandbox peuvent choisir leur client.rack. Sans client.rack, le producteur refuse ce réglage, comme Kafka.

Les files de lettres mortes des share groups (KIP-1191), une autre nouveauté de la 4.4, ne sont pas encore modélisées.

Un playground reconstruit

Trois façons de voir un cluster

Le canevas propose désormais trois vues, à choisir depuis sa barre d’outils :

  • Brokers est l’image familière : les producteurs à gauche, le cluster au milieu, les groupes de consommateurs et les share groups à droite.
  • Lanes trace une ligne par partition sur un axe d’offsets commun : les réplicas les uns sous les autres, le leader en premier, le high watermark comme une seule ligne qui les traverse tous. Un follower en retard a un log visiblement plus court, le log d’un broker arrêté reste figé, et chaque consommateur se tient à sa position de lecture avec son offset validé et son lag. Vous voyez d’un coup d’œil où chacun en est dans le log.
  • Matrix sert aux clusters trop grands pour être dessinés : un tableau avec les topics en lignes et les brokers en colonnes, et quatre filtres - Failures, Balance, Lag et Traffic - qui le colorent et le trient du pire au meilleur. Survoler un broker montre ce que le cluster perdrait, topic par topic, avant que vous ne l’arrêtiez. Un grand cluster en free play s’ouvre de lui-même en Matrix.

Le canevas montre ce qui a changé

Les changements d’état se jouent désormais sur l’élément qui a changé plutôt que par une pulsation générique : les marqueurs de high watermark glissent jusqu’à leur nouvel offset, la couronne du leader passe de l’ancien leader au nouveau, et l’étiquette ISR d’un follower prend la couleur du changement. Un enregistrement produit atterrit dans sa propre cellule du log, un canevas chargé dessine les enregistrements comme de courtes traînées, et un broker arrêté reste sur le canevas, estompé, pour que vous voyiez ce qui s’y trouvait. Sur les canevas multi-régions, le lien miroir affiche son RPO, chaque bande de DC indique ce que coûterait sa perte, une partition réseau montre quel côté continue de servir, la bande KRaft compte sa majorité, et la voie d’un share group affiche le minuteur de verrou et le nombre de livraisons de chaque enregistrement.

Une frise chronologique lisible

Sur desktop, le dock du bas est désormais un rail d’une seule ligne : les images y sont placées à leur vrai temps de simulation, si bien qu’une rafale se lit comme un amas et une période calme comme un vide, et vous naviguez en glissant le long du rail. Ouvrez ses voies d’événements et chaque événement de l’exécution est disposé sur les voies produce, replicate, brokers et consume, les pannes en rouge, avec l’événement principal de chaque image mis en évidence.

Des inspecteurs qui répondent à des questions

Le panneau de droite part désormais des questions que vous vous posez. Une partition se lit comme une règle graduée de ses offsets, un broker comme ce que vous perdez quand il s’arrête, un topic comme une voie par partition, un producteur comme son chemin d’envoi, et un groupe de consommateurs comme des voies ou une grille de partitions. Why liste ce qui a cassé et pourquoi, les Metrics sont regroupées par rôle, et certains inspecteurs montrent ce qui va se passer ensuite, pas seulement l’état courant. Les vues multi-régions gagnent une carte DR qui affiche le log de chaque région et la fin non mise en miroir sous forme de RPO.

Le canevas fait de la place au terminal

Le terminal CLI Kafka reste ancré sous le canevas, mais le canevas lui fait désormais de la place au lieu de disparaître derrière lui - si bien que kafka-server-stop et la chute de broker-1 sont à l’écran en même temps, et que le terminal dispose de toute la largeur du canevas pour ce que vous tapez et ce qu’affichent les outils. Sur un écran large, dock side dans sa barre de titre le place plutôt dans une colonne à côté du canevas. La sortie conserve ses colonnes, et le menu des hôtes est un tableau ssh de chaque broker et contrôleur. Les fichiers de configuration des brokers correspondent à Kafka 4.4, et kafka-reassign-partitions --generate ainsi que le drainage d’un broker avant son retrait fonctionnent comme sur un vrai cluster.

Prise en main, sans visite guidée

La visite guidée modale en 13 étapes a disparu. À sa place, une carte Getting started dans un coin du canevas : les mêmes sujets sous forme de liste à cocher, à parcourir dans l’ordre de votre choix, chacun avec un « Show me ». L’aide est désormais une référence où l’on cherche ce dont on a besoin, un scénario scripté peut être dupliqué en bac à sable avec Undo, les scénarios suggèrent leurs propres manipulations « Try it yourself » et la suite à donner, et un lien partagé rejoue désormais le chemin qui l’a mené à l’état qu’il affiche.

Un nouveau look, et une passe sur l’accessibilité

Tout le site, playground compris, adopte un nouveau look inspiré du choucas de notre nom : encre sombre, reflet bleu et gris, avec chaque paire de couleurs de texte au niveau WCAG AA. Avec lui sont arrivés des liens d’évitement et des régions nommées, un rail de scénarios accessible en une seule tabulation, un contraste AA pour les régions inactives, un retour visuel à l’appui, des cibles tactiles plus grandes, et des animations qui respectent prefers-reduced-motion en gardant les fondus et en supprimant les déplacements. La mise en page mobile a eu sa propre passe, jusqu’à un test qui vérifie que chaque libellé tient encore.

En dehors du playground

Le playground lui-même n’est pas indexable, les moteurs de recherche n’ont donc jamais vu le texte de ses scénarios. Désormais, chaque scénario a sa propre page sous /kafka-simulator/scenarios/ : son introduction et sa conclusion, chaque étape avec un lien « Open at this step », une vraie image du canevas que vous pouvez parcourir pas à pas, et les configurations Kafka qu’il touche. Avec la v2.0, cela fait 136 pages.

À côté se trouvent des pages de dépannage pour les erreurs et symptômes Kafka - ce que signifie le problème, les causes probables, les correctifs et ce qu’il ne faut pas faire, si le client réessaie de lui-même - chacune liée aux scénarios où le problème survient, ouverts à l’instant où il se produit. La page sur l’autorisation les rejoint avec cette version. Le changelog se lit désormais comme des notes de version sur une frise chronologique.

Encore une chose

Nous avons caché quelque chose dans cette version. À vous de le trouver.

La fin de la feuille de route

La v2.0 achève ce qui a commencé avec la v1.0 : onze volets toutes les deux semaines, 136 scénarios, de l’anatomie d’un broker unique jusqu’aux files d’attente et aux capstones couvrant toute la plateforme. Tout tourne dans le navigateur, de manière déterministe, selon la sémantique d’Apache Kafka 4.4, sans backend et sans aucune télémétrie sur vos scénarios.

Le cursus est complet, mais le simulateur est un bac à sable, pas un cours que l’on termine. Ouvrez le simulateur, construisez quelque chose, et cassez-le.