Apache Kafka è una tecnologia per realizzare piattaforme distribuite a livello globale per lo streaming di eventi. Kafka viene quindi integrato e sfruttato per applicazioni e servizi di: gestione delle data pipeline, analisi dei dati, data integration e qualsiasi altra applicazione che necessiti di sfruttare concetti come l’event-driven.
Essendo un prodotto globale, una delle best practice di Kafka prevede che per realizzare una data platform resiliente occorra creare repliche distribuite su diverse zone geografiche a livello mondiale.
E’ una best practise nota anche nella progettazione di architetture globali quella di replicare i sistemi in regioni geografiche differenti, ma, nel caso di Kafka, questa larga distribuzione comporta, negli attuali scenari Cloud, che il traffico tra repliche abbia un impatto decisamente negativo in merito ai costi operativi. I provider Cloud, infatti, addebitano delle spese in funzione della quantità di traffico di rete tra zone.
In Kafka questo problema diventa rilevante per il fatto che il client comunica solo con il partition leader (per un approfondimento su come funziona Kafka ti consigliamo di leggere la guida ufficiale) che molto spesso potrebbe essere residente in una differente zona geografica rispetto al client. Un problema non da poco perchè, su scala globale, lo scarso efficientamento del traffico si può tradurre anche in un aumento del 40-50% dei costi.
Kafka ti viene in aiuto in situazioni come quella raccontata nel paragrafo precedente attraverso la possibilità di recuperare i dati direttamente dalla partition replica e non dalla partition leader, cioè un consumer prenderà le informazioni solo da un broker residente nella medesima zona geografica. Questa configurazione permette di eliminare i costosi traffici di rete tra differenti zone geografiche.
Chiaramente affinchè questa configurazione funzioni è necessario che sia i consumer sia i broker sappiano a quale zona geografica appartengano. Anche in questo caso, Kafka ti viene in aiuto permettendo di impostare il valore di metadati che determinano la zona in due variabili: broker.rack e client.rack.
Sembra tutto eccezionale ma, purtroppo, così non è perchè recuperare le informazioni direttamente dalle repliche potrebbe, dall’altro canto, aumentare la latenza end-end che magari, per time-sensitive application, potrebbe non essere l’ideale. A ciò si deve anche aggiungere che occorre gestire differentemente il load balancing ed i processi manutentivi al fine di evitare interruzioni di servizi e sovraccarichi su determinate repliche.
Come sempre, nelle architetture complesse le scelte non sono mai scontate e si portano dietro vantaggi e svantaggi che occorre analizzare prima di implementare tecnologie e strumenti che hanno un impatto strategico in applicazioni business critical. Certamente, però, in architetture complesse e distribuite è molto probabile trovare margini di miglioramento ed efficientamento che si traducono in minori costi.
Abbiamo progettato ed implementato architetture complesse in ambienti sensibili e critici che utilizzano Apache Kafka in maniera integrata. 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 eventi ed enormi flussi di dati con garanzia 12 mesi da qualsiasi bug. Contattaci subito e senza impegno per maggiori informazioni.