L’ecosistema del data streaming raggiunge un importante traguardo con il rilascio di Apache Kafka 4.0, una versione che segna un punto di svolta fondamentale nell’evoluzione di questa piattaforma. Questo aggiornamento rappresenta non solo un cambio di numero di versione, ma una vera e propria trasformazione architetturale che promette di migliorare significativamente scalabilità, performance e semplicità operativa.
In questo articolo, esploreremo le novità più rilevanti introdotte in Apache Kafka 4.0 e come queste possano influenzare positivamente le architetture di data streaming della tua organizzazione.
La novità più significativa di Apache Kafka 4.0 è senza dubbio il completo abbandono di Apache ZooKeeper. Questa transizione, preparata nel corso delle versioni precedenti, è ora giunta a completamento: Kafka 4.0 opera esclusivamente in modalità KRaft (Kafka Raft), utilizzando un proprio protocollo di consenso distribuito.
Il passaggio a KRaft rappresenta un cambiamento architetturale fondamentale che porta numerosi vantaggi, tra cui:
È importante sottolineare come questo cambiamento rappresenti il culmine di oltre 10 anni di collaborazione tra le comunità di Apache Kafka e Apache ZooKeeper. Come espresso nel blog ufficiale, la comunità Kafka ha desiderato ringraziare quella di ZooKeeper per il supporto fornito durante questo lungo periodo, riconoscendo come ZooKeeper sia stato fondamentale per l’evoluzione e il successo di Kafka.
Un’altra innovazione di rilievo in Kafka 4.0 è la disponibilità generale di KIP-848, che introduce un protocollo rivoluzionario per la gestione dei gruppi di consumer. Questa funzionalità, precedentemente in fase di anteprima, è ora pronta per l’utilizzo in ambienti di produzione.
Il nuovo protocollo elimina completamente i “rebalance stop-the-world”, uno dei principali colli di bottiglia nelle precedenti versioni di Kafka. Nei vecchi rebalance, tutti i consumer dovevano interrompere temporaneamente il consumo dei messaggi quando un nuovo consumer si univa al gruppo o quando uno esistente abbandonava. Con il nuovo protocollo, i rebalance avvengono in modo incrementale, permettendo ai consumer di continuare a elaborare messaggi durante la riassegnazione delle partizioni.
Questa evoluzione migliora significativamente sia la stabilità che le performance dei gruppi di consumer, riducendo la latenza end-to-end e aumentando il throughput complessivo. L’implementazione semplifica inoltre il codice client, trasferendo gran parte della complessità del rebalance dal client al broker, in linea con la filosofia di architetture cloud-native moderne.
Kafka 4.0 introduce anche “Queues for Kafka” (KIP-932), una funzionalità in accesso anticipato che espande significativamente le capacità della piattaforma. Questo sviluppo permette a Kafka di supportare nativamente semantiche di coda tradizionali, rendendo la piattaforma più versatile per un’ampia gamma di casi d’uso( a breve scriveremo un articolo dedicato proprio a questi casi d’uso).
Attraverso il concetto di “share group”, Kafka ora può implementare il consumo cooperativo utilizzando i topic standard. Questa funzionalità è concettualmente simile alle “sottoscrizioni condivise durevoli” presenti in altri sistemi di messaggistica, ma implementata in modo coerente con l’architettura e le performance che caratterizzano Kafka.
L’introduzione delle code amplia notevolmente gli scenari in cui Kafka può essere utilizzato efficacemente, permettendo alle organizzazioni di consolidare le proprie infrastrutture di messaggistica attorno a una singola tecnologia. Questa evoluzione si allinea perfettamente con le tendenze di semplificazione architetturale che molte aziende stanno perseguendo.
Con Kafka 4.0, ci sono importanti aggiornamenti nei requisiti di sistema e nelle compatibilità da considerare attentamente nella pianificazione dell’upgrade: Kafka Clients e Kafka Streams ora richiedono Java 11, mentre Kafka Brokers, Connect e Tools necessitano di Java 17. Questo aggiornamento dei requisiti di runtime permette a Kafka di sfruttare le funzionalità più recenti del linguaggio Java, migliorando performance e sicurezza.
Inoltre, Kafka 4.0 rimuove le API deprecate da almeno 12 mesi, in linea con la politica di gestione del ciclo di vita della piattaforma. Questo approccio permette di semplificare la piattaforma e incoraggiare l’adozione delle funzionalità più recenti.
Invitandoti a leggere l’annuncio ufficiale del rilascio Kafka 4.0 in cui sono indicate tutte le novità di questa nuova versione, di seguito, ti indichiamo quelle che per noi sono le più significative.
KIP-890 completa la seconda fase di miglioramento della resilienza delle transazioni, riducendo significativamente la possibilità di “transazioni zombie” durante i guasti dei producer.
KIP-966 introduce in anteprima il concetto di “Eligible Leader Replicas” (ELR), un sottoinsieme delle repliche ISR garantite per avere dati completi fino all’high-watermark. Le ELR sono sicure per l’elezione del leader, prevenendo potenziali perdite di dati durante i cambi di leadership.
KIP-996 implementa un meccanismo di “Pre-Vote” per ridurre le elezioni non necessarie del leader KRaft nei cluster Kafka, migliorando la stabilità in caso di partizioni di rete o problemi transitori.
Infine, KIP-1076 estende le metriche per le applicazioni client, permettendo la raccolta di metriche non solo dai client Kafka ma anche dalle applicazioni embedded come Kafka Streams, fornendo una visione più completa delle performance.
Come partner tecnologico specializzato nell’implementazione di architetture di data streaming, e grazie alle competenze specialistiche maturate in tantissimi settori e con numerosi Clienti ti forniamo assistenza e supporto, consulenza di Solution Architect e realizziamo architetture che ti permettono di gestire data stream con garanzia 12 mesi da qualsiasi bug. Contattaci subito e senza impegno per maggiori informazioni.