Uso di Apache Kafka

Broker di tuning

È possibile controllare il numero di partizioni in un argomento. L'aumento del numero di partizioni e del numero di broker in un cluster porta ad un aumento del parallelismo del consumo dei messaggi, che a sua volta migliora il throughput di un cluster Kafka. Tuttavia, aumenta anche il tempo necessario per replicare i dati tra i set di repliche.

Produttori tuning

È possibile eseguire un producer in due modalità diverse: sincrona e asincrona. In modalità sincrona, non appena viene pubblicato un messaggio, il produttore invia una richiesta al broker. Pertanto, se stai producendo 100 messaggi al secondo, il produttore invia 100 richieste al secondo al broker. Ciò riduce il throughput e funge da operazione di blocco. Quindi, quando si pubblica un numero elevato di messaggi, è meglio eseguire i produttori in modalità asincrona.

In modalità asincrona, è necessario eseguire il tuning di due parametri per ottenere le migliori prestazioni: batch.size e linger.ms (tempo di latenza). La dimensione del batch è la dimensione dei dati da inviare in un batch, misurata in byte. Ad esempio, se si imposta la dimensione batch su 100, il producer attende che i messaggi aggiungano fino a 100 byte prima di effettuare una chiamata al broker. Se la produzione dei messaggi è bassa e si imposta una dimensione batch elevata, il producer attende molto tempo prima di produrre i messaggi. Ciò riduce il throughput e aumenta la latenza di consegna dei messaggi. Pertanto, a seconda del numero di messaggi prodotti, questo valore deve essere ottimizzato. La dimensione batch predefinita è 16.384.

Linger time è un'altra metrica basata su quando un produttore decide di inviare una richiesta a un broker. Utilizzando l'esempio precedente, se la dimensione del batch è impostata su 100 byte e si stanno producendo solo 50 byte al secondo, il producer deve attendere due secondi prima di pubblicare tali messaggi. Per evitare questo ritardo, è possibile regolare il tempo di permanenza (misurato in millisecondi) per garantire che il produttore non aspetti troppo tempo prima di inviare i messaggi. L'impostazione del tempo di permanenza a 500 ms in questo esempio fa attendere al massimo mezzo secondo al produttore.

La compressione può anche migliorare la latenza. Per impostazione predefinita, i messaggi Kafka non vengono compressi, ma è possibile configurare i producer in modo che vengano compressi. I broker e i consumatori hanno quindi il sovraccarico aggiuntivo di decomprimere i messaggi, ma la latenza complessiva dovrebbe essere ridotta in quanto la dimensione fisica dei dati trasmessi sulla rete è più piccola.

Ottimizzazione dei consumatori

I consumer ricevono messaggi in batch, in modo simile alla modalità di pubblicazione dei producer in batch. Se tiri molti messaggi e prendi molto tempo per elaborarli, il throughput ne risente. Allo stesso modo, se esegui il polling del broker per un singolo messaggio ogni volta, il numero di richieste al broker potrebbe diminuire il throughput.

Avere più partizioni e consumatori all'interno di un gruppo di consumer può contribuire a migliorare il throughput. Ma ricorda che con l'aumentare del numero di consumatori, aumenta anche il numero di richieste di commit offset al broker. Poiché il commit di un offset consiste nell'invio di un messaggio Kafka a un argomento interno, ciò aumenta indirettamente il carico sul broker. Pertanto, avere un numero ottimale di consumatori è fondamentale.

MirrorMaker Ottimizzazione delle prestazioni

Kafka MirrorMaker è uno strumento utilizzato per eseguire il mirroring dei messaggi Kafka da un data center o da un cluster a un altro. Poiché questo sta producendo internamente messaggi a Kafka, la maggior parte delle tecniche di ottimizzazione già discusse sono vere anche qui. Poiché questo comporta anche la trasmissione di messaggi su lunghe distanze, sono disponibili alcuni parametri di configurazione che possono essere ottimizzati per prestazioni migliori.

• MirrorMaker2 Posizione: MirrorMaker può essere installato nell'origine o nella destinazione. Tuttavia, si consiglia di installare a destinazione perché la produzione di messaggi su lunghe distanze aumenta le possibilità di perdere dati durante la trasmissione.
• Compressione: per impostazione predefinita, la compressione dei messaggi nei producer Kafka è impostata su Nessuna. Tuttavia, per comprimere i messaggi che escono dall'origine alla destinazione, modificare la compressione in gzip. Questo, aiuta con dimensioni batch più grandi.
• Dimensione batch: l'aumento della dimensione batch dei messaggi aumenta il throughput. La combinazione di questo con la compressione assicura che un gran numero di messaggi vengono trasmessi rapidamente. Se la dimensione del batch di destinazione richiede più tempo del tempo di permanenza configurato, i batch inviati non vengono completamente riempiti. Ciò riduce l'efficienza di compressione e spreca la larghezza di banda. Pertanto, è importante ottimizzare le dimensioni del batch insieme a consentire la compressione e il tuning.
• Linger Time: aumentare il tempo di permanenza per consentire il riempimento completo dei lotti è importante. Ciò potrebbe aumentare la latenza, ma il throughput complessivo migliora. È necessario considerare l'importanza della latenza per il caso d'uso aziendale.
• Aumenta parallelismo: per aumentare ulteriormente il throughput, è possibile distribuire più istanze di MirrorMaker nello stesso gruppo di consumer. Ciò facilita la ricezione di più consumer MirrorMaker dalla stessa origine e la produzione alla destinazione in parallelo.

Configurazioni server di produzione nel tuning Kafka

È possibile eseguire il tuning di diversi altri parametri di configurazione per migliorare le prestazioni di Kafka in un ambiente di produzione. I parametri riportati di seguito migliorano le prestazioni di replica dei messaggi all'interno delle partizioni.

• num.replica.fetchers: specifica il numero di thread utilizzati per replicare i messaggi dal leader ai follower. Un numero maggiore di fetcher di replica migliora il parallelismo nella replica.
• replica.fetch.max.bytes: indica il numero di byte di dati da recuperare dal leader. Un numero maggiore indica un chunk più grande di dati recuperati, migliorando il throughput della replica.
• num.partitions: specifica il numero massimo di consumer che un argomento può avere in un gruppo di utenti specifico, che è uguale al numero di partizioni disponibili in tale argomento. Aumentare le partizioni aumenta il parallelismo e quindi il throughput. Tuttavia, molte partizioni consumano anche più risorse, quindi è necessario eseguire lo scale up anche delle risorse.

Bilanciamento dei cluster Apache Kafka

Ogni volta che un nuovo broker viene aggiunto a un cluster Kafka, le partizioni esistenti non vengono distribuite tramite il nuovo broker. Ciò significa che il nuovo broker non è occupato e se uno o più vecchi broker scendono, la replica e i potenziali leader vengono ridotti. Questo è noto come leader distorsione. Puoi evitare questo facendo in modo che qualsiasi broker appena aggiunto ottenga una quota delle partizioni. Il ribilanciamento del cluster è importante. Allo stesso modo, se un broker ha più del numero medio di partizioni per un argomento, noto come deviazione del broker, può portare a problemi di prestazioni.

Ottimizzazione delle prestazioni di Kafka

Quando si esegue Kafka come cluster, esistono diversi modi per ottimizzarne le prestazioni. È possibile ottimizzare vari parametri di configurazione per trovare un equilibrio tra throughput e latenza. L'ingegneria è impegnata a calcolare i valori migliori per alcuni di questi parametri, come il tempo di permanenza, la dimensione del batch, il numero di partizioni e così via. A seconda del caso d'uso, è possibile decidere che il throughput sia più importante della latenza, che la latenza sia più importante del throughput o che sia preferibile un equilibrio tra i due.