Una dipendenza storica
Fin dalla sua nascita Apache Kafka ha utilizzato ZooKeeper per gestire i metadati del cluster: l’elenco dei broker attivi, l’assegnazione delle partizioni ai nodi, l’elezione del controller e la configurazione dei topic. ZooKeeper è un servizio di coordinamento distribuito robusto e collaudato, ma la sua presenza introduce complessità operativa. Un deployment Kafka richiede due cluster separati — Kafka e ZooKeeper — ciascuno con le proprie esigenze di monitoraggio, scaling, aggiornamento e backup.
La doppia infrastruttura ha un costo concreto: più componenti da gestire, più modalità di errore da prevedere, più competenze richieste ai team operativi. Per i deployment di dimensioni ridotte la complessità è sproporzionata; per quelli di grandi dimensioni, la scalabilità dei metadati in ZooKeeper diventa essa stessa un vincolo.
KRaft: il quorum interno di metadati
Kafka 2.8, rilasciato nell’aprile 2021, introduce KRaft (Kafka Raft metadata mode) in early access. KRaft sostituisce ZooKeeper con un quorum interno di controller basato sul protocollo Raft, implementato direttamente nei broker Kafka. I metadati del cluster vengono gestiti come un log replicato all’interno dello stesso sistema, senza dipendenze esterne.
Il quorum KRaft è formato da un sottoinsieme di broker designati come controller. Uno di essi è il leader attivo, responsabile della gestione dei metadati; gli altri sono follower che replicano il log e sono pronti a subentrare in caso di guasto. L’elezione del leader avviene tramite il protocollo Raft, che garantisce consenso anche in presenza di partizioni di rete.
Vantaggi architetturali
L’eliminazione di ZooKeeper porta benefici su più livelli. Il deployment si semplifica: un singolo tipo di processo da configurare, aggiornare e monitorare. I metadati scalano meglio perché il log Raft è ottimizzato per il caso d’uso specifico di Kafka, senza i vincoli generici di ZooKeeper. Il tempo di recovery del controller migliora: il nuovo leader dispone già di una copia locale dei metadati e può attivarsi rapidamente.
Il numero massimo di partizioni per cluster, storicamente limitato dalla capacità di ZooKeeper di gestire i watch su migliaia di nodi, può crescere significativamente con KRaft. Per le organizzazioni che gestiscono decine di migliaia di topic con centinaia di migliaia di partizioni, questo è un vincolo reale che KRaft allenta.
Una transizione graduale
KRaft in Kafka 2.8 è dichiarato early access: utilizzabile per valutazione e test, non ancora raccomandato per la produzione. La roadmap prevede la stabilizzazione progressiva nelle versioni successive e la rimozione definitiva della dipendenza da ZooKeeper in una release futura. La migrazione dai cluster esistenti sarà supportata da strumenti dedicati.
La riscrittura architetturale di KRaft rappresenta il cambiamento strutturale di maggiore portata nella storia di Kafka: rimuovere una dipendenza esterna presente fin dal primo giorno per sostituirla con un meccanismo interno progettato per le esigenze specifiche della piattaforma.
Link: kafka.apache.org