Best Practice di Configurazione Kafka per Ambienti di Produzione

Kafka è indulgente in fase di sviluppo e molto meno in produzione. Un topic con una sola replica funziona bene finché un broker non muore. Un producer con acknowledgment deboli sembra veloce finché i messaggi non scompaiono durante un guasto. Un consumer che committa automaticamente gli offset sembra semplice finché non committa lavoro che non ha effettivamente completato. La configurazione di Kafka in produzione riguarda principalmente decidere quali guasti sei disposto a tollerare e poi rendere esplicite tali decisioni.

Questa guida copre le best practice di configurazione di Kafka per ambienti di produzione senza fingere che esista un unico file di configurazione perfetto. Le impostazioni corrette dipendono dal carico di lavoro, dai requisiti di latenza, dalle esigenze di durabilità, dalla maturità operativa e dalla versione di Kafka. Gli esempi seguenti sono punti di partenza che dovresti testare con il tuo traffico.

Comprensione dei Componenti Chiave di Kafka e della Loro Configurazione

Prima di immergerci nelle configurazioni specifiche, è cruciale comprendere i componenti principali di Kafka e come le loro impostazioni influenzano il comportamento complessivo del sistema.

Broker: I server Kafka che memorizzano i dati e servono le richieste dei client. La configurazione del broker determina prestazioni, utilizzo delle risorse e tolleranza ai guasti.
Topic: Categorie o feed di messaggi a cui si pubblica.
Partizioni: I topic sono suddivisi in una o più partizioni, consentendo il parallelismo nell'elaborazione e nell'archiviazione.
Replica: Il processo di copia delle partizioni su più broker per garantire la durabilità e la disponibilità dei dati in caso di guasti del broker.
Gruppi di Consumatori: Un gruppo di consumatori che cooperano per consumare messaggi da un topic. Kafka garantisce che ogni messaggio all'interno di un topic venga consegnato al massimo a un consumatore all'interno di ciascun gruppo di consumatori.

Strategie di Topic e Partizionamento

Una configurazione efficace di topic e partizioni è fondamentale per la scalabilità e le prestazioni di Kafka.

Numero di Partizioni

Scegliere il giusto numero di partizioni è una decisione critica. Più partizioni consentono un maggiore parallelismo lato consumatore, il che significa che più istanze di consumatori possono elaborare i dati contemporaneamente. Tuttavia, troppe partizioni possono mettere a dura prova le risorse del broker (memoria, I/O del disco) e aumentare la latenza. Una regola pratica comune è iniziare con un numero di partizioni che rifletta il throughput massimo previsto del consumatore, considerando che potresti voler aggiungere più partizioni in seguito se necessario.

Considerazione: Il numero massimo di partizioni che un broker può gestire è limitato dalla sua memoria. Ogni partizione richiede memoria per le sue repliche leader e follower.
Raccomandazione: Punta a un numero di partizioni che sia in linea con le tue esigenze di parallelismo del consumatore, ma evita un partizionamento eccessivo. Monitora l'utilizzo delle risorse del broker per trovare un equilibrio ottimale.

Chiave di Partizionamento

Quando si producono messaggi, una chiave di partizionamento (spesso una chiave del record) determina in quale partizione verrà scritto un messaggio. Un partizionamento coerente è essenziale per l'elaborazione ordinata all'interno di un gruppo di consumatori.

partitioner.class: Questa configurazione del producer può essere impostata su org.apache.kafka.clients.producer.internals.DefaultPartitioner (predefinita, utilizza l'hash della chiave) o su un partizionatore personalizzato.
Best Practice: Utilizza una chiave che distribuisca i messaggi uniformemente tra le partizioni. Se i messaggi con la stessa chiave devono essere elaborati in ordine, Kafka garantisce l'ordine solo all'interno di una partizione.

Replica e Tolleranza ai Guasti

La replica è il meccanismo principale di Kafka per garantire la durabilità e la disponibilità dei dati.

Fattore di Replica

Il fattore di replica determina quante copie di ogni partizione vengono mantenute nel cluster. Per ambienti di produzione, è altamente raccomandato un fattore di replica minimo di 3.

Vantaggio: Con un fattore di replica di 3, Kafka può solitamente tollerare un guasto del broker mantenendo un'altra replica disponibile. La disponibilità esatta dipende da min.insync.replicas, acks del producer, impostazioni di elezione del leader e quali broker si guastano.
Configurazione: Viene impostato a livello di topic, durante la creazione del topic o tramite comandi kafka-topics.sh.

# Esempio: Creare un topic con fattore di replica 3
kafka-topics.sh --create --topic my-production-topic --bootstrap-server kafka-broker-1:9092 --replication-factor 3 --partitions 6

`min.insync.replicas`

Questa impostazione di configurazione del broker determina il numero minimo di repliche che devono confermare un'operazione di scrittura prima che questa sia considerata riuscita. Per topic con un fattore di replica di N, impostare min.insync.replicas=M (dove M < N) garantisce che una scrittura venga confermata solo dopo che M repliche l'hanno confermata. Per prevenire la perdita di dati, min.insync.replicas dovrebbe tipicamente essere impostato su N-1 o N/2 + 1 a seconda dei tuoi compromessi tra disponibilità e durabilità.

Raccomandazione: Per topic critici, imposta min.insync.replicas su replication_factor - 1. Ciò garantisce che almeno due repliche (in una configurazione a 3 repliche) abbiano i dati prima di confermare la scrittura, prevenendo la perdita se il leader si guasta.
Configurazione: Questa è una configurazione a livello di broker e può anche essere impostata per topic.

# broker.properties
min.insync.replicas=2

# Configurazione a livello di topic (sovrascrive l'impostazione del broker)
# kafka-configs.sh --alter --topic my-critical-topic --bootstrap-server ... --add-config min.insync.replicas=2

Elezione del Leader e Controller

Kafka utilizza un broker controller per gestire lo stato del cluster, inclusa la leadership delle partizioni. Configurazioni robuste del controller sono vitali.

controller.quorum.voters: Nei cluster basati su KRaft, specifica i votanti del quorum del controller. I cluster basati su ZooKeeper utilizzano una diversa configurazione del piano di controllo, quindi non copiare questa impostazione ciecamente tra le architetture.
num.io.threads e num.network.threads: Queste impostazioni del broker controllano il numero di thread dedicati alla gestione delle richieste I/O e di rete. Regola in base al carico di lavoro e alla CPU disponibile.

Configurazioni di Producer e Consumer

Ottimizzare le impostazioni di producer e consumer è fondamentale per ottenere un throughput elevato e una bassa latenza.

Configurazioni del Producer

acks: Controlla il numero di acknowledgment richiesti dalle repliche. Impostare acks=all (o -1) fornisce la garanzia di durabilità più forte. Combinato con min.insync.replicas, è cruciale per la produzione.
retries: Imposta un valore alto (es., Integer.MAX_VALUE) per garantire che i guasti transitori non portino alla perdita di messaggi. Utilizza max.in.flight.requests.per.connection in modo efficace con i tentativi.
max.in.flight.requests.per.connection: Controlla il numero massimo di richieste non confermate che possono essere inviate a un broker. I client più vecchi spesso utilizzavano 1 per evitare il riordino con i tentativi. I producer idempotenti moderni possono preservare l'ordinamento con limiti di sicurezza più elevati, ma controlla la versione del client e le impostazioni.
batch.size e linger.ms: Queste impostazioni controllano il raggruppamento dei messaggi. Lotti più grandi possono migliorare il throughput ma aumentare la latenza. linger.ms aggiunge un piccolo ritardo per consentire il raggruppamento di più messaggi.

# producer.properties
acks=all
retries=2147483647
max.in.flight.requests.per.connection=1
batch.size=16384
linger.ms=5

Configurazioni del Consumer

auto.offset.reset: Per la produzione, latest è spesso preferito per evitare di rielaborare vecchi messaggi al riavvio. earliest può essere utilizzato se è necessario rielaborare i messaggi dall'inizio.
enable.auto.commit: Imposta su false per un'elaborazione affidabile. I commit manuali ti danno il controllo su quando vengono committati gli offset, prevenendo la riconsegna o la perdita di messaggi. Utilizza commitSync() o commitAsync() per commit espliciti.
max.poll.records: Controlla il numero massimo di record restituiti in una singola chiamata poll(). Regola per gestire il carico di elaborazione e prevenire i ribilanciamenti del consumatore.
isolation.level: Imposta su read_committed quando si utilizzano transazioni Kafka per garantire che i consumatori leggano solo messaggi committati.

# consumer.properties
group.id=my-consumer-group
auto.offset.reset=latest
enable.auto.commit=false
isolation.level=read_committed
max.poll.records=500

Considerazioni sulla Sicurezza

Proteggere il tuo cluster Kafka è negoziabile in ambienti di produzione.

Autenticazione e Autorizzazione

SSL/TLS: Crittografa la comunicazione tra client e broker, e tra broker stessi. Ciò richiede la generazione e la distribuzione di certificati.
SASL (Simple Authentication and Security Layer): Utilizza meccanismi SASL come GSSAPI (Kerberos), PLAIN o SCRAM per autenticare i client.
Autorizzazione (ACL): Configura le liste di controllo degli accessi (ACL) per definire quali utenti o principal possono eseguire operazioni specifiche (lettura, scrittura, creazione topic, ecc.) su quali risorse (topic, gruppi di consumatori).

Crittografia

ssl.enabled.protocols: Assicurati di utilizzare protocolli sicuri come TLSv1.2 o TLSv1.3.
ssl.cipher.suites: Configura suite di crittografia robuste.

Esempio di Configurazione (Producer con SASL su TLS)

security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="myuser" password="mypassword";
ssl.truststore.location=/path/to/truststore.jks
ssl.truststore.password=password

Ottimizzazione delle Prestazioni e Monitoraggio

Il monitoraggio e l'ottimizzazione continui sono essenziali per mantenere prestazioni ottimali.

Ottimizzazione del Broker

num.partitions: Sebbene questa sia un'impostazione a livello di topic, il broker deve gestire il numero totale di partizioni. Monitora CPU, memoria e I/O del disco.
log.segment.bytes e log.roll.hours: Controllano la dimensione e la frequenza di rotazione dei segmenti di log. Segmenti più piccoli possono portare a più descrittori di file aperti e maggiore overhead. Segmenti più grandi possono consumare più spazio su disco per segmento ma ridurre l'overhead.
message.max.bytes: La dimensione massima di un messaggio in byte. Assicurati che sia abbastanza grande per il tuo caso d'uso ma non eccessivamente.
replica.fetch.max.bytes: Controlla il numero massimo di byte per richiesta di fetch da parte di una replica follower. Ottimizza per bilanciare l'efficienza del fetch e l'utilizzo della memoria.

Ottimizzazione JVM

Dimensione Heap: Alloca memoria heap sufficiente per la JVM che esegue Kafka. Monitora l'utilizzo dell'heap e l'attività GC.
Garbage Collector: Scegli un algoritmo GC appropriato (es., G1GC è spesso raccomandato per Kafka).

Monitoraggio

Implementa un monitoraggio completo utilizzando strumenti come Prometheus/Grafana, Datadog o soluzioni di monitoraggio specifiche per Kafka.

Metriche Chiave: Monitora la salute del broker, il throughput del topic, il lag del consumatore, lo stato della replica, la latenza delle richieste e l'utilizzo delle risorse (CPU, memoria, disco, rete).
Alerting: Imposta avvisi per condizioni critiche come lag elevato del consumatore, mancata risposta del broker o esaurimento dello spazio su disco.

Ribilanciamenti dei Gruppi di Consumatori

I ribilanciamenti dei gruppi di consumatori si verificano quando i consumatori si uniscono o lasciano un gruppo, o quando le partizioni vengono riassegnate. Ribilanciamenti frequenti possono interrompere l'elaborazione.

session.timeout.ms: Quanto tempo un broker attende che un consumatore invii un heartbeat prima di considerarlo morto. Valori più bassi significano un rilevamento più rapido ma possono portare a ribilanciamenti prematuri a causa di problemi di rete.
heartbeat.interval.ms: Con quale frequenza i consumatori inviano heartbeat. Dovrebbe essere significativamente inferiore a session.timeout.ms.
max.poll.interval.ms: Il tempo massimo tra le chiamate poll da un consumatore. Se un consumatore impiega più tempo di questo per elaborare i messaggi e fare poll di nuovo, verrà considerato morto, innescando un ribilanciamento. Assicurati che i tuoi consumatori possano elaborare i messaggi entro questo intervallo.
Suggerimento: Ottimizza la logica di elaborazione del consumatore per completare il lavoro entro max.poll.interval.ms ed evitare ribilanciamenti non necessari a causa di consumatori lenti.

Impostazioni Predefinite di Produzione che Deciderei Esplicitamente

Non lasciare il comportamento importante di Kafka a impostazioni predefinite accidentali. Alcune impostazioni predefinite sono ragionevoli per uso generale, ma i sistemi di produzione necessitano di decisioni che corrispondano ai dati.

Per flussi di eventi critici, utilizza un fattore di replica di 3 o più dove il cluster ha abbastanza broker e rack per supportarlo. Abbinalo a acks=all sui producer e min.insync.replicas=2 su un topic a tre repliche. Questa combinazione significa che una scrittura viene confermata solo quando il leader e almeno un follower in-sync la possiedono. Se troppe repliche cadono fuori sincronia, i producer ricevono errori invece di accettare silenziosamente una durabilità più debole.

Quel compromesso è intenzionale. Durante un guasto, un topic altamente durevole può rifiutare le scritture piuttosto che confermare dati che si trovano solo su un broker. Alcuni sistemi preferiscono la disponibilità alla durabilità per determinati dati di telemetria o clickstream. Va bene se è una scelta consapevole. È pericoloso quando nessuno si rende conto che il topic è stato configurato in quel modo.

Disabilita l'elezione del leader non pulita per i topic in cui la perdita di dati non è accettabile. L'elezione non pulita può riportare online una partizione eleggendo una replica fuori sincronia, ma quella replica potrebbe mancare di record confermati a seconda della cronologia dei guasti e delle impostazioni del producer. Per dati critici, rimanere non disponibili è spesso meglio che perdere o riavvolgere i record senza preavviso.

Numero di Partizioni: Scegli per Throughput e Operazioni

Il numero di partizioni controlla il parallelismo, ma più partizioni non sono gratuite. Ogni partizione aggiunge metadati, descrittori di file, lavoro di replica, lavoro di elezione del leader e overhead di recupero. Influisce anche sul comportamento del gruppo di consumatori. Un topic con 200 partizioni può supportare più parallelismo del consumatore rispetto a un topic con 12, ma crea anche più parti mobili durante i riavvii del broker e i ribilanciamenti.

Inizia stimando il parallelismo e il throughput del consumatore. Se il servizio consumatore eseguirà al massimo 12 istanze, 48 partizioni potrebbero essere sufficienti. Se prevedi centinaia di thread di elaborazione indipendenti, potresti aver bisogno di più. Lascia spazio per la crescita, perché aumentare le partizioni in seguito può cambiare la distribuzione delle chiavi e il comportamento di ordinamento per i messaggi con chiave.

L'ordinamento è garantito solo all'interno di una partizione. Se tutti gli eventi per customer_id=123 devono essere elaborati in ordine, utilizza una chiave stabile basata su quell'ID cliente. Non aspettarti l'ordinamento sull'intero topic. Inoltre, fai attenzione alle chiavi calde. Se un cliente, tenant o dispositivo produce una grande quota di traffico, il partizionamento basato su chiave può sovraccaricare una partizione mentre altre rimangono inattive.

Per sistemi multi-tenant, considera se un topic condiviso o molti topic per tenant è più facile da gestire. Molti topic minuscoli possono creare overhead di metadati. Un enorme topic condiviso può complicare la conservazione, il controllo degli accessi e la risposta agli incidenti. La scelta migliore dipende dai requisiti di isolamento e dalla forma del traffico.

La Conservazione è una Decisione di Prodotto, Non Solo un'Impostazione del Broker

La conservazione di Kafka determina per quanto tempo i dati rimangono disponibili per la riproduzione. Una conservazione breve risparmia disco ma limita il recupero. Una conservazione lunga abilita backfill e flussi di lavoro di audit ma aumenta il costo di archiviazione e il tempo di recupero.

Imposta la conservazione per topic in base a come vengono utilizzati i dati. Un topic di comandi potrebbe aver bisogno solo di una finestra breve. Un topic di cronologia eventi potrebbe aver bisogno di giorni o settimane. Un topic compattato che rappresenta lo stato più recente utilizza un modello diverso: Kafka mantiene il valore più recente per chiave dopo la compattazione, più tombstone per le eliminazioni fino alla pulizia.

Impostazioni comuni includono:

retention.ms=604800000
retention.bytes=-1
cleanup.policy=delete

Per topic compattati:

cleanup.policy=compact
min.cleanable.dirty.ratio=0.5
delete.retention.ms=86400000

Fai attenzione con messaggi grandi. Kafka può gestire record più grandi quando configurato coerentemente, ma aumentare message.max.bytes significa controllare max.request.size del producer, fetch.max.bytes del consumatore, le impostazioni di fetch della replica del broker e l'impatto sulla memoria. In molti sistemi, archiviare payload grandi in object storage e inviare un riferimento tramite Kafka è più semplice e affidabile.

Impostazioni del Producer che Evitano Dolori

Per la maggior parte dei producer di produzione, abilita l'idempotenza a meno che tu non abbia un motivo specifico per non farlo. La produzione idempotente aiuta a prevenire scritture duplicate causate da tentativi dopo guasti transitori. Molti client Kafka moderni lo abilitano automaticamente in determinate configurazioni, ma vale la pena rendere visibile la decisione nella configurazione del producer.

Esempio di base del producer:

acks=all
enable.idempotence=true
retries=2147483647
delivery.timeout.ms=120000
request.timeout.ms=30000
linger.ms=5
batch.size=32768
compression.type=zstd

La scelta della compressione dipende dal budget della CPU e dalla versione di Kafka. zstd spesso fornisce una forte compressione, mentre lz4 e snappy sono scelte comuni a bassa latenza. Testa con i tuoi payload. I log JSON, i record Avro, i messaggi protobuf e i dati binari già compressi si comportano diversamente.

Il raggruppamento è un altro compromesso. Un linger.ms piccolo dà al producer una breve finestra per raggruppare i record, il che può migliorare il throughput e la compressione. Impostarlo troppo alto aggiunge latenza. Per i percorsi di richiesta rivolti all'utente, tieni a mente i budget di latenza. Per l'ingestione in background, un po' più di linger può essere accettabile.

Non ignorare gli errori del producer. Se acks=all e min.insync.replicas rifiutano una scrittura durante problemi del broker, questa è una backpressure utile. L'applicazione deve decidere se riprovare, bufferizzare, fallire la richiesta o instradare a un fallback. Registrare l'errore e rilasciare l'evento non è una strategia di durabilità.

Impostazioni del Consumer che Corrispondono alla Semantica di Elaborazione

I commit degli offset del consumatore definiscono cosa significa "elaborato". Con enable.auto.commit=true, il client può committare gli offset prima che la tua applicazione abbia completato in sicurezza il lavoro. Ciò può essere accettabile per analisi usa e getta, ma è rischioso per pagamenti, ordini, distribuzioni o qualsiasi cosa in cui perdere un evento fa male.

Per un'elaborazione affidabile, disabilita il commit automatico e committa dopo che il lavoro è stato completato:

enable.auto.commit=false
max.poll.records=500
max.poll.interval.ms=300000
session.timeout.ms=45000
heartbeat.interval.ms=15000
partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

La strategia di commit dipende dall'applicazione. commitSync() è più semplice e fornisce un comportamento di errore chiaro, ma può aggiungere latenza. commitAsync() può migliorare il throughput, ma devi gestire con cura gli errori di callback. Molti servizi committano periodicamente dopo lotti riusciti e rendono le scritture a valle idempotenti in modo che la riproduzione sia sicura.

Se l'elaborazione di un messaggio può richiedere molto tempo, riduci max.poll.records, aumenta max.poll.interval.ms o sposta il lavoro lento dietro una coda interna mentre il ciclo di poll continua in modo responsabile. Un consumatore che smette di fare poll per troppo tempo innesca un ribilanciamento, e ribilanciamenti ripetuti fanno sembrare instabile l'intero gruppo.

Utilizza l'appartenenza statica per i consumatori che si riavviano frequentemente ma tornano con identità stabili. Può ridurre i ribilanciamenti non necessari durante le distribuzioni rolling. Il ribilanciamento cooperativo può anche ridurre le interruzioni rispetto al ribilanciamento eager, a seconda del supporto del client.

Sicurezza che i Team Possano Gestire

Kafka di produzione dovrebbe utilizzare la crittografia in transito quando il traffico attraversa reti non fidate o trasporta dati sensibili. La maggior parte delle organizzazioni dovrebbe utilizzare TLS per la comunicazione client-broker e inter-broker. L'autenticazione può essere TLS reciproco, SASL/SCRAM, Kerberos, OAuth o un altro meccanismo supportato a seconda dell'ambiente.

Le ACL dovrebbero essere sufficientemente specifiche da prevenire danni accidentali. Un producer per orders.created non ha bisogno del permesso di scrivere su ogni topic. Un gruppo di consumatori per la fatturazione non ha bisogno del permesso di alterare le configurazioni del broker. Utilizza convenzioni di denominazione che rendano le ACL leggibili e mantieni i principal dei servizi legati alle applicazioni piuttosto che ai singoli umani.

I segreti necessitano di rotazione. Se le credenziali SASL o i keystore vengono copiati manualmente sui server, la rotazione diventa dolorosa e alla fine smette di accadere. Utilizza il gestore di segreti della tua piattaforma dove possibile. Testa la rotazione in staging, inclusi i riavvii rolling dei client.

Decidi anche chi può creare topic. La creazione automatica di topic è comoda in sviluppo e pericolosa in produzione. Un errore di battitura in un nome di topic può creare un nuovo topic con partizioni predefinite, replica predefinita e conservazione predefinita. Molti cluster di produzione disabilitano la creazione automatica di topic e gestiscono i topic tramite codice dell'infrastruttura o un flusso di lavoro approvato.

Controlli del Broker e dello Storage

Kafka è sensibile al disco. Utilizza storage con latenza prevedibile, monitora aggressivamente l'utilizzo del disco e mantieni abbastanza spazio libero per conservazione, recupero della replica ed errori operativi. Un broker con un disco pieno può creare un incidente molto più grande di un broker con CPU elevata.

Separa i log di Kafka da carichi di lavoro rumorosi non correlati. Evita di mettere i dati di Kafka su dischi condivisi dove un altro processo può improvvisamente consumare I/O. In ambienti cloud, comprendi i limiti di throughput del volume, i crediti burst e il comportamento di recupero. Un disco che si comporta bene per un minuto potrebbe comunque avere difficoltà sotto replica e compattazione sostenute.

La consapevolezza dei rack è importante quando hai più zone di disponibilità o rack. Configura gli ID dei rack del broker e il posizionamento dei topic in modo che le repliche non siano tutte nello stesso dominio di guasto. Un fattore di replica di 3 è meno utile se tutte e tre le repliche scompaiono con un problema di rack o zona.

Monitoraggio e Avvisi che Catturano Guasti Reali

Una configurazione di monitoraggio Kafka utile osserva sia gli interni di Kafka che l'esperienza del client. Le metriche del broker da sole non ti dicono se i consumatori stanno tenendo il passo o se i producer stanno vedendo errori.

Osserva le partizioni sotto-replicate, le partizioni offline, il conteggio dei controller attivi, la latenza delle richieste, i tassi di errore di produce e fetch, il throughput di rete, l'utilizzo del disco, la latenza I/O del disco, i tassi di restringimento ed espansione ISR, il tempo di coda degli eventi del controller, il lag del consumatore, il tasso di ribilanciamento e i conteggi di tentativi/errori del client.

Il lag del consumatore necessita di contesto. Un lag di 100 record può andare bene su un topic che riceve milioni all'ora. Un lag di 100 può essere grave su un topic di comandi a basso volume. Avvisa sull'età del lag o sul tempo di recupero quando possibile, non solo sul conteggio grezzo dei record.

Testa i riavvii del broker durante le finestre di manutenzione prima del primo guasto reale. Un cluster Kafka di produzione dovrebbe sopravvivere a un riavvio pianificato del broker senza perdita di dati e senza sorprendere i client. Se un riavvio del broker crea un incidente importante, il cluster era già fragile.

Un Passaggio di Prontezza per la Produzione

Prima di dichiarare un cluster Kafka pronto per la produzione, controllerei questi elementi:

I topic critici hanno partizioni esplicite, fattore di replica, conservazione, politica di pulizia e min.insync.replicas.
I producer per topic critici utilizzano acks=all, idempotenza dove supportata, tentativi e gestione degli errori chiara.
I consumatori committano gli offset solo dopo che l'applicazione ha raggiunto il punto di elaborazione previsto.
TLS, autenticazione e ACL sono abilitati e testati.
La creazione automatica di topic è disabilitata o strettamente controllata.
Il monitoraggio copre la salute del broker, gli errori del client, il lag del consumatore, il disco e la replica.
Le aspettative di backup o riproduzione sono documentate. La conservazione di Kafka non è un sostituto per ogni esigenza di backup.
Le procedure di riavvio del broker, distribuzione del client e rotazione delle credenziali sono state testate.

Il Messaggio Pratico

La configurazione di produzione di Kafka è un insieme di compromessi, non una ricetta universale. Rendi esplicite le scelte di durabilità, ordinamento, riproduzione, sicurezza e latenza per topic e per applicazione. Quindi testa tali scelte con riavvii del broker, guasti del client, consumatori lenti e scenari di disco pieno prima che il traffico di produzione ti insegni la lezione.