In veste di partner di Confluent, non potevamo perdere l’opportunità di unirci agli altri 3.000 partecipanti ( online e in presenza) al Kafka Summit 2024 di Londra, per conoscere le ultime novità e gli sviluppi futuri di Kafka come tecnologia di streaming e per continuare a scoprire questa tecnologia al fine di fornire ai nostri clienti la soluzione migliore per i loro use case Apache Kafka.
Introduzione e Keynote
Il keynote, tenuto da un team di relatori di Confluent, ha riguardato gli sviluppi di Apache Kafka e della propria piattaforma. Quest’anno Apache Kafka ha raggiunto il millesimo KIP, un forte indicatore della vivacità e dell’impegno della comunità nello sviluppo di Kafka come piattaforma di streaming. Altre pietre miliari di Kafka celebrate nell’ultimo anno sono le nuove versioni 3.6 e 3.7, il rilascio di un’immagine ufficiale di Apache Kafka Docker e nuove funzionalità come Tiered Storage (KIP-405, in accesso anticipato) e metriche lato client (KIP-714). Tra le prossime funzionalità in fase di sviluppo, una di particolare interesse è Queues for Kafka (KIP-932), ancora in fase di valutazione, che consentirà ai consumatori di condividere partizioni quando consumano i dati, eliminando l’attuale limite di parallelismo di un consumatore per partizione.
Il team di Confluent ha presentato la sua piattaforma Confluent Cloud come un warehouse unificato per i prodotti di dati tra operazioni e analisi. Tutti i dati potranno essere archiviati in topic Kafka.
Diverse presentazioni hanno mostrato come gestire questo sistema di dati interamente Kafka, anche attraverso una mappa dell’elaborazione dei flussi che forniscono (la vista “Stream Lineage”) e un hub centralizzato e consultabile per i metadati tecnici e aziendali sugli argomenti (lo “Stream Catalog”) che consente agli sviluppatori di trovare la risorsa di dati più rilevante per le loro esigenze.
Forse l’aspetto più interessante dello sviluppo di Confluent Cloud è l’integrazione dei dati Kafka business-oriented e dei dati Parquet analytics-oriented, utilizzati e gestiti da Apache Iceberg. La sua funzionalità “TableFlow” consente di archiviare i dati Kafka nel cloud come file Parquet, accessibili come data lake attraverso Iceberg, fornendo viste sia tabellari che di flusso degli stessi dati. L’obiettivo è quello di rendere questo sistema completamente bidirezionale, in modo che gli aggiornamenti provenienti sia da Iceberg che da Kafka siano visibili da entrambi i lati, unificando i due regimi di elaborazione dei dati e rendendo i dati operativi e analitici ampiamente disponibili in tutto l’ecosistema di dati di un’organizzazione.
Personalizzazione dei Componenti
La piattaforma Confluent fornisce un insieme di componenti che consentono a un’organizzazione di concentrare i propri sforzi sullo sviluppo della logica di business utilizzando il componente della piattaforma Confluent come base per la comunicazione asincrona. Tuttavia, i vari componenti della piattaforma Confluent possono essere completamente sostituiti con componenti che forniscono un valore specifico. Le principali offerte di valore possono essere
Riduzione dei costi
- Per i contesti in cui è possibile ridurre alcuni requisiti di performance, WarpStream propone di ridurre il costo del cluster Kafka utilizzando la sua struttura cloud, che offre un’architettura cloud-native di Kafka che memorizza i dati in S3. I broker di Kafka sono stati riadattati per eliminare la maggior parte dei costi sfruttando le proprietà di S3, che offre risparmio, affidabilità, scalabilità ed elasticità.
- Senza alcun compromesso: RedPanda offre una piattaforma di streaming costruita con la stessa astrazione di Confluent per Kafka (log infinito, suddivisione degli argomenti in partizioni e modello pub-sub). RedPanda sostiene di essere “6 volte più conveniente di Apache Kafka e 10 volte più veloce”. Dopotutto, lo stack tecnologico non è basato su JVM e non utilizza un servizio di coordinamento come Apache Zookeeper, ma ha RAFT incorporato (come già faceva Kafka con KIP-500).
Miglioramento delle prestazioni
- Per contesti particolari: Responsive è un’azienda che offre una libreria di soluzioni stateful-streaming che può essere scambiata con lo stream Kafka. La differenza principale è che gli archivi di stato sono remoti, consentendo all’applicazione di essere stateless. Questo risolve la dolorosa operazione di ribilanciamento quando si scala una flotta di microservizi che implementano l’elaborazione stateful stream.
- Senza alcun compromesso: Pulsar è una piattaforma di streaming come la piattaforma Confluent. Ha un’architettura più complessa di Kafka, con componenti specializzati come Bookkeeper e ancora Zookeeper. Questa complessità può fornire migliori prestazioni, ma anche l’impegno di gestirle.
La maggior parte della personalizzazione presentata può essere vista come un refactoring del componente Kafka per sfruttare i servizi cloud-native, ed è possibile che Confluent abbia fatto la stessa cosa con Kora: migliorare la scalabilità e abbassare il costo per i suoi clienti.
Il nostro intervento preferito: “Attacking (and Defending) Apache Kafka“
In generale, esistono contesti in cui sistemi di integrazione come Apache Kafka si fanno carico di trasportare dati privati e sensibili che, se nelle mani di qualcuno con cattive intenzioni, potrebbero portare a gravi danni, non solo attraverso il furto di dati relativi a persone identificabili, ma anche attraverso la manipolazione di “messaggi di comando” che potrebbero consentire la manipolazione e/o il controllo dei sistemi che ricevono quelle informazioni.
Come ha spiegato Francesco Tisiot nel suo interessante intervento “Attacking (and Defending) Apache Kafka”, che ha delineato i punti più suscettibili del sistema e le potenziali conseguenze di vari attacchi, è possibile attuare misure proattive durante la fase di progettazione per salvaguardare i dati.
Kafka è:
- Distribuito: ci sono molti nodi (broker) che possono essere attaccati, ma anche la rete. Ad esempio, è facile colpire la rete tra i nodi dei nodi stessi con un attacco DDOS o utilizzare un man-in-the-middle per intercettare il traffico. SSL, mascheramento dei dati e crittografia dovrebbero essere inclusi nella progettazione.
- Uno strumento di streaming in tempo reale o quasi: significa che tutto avviene velocemente, compresi i danni. In caso di attacco, il tempo di reazione è fondamentale. Il monitoraggio dovrebbe essere abilitato in una fase iniziale.
- Flessibile: Kafka non si preoccupa molto della struttura dei dati che vi transitano; è importante definire una struttura molto rigida per i dati e sanificarli a ogni passaggio, poiché un messaggio strutturato in questo modo può facilmente infrangere le soft rules del db di destinazione o impartire comandi indesiderati al sistema di destinazione sfruttando la sua logica aziendale.
- Integrabile: Kafka è spesso così facile da integrare che è sufficiente un file di configurazione, che contiene molte credenziali e informazioni sull’infrastruttura.
“Event Modeling Anti-patterns“
Una parte complessa della creazione di qualsiasi artefatto software è la modellazione del suo dominio. Nel caso di un sistema di integrazione, in particolare, è importante sapere come modellare gli eventi che si verificheranno e come gestire gli errori, e spesso vengono in soccorso pattern di progettazione ben progettati e conosciuti.
Nel suo divertente intervento “Event modeling anti-patterns”, Oskar Dudycz ha descritto il processo di modellazione degli eventi “per contraddizione”, partendo da progetti molto “statici” spesso utilizzati quando la tecnologia era anch’essa “statica”, una sorta di “architettura guidata dal database” come l’ha definita Oscar, per arrivare invece a modi più moderni di modellare gli eventi in modo che possano passare attraverso un’architettura guidata dagli eventi (che può essere facilmente implementata utilizzando Kafka), portando le informazioni veramente importanti per la logica di business dei sottoscrittori.
Ciò che dovrebbe essere realmente modellato, dopo averne compreso la semantica, sono tre tipi di eventi: Comando, Evento, Documento. In generale, gli eventi non possono essere solo le informazioni prese dal log di scrittura del database (creazione, aggiornamento, …), cioè l’origine CRUD, poiché questi eventi non portano informazioni sufficienti per la logica di business. Dall’altro lato, c’è quello che viene chiamato “sourcing delle proprietà”, ossia l’invio di un evento per ogni cambiamento di proprietà, per cui l’architettura viene inondata di eventi. Come ha spiegato Oscar, è importante studiare come raggruppare le (sole) informazioni rilevanti per implementare la semantica di uno specifico tipo di evento.
Un altro aspetto importante dell’implementazione di questo tipo di architetture è quello di identificare tutti gli errori che possono verificarsi e capire come gestirli. Anche in questo caso, in letteratura sono disponibili molti design pattern. Come ha spiegato Cedric Schaller nel suo intervento “Error Handling with Kafka: From Patterns to Code”, data la natura dell’architettura di Apache Kafka, questi sono gli errori più comuni che devono essere gestiti in un’implementazione robusta (possibilmente senza invalidare le buone proprietà di Kafka imponendo una gestione troppo rigida):
- Errore di validazione: risolvere questo tipo di errore è semplice come implementare un qualsiasi meccanismo di validazione dei dati.
- Errori di sistemi di terze parti (database, servizi web, ecc.)
- Problemi infrastrutturali di Kafka (nodi non disponibili nel cluster, perdita di dati a causa di una replica insufficiente, ecc.)
- Problemi di scrittura (perdita dell’ordine o della transazionalità, errori di scrittura, ecc.)
- Problemi di consumo e di elaborazione (pillole di veleno, eccezioni dell’applicazione durante l’elaborazione dei dati, ecc.)
Come ha spiegato Cedric, il primo passo per un’implementazione solida che prevenga alcuni di questi errori è una configurazione dell’infrastruttura personalizzata forte e affidabile. Dopo aver messo in sicurezza l’infrastruttura, è importante scegliere il pattern giusto da utilizzare per implementare i requisiti logici. Cedric ha spiegato e dimostrato in dettaglio i pattern: “stop on error”, “dead letter topic” per scartare i messaggi irrecuperabili, “retry topic” per rielaborare alcuni messaggi, “maintaining the order of events” per accodare i messaggi interrotti mantenendo l’ordine per essere rielaborati in seguito (manualmente, eventualmente).
Conclusioni
Kafka Summit 2024 è stato animato dai miglioramenti di Apache Kafka e Confluent Cloud. I partecipanti hanno potuto scoprire le nuove versioni di Kafka, le funzionalità e l’entusiasmante Queues for Kafka. Confluent Cloud ha impressionato per la sua visione di unificazione dei dati grazie a Stream Lineage, Stream Catalog e TableFlow.
Durante il summit è stata evidenziata la flessibilità di Confluent garantita da soluzioni come WarpStream, RedPanda e Pulsar che offrono una personalizzazione per ridurre i costi e migliorare le prestazioni.
La sicurezza è stato un tema chiave, riguardo cui diversi esperti hanno esposto misure proattive come la crittografia, la convalida dei dati e il monitoraggio. Inoltre, sono state affrontate le migliori pratiche per la modellazione degli eventi e la gestione degli errori .
Grazie a questi progressi, le aziende possono sfruttare la potenza di Kafka e Confluent Cloud per costruire pipeline di dati sicure ed efficienti.
Autori: Giovanni Morlin, Mario Taccori, Bradley Gersh Software Engineers @ Bitrock
