Ottimizzazione delle Partizioni Kafka per Scalabilità e Throughput

Il numero di partizioni Kafka è una di quelle impostazioni che sembra semplice finché non devi conviverci. Troppe poche partizioni e i consumatori non possono scalare. Troppe e i broker passano più tempo a gestire i metadati, i ribilanciamenti richiedono più tempo e il rumore operativo aumenta.

Non esiste un numero migliore universale. Un topic di pagamenti, un topic di clickstream e un topic compattato sullo stato dei clienti hanno diverse esigenze di ordinamento, dimensioni dei messaggi, impostazioni di conservazione e comportamento dei consumatori. La domanda utile non è "Quante partizioni sono migliori?" È "Di quante partizioni abbiamo bisogno per il throughput, l'ordinamento e la crescita di questo topic senza creare overhead inutile per il broker?"

Comprendere le Partizioni Kafka

Alla base, un topic Kafka è diviso in una o più partizioni. Ogni partizione è un log ordinato di sola aggiunta. Le partizioni sono l'unità di parallelismo in Kafka:

I produttori scrivono nelle partizioni: Un produttore può scegliere direttamente una partizione, usare una chiave o lasciare che il partizionatore distribuisca i record.
I consumatori leggono dalle partizioni: A ogni consumatore in un gruppo di consumatori viene assegnata una o più partizioni da leggere in esclusiva. Ciò garantisce che i messaggi all'interno di una partizione vengano elaborati in ordine da una singola istanza del consumatore all'interno di quel gruppo.
I broker ospitano le partizioni: I broker Kafka memorizzano leader e repliche. Un topic con più partizioni può distribuire l'archiviazione e il traffico tra i broker.

Caratteristiche Chiave delle Partizioni:

Ordinate all'interno di una partizione: I messaggi all'interno di una singola partizione sono sempre ordinati. I consumatori all'interno di un gruppo mantengono questo ordine.
Non ordinate tra le partizioni: Non esiste un ordine garantito dei messaggi tra diverse partizioni dello stesso topic.
Parallelismo: In un gruppo di consumatori, il numero utile di consumatori attivi per un topic non può superare il numero di partizioni. I consumatori extra rimangono inattivi per quel topic.

Fattori che Influenzano il Numero di Partizioni

Diversi fattori critici dovrebbero essere valutati quando si decide il numero di partizioni per un topic Kafka:

1. Requisiti di Throughput (Produttori e Consumatori)

Throughput del produttore: Più partizioni possono distribuire le scritture tra i broker, ma solo se i leader sono bilanciati e i produttori distribuiscono bene i record. Un topic con chiave e una chiave calda può ancora sovraccaricare una partizione.
Throughput del consumatore: Se un singolo consumatore può elaborare 2.000 messaggi al secondo e il topic raggiunge un picco di 20.000 messaggi al secondo, hai bisogno di abbastanza partizioni per eseguire abbastanza consumatori nel gruppo. Il numero esatto dipende dalla velocità misurata del consumatore, non da supposizioni.

2. Obiettivi di Scalabilità

Crescita futura: Kafka ti consente di aumentare le partizioni, ma ridurre il numero di partizioni non è un'operazione normale in loco. Di solito crei un nuovo topic e migri.
Ribilanciamento: L'aggiunta di partizioni può innescare ribilanciamenti del gruppo di consumatori. Con consumatori occupati, ciò può temporaneamente rallentare o mettere in pausa l'elaborazione.
Comportamento delle chiavi: L'aumento delle partizioni modifica la mappatura chiave-partizione per molti produttori che utilizzano il comportamento di partizionamento predefinito. Ciò può sorprendere i sistemi che presumevano che una chiave rimanesse sempre sulla stessa partizione nel tempo.

3. Risorse del Broker

Disco: Più partizioni significano più segmenti di log e più file da gestire, specialmente con la replica.
Rete: La replica e i fetch dei consumatori aggiungono traffico. Il problema non è solo il numero di topic, ma le repliche, la conservazione, la dimensione dei messaggi e il fan-out dei consumatori.
CPU e memoria: Broker, controller e client pagano tutti un certo overhead per un numero elevato di partizioni. Le versioni moderne di Kafka gestiscono cluster grandi meglio di quelle più vecchie, ma il numero di partizioni è ancora un lavoro di pianificazione della capacità.

4. Requisiti di Ordinamento dei Messaggi

Ordinamento basato su chiave: Se l'ordinamento è critico e usi una chiave del messaggio, i record con la stessa chiave vanno tipicamente nella stessa partizione. Ciò fornisce un ordine per chiave, non un ordine a livello di topic. Una chiave calda finisce comunque su una partizione e può creare un collo di bottiglia per un consumatore.
Nessun ordinamento rigoroso: Se l'ordinamento rigoroso dei messaggi non è un requisito, puoi distribuire i messaggi più liberamente tra le partizioni, dando priorità a throughput e parallelismo.

5. Scalabilità del Gruppo di Consumatori

Come accennato, il numero di partizioni determina il numero massimo di consumatori che possono leggere contemporaneamente da un topic all'interno di un gruppo di consumatori. Se devi scalare il tuo consumo aggiungendo più istanze di consumatori, devi avere almeno tante partizioni quante sono le istanze di consumatori desiderate.

Un Modo Pratico per Scegliere un Numero di Partizioni

Ecco alcune strategie pratiche per aiutarti a raggiungere un numero ottimale di partizioni:

1. Inizia con una Baseline e Monitora

Una baseline utile inizia con il parallelismo dei consumatori. Se prevedi quattro istanze di consumatori per questo topic, iniziare con più di quattro partizioni dà spazio per ribilanciare e crescere.

Esempio: se prevedi di eseguire quattro consumatori, potresti iniziare con otto partizioni. Ciò consente a ciascun consumatore di possedere due partizioni e puoi aggiungere qualche altro consumatore prima di ripartizionare. Questo è un punto di partenza, non una legge.

Monitora continuamente il tuo cluster Kafka e il lag dei consumatori. Se osservi un lag elevato dei consumatori che non può essere risolto aggiungendo più istanze di consumatori (perché hai raggiunto il limite di partizioni), è un chiaro indicatore che devi aumentare il numero di partizioni.

2. Calcola in Base al Throughput Previsto

Puoi stimare le partizioni richieste dal throughput misurato:

Formula: Numero di Partizioni = (Throughput Totale Previsto / Throughput per Istanza di Consumatore) * Buffer
- Throughput totale previsto: Usa il tasso di produzione di picco, non la media giornaliera.
- Throughput per istanza di consumatore: Misura il tuo consumatore reale con dimensioni reali dei messaggi e chiamate a valle.
- Buffer: Aggiungi margine per picchi e crescita. Evita di fingere che il calcolo sia esatto.

Esempio:

Throughput di picco previsto: 50.000 messaggi al secondo
Throughput di una singola istanza di consumatore: 5.000 messaggi al secondo
Buffer: 1,5x
(50.000 / 5.000) * 1,5 = 15

In questo caso, 16 partizioni è un punto di partenza ragionevole e arrotondato. Se l'ordinamento, la capacità del broker o la distribuzione delle chiavi spingono contro questo numero, regolalo.

3. Considera le Capacità e i Limiti del Broker

Fai attenzione al numero totale di partizioni nel cluster. Non esiste un numero sicuro di partizioni per broker che si applichi ovunque. Hardware, versione di Kafka, fattore di replica, conservazione, dimensione dei messaggi, carico del controller e obiettivi di recupero in caso di guasto contano tutti.

Invece di trattare "100 partizioni per broker" o "1.000 partizioni per broker" come verità universali, monitora le metriche del broker: latenza delle richieste, I/O del disco, salute del controller, partizioni sottoreplicate, pressione della cache di pagina e durata del ribilanciamento. Usa i limiti testati della tua piattaforma se la tua organizzazione li ha.

4. Distribuzione delle Chiavi e Partizioni Calde

Se usi chiavi dei messaggi, analizza la distribuzione delle chiavi prima di decidere che "più partizioni" risolveranno il throughput. Poche chiavi dominanti possono creare partizioni calde. Il broker che ospita il leader lavora di più e il consumatore assegnato a quella partizione resta indietro.

Soluzione: Se prevedi partizioni calde, considera strategie come:
- Usa una chiave meno sbilanciata quando l'ordinamento aziendale lo consente.
- Usa una chiave composita, come customer_id:event_type, se preserva l'ordinamento di cui hai bisogno.
- Dividi un flusso di lavoro caldo in un topic separato.
- Sharda deliberatamente una chiave calda, quindi gestisci l'ordinamento a un ambito più ristretto.

Aumentare le partizioni può aiutare con un'ampia distribuzione. Non divide una chiave tra i consumatori se tutti i record per quella chiave devono rimanere ordinati.

Creazione e Modifica dei Topic con Partizioni

Quando crei un nuovo topic, specifichi il numero di partizioni.

Creazione di un Topic con un Numero Specifico di Partizioni

Usando lo script kafka-topics.sh:

kafka-topics.sh --create --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092,kafka-broker-2:9092 \
  --partitions 16 \
  --replication-factor 3

--partitions 16: Imposta il topic con 16 partizioni.
--replication-factor 3: Ogni partizione avrà 3 repliche su broker diversi per la tolleranza ai guasti.

Aumentare le Partizioni su un Topic Esistente

Questa è un'operazione comune, ma ha implicazioni. Kafka ti consente di aumentare il numero di partizioni per un topic. Diminuire richiede una migrazione verso un altro topic.

Usando lo script kafka-topics.sh:

kafka-topics.sh --alter --topic my-high-throughput-topic \
  --bootstrap-server kafka-broker-1:9092 \
  --partitions 24

--partitions 24: Aumenta le partizioni per my-high-throughput-topic a 24.

Considerazioni Importanti quando si Modificano le Partizioni:

Ribilanciamento del consumatore: L'aumento delle partizioni può innescare ribilanciamenti per i gruppi di consumatori iscritti. Ciò può temporaneamente mettere in pausa o rallentare il consumo.
Nuove Partizioni: Le nuove partizioni vengono aggiunte al topic. I messaggi esistenti non vengono ripartizionati.
Mappatura delle chiavi: Per i produttori con chiave, l'aggiunta di partizioni può cambiare dove vengono scritti i record futuri per una chiave.
Risorse del broker: Assicurati che i broker abbiano capacità per i leader e le repliche aggiuntivi.

Se l'ordine delle chiavi su tutta la cronologia è importante, fai attenzione. I record esistenti rimangono nelle vecchie partizioni, mentre i nuovi record potrebbero mapparsi diversamente dopo la modifica del numero di partizioni.

Metriche che Indicano che il Numero di Partizioni è Sbagliato

Il lag del consumatore è il segnale ovvio, ma non è sufficiente da solo. Il lag può derivare da database a valle lenti, codice del consumatore scadente, impostazioni di fetch piccole, sovraccarico del broker o troppo poche partizioni.

Cerca questi schemi:

I consumatori sono sani, ma alcune istanze sono inattive perché ci sono meno partizioni di consumatori.
Una partizione ha un lag molto più alto delle altre.
Un broker porta molti leader di partizioni calde.
La latenza del produttore aumenta durante il traffico di picco anche se il cluster ha broker di riserva.
I ribilanciamenti richiedono abbastanza tempo da influenzare gli obiettivi di livello di servizio.

Per i gruppi di consumatori:

kafka-consumer-groups.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --group my-consumer-group

Per la disposizione del topic:

kafka-topics.sh --bootstrap-server kafka-broker-1:9092 \
  --describe --topic my-high-throughput-topic

Se solo una partizione è in ritardo, aggiungere consumatori non aiuterà a meno che il lavoro non possa essere distribuito su più partizioni.

Best Practice e Insidie

Fai:

Inizia con esigenze misurate: Usa il numero previsto di consumatori, test di throughput e capacità del broker.
Allineati con il parallelismo dei consumatori: Assicurati di avere abbastanza partizioni per scalare efficacemente le tue istanze di consumatori.
Lascia spazio per la crescita: Aggiungere partizioni in seguito è possibile, ma non senza conseguenze.
Comprendi la distribuzione delle chiavi: Se usi chiavi, analizza la loro distribuzione per evitare partizioni calde.
Sfrutta gli strumenti di monitoraggio Kafka: Usa strumenti per tracciare le metriche di topic/partizioni, il lag dei consumatori e il carico del broker.

Non fare:

Sovra-partizionare: Troppe partizioni aumentano l'overhead, possono rallentare i ribilanciamenti e possono rendere il recupero in caso di guasto più rumoroso.
Sotto-partizionare: Limita la scalabilità e il throughput, portando al lag dei consumatori.
Seguire ciecamente numeri arbitrari: Usa le regole pratiche solo come punti di partenza.
Dimenticare la capacità del broker: Assicurati che i tuoi broker possano gestire il numero totale di partizioni su tutti i topic.
Aspettarsi un ordinamento perfetto tra le partizioni: Ricorda che l'ordinamento è garantito solo all'interno di una partizione.

Un Processo Decisionale Ragionevole

Per un nuovo topic, di solito lavoro in questo ordine:

Definisci il requisito di ordinamento. Per cliente? Per account? Nessun ordine rigoroso?
Misura o stima il throughput di picco del produttore e la dimensione del messaggio.
Benchmarka un'istanza di consumatore con dipendenze a valle realistiche.
Scegli le partizioni in base al parallelismo dei consumatori necessario più il margine di crescita.
Controlla l'impatto totale sul cluster dopo aver incluso il fattore di replica.
Monitora il lag per partizione e il carico del broker dopo il lancio.

Il numero di partizioni non è un concorso di bellezza. Un topic banale con otto partizioni ben utilizzate è meglio di un topic con 96 partizioni per lo più inattive che rallenta ogni ribilanciamento. Scegli il numero più piccolo che ti dà il parallelismo e lo spazio di crescita di cui hai effettivamente bisogno.