La v2.0 è l’ultimo pacchetto del programma. Aggiunge quattro moduli - schema-registry, authorization, share-groups e capstones - più tre scenari sui topic diskless nel modulo storage, un’esercitazione di DR active-active nel modulo dr e il partizionamento consapevole del rack nel modulo producer, per un totale di 24 nuovi scenari. Sblocca i livelli governance e diskless nel free play e completa il programma del Kafka Simulator a 136 su 136.

È anche la release in cui il playground attorno a quegli scenari è stato ricostruito. Dalla v1.9 ne è cambiata quasi ogni parte: il canvas ha tre viste, la timeline è diventata qualcosa che si può leggere, gli inspector rispondono a domande invece di elencare campi e il terminale non copre più il canvas.

Cosa c’è nella v2.0

Schema Registry (schema-registry, 3 scenari). Subject e versioni, cosa verificano la compatibilità backward, forward e full e una modifica incompatibile respinta prima di essere registrata.

Autorizzazione (authorization, 2 scenari). Il controllo degli accessi sul percorso dei dati - come un’ACL, o un role binding RBAC, consente o nega una produce quando l’authorizer nega per impostazione predefinita.

Entrambi arrivano nel free play con il nuovo livello governance: schema registry, controlli ACL e RBAC e kafka-acls nel terminale, così puoi ricostruire e rompere a mano qualsiasi cosa mostrino gli scenari.

Share group (share-groups, 9 scenari). La semantica a coda di Kafka, introdotta con la KIP-932:

Gli share group cambiano il modo in cui si consuma da Kafka, e vederli accanto ai classici consumer group mostra cosa c’è di diverso.

Capstone (capstones, 5 scenari). Scenari end-to-end che combinano durabilità, transazioni, storage, multi-DC e governance, con più cose che succedono contemporaneamente: una pipeline di pagamenti exactly-once che sopravvive alla perdita di una regione, un failover regionale senza perdita di dati, una migrazione senza downtime con Cluster Linking, un backbone attivo/attivo multi-DC e una pipeline ottimizzata insieme per throughput e latenza.

Disaster recovery (dr, 1 scenario in più). Un’esercitazione di DR active-active: si perde la regione west, il suo producer e il suo consumer group passano a east e continuano a scrivere, poi west riparte e tornano indietro. Non viene promosso nulla, e i record che west non ha mai replicato sono il prezzo.

Producer (producer, 1 scenario in più). Il partizionamento consapevole del rack, novità di Kafka 4.4: un producer tiene i record senza chiave nella propria zona di disponibilità, finché quella zona non perde i suoi leader. Più dettagli qui sotto, in Apache Kafka 4.4.

Topic diskless (direzione KIP-1150, bozza KIP-1163/1164)

Un topic diskless tiene i dati delle sue partizioni nell’object storage invece che sui dischi dei broker. Un broker accumula in un buffer i record di molte partizioni e li carica come un unico oggetto WAL; un coordinator diskless assegna gli offset quando committa quell’oggetto, e la produce riceve l’ack al momento del commit. Le repliche costruiscono il proprio log rileggendo l’oggetto dallo storage invece di fare fetch dal leader, e producer e consumer usano una replica nella propria availability zone.

Lo stato attuale: la KIP-1150 è accettata come direzione, mentre la KIP-1163 e la KIP-1164, che definiscono come funziona, sono ancora Under Discussion (KAFKA-19161 traccia l’implementazione). Modelliamo la bozza attuale e la segnaliamo come «KIP draft» in tutto il simulatore. Nomi e comportamento potrebbero cambiare prima che qualcosa di tutto questo arrivi in Kafka.

Tre scenari (storage, 05.4.1-05.4.3):

  • Diskless: il percorso di scrittura - due producer e due partizioni condividono un unico oggetto WAL, nessun offset esiste finché il coordinator non lo committa, e le repliche rileggono i dati dall’object storage.
  • Nessuna replica tra AZ - gli stessi 3 record vanno a un topic classico e a uno diskless distribuiti su tre AZ; la card Cross-AZ traffic si ferma a 7 hop per il classico e 0 per il diskless.
  • Il prezzo è la latenza - la stessa produce acks=all riceve l’ack in 300 ms su un topic classico e in 1300 ms su uno diskless, mentre un burst che riempie il buffer riceve l’ack in 800 ms. I tempi sono dilatati perché ogni passo sia visibile.

Nel free play: un preset Diskless 3 AZ, un interruttore diskless per ogni topic e slider per le tempistiche diskless. Il canvas guadagna una corsia per l’object storage con un proprio asse temporale, vassoi WAL sotto ogni broker e un badge del coordinator, e il pannello delle metriche una card Cross-AZ traffic. Nel terminale, kafka-topics --create --config diskless.enable=true crea un topic diskless e kafka-diskless-metadata (a sua volta uno strumento in bozza, non ancora presente in Apache Kafka) mostra gli offset per partizione ed elenca gli oggetti WAL nello storage.

Il compromesso in breve: meno traffico di replica tra AZ, produce più lente - la bozza punta a una latenza di produce intorno ai 500 ms al P50 e a 1-2 s al P99. Il Kafka classico può già leggere da un follower nella stessa AZ (KIP-392), quindi ciò che il diskless aggiunge è l’assenza di replica da broker a broker e una produce che non deve raggiungere il leader.

Apache Kafka 4.4

Il modello segue ora Apache Kafka 4.4, uscito questa settimana. Abbiamo confrontato la 4.3.0 con la 4.4.0 e non abbiamo trovato nessun valore predefinito, output della CLI o messaggio di errore su cui si basa il simulatore che sia cambiato, quindi negli scenari tutto si comporta come prima.

La v2.0 modella una novità della 4.4: il partizionamento consapevole del rack nel producer (KIP-1123). Con partitioner.rack.aware=true e un client.rack, il partitioner predefinito invia i record senza chiave alle partizioni il cui leader si trova nella zona di disponibilità del producer, e a qualsiasi partizione quando quella zona non ha un leader, così il traffico di produzione resta nella zona. Il nuovo scenario Partizionamento consapevole del rack mostra entrambi i casi. Nel free play l’inspector del producer ha l’interruttore, e i producer con cui parte una sandbox possono scegliere il proprio client.rack. Senza client.rack il producer rifiuta l’impostazione, come fa Kafka.

Le dead-letter queue dei share group (KIP-1191), un’altra novità della 4.4, non sono ancora modellate.

Un playground ricostruito

Tre modi di vedere un cluster

Il canvas ora ha tre viste, che si cambiano dalla sua barra degli strumenti:

  • Brokers è l’immagine familiare: i producer a sinistra, il cluster al centro, i consumer group e gli share group a destra.
  • Lanes disegna una riga per partizione su un asse degli offset condiviso: le repliche una sotto l’altra, il leader per primo, l’high watermark come un’unica linea che le attraversa tutte. Un follower in ritardo ha un log visibilmente più corto, il log di un broker fermo resta immobile, e ogni consumer sta alla sua posizione di lettura con il suo offset committato e il suo lag. Vedi a colpo d’occhio dove si trova ciascuno nel log.
  • Matrix è per i cluster troppo grandi da disegnare: una tabella con i topic sulle righe e i broker sulle colonne, e quattro lenti - Failures, Balance, Lag e Traffic - che la colorano e la ordinano partendo dal caso peggiore. Passando sopra un broker vedi cosa perderebbe il cluster, topic per topic, prima di fermarlo. Un cluster free-play di grandi dimensioni si apre da solo in Matrix.

Il canvas mostra cosa è cambiato

I cambi di stato ora si animano sull’elemento che è cambiato invece che con un impulso generico: i marcatori dell’high watermark scorrono fino al nuovo offset, la corona del leader passa dal vecchio leader al nuovo e il tag ISR di un follower prende il colore della modifica. Un record prodotto atterra sulla propria cella del log, un canvas affollato disegna i record come brevi scie e un broker fermo resta sul canvas, sbiadito, così vedi cosa c’era prima. Sui canvas multi-regione il mirror link mostra il suo RPO, ogni fascia di DC dice quanto costerebbe perderla, una partizione di rete mostra quale lato continua a servire, la striscia KRaft conta la sua maggioranza e la corsia di uno share group mostra il timer del lock e il conteggio delle consegne di ogni record.

Una timeline che si legge davvero

Su desktop il dock in basso è ora una rail di una sola riga: i frame si trovano al loro vero tempo di simulazione, così un burst si legge come un gruppo compatto e un tratto tranquillo come un vuoto, e ti sposti trascinando lungo la rail. Apri le sue event lanes e ogni evento della run viene disposto su corsie di produce, replica, broker e consumo, con i guasti in rosso e l’evento principale di ogni frame evidenziato.

Inspector che rispondono a domande

Il pannello di destra ora parte dalle domande che ti fai. Una partizione si legge come un righello dei suoi offset, un broker come ciò che perdi quando si ferma, un topic come una corsia per partizione, un producer come il suo percorso di invio e un consumer group come corsie o una griglia di partizioni. Why elenca cosa si è rotto e perché, le Metrics sono raggruppate per ruolo e alcuni inspector mostrano cosa succederà dopo, non solo lo stato attuale. Le viste multi-regione hanno una card DR che mostra il log di ogni regione e la coda non ancora replicata dal mirror come RPO.

Il canvas fa spazio al terminale

Il terminale CLI di Kafka resta agganciato sotto il canvas, ma ora il canvas gli fa spazio invece di finirci dietro - così kafka-server-stop e la caduta di broker-1 sono sullo schermo insieme, e il terminale ha tutta la larghezza del canvas per quello che scrivi e quello che stampano gli strumenti. Su uno schermo largo, dock side nella sua barra del titolo lo sposta in una colonna accanto al canvas. L’output mantiene le sue colonne e il menu degli host è una tabella ssh con tutti i broker e i controller. I file di configurazione dei broker corrispondono a Kafka 4.4, e kafka-reassign-partitions --generate e il drenaggio di un broker prima della sua rimozione funzionano come su un cluster reale.

Per iniziare, senza un tour

Il tour modale in 13 passi non c’è più. Al suo posto c’è una card Getting started in un angolo del canvas: gli stessi argomenti come checklist da completare in qualsiasi ordine, ciascuno con un «Show me». L’aiuto è ora un riferimento in cui cercare le cose, uno scenario scritto in anticipo può essere trasformato in una sandbox con Undo, gli scenari suggeriscono le proprie mosse «Try it yourself» e cosa fare dopo, e un link condiviso ora riproduce il percorso con cui si è arrivati allo stato che mostra.

Un nuovo aspetto, e un intervento sull’accessibilità

L’intero sito, playground compreso, ha un nuovo aspetto ispirato alla taccola del nostro nome: inchiostro scuro, un riflesso blu e il grigio, con ogni coppia di colori del testo a livello WCAG AA. Insieme sono arrivati skip link e regioni con nome, una rail degli scenari raggiungibile con un solo tab stop, contrasto AA per le regioni inattive, feedback alla pressione e aree di tocco più grandi, e animazioni che rispettano prefers-reduced-motion mantenendo le dissolvenze ed eliminando i movimenti. Il layout per telefono ha avuto un intervento dedicato, fino a un test che verifica che ogni etichetta ci stia ancora.

Fuori dal playground

Il playground in sé non è indicizzabile, quindi i motori di ricerca non hanno mai visto il testo dei suoi scenari. Ora ogni scenario ha una propria pagina sotto /kafka-simulator/scenarios/: la sua introduzione e la sua conclusione, ogni passo con un link «Open at this step», un vero frame del canvas da percorrere passo dopo passo e le configurazioni Kafka che tocca. Con la v2.0 sono 136 pagine.

Accanto a loro ci sono le pagine di troubleshooting per errori e sintomi di Kafka - cosa significa il problema, le cause probabili, le soluzioni e cosa non fare, se il client ritenta o no - ciascuna collegata agli scenari in cui si verifica, aperti nel momento esatto in cui succede. Con questa release si aggiunge la pagina sull’autorizzazione. Il changelog ora si legge come note di rilascio su una timeline.

Ancora una cosa

In questa release abbiamo nascosto qualcosa. Trovarlo tocca a te.

La fine della roadmap

La v2.0 completa ciò che è iniziato con la v1.0: undici pacchetti a cadenza bisettimanale, 136 scenari, dall’anatomia di un singolo broker fino alle code e ai capstone sull’intera piattaforma. Tutto gira nel browser, in modo deterministico, con la semantica di Apache Kafka 4.4, senza backend e senza telemetria sui tuoi scenari.

Il programma è completo, ma il simulatore è una sandbox, non un corso da finire. Apri il simulatore, costruisci qualcosa e rompilo.