Dasar kapasitas

Perhitungan diska, jaringan, dan bandwidth partisi untuk perencanaan kapasitas cluster.

Daftar isi

Perencanaan kapasitas menentukan seberapa besar diska, jaringan, dan jumlah partisi yang disiapkan sebelum cluster Kafka menerima beban nyata. Topik ini membahas perhitungan kebutuhan diska dari throughput, retensi, dan replication factor, perhitungan bandwidth jaringan dari jumlah consumer group, serta hubungan jumlah partisi dengan bandwidth per partisi. Seluruh perhitungan menggunakan angka contoh yang tetap sehingga dapat dihitung ulang, dan hasilnya disusun menjadi tabel simulasi untuk tiga skenario. Setelah membaca topik ini, kebutuhan sumber daya sebuah topic dapat dihitung dan dibandingkan dengan pengukuran pada cluster yang sudah berjalan.

Masukan perencanaan kapasitas#

Empat masukan menentukan hasil perencanaan, yaitu throughput produksi, retensi, replication factor, dan overhead. Throughput produksi adalah laju byte yang ditulis producer ke topic per detik, dinyatakan dalam MB per detik, dan nilainya diambil dari pengukuran metrik BytesInPerSec atau dari perkiraan beban aplikasi. Retensi menyatakan lama log disimpan sebelum dibuang, yang diatur lewat retention.ms dan retention.bytes per topic serta log.retention.hours pada broker. Replication factor menyatakan jumlah salinan setiap partisi di cluster dan berfungsi ganda, yaitu menaikkan keandalan sekaligus menggandakan kebutuhan diska dan trafik jaringan.

Overhead mencakup bagian log yang tidak terhitung sebagai isi pesan, misalnya berkas indeks .index dan .timeindex, metadata batch, serta ruang kosong pada segmen terakhir yang sedang ditulis. Overhead dinyatakan sebagai fraksi, dan nilai antara 0,05 dan 0,15 adalah titik awal yang lazim sebelum data pengukuran tersedia. Empat masukan ini cukup untuk menghitung kebutuhan diska dan jaringan pada tingkat cluster, sedangkan pengukuran ulang setelah topic berjalan menutup selisih antara perkiraan dan kenyataan.

Rumus kebutuhan diska#

Kebutuhan diska sebuah topic dihitung dengan melipatgandakan laju produksi terhadap waktu simpan, jumlah salinan, dan overhead. Apabila laju produksi dinyatakan $P$ dalam MB per detik, retensi dinyatakan $R$ dalam hari, replication factor dinyatakan $F$ , dan overhead dinyatakan $o$ sebagai fraksi, kebutuhan diska $D$ dalam MB mengikuti

D = P \times S \times R \times F \times (1 + o)

Nilai $S$ adalah jumlah detik dalam satu hari, yaitu 86.400, dan hasil pembagian terhadap 1.024 mengubah satuan MB menjadi GB pada konvensi 1 GB = 1.024 MB. Kebutuhan per broker diperoleh dengan membagi hasilnya dengan jumlah broker, dengan asumsi sebaran salinan di antara broker merata.

Angka $P$ diambil dari laju byte yang benar-benar dikirim producer, bukan ukuran data sebelum kompresi, karena broker menyimpan batch sebagaimana diterima sehingga kompresi sisi producer sudah terhitung. Retensi berbasis ukuran lewat retention.bytes bekerja dari sisi berlawanan, yaitu log dibuang ketika ukurannya melampaui batas, sehingga rumus menaksir batas mana yang tercapai lebih dahulu.

Rumus bandwidth jaringan#

Bandwidth jaringan muncul dari tiga arus, yaitu tulisan producer, salinan antar broker, dan pembacaan consumer. Tulisan masuk sebesar $P$ karena setiap byte yang diproduksi dikirim satu kali ke cluster, sedangkan salinan antar broker menambah $(F - 1) \times P$ karena setiap salinan tambahan mengikuti log leader. Bandwidth pembacaan total dinyatakan $C$ dan dihitung dari jumlah consumer group yang membaca topic secara penuh,

C = P \times G

dengan $G$ menyatakan jumlah consumer group tersebut. Setiap group membaca seluruh log secara independen, sehingga pembacaan berlipat seiring jumlah group, bukan jumlah consumer dalam satu group.

Nilai per broker diperoleh dengan membagi $D$ , $(F - 1) \times P$ , dan $C$ dengan jumlah broker bila sebarannya merata. Angka ini menjadi dasar pemilihan kapasitas antarmuka jaringan, sedangkan metrik BytesOutPerSec dan ReplicationBytesOutPerSec menyediakan angka nyata untuk memverifikasinya.

Perhitungan dengan skrip Python#

Skrip berikut menerapkan rumus diska dan bandwidth dengan angka masukan tetap, yaitu topic dengan laju produksi 10 MB per detik, retensi tujuh hari, replication factor 3, overhead 0,10, tiga broker, dan dua consumer group. Konstanta DETIK_PER_HARI dan MB_PER_GB di bagian atas mengikat konversi satuan yang digunakan rumus, sedangkan kelima baris print menyusun laporan dengan satuan yang sama dengan perhitungan manual. Karena seluruh masukan ditetapkan, keluarannya identik pada setiap eksekusi dan dapat dihitung ulang secara manual.

python hitung-kapasitas.py

# Perhitungan kapasitas dasar dengan angka masukan tetap,
# sehingga setiap hasil dapat dihitung ulang oleh pembaca.

throughput = 10.0     # laju produksi, MB per detik
retensi = 7           # lama simpan log, hari
replikasi = 3         # replication factor
overhead = 0.10       # fraksi overhead indeks dan metadata batch
broker = 3            # jumlah broker
grup = 2              # jumlah consumer group yang membaca topic penuh

DETIK_PER_HARI = 86_400
MB_PER_GB = 1024

diska_mb = throughput * DETIK_PER_HARI * retensi * replikasi * (1 + overhead)
diska_gb = diska_mb / MB_PER_GB
konsumsi = throughput * grup
per_broker_d = diska_gb / broker
per_broker_c = konsumsi / broker
trafik_replikasi = throughput * (replikasi - 1)

print(f"Diska topic dengan replikasi  : {diska_gb:,.1f} GB")
print(f"Diska per broker              : {per_broker_d:,.1f} GB")
print(f"Bandwidth konsumsi total      : {konsumsi:.1f} MB per detik")
print(f"Bandwidth konsumsi per broker : {per_broker_c:.1f} MB per detik")
print(f"Trafik replikasi antar broker : {trafik_replikasi:.1f} MB per detik")

text Keluaran

Diska topic dengan replikasi  : 19,490.6 GB
Diska per broker              : 6,496.9 GB
Bandwidth konsumsi total      : 20.0 MB per detik
Bandwidth konsumsi per broker : 6.7 MB per detik
Trafik replikasi antar broker : 20.0 MB per detik

Hasil perhitungan menunjukkan topic tersebut memerlukan sekitar 19.490 GB diska yang tersebar menjadi sekitar 6.497 GB per broker, dengan pembacaan 20 MB per detik yang terbagi sekitar 6,7 MB per detik ke setiap broker. Trafik replikasi sebesar dua kali laju produksi mencerminkan replication factor 3, karena setiap pesan disalin ke dua follower. Nilai-nilai ini berupa pembulatan karena overhead baru diketahui persis setelah log terbentuk, sehingga hasil akhirnya dikalibrasi dengan ukuran direktori log yang nyata.

Simulasi tiga skenario#

Tabel berikut menerapkan rumus yang sama pada tiga skenario, dan semuanya menggunakan overhead 0,10 serta konvensi 1 GB = 1.024 MB. Skenario A menggambarkan topic arsip kecil dengan satu group pembaca, skenario B menggambarkan topic pemantauan dengan replication factor 3 dan dua group, sedangkan skenario C menggambarkan topic kejadian utama dengan laju tinggi dan retensi dua minggu.

Skenario	Throughput (MB/detik)	Retensi (hari)	Replication factor	Group	Diska total (GB)	Konsumsi (MB/detik)
A	1	3	2	1	556,9	1
B	5	7	3	2	9.745,3	10
C	20	14	3	3	77.962,5	60

Diska tumbuh linear terhadap setiap masukan, sehingga skenario C menambah sekitar 5.570 GB per hari setelah replikasi, dengan retensi dua minggu sebagai penentu utama. Perbandingan A dan B memperlihatkan efek gabungan, karena diska B 17,5 kali diska A meskipun throughputnya hanya lima kali. Konsumsi C mencapai 60 MB per detik dengan tiga group, angka yang sudah mendekati kapasitas antarmuka jaringan broker kelas menengah.

Jumlah partisi dan bandwidth per partisi#

Rumus-rumus sebelumnya menghitung kebutuhan total, sedangkan jumlah partisi menentukan cara kebutuhan itu terbagi ke dalam kapasitas per partisi. Setiap partisi menulis ke satu berkas log pada broker, sehingga bandwidth tulis per partisi dibatasi kecepatan penyimpanan yang melayaninya. Apabila bandwidth tulis satu partisi dinyatakan $w$ , bandwidth baca satu partisi dinyatakan $r$ , dan jumlah partisi dinyatakan $n$ , nilai $n$ minimal mengikuti

n \geq \max\left(\left\lceil \frac{P}{w} \right\rceil, \left\lceil \frac{C}{r} \right\rceil\right)

yaitu nilai terbesar dari batas penulisan dan batas pembacaan. Nilai $w$ dan $r$ adalah perkiraan awal dari pengukuran karena kapasitasnya bergantung pada jenis diska dan jumlah fetcher replika.

Struktur partisi dapat dibaca langsung dari cluster. Blok berikut membuat topic tetap m7-kapasitas-demo dengan empat partisi baru, yaitu dihapus lalu dibuat kembali, sehingga jumlah baris deskripsi selalu sama pada setiap eksekusi.

bash

(
  cd /home/kal/my-project/kafka-runtime/kafka
  bin/kafka-topics.sh --bootstrap-server localhost:9092 --delete --if-exists --topic m7-kapasitas-demo 2>/dev/null
  sleep 2
  bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic m7-kapasitas-demo --partitions 4
  bin/kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic m7-kapasitas-demo | grep "Partition:" | expand
)

text Keluaran

Created topic m7-kapasitas-demo.
        Topic: m7-kapasitas-demo        Partition: 0    Leader: 1       Replicas: 1     Isr: 1  Elr:    LastKnownElr: 
        Topic: m7-kapasitas-demo        Partition: 1    Leader: 1       Replicas: 1     Isr: 1  Elr:    LastKnownElr: 
        Topic: m7-kapasitas-demo        Partition: 2    Leader: 1       Replicas: 1     Isr: 1  Elr:    LastKnownElr: 
        Topic: m7-kapasitas-demo        Partition: 3    Leader: 1       Replicas: 1     Isr: 1  Elr:    LastKnownElr:

Keluaran memuat satu baris per partisi, dan setiap baris menyebut Leader: 1 serta Isr: 1 karena demo berjalan pada satu broker. Pada cluster multi-broker, baris yang sama memperlihatkan sebaran salinan antar broker. Empat partisi berarti empat alur tulis serentak, angka yang dicocokkan dengan hasil pembagian $P$ dengan $w$ dan $C$ dengan $r$ .

Garis panduan perencanaan#

Perhitungan menghasilkan titik awal, sedangkan keputusan akhir mengikuti pengukuran dan penalaran biaya. Menetapkan jumlah partisi jauh melebihi hasil rumus jarang menguntungkan, karena setiap partisi menambah berkas log terbuka, alur replikasi, slot pemindahan saat rebalancing, dan waktu pemulihan broker, sementara bandwidth per partisi menurun pada diska yang menampung banyak log. Jumlah partisi ditetapkan dari hasil rumus dengan ruang tumbuh moderat, misalnya target dua kali beban saat ini, lalu dibiarkan sampai pengukuran menunjukkan kebutuhan baru. Rencana diperbarui setiap ada perubahan retensi atau penambahan consumer group, karena keduanya mengubah diska dan bandwidth tanpa mengubah throughput produksi. Rencana cukup disimpan sebagai angka sederhana, yaitu kebutuhan diska per broker, bandwidth per broker, dan jumlah partisi per topic, sehingga kebutuhan baru dibandingkan tanpa menjalankan ulang seluruh perhitungan.

Kesalahan umum#

Menghitung diska tanpa mengalikan replication factor. Log tersimpan sebanyak jumlah salinannya, sehingga topic dengan replication factor 3 menuntut tiga kali kebutuhan awal di seluruh cluster. Masukkan $F$ sejak awal agar ukuran cluster tidak dirancang dari angka yang terlalu kecil.
Menggunakan throughput teoretis tanpa pengukuran. Angka dari dokumen aplikasi sering berbeda dari kenyataan, dan selisihnya berlipat melalui retensi serta replikasi. Ukur BytesInPerSec pada topic yang sudah berjalan sebelum menghitung topic berikutnya.
Menetapkan jumlah partisi hanya dari sisi tulisan. Partisi yang memadai untuk penulisan dapat tetap tertinggal saat konsumsi karena bandwidth baca total berlipat per consumer group. Hitung $C$ dan cocokkan dengan bandwidth baca per partisi sebelum menetapkan $n$ .
Mencatat kebutuhan diska tanpa overhead. Berkas indeks dan metadata batch membuat penggunaan riil melampaui hasil kali murni, dan selisihnya menumpuk sampai diska penuh. Tetapkan overhead fraksional, misalnya 0,10, lalu kalibrasi dari ukuran log nyata.

Ringkasan#

Kebutuhan diska dihitung dari throughput produksi, jumlah detik per hari, retensi, replication factor, dan overhead, mengikuti $D = P \times S \times R \times F \times (1 + o)$ .
Bandwidth konsumsi total sama dengan throughput produksi dikalikan jumlah consumer group, dan salinan antar broker menambah trafik sebesar $(F - 1) \times P$ .
Jumlah partisi minimal diambil dari nilai terbesar antara hasil bagi throughput tulis dengan bandwidth per partisi dan hasil bagi bandwidth konsumsi dengan bandwidth baca per partisi.
Hasil perencanaan diverifikasi dengan metrik nyata seperti BytesInPerSec, dan jumlah partisi dijaga dekat dengan kebutuhan agar biaya per partisi tidak sia-sia.

Referensi#

Broker configs — Apache Software Foundation — parameter retensi dan replikasi seperti log.retention.hours, log.retention.bytes, dan num.replica.fetchers.
Topic configs — Apache Software Foundation — pengaturan retensi per topic melalui retention.ms dan retention.bytes.
Monitoring — Apache Software Foundation — metrik BytesInPerSec dan BytesOutPerSec untuk memverifikasi angka perencanaan dengan beban nyata.