Throughput Planning: Panduan Perencanaan Kapasitas Kluster Apache Kafka #

Dalam membangun infrastruktur data terdistribusi menggunakan Apache Kafka, salah satu kesalahan paling fatal yang sering kita lakukan adalah mengabaikan perencanaan kapasitas (capacity planning) sejak awal. Banyak tim operasional langsung menginstal Kafka menggunakan spesifikasi server insting atau acak, lalu terkejut ketika kluster mereka kolaps saat menerima lonjakan lalu lintas data (traffic spike), mengalami kehabisan socket jaringan, atau mengalami penurunan performa akibat memori page cache yang terlalu kecil.

Kafka dirancang untuk menangani beban throughput yang sangat masif dengan memanfaatkan efisiensi perangkat keras secara maksimal. Namun, efisiensi ini hanya dapat dicapai jika kita melakukan sinkronisasi yang cermat antara kebutuhan lalu lintas data bisnis dengan alokasi bandwidth jaringan, kapasitas I/O disk, ukuran memori page cache sistem operasi, dan daya komputasi CPU. Perencanaan throughput yang matang membantu kita menghindari pemborosan biaya akibat kelebihan alokasi (over-provisioning) sekaligus mencegah bencana kegagalan produksi akibat kekurangan alokasi (under-provisioning).

Dalam panduan ini, kita akan membahas metodologi kalkulasi kapasitas kluster Kafka secara terstruktur. Kita akan mempelajari formula matematika untuk menghitung kebutuhan bandwidth jaringan, merancang kapasitas penyimpanan disk dan estimasi IOPS, menghitung alokasi RAM yang optimal untuk sistem page cache OS, serta mengidentifikasi faktor-faktor yang memicu beban CPU broker.

Pengantar Perencanaan Kapasitas Kafka #

Perencanaan kapasitas di Kafka didasarkan pada prinsip bahwa broker bertindak sebagai saluran pipa berkecepatan tinggi yang memindahkan data dari produser ke konsumen seefisien mungkin. Kafka sangat mengandalkan arsitektur penyimpanan linier dan transfer data bebas salinan (Zero-Copy). Oleh karena itu, hambatan utama (bottleneck) di Kafka biasanya bukan terletak pada daya pemrosesan CPU, melainkan pada bandwidth kartu jaringan (Network Card Interface) dan kecepatan baca-tulis disk (Disk I/O).

Untuk menghitung kapasitas kluster secara akurat, kita harus mengumpulkan metrik kunci dari kebutuhan bisnis kita terlebih dahulu:

1. Laju Data Masuk (Write Throughput): Berapa megabyte data yang diproduksi per detik di waktu sibuk?
2. Faktor Replikasi (Replication Factor): Berapa banyak salinan data yang ingin kita simpan untuk toleransi kegagalan?
3. Laju Data Keluar (Read Throughput): Berapa banyak kelompok konsumen (consumer group) independen yang akan membaca data tersebut secara bersamaan?
4. Waktu Retensi (Retention Period): Berapa lama data harus disimpan sebelum dihapus oleh broker?

Mengukur Kebutuhan Throughput Jaringan (Bandwidth) #

Jaringan adalah gerbang pertama dari kluster Kafka kita. Seluruh pesan masuk dan keluar harus melewati kartu jaringan (Network Interface Card - NIC) pada setiap broker. Kegagalan menghitung bandwidth jaringan akan menyebabkan kemacetan antrean pada thread network processor dan memicu terjadinya timeout di sisi klien.

1. Perhitungan Bandwidth Jaringan Masuk (Inbound Traffic) #

Data yang masuk ke kluster kita terdiri dari data yang dikirim oleh produser ditambah dengan lalu lintas replikasi data antar broker (replication traffic).

Formula untuk mengukur total inbound traffic pada kluster adalah:

$$\text{Total Inbound Bandwidth} = \text{Data Rate Produser (MB/s)} \times \text{Replication Factor (RF)} \times (1 + \text{Overhead Metadata})$$

Di mana:

• Data Rate Produser: Volume data bersih yang diproduksi oleh aplikasi kita per detik.
• Replication Factor: Jumlah salinan partisi. Jika RF disetel ke 3, setiap pesan yang masuk harus diduplikasi sebanyak 2 kali lagi ke broker follower.
• Overhead Metadata: Alokasi tambahan untuk header pesan, offset, dan jabat tangan protokol (kita disarankan menyetel buffer aman sebesar $10%$ atau $0.1$).

2. Perhitungan Bandwidth Jaringan Keluar (Outbound Traffic) #

Data yang keluar dari kluster kita didominasi oleh penarikan data oleh konsumen ditambah dengan aktivitas replikasi internal (di mana leader mengirimkan data ke follower). Namun, karena lalu lintas replikasi sudah dihitung pada porsi inbound broker follower, di sisi outbound kita fokus pada jumlah consumer group aktif.

Formula untuk mengukur total outbound traffic pada kluster adalah:

$$\text{Total Outbound Bandwidth} = (\text{Data Rate Produser} \times \text{Jumlah Consumer Group}) + \text{Replication Traffic}$$

Di mana:

• Jumlah Consumer Group: Berapa banyak aplikasi unik yang membaca topik tersebut secara bersamaan.
• Replication Traffic: Bernilai $\text{Data Rate Produser} \times (\text{RF} - 1)$ karena leader mengirimkan salinan data ke broker follower.

Studi Kasus Perhitungan Bandwidth #

Misalkan kita memiliki skenario produksi berikut:

• Data Rate Produser: $20 \text{ MB/s}$
• Replication Factor (RF): $3$
• Jumlah Consumer Group: $4$ kelompok konsumen independen.
• Overhead Metadata: Disetel $10%$.

Mari kita hitung total kebutuhan bandwidth jaringan:

Bandwidth Masuk (Inbound): $$\text{Total Inbound} = 20 \text{ MB/s} \times 3 \times 1.1 = 66 \text{ MB/s}$$

Bandwidth Keluar (Outbound): $$\text{Replication Traffic} = 20 \text{ MB/s} \times (3 - 1) = 40 \text{ MB/s}$$ $$\text{Consumer Traffic} = 20 \text{ MB/s} \times 4 = 80 \text{ MB/s}$$ $$\text{Total Outbound} = 80 \text{ MB/s} + 40 \text{ MB/s} = 120 \text{ MB/s}$$

Total Beban Jaringan Kluster: $$\text{Total Bandwidth} = 66 \text{ MB/s} \text{ (In)} + 120 \text{ MB/s} \text{ (Out)} = 186 \text{ MB/s}$$

Jika kita membagi beban ini secara merata ke dalam kluster dengan 3 broker, maka rata-rata beban per broker adalah:

• Rata-rata Inbound per Broker: $22 \text{ MB/s}$ (Setara dengan $\approx 176 \text{ Mbps}$)
• Rata-rata Outbound per Broker: $40 \text{ MB/s}$ (Setara dengan $\approx 320 \text{ Mbps}$)

Dari angka ini, kartu jaringan $1 \text{ Gbps}$ per server sudah sangat mencukupi, dengan catatan tidak ada lonjakan beban (spike) yang melebihi 3 kali lipat rata-rata. Namun, jika laju produser naik menjadi $100 \text{ MB/s}$, kita wajib beralih ke kartu jaringan $10 \text{ Gbps}$ untuk menghindari saturasi.

Diagram Pemetaan Komponen Kapasitas Kluster #

Berikut adalah diagram relasi yang menunjukkan bagaimana variabel bisnis dipetakan ke alokasi sumber daya fisik (Network, CPU, Memory, Disk Space, Disk I/O) pada kluster Kafka kita:

flowchart TD
    subgraph BusinessMetrics ["Kebutuhan Bisnis"]
        RateProd["Data Rate Produser (MB/s)"]
        RF["Replication Factor (RF)"]
        NumGroups["Jumlah Consumer Group"]
        RetHours["Waktu Retensi (Jam/Hari)"]
    end

    subgraph HardwareResource ["Alokasi Sumber Daya Fisik Broker"]
        NetBandwidth["Jaringan: Bandwidth Interface (NIC)"]
        DiskSpace["Penyimpanan: Kapasitas Disk Total"]
        DiskIO["I/O Disk: IOPS & Sequential Throughput"]
        OSCache["Memori: RAM Page Cache OS"]
        CPUPower["Komputasi: Core CPU (SSL/Compression)"]
    end

    RateProd --> NetBandwidth
    RF --> NetBandwidth
    NumGroups --> NetBandwidth

    RateProd --> DiskSpace
    RF --> DiskSpace
    RetHours --> DiskSpace

    RateProd --> DiskIO
    RF --> DiskIO
    NumGroups --> DiskIO

    RateProd --> OSCache
    RF --> OSCache
    
    RateProd --> CPUPower

Perencanaan Kapasitas Penyimpanan (Disk Storage & IOPS) #

Setelah merancang jaringan, kita harus merencanakan media penyimpanan data. Perencanaan disk mencakup dua dimensi: Kapasitas Disk (Disk Space) untuk menampung retensi data, dan Kinerja Disk (Disk I/O / IOPS) untuk melayani kecepatan tulis dan baca.

1. Menghitung Kapasitas Disk Total (Disk Space) #

Kita harus memastikan bahwa server memiliki ruang penyimpanan yang cukup untuk menyimpan data historis sesuai waktu retensi sebelum dihapus otomatis.

Formula perhitungan kapasitas disk bersih yang dibutuhkan kluster adalah:

$$\text{Kapasitas Disk Total} = \text{Data Rate Produser (MB/s)} \times 86400 \times \text{Retensi (Hari)} \times \text{RF} \times (1 + \text{Buffer Space})$$

Di mana:

• 86400: Jumlah detik dalam satu hari.
• Buffer Space: Alokasi tambahan untuk mengantisipasi keterlambatan pembersihan segmen kotor, indeks internal, dan ruang kosong aman sistem operasi (disarankan minimal $20%$ atau $0.2$).

Contoh Perhitungan Ruang Disk: #

Menggunakan skenario sebelumnya (Produser $20 \text{ MB/s}$, $\text{RF} = 3$) dengan target Retensi 7 Hari dan buffer $20%$: $$\text{Kapasitas Disk} = 20 \text{ MB/s} \times 86400 \times 7 \times 3 \times 1.2 = 43.545.600 \text{ MB} \approx 43,5 \text{ TB}$$

Jika kluster kita terdiri dari 3 broker, maka setiap broker harus menyiapkan ruang penyimpanan sebesar: $$\frac{43,5 \text{ TB}}{3} = 14,5 \text{ TB per Broker}$$

Kita dapat memenuhi kapasitas ini dengan menggunakan konfigurasi JBOD (Just a Bunch of Disks) berisi beberapa disk lokal (misalnya 4 x 4 TB disk per server).

2. Memilih Tipe Storage: HDD vs SSD #

Pemilihan tipe disk berdampak langsung pada latensi dan throughput baca-tulis:

• HDD (Hard Disk Drive): Sangat efisien untuk penulisan linier (sequential writes) yang merupakan pola dasar penulisan log segment Kafka. HDD menawarkan kapasitas besar dengan harga murah. Namun, jika ada konsumen yang membaca data lama (cold data) dari disk, kepala baca HDD akan bergerak secara acak (random reads), memicu penurunan performa I/O secara drastis (disk thrashing).
• SSD (Solid State Drive / NVMe): Menawarkan IOPS acak yang sangat tinggi. Sangat direkomendasikan jika kluster kita melayani aplikasi real-time yang sensitif terhadap latensi, atau jika kita mengantisipasi adanya konsumen yang sering membaca data historis dari disk secara acak.

Perencanaan Kapasitas Memori (Page Cache OS) #

Salah satu keunikan arsitektur Apache Kafka adalah ia tidak menyimpan data pesan di dalam heap memori JVM-nya. JVM broker hanya disarankan menggunakan heap kecil (sekitar 4 GB hingga 6 GB) untuk mengelola struktur metadata dan koneksi socket. Sisanya, Kafka menyerahkan manajemen caching data segmen log sepenuhnya kepada Page Cache Sistem Operasi (RAM Bebas).

Ketika produser menulis pesan, data sebenarnya ditulis ke page cache RAM terlebih dahulu. OS kemudian menyiram (flush) page cache ini ke disk secara asinkron. Jika konsumen meminta data yang baru saja diproduksi, Kafka akan membaca data tersebut langsung dari page cache RAM tanpa perlu menyentuh disk fisik sama sekali (Zero-Copy read). Skenario ini disebut Page Cache Hit.

flowchart TD
    Producer["PRODUSER"] --> Cache["OS PAGE CACHE (Memori Utama / RAM)"]
    Cache -- "Zero-Copy" --> Consumer["KONSUMEN"]
    Cache -- "Asinkron Flush" --> Disk["DISK FISIK"]
    Disk -- "Hanya dibaca jika data dingin / Cache Miss" --> Consumer

Rumus Estimasi Kebutuhan RAM Page Cache #

Agar kluster kita beroperasi dengan latensi minimal, kita harus memastikan bahwa seluruh partisi topik yang aktif ditulis saat ini dapat ditampung sepenuhnya di dalam page cache RAM.

Aturan praktis (rule of thumb) minimal untuk sizing memori page cache adalah menyimpan data hasil produksi selama 1 hingga 2 jam terakhir di dalam RAM:

$$\text{Kebutuhan RAM Page Cache} = \text{Data Rate Produser (MB/s)} \times 3600 \text{ detik} \times \text{Replication Factor (RF)}$$

Contoh Perhitungan RAM: #

Untuk laju produser $20 \text{ MB/s}$ dan $\text{RF} = 3$: $$\text{RAM Page Cache} = 20 \text{ MB/s} \times 3600 \times 3 = 216.000 \text{ MB} \approx 216 \text{ GB}$$

Jika kita bagi ke dalam 3 broker: $$\text{Alokasi RAM per Broker} = \frac{216 \text{ GB}}{3} = 72 \text{ GB per Broker}$$

Jadi, spesifikasi server broker kita disarankan memiliki kapasitas RAM total minimal 80 GB (72 GB untuk Page Cache OS, 6 GB untuk JVM Heap, dan 2 GB untuk sistem operasi). Jika server hanya memiliki RAM 16 GB, maka page cache akan cepat penuh dan memaksa konsumen membaca langsung dari disk fisik, menyebabkan latensi melonjak tajam (high latency spikes).

Perencanaan Kapasitas CPU (Kompresi & Enkripsi) #

Meskipun Kafka broker umumnya hemat CPU karena tidak melakukan parsing isi pesan, ada dua fitur keamanan dan optimalisasi yang dapat memicu lonjakan beban CPU secara signifikan pada broker:

1. Enkripsi Transit (SSL/TLS) dan Otentikasi SASL #

Ketika kita mengaktifkan enkripsi SSL/TLS untuk mengamankan data yang ditransmisikan antara klien dan broker, CPU broker harus melakukan proses enkripsi/dekripsi paket data secara real-time pada setiap socket jaringan. Proses jabat tangan SSL (SSL Handshake) berulang dari ribuan klien juga sangat membebani CPU.

2. Dekompresi Pesan untuk Validasi #

Secara umum, produser bertugas mengompresi pesan (misalnya dengan Zstd) dan konsumen mendekompresinya, sehingga broker hanya menyimpan biner mentah. Namun, broker terpaksa melakukan dekompresi di sisi server jika:

• Kita mengonfigurasi fitur validasi rekaman (misalnya memvalidasi timestamp pesan).
• Jenis kompresi yang disetel pada broker (compression.type di broker) berbeda dengan jenis kompresi yang dikirim oleh produser. Kondisi ini memaksa broker mendekompresi payload dan mengompresinya ulang (re-compression) menggunakan algoritma target sebelum ditulis ke disk.

Rekomendasi Sizing CPU #

• Kluster Non-SSL / Tanpa Kompresi Broker: Cukup gunakan 4 hingga 8 core CPU per broker.
• Kluster SSL Aktif + SASL + Kompresi Aktif: Gunakan minimal 16 hingga 32 core CPU per broker, dan pastikan kita mengaktifkan fitur enkripsi perangkat keras (Intel QuickAssist atau instruksi AES-NI) di tingkat prosesor untuk meringankan beban kriptografi.

Kepatuhan Operasional dan Checklist Audit Perencanaan Kapasitas #

Lakukan evaluasi terhadap desain arsitektur kluster kita menggunakan tabel audit kapasitas berikut untuk menjamin kesiapan sebelum masuk ke fase deployment produksi:

Ringkasan #

• Jaringan adalah Hambatan Utama — Selalu hitung total inbound dan outbound bandwidth dengan memasukkan faktor replikasi dan jumlah consumer group untuk menghindari saturasi kartu jaringan.
• Sediakan RAM untuk Page Cache — Alokasikan RAM bebas yang cukup agar data log segmen terpanas (minimal 2 jam terakhir) tetap berada di memori page cache OS guna menjamin latensi baca yang rendah.
• Gunakan SSD untuk Latensi Rendah — Pilih media penyimpanan SSD/NVMe jika kluster kita melayani pembacaan acak oleh konsumen lambat atau jika beban IOPS sangat fluktuatif.
• Optimalkan CPU dari Kriptografi — Siapkan kapasitas core CPU tambahan jika kluster mengaktifkan enkripsi SSL/TLS transit dan otentikasi SASL guna meredam overhead overhead enkripsi.

← Sebelumnya: Debugging Message Flow   Berikutnya: Partition & Broker Sizing →