Belajar Apache Kafka - Scaling Kafka Clusters

#Pendahuluan

Cluster Kafka yang sehat pada hari ini belum tentu sehat enam bulan lagi — traffic tumbuh, topic baru bermunculan, dan broker mulai mendekati batas disk atau CPU. Pertanyaannya bukan apakah perlu scaling, melainkan bagaimana melakukannya tanpa downtime dan tanpa mengganggu aplikasi.

Episode 20 ini akan membahas scaling horizontal dengan menambah broker, pemindahan partition dan replica lewat reassignment, dampak penambahan partition terhadap ordering dan consumer, capacity planning yang benar, serta Cruise Control untuk mengotomatiskan rebalancing dan mendeteksi anomali.

#Horizontal Scaling

#Menambah Broker

Menambah broker ke cluster di KRaft mode cukup mudah: siapkan node baru, format storage, dan mulai. Broker baru otomatis bergabung dan mulai menerima partition baru. Namun — penting untuk dipahami — broker baru tidak otomatis mengambil partition yang sudah ada; keseimbangan hanya tercapai setelah reassignment.

#Partition Reassignment

Pindahkan partition antar broker dengan kafka-reassign-partitions.sh:

bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
  --reassignment-json-file reassignment.json --execute

File reassignment.json berisi daftar partition beserta daftar broker tujuan:

{
  "version": 1,
  "partitions": [
    {"topic": "orders", "partition": 0, "replicas": [1, 2, 3]}
  ]
}

"replicas": [1, 2, 3] menentukan broker yang memegang replica. Proses reassignment menyalin data dulu (mirror), lalu memindahkan leadership — aman dan tanpa kehilangan data.

#Replica Reassignment dan Load Balancing

Reassignment juga dipakai untuk menyeimbangkan replica (bukan hanya leader) — misalnya memastikan dua replica topic tidak berada di broker yang sama (rack awareness). Setelah broker baru mengejar ketinggalan, jalankan preferred leader election agar beban leader tersebar merata, dan ulangi kafka-reassign-partitions.sh --verify untuk memastikan selesai.

#Partition Scaling

#Menambah Jumlah Partition

Kadang topic perlu partition tambahan karena consumer group membutuhkan paralelisme lebih besar. Gunakan --alter:

bin/kafka-topics.sh --bootstrap-server localhost:9092 \
  --alter --topic orders --partitions 12

kafka-topics.sh --alter --partitions 12 memperluas topic dari 6 ke 12 partition. Operasi ini hanya bisa menambah, tidak bisa mengurangi.

#Dampak terhadap Key dan Consumer

Menambah partition memiliki efek samping yang harus dipahami:

• Hash key berubah: murmur2(key) % numPartitions menghitung ulang tujuan key, sehingga record dengan key yang sama bisa pindah partition — ordering per key tidak dijamin utuh setelah perubahan ini.
• Consumer rebalance: jumlah partition berubah memicu rebalance consumer group; pastikan aplikasi siap.
• Data lama tidak dipindahkan; partition baru mulai kosong, menciptakan ketidakseimbangan sementara hingga di-reassign.

#Strategi yang Aman

Desain jumlah partition sejak awal dengan menyisakan ruang pertumbuhan, atau pertimbangkan partition key yang tetap stabil. Jika penambahan tak terhindarkan, lakukan saat beban rendah, komunikasikan ke tim consumer, dan pantau rebalance serta lag pasca perubahan.

#Capacity Planning

#Broker Count dan Replication Factor

Aturan umum: total throughput yang dibutuhkan dibagi throughput per broker, dikali faktor replikasi dan toleransi kegagalan. Dengan replication factor 3, kapasitas efektif sekitar sepertiga kapasitas disk total — karena setiap record tersimpan di tiga broker.

#Disk Sizing dan Network

Perhitungkan: throughput tulis per detik dikali retention time menentukan ukuran disk per partition. Dengan tiered storage (episode 11), disk lokal hanya menampung hot data. Jangan lupa bandwidth: replikasi dan recovery membutuhkan jaringan — saat satu broker mati, follower lain menyerap beban replikasi tambahan.

#Partition Count dan Consumer

Jumlah partition membatasi paralelisme consumer maksimum per group. Rencanakan partition = target consumer group × cadangan pertumbuhan. Terlalu sedikit partition membatasi throughput; terlalu banyak menambah beban metadata dan latensi rebalance.

#Cruise Control

#Pengenalan Cruise Control

Cruise Control adalah sistem open-source dari LinkedIn yang mengotomatiskan operasi cluster Kafka: rebalancing, partition movement, dan deteksi anomali. Ia memakai goal-based optimization: kalian mendefinisikan tujuan (misalnya distribusi leader merata, disk seimbang), dan Cruise Control menghitung serta mengeksekusi rencana reassignment terbaik.

#Fitur Utama

• Automated rebalancing: menjadwalkan pemindahan partition berdasarkan tujuan tanpa intervensi manual.
• Anomaly detection: mendeteksi broker yang tidak sehat, disk yang tidak seimbang, dan partition yang under-replicated.
• Self-healing: menangkap masalah dan menjalankan aksi perbaikan otomatis.
• Limit kustom: mengontrol kecepatan pemindahan data agar tidak mengganggu beban produksi.

#Penutup

Di episode 20 ini kalian sudah memahami scaling horizontal dengan menambah broker, partition dan replica reassignment, dampak penambahan partition terhadap key dan consumer, prinsip capacity planning, serta Cruise Control untuk rebalancing otomatis.

Inti yang harus dibawa pulang:

• Broker baru tidak otomatis menerima partition — reassignment diperlukan.
• kafka-reassign-partitions.sh memindahkan partition tanpa downtime.
• Menambah partition mengubah hasil hash key dan bisa memecah ordering.
• Capacity planning mencakup throughput, disk, network, dan replication factor.
• Jumlah partition membatasi paralelisme consumer maksimum.
• Cruise Control mengotomatiskan rebalancing dan mendeteksi anomali.

Di episode 21 selanjutnya kita akan mengoptimalkan performa: performance tuning and optimization. Kalian akan belajar tuning producer dan consumer, optimasi JVM dan OS untuk broker, serta konfigurasi topic untuk throughput dan latensi terbaik.