Belajar Apache Kafka - Performance Tuning & Optimization

#Pendahuluan

Kafka mampu menangani jutaan record per detik, tetapi performa itu tidak muncul otomatis — ia adalah hasil dari konfigurasi yang disesuaikan dengan workload. Broker, producer, consumer, dan topic masing-masing punya parameter yang saling memengaruhi, dan perubahan di satu sisi sering berdampak di sisi lain.

Episode 21 ini akan membahas tuning dari empat sudut: producer, consumer, broker (termasuk JVM dan OS), serta konfigurasi topic. Kalian akan memahami trade-off throughput versus latensi dan cara menyetel parameter yang paling berdampak untuk workload kalian.

#Optimasi Producer

#Batching dan Compression

Parameter paling berpengaruh pada throughput producer:

batch.size=131072
linger.ms=20
compression.type=zstd
acks=all

batch.size=131072 memperbesar ukuran batch menjadi 128KB dan linger.ms=20 menahan record 20ms untuk menggabungkan tulis — ini meningkatkan throughput secara dramatis. compression.type=zstd mengurangi byte yang dikirim: zstd memberi rasio terbaik, snappy dan lz4 menawarkan keseimbangan CPU.

#Acks dan In-Flight

acks=all memberi durability terbaik; trade-off-nya menunggu konfirmasi semua ISR. max.in.flight.requests.per.connection mengatur berapa banyak request yang dikirim tanpa menunggu — dengan idempotence aktif, nilai 5 aman tanpa reordering. Untuk latensi terendah, linger.ms=0 dan batch kecil, tetapi throughput turun.

#Optimasi Consumer

#Fetch Size dan Poll Interval

Consumer yang lambat sering bukan karena kode, melainkan konfigurasi fetch yang kecil:

fetch.min.bytes=1048576
fetch.max.wait.ms=500
max.poll.records=500

fetch.min.bytes=1048576 membuat broker menunggu hingga 1MB terkumpul sebelum merespons — mengurangi jumlah round-trip dan menaikkan throughput. max.poll.records membatasi jumlah record per poll agar pemrosesan tidak melebihi max.poll.interval.ms.

#Partition Assignment Strategy

Strategi assignment menentukan bagaimana partition dibagi antar consumer:

• RangeAssignor: default, pembagian per topic — dapat menciptakan ketidakseimbangan antar topic.
• RoundRobinAssignor: memutar partition secara merata lintas topic.
• StickyAssignor: menjaga assignment lama selama mungkin agar stabil saat rebalance.
• CooperativeStickyAssignor: mendukung rebalancing inkremental (episode 6) untuk cluster besar.

Pilih CooperativeStickyAssignor untuk rebalance yang lebih mulus pada consumer group besar.

#Optimasi Broker

#Tuning JVM

Broker adalah aplikasi JVM. Dua hal yang paling berdampak:

• Heap size: cukup untuk metadata dan buffer, biasanya 4-6GB; jangan terlalu besar karena Kafka sangat bergantung pada page cache OS, bukan heap.
• Garbage collector: G1GC default sudah baik; hindari GC pause panjang dengan memantau kafka.server:type=KafkaRequestHandlerPool. Pastikan data baca melalui page cache, bukan heap.

#OS-Level Tuning

sysctl -w vm.swappiness=1
sysctl -w vm.dirty_ratio=60
sysctl -w vm.dirty_background_ratio=5
sysctl -w net.core.wmem_max=209715200
sysctl -w net.core.rmem_max=209715200

vm.swappiness=1 mengurangi penggunaan swap yang bisa menyebabkan GC pause besar, dan net.core.wmem_max memperbesar buffer soket jaringan. File descriptor limit (ulimit -n) harus cukup tinggi karena setiap koneksi klien memakai satu fd.

#Disk dan Page Cache

Kafka menulis sekuensial, jadi:

• Pakai disk SSD/NVMe untuk tulis; page cache menangani mayoritas baca.
• Jangan menempatkan data log dan OS pada disk yang sama.
• Page cache adalah aset terbesar Kafka: data yang sering dibaca disimpan otomatis di RAM oleh OS, dan zero-copy membuat transfer ke jaringan tanpa menyalin data lewat user space. Semakin besar RAM, semakin banyak data panas yang ditampung page cache.

#Konfigurasi Topic

#Segment dan Retention

segment.bytes=1073741824
segment.ms=604800000
retention.ms=604800000
log.flush.interval.messages=100000

segment.bytes=1073741824 (1GB) mengurangi jumlah segmen kecil yang memperbanyak operasi index; log.flush.interval.messages menunda flush ke disk — dengan replikasi sebagai jaminan durability, flush jarang justru mempercepat tulis.

#Compression dan Message Format

Pastikan message.format.version sejajar dengan versi broker untuk performa terbaik. Compression codec konsisten antara producer dan broker menghindari re-compress yang membuang CPU. Pemantauan terus-menerus diperlukan: tuning yang benar di satu workload belum tentu benar di workload lain.

#Penutup

Di episode 21 ini kalian sudah memahami tuning producer dengan batching, compression, dan acks, tuning consumer dengan fetch size dan assignment strategy, optimasi broker pada JVM, OS, dan page cache, serta konfigurasi topic untuk throughput dan latensi.

Inti yang harus dibawa pulang:

• Batching dengan batch.size dan linger.ms adalah pengungkit throughput terbesar.
• Page cache dan zero-copy adalah alasan Kafka sangat cepat dalam membaca.
• Heap JVM dijaga kecil; RAM besar dipakai untuk page cache.
• CooperativeStickyAssignor menstabilkan rebalance pada group besar.
• Segment dan retention diatur sejalan dengan pola akses data.
• Selalu ukur baseline sebelum dan sesudah tuning.

Di episode 22 selanjutnya kita akan memantau cluster: monitoring dan observability. Kalian akan belajar metrik JMX, metrik kunci seperti under-replicated partition dan consumer lag, integrasi Prometheus dan Grafana, serta tool seperti Burrow untuk monitoring lag.