Per anni, Apache Kafka è stato il pilastro indiscusso per l’event streaming. Dal punto di vista tecnico funziona bene: throughput elevato, fault tolerance robusta, ordinamento garantito per partizione. Il problema non è che Kafka sia lento: è che, negli ambienti cloud hyperscaler, Kafka è caro. E i costi non derivano da inefficienze del codice, bensì da scelte architetturali strutturali difficili da comprimere con il modello attuale.
In questo articolo di Cristian Bianco, Software Engineer in Bitrock, esploreremo una delle evoluzioni più radicali di Apache Kafka: il passaggio al modello Diskless, una vera svolta per l’ottimizzazione dei costi infrastrutturali.
Con KIP-1150, accompagnata dalle proposte correlate KIP-1163 e KIP-1164, la community Apache Kafka affronta direttamente questo problema. Non si tratta di una feature per ridurre la latenza o aumentare il throughput: è una proposta pensata per ridurre drasticamente il costo operativo di un cluster Kafka nel cloud, separando in modo definitivo il livello di calcolo da quello di storage.
Perché Kafka è costoso nel cloud
Il design classico di Kafka genera costi infrastrutturali elevati in ambiente cloud. Non per inefficienza, ma per come è costruito: ogni scelta architetturale che garantisce affidabilità e ordinamento ha un corrispettivo economico che, mentre in ambiente on-premise era trascurabile, nel cloud diventa molto visibile.
Traffico Cross-AZ. La sincronizzazione delle repliche tra diverse zone di disponibilità è continua e inevitabile. Su piattaforme come AWS o GCP, il trasferimento dati tra AZ ha un costo. Con cluster di grandi dimensioni e replica a tre AZ, questa voce diventa rapidamente la più rilevante della bolletta infrastrutturale. Non si tratta di un costo che si può ottimizzare via codice: è strutturale al modello di replica.
Over-provisioning dei dischi. I broker Kafka sono nodi con stato: il disco locale è parte integrante del processo. Questo significa che bisogna dimensionare i dischi per il picco, non per la media. Chi ha workload variabili finisce inevitabilmente per pagare storage che usa solo una parte del tempo. E, quando lo spazio non basta, la soluzione è il rebalancing: spostare fisicamente i dati tra broker, un’operazione lenta e costosa che blocca risorse durante l’esecuzione.
I limiti della Tiered Storage (KIP-405). La tiered storage, introdotta per spostare i segmenti “dormienti” su object storage, era un primo passo nella direzione giusta. Ma risolve solo il problema dei dati storici. I dati attivi, quelli prodotti e consumati in tempo reale, restano ancora sui dischi locali, con i relativi costi di storage a blocchi e di replica Cross-AZ. Il problema strutturale rimane.
L’Innovazione Architetturale: Diskless Topics (KIP-1150)
La risposta di KIP-1150 a questi problemi non è ottimizzare il modello esistente: è cambiarlo alla radice. L’idea centrale è spostare la fonte di verità dai dischi locali dei broker all’object storage: Amazon S3, Google Cloud Storage o equivalenti. I broker smettono di essere nodi con stato e diventano nodi di calcolo puri. I costi che derivano dallo storage a blocchi e dal traffico di replica Cross-AZ, in questo modello, in larga parte scompaiono.
Object storage come fonte di verità. I messaggi prodotti vengono bufferizzati in memoria e caricati direttamente sull’object storage in file immutabili chiamati WAL Segments (Write-Ahead Log). Non esiste più una scrittura primaria su disco locale. L’object storage è il log, non un layer secondario di archiviazione. Il costo dello storage a blocchi, significativamente più alto dell’object storage a parità di GB, viene sostituito da un modello molto più economico.
Il ruolo del Diskless Coordinator. L’object storage non ha un ordinamento logico nativo: due scritture concorrenti non producono automaticamente un ordine deterministico. Il Diskless Coordinator è il componente introdotto per risolvere questo problema, assegnando gli offset definitivi e stabilendo l’ordine globale dei messaggi per ciascuna partizione. Svolge la funzione che nel modello classico era del leader broker, ma disaccoppiato dallo storage fisico.
I dischi come cache, non come storage. I broker follower non replicano più direttamente dal leader. Scaricano i segmenti necessari direttamente dall’object storage, usando i dischi locali solo come cache per accelerare le letture. Il traffico Cross-AZ di replica, la voce di costo più difficile da comprimere nel modello classico, scompare: tutti i broker leggono dalla stessa fonte globalmente accessibile.
Elasticità senza over-provisioning. L’aggiunta di nuovi broker per gestire picchi di traffico non richiede più la copia massiva dei dati. Il nuovo nodo inizia semplicemente a scaricare i segmenti dall’object storage. Non è solo una questione di velocità: significa che non è più necessario tenere broker sovradimensionati per assorbire i picchi. Si paga per ciò che si usa, non per ciò che potrebbe servire.
Il costo dei topic diskless: la latenza
Ridurre i costi con i topic diskless non è gratis. C’è un trade-off preciso e importante da capire prima di adottarli: la latenza aumenta.
Nel modello classico, un messaggio scritto su disco locale è disponibile ai consumer in pochi millisecondi. Nel modello diskless, i messaggi vengono prima bufferizzati in memoria, poi caricati sull’object storage, e solo dopo resi disponibili. Le API dell’object storage introducono una latenza aggiuntiva che porta il P99 nell’ordine di 1-2 secondi. Non è un problema tecnico risolvibile: è il costo diretto del risparmio.
Questo rende la scelta molto più semplice da inquadrare: se la latenza sub-secondo è un requisito, i topic diskless non sono la scelta giusta. Se invece si lavora con workload dove qualche secondo di ritardo è tollerabile:log aggregation, telemetria, archiviazione, analytics, il risparmio sui costi è reale e immediato.
Quando adottare i topic diskless
Il criterio di selezione è semplice: i topic diskless sono la scelta giusta quando il costo di storage e rete è il problema principale, e la latenza di qualche secondo è accettabile per il workload in questione.
Log aggregation e telemetria ad alto volume. Migliaia di microservizi che producono eventi, metriche e trace generano volumi enormi a costo elevato con il modello classico. La latenza di qualche secondo non impatta la funzionalità, e il risparmio è direttamente proporzionale al volume prodotto.
Archiviazione a lungo termine. Conservare mesi o anni di eventi su dischi a blocchi è costoso. L’object storage è progettato esattamente per questo: durabilità elevatissima a un costo per GB molto inferiore. Con i topic diskless, la retention a lungo termine smette di essere un costo difficile da giustificare.
Workload con traffico imprevedibile. Chi oggi dimensiona il cluster per i picchi, pagando per capacità inutilizzata la maggior parte del tempo, beneficia direttamente dell’elasticità disaccoppiata. Si scala quando serve, senza portarsi dietro lo storage.
Quando non adottarli. Se la latenza sub-100ms è un requisito, trading, pagamenti real-time, pipeline di controllo: il modello diskless non è la scelta corretta, almeno nelle specifiche attuali. Analogamente, in ambienti on-premise senza un object storage gestito, i vantaggi economici scompaiono e rimane solo la complessità aggiuntiva.
Stato attuale e roadmap
Al momento della scrittura, KIP-1150, KIP-1163 e KIP-1164 sono ancora in fase di discussione e votazione all’interno della community Apache Kafka e non fanno parte di alcuna release stabile. Chi vuole seguire l’evoluzione può consultare le pagine ufficiali su Confluence, dove il design continua a essere affinato attraverso il feedback della community.
L’adozione di questa architettura non sarà automatica: i topic diskless coesisteranno con i topic classici. La scelta si farà a livello di singolo topic, in base al profilo del workload, esattamente come oggi si scelgono i parametri di retention o replication factor.
Conclusione
I topic diskless non nascono per rendere Kafka più veloce. Nascono per rendere Kafka più economico nel cloud. È una distinzione importante, perché cambia completamente il modo in cui si valuta l’adozione: non si tratta di un upgrade tecnico, ma di una decisione economica con un trade-off chiaro e ben definito.
Chi gestisce cluster Kafka con grandi volumi in ambiente cloud multi-AZ, e i cui workload tollerano una latenza nell’ordine del secondo, ha davanti una proposta concreta di riduzione dei costi operativi. Chi invece lavora con requisiti di latenza stringenti può continuare a usare il modello classico: i due approcci coesisteranno, selezionabili a livello di singolo topic.In Bitrock, trasformiamo le sfide infrastrutturali in vantaggi competitivi. Scopri i nostri servizi in ambito Engineering e come possiamo supportarti nella prossima fase della tua evoluzione digitale.
References
KIP-1164: Diskless Coordinator
___________________________________________________________________
Autore: Cristian Bianco, Software Engineering @ Bitrock