Over-Partitioning #

Dalam ekosistem Apache Kafka, partisi (partition) adalah unit dasar skala, paralelisme, dan distribusi data. Secara teori, menambah jumlah partisi pada topik adalah cara utama untuk mendongkrak performa sistem: semakin banyak partisi, semakin banyak broker leader yang dapat membagi beban kerja, dan semakin banyak konsumen dalam satu Consumer Group yang dapat membaca data secara bersamaan. Paradoksnya, pendekatan “semakin banyak, semakin baik” ini menyimpan jebakan arsitektural yang fatal. Menambahkan partisi secara berlebihan tanpa perhitungan matang — sebuah kondisi yang dikenal sebagai Over-Partitioning — dapat menurunkan performa kluster secara keseluruhan. Dampak negatif paling instan dari over-partitioning justru pertama kali dirasakan di sisi klien produser dalam bentuk pembengkakan penggunaan memori Java Virtual Machine (JVM) yang masif, yang berujung pada terjadinya kemacetan pengiriman data (backpressure) hingga memicu galat kehabisan memori (Out Of Memory / OOM).

Mekanisme Internal Penyangga Memori Klien Produser #

Untuk memahami mengapa jumlah partisi yang terlalu banyak dapat melumpuhkan klien produser kita, kita harus menengok kembali arsitektur internal dari komponen Record Accumulator.

Seperti yang telah kita pelajari pada bab Producer Workflow, klien produser Kafka memisahkan utas aplikasi utama dengan utas pengirim jaringan (Sender Thread). Jembatan penghubung di antara keduanya adalah RecordAccumulator.

Di tingkat kode Java, Record Accumulator menyimpan antrean pesan menggunakan struktur data peta thread-safe:

ConcurrentMap<TopicPartition, ArrayDeque<ProducerBatch>> batches;

Struktur data ini berarti setiap partisi dari setiap topik memiliki antrean memorinya sendiri.

• Ketika aplikasi kita memanggil .send() ke Partisi 0, produser akan membuat atau mengisi objek ProducerBatch aktif khusus untuk Partisi 0.
• Jika aplikasi kemudian mengirim pesan ke Partisi 1, produser harus mengalokasikan satu ProducerBatch baru lagi khusus untuk Partisi 1.
• Memori biner fisik untuk setiap batch ini diminta langsung ke komponen Buffer Pool Manager dengan ukuran standar sebesar properti batch.size (default: 16.384 byte atau 16 KB).

Dampak Over-Partitioning di Sisi Produser: Pembengkakan Memori #

Masalah pembengkakan memori terjadi ketika jumlah partisi yang aktif ditulis oleh produser membengkak hingga menyentuh angka ribuan.

Bayangkan kita memiliki sistem dengan spesifikasi berikut:

• Jumlah Topik: 50 topik independen.
• Jumlah Partisi Per Topik: 100 partisi (total 5.000 partisi di kluster).
• Konfigurasi Produser: Properti batch.size disetel ke 32 KB (untuk meningkatkan efisiensi batching), dan total kapasitas memori buffer pengirim (buffer.memory) dibiarkan menggunakan nilai default sebesar 32 MB (33.554.432 byte).

Skenario Transmisi Data #

Jika produser kita mendistribusikan data secara merata ke seluruh partisi menggunakan partitioner (misalnya saat memproses aliran log sensor atau clickstream non-key):

1. Dalam satu siklus waktu singkat, produser mulai menulis ke 5.000 partisi yang berbeda.
2. Record Accumulator mendeteksi bahwa belum ada batch aktif untuk 5.000 partisi tersebut.
3. Klien produser meminta alokasi memori buffer 32 KB ke Buffer Pool Manager untuk setiap partisi aktif tersebut.
4. Mari kita hitung total kebutuhan memori minimum:

$$\text{Memori Buffer Aktif} = 5.000 \text{ partisi} \times 32 \text{ KB} = 160.000 \text{ KB} \approx 160 \text{ MB}$$

5. Benturan Fisik: Klien produser hanya memiliki batas alokasi memori buffer.memory sebesar 32 MB.
6. Ketika alokasi memori di Buffer Pool menyentuh angka 32 MB (baru menampung sekitar 1.000 antrean partisi), Buffer Pool Manager akan kehabisan memori kosong secara total.
7. Pemanggilan .send() berikutnya dari utas aplikasi utama kita akan terblokir secara sinkron selama properti durasi max.block.ms (default: 60.000 ms atau 1 menit).
8. Aplikasi mengalami kemacetan parah (extreme backpressure). Latensi pemrosesan bisnis melonjak drastis, dan jika broker tidak merespons cepat untuk mengosongkan buffer dalam waktu 1 menit, produser akan crash dengan membuang exception TimeoutException: Failed to allocate memory within the configured max block time.

Rumus Perhitungan Memori Buffer Produser #

Sebagai arsitek sistem, kita harus melakukan perhitungan kapasitas memori produser secara presisi sebelum melakukan deploy ke server produksi.

Rumus empiris untuk menghitung kebutuhan memori minimum dari Record Accumulator agar terhindar dari backpressure adalah:

$$\text{Kebutuhan Memori} = \text{Jumlah Topik} \times \text{Partisi Per Topik} \times \text{batch.size} \times \text{Faktor Antrean}$$

Keterangan Parameter: #

• Jumlah Topik: Total topik aktif yang ditulis oleh satu instans aplikasi produser kita.
• Partisi Per Topik: Jumlah partisi fisik untuk masing-masing topik.
• batch.size: Ukuran kapasitas per batch (default: 16 KB).
• Faktor Antrean: Biasanya bernilai minimal 2. Mengapa? Karena pada throughput tinggi, selalu ada satu batch aktif yang sedang diisi oleh utas aplikasi (Ongoing Batch) dan satu batch yang baru saja ditutup dan sedang menunggu dikirim ke jaringan oleh Sender Thread (Ready Batch).

Contoh Simulasi Kasus Nyata #

Mari kita evaluasi apakah konfigurasi berikut aman:

• Topik = 10
• Partisi = 64 (total 640 partisi)
• batch.size = 64 KB
• buffer.memory = 32 MB

$$640 \text{ partisi} \times 64 \text{ KB} \times 2 = 81.920 \text{ KB} \approx 81,9 \text{ MB}$$

• Analisis: Kebutuhan memori minimum adalah 81,9 MB, namun kapasitas buffer kita hanya 32 MB. Konfigurasi ini tidak aman dan dijamin akan sering mengalami pemblokiran jika lalu lintas data sedang padat.
• Solusi: Kita harus menaikkan buffer.memory minimal menjadi 128 MB di konfigurasi produser kita.

Diagram Mermaid: Visualisasi Fragmentasi Memori Heap Produser #

Bagan berikut memvisualisasikan bagaimana alokasi memori buffer pool produser terpecah-pecah (fragmented) dan terkuras habis untuk mengakomodasi ribuan antrean partisi kecil yang tidak efisien akibat over-partitioning:

flowchart TD
    subgraph Heap ["Memori Heap Klien Produser (buffer.memory = 32 MB)"]
        direction TB
        subgraph ActiveQueues ["Record Accumulator: 3.000 Antrean Partisi"]
            direction LR
            P0["Partisi 0 <br> (16 KB Buffer)"]
            P1["Partisi 1 <br> (16 KB Buffer)"]
            P2["Partisi 2 <br> (16 KB Buffer)"]
            Dots["..."]
            P3000["Partisi 2999 <br> (16 KB Buffer)"]
        end
        BP["Buffer Pool Manager: Kosong / Terfragmentasi"]
    end
    
    AppThread["Utas Aplikasi (send)"] -->|"Minta memori baru"| BP
    BP -->|"RAM Habis! Memicu Blokir"| Backpressure["Backpressure (max.block.ms = 60s)"]
    
    style Heap stroke:#e5e7eb
    style ActiveQueues stroke:#e5e7eb
    style P0 stroke:#0288d1,stroke-width:2px
    style P1 stroke:#0288d1,stroke-width:2px
    style P2 stroke:#0288d1,stroke-width:2px
    style P3000 stroke:#0288d1,stroke-width:2px
    style BP stroke:#c62828,stroke-width:2px

Dampak Negatif Over-Partitioning di Sisi Broker #

Selain menyiksa memori klien produser, over-partitioning memberikan beban overhead yang sangat berat di sisi kluster broker Kafka:

1. Pembengkakan Berkas Terbuka (Open File Descriptors) #

Di tingkat sistem operasi broker, setiap partisi Kafka dipetakan ke sebuah folder fisik di dalam direktori data. Di dalam folder ini, minimal terdapat berkas data log komit (.log), berkas indeks offset (.index), dan berkas indeks waktu (.timeindex).

• OS broker harus membuka koneksi berkas (file handler) aktif untuk masing-masing file ini. Jika broker melayani 50.000 partisi, broker harus menjaga minimal 150.000 berkas terbuka secara bersamaan, memicu risiko menyentuh batas ulimit sistem operasi Linux.

2. Lonjakan Latensi Pemulihan (Failover Recovery Latency) #

Jika salah satu broker dalam kluster mati mendadak, broker coordinator harus mempromosikan follower menjadi leader baru untuk ribuan partisi yang ditinggalkan oleh broker yang mati tersebut.

• Proses pemilihan leader (leader election) dan sinkronisasi metadata ini memakan waktu komputasi CPU. Jika kluster memiliki terlalu banyak partisi, proses failover yang harusnya selesai dalam hitungan milidetik dapat membengkak hingga puluhan detik atau menit, menyebabkan sistem mengalami downtime sementara.

Panduan dan Strategi Penentuan Jumlah Partisi yang Ideal #

Bagaimana kita menentukan jumlah partisi topik yang ideal tanpa jatuh ke dalam jebakan over-partitioning? Kita wajib menggunakan pendekatan berbasis target kapasitas throughput.

Rumus Penskalaan Partisi: #

Kita harus mengukur throughput dari satu thread produser dan konsumen kita terlebih dahulu di lingkungan staging:

$$\text{Jumlah Partisi} = \max\left(\frac{\text{Target Throughput Global}}{\text{Throughput Produser Tunggal}}, \frac{\text{Target Throughput Global}}{\text{Throughput Konsumen Tunggal}}\right)$$

• Contoh Kasus:
  • Target throughput bisnis kita adalah 100 MB/detik.
  • Berdasarkan uji coba, satu produser kita sanggup menulis 20 MB/detik.
  • Namun, satu konsumen kita (karena harus melakukan query database yang lambat) hanya sanggup memproses 5 MB/detik.
  • Perhitungan Partisi:
    • Sisi produser: $100 / 20 = 5$ partisi.
    • Sisi konsumen: $100 / 5 = 20$ partisi.
  • Hasil: Ambil nilai terbesar, yaitu 20 partisi. Membuat lebih dari 24 partisi untuk topik ini adalah pemborosan resource yang tidak perlu.

Implementasi Java & Konfigurasi Protektif #

Berikut adalah perbandingan antara konfigurasi produser yang rentan mengalami crash memori akibat over-partitioning (anti-pattern) dengan konfigurasi penyesuaian memori yang benar:

// ANTI-PATTERN: Mengabaikan rasio partisi topik terhadap alokasi memori buffer
// Produser menulis ke ribuan partisi dengan memory buffer default yang sempit
public class DangerousMultiTopicProducer {
    public KafkaProducer<String, String> createProducer() {
        Properties props = new Properties();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
        
        // ✗ batch.size dinaikkan tanpa menyeimbangkan buffer.memory
        props.put(ProducerConfig.BATCH_SIZE_CONFIG, "65536"); // 64 KB
        
        // ✗ buffer.memory dibiarkan default (32 MB) padahal menulis ke 2.000 partisi
        // Produser akan terblokir instan saat RAM buffer habis terfragmentasi
        
        return new KafkaProducer<>(props);
    }
}

// BENAR: Menyesuaikan alokasi memori buffer secara proporsional dengan jumlah partisi
public class SafeMultiTopicProducer {
    public KafkaProducer<String, String> createProducer() {
        Properties props = new Properties();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
        
        props.put(ProducerConfig.BATCH_SIZE_CONFIG, "32768"); // 32 KB per batch
        
        // ✓ BENAR: Naikkan buffer.memory menjadi 256 MB untuk menampung ribuan antrean partisi aktif
        props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, String.valueOf(256 * 1024 * 1024)); // 256 MB
        
        // ✓ BENAR: Gunakan Sticky Partitioner untuk memusatkan pesan non-key ke satu partisi aktif
        // Ini secara drastis meminimalkan jumlah batch partisi terbuka di Record Accumulator
        
        // ✓ BENAR: Batasi waktu blokir agar utas aplikasi bisnis tidak menggantung terlalu lama saat failover
        props.put(ProducerConfig.MAX_BLOCK_MS_CONFIG, "15000"); // 15 detik
        
        return new KafkaProducer<>(props);
    }
}

Direct Byte Buffers vs Heap Memory di Record Accumulator #

Untuk menganalisis lebih dalam overhead memori pada produser Kafka, kita harus memahami bagaimana Java Virtual Machine (JVM) mengalokasikan memori untuk buffer pengirim. Secara internal, Buffer Pool Manager dapat dikonfigurasi untuk menggunakan memori Heap standard (melalui ByteBuffer.allocate()) atau menggunakan memori Direct (off-heap memory melalui ByteBuffer.allocateDirect()).

• Heap Memory (Default): Alokasi memori heap berada di bawah pengawasan langsung dari Java Garbage Collector (GC). Ketika produser kita memproses jutaan pesan kecil per detik dalam kondisi over-partitioning, jutaan objek ProducerBatch kecil akan dibuat dan dihancurkan secara dinamis. Perilaku ini akan membanjiri ruang Young Generation di memori heap, memicu GC untuk bekerja ekstra keras melakukan pembersihan (stop-the-world pauses), yang akhirnya melumpuhkan latensi aplikasi kita secara keseluruhan.
• Direct Memory (Off-Heap): Alokasi direct memory berada di luar kendali GC, langsung pada RAM fisik sistem operasi. Proses penulisan soket jaringan menggunakan direct memory jauh lebih cepat karena Java dapat melakukan operasi I/O soket secara Zero-Copy tanpa perlu menyalin data dari heap memory ke ruang memori kernel OS terlebih dahulu. Namun, alokasi memori direct secara dinamis memiliki overhead komputasi pembuatan objek (allocation cost) yang jauh lebih mahal dibandingkan heap memory.

Solusi Desain Klien Kafka #

Klien Kafka mengatasi dilema ini dengan menerapkan sistem penyewaan memori terkelola di dalam Buffer Pool. Saat dinyalakan, Buffer Pool melakukan pra-alokasi memori dalam ukuran batch tetap (batch.size). Ketika sebuah batch selesai dikirim ke broker, memori biner dari batch tersebut tidak dibuang untuk kemudian dibersihkan oleh GC, melainkan dikembalikan ke antrean Buffer Pool untuk langsung digunakan kembali oleh utas aplikasi lain. Melalui desain daur ulang (recycling) ini, Kafka memperoleh kecepatan direct memory tanpa perlu membayar overhead pembuatan objek berulang kali, sekaligus menjaga heap JVM tetap bersih dari ancaman GC overhead.

Diagnosis Over-Partitioning Menggunakan CLI Tools #

Sebagai administrator sistem, kita dapat memantau tanda-tanda terjadinya over-partitioning pada kluster Kafka aktif menggunakan perintah konsol terminal (CLI tools) Linux standar.

1. Menghitung Total Partisi Aktif di Kluster #

Kita dapat memanfaatkan Kafka admin CLI bawaan untuk menghitung jumlah total partisi pada seluruh topik yang terdaftar:

# Ambil daftar seluruh topik, deskripsikan masing-masing, lalu hitung kemunculan label partisi
kafka-topics.sh --bootstrap-server localhost:9092 --list | \
  xargs -I {} kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic {} | \
  grep -c "Partition:"

2. Memeriksa File Descriptor Terbuka pada OS Broker #

Di dalam server OS Linux yang menjalankan Kafka Broker, kita dapat memantau berapa banyak berkas deskriptor (file handlers) yang sedang dikunci oleh proses Kafka (misalnya PID proses Kafka adalah 1234):

# Menghitung berkas deskriptor terbuka oleh proses JVM Kafka
lsof -p 1234 | wc -l

Jika angka keluaran mendekati batas maksimum sistem operasi (yang dapat dilihat via perintah ulimit -n), kluster kita berada dalam risiko kegagalan crash akibat over-partitioning.

3. Memahami Berkas Fisik Per Partisi di Disk #

Setiap partisi yang dialokasikan di dalam direktori penyimpanan data broker (log.dirs) akan membuat satu sub-folder khusus yang menyimpan berkas-berkas berikut:

Keberadaan ribuan sub-folder partisi dengan empat berkas wajib ini menjelaskan mengapa over-partitioning secara instan memakan kapasitas Inodes sistem berkas Linux dan memicu overhead pencarian I/O disk yang sangat lambat.

Ringkasan #

• Over-Partitioning: Praktik menambahkan partisi secara berlebihan tanpa perhitungan yang memicu fragmentasi memori dan menurunkan efisiensi kluster.
• Record Accumulator Bloat: Memori JVM produser terfragmentasi karena setiap partisi aktif memiliki antrean ProducerBatch independen.
• Buffer Pool Exhaustion: Produser akan kehabisan memori buffer ketika total partisi dikalikan batch.size melebihi properti buffer.memory.
• Backpressure: Kehabisan buffer memicu pemblokiran sinkron pada utas aplikasi bisnis selama parameter max.block.ms sebelum akhirnya melempar exception timeout.
• OS File Descriptors: Over-partitioning membebani CPU broker untuk memelihara ratusan ribu file handlers terbuka pada sistem operasi Linux.
• Consistent Scaling: Hitung jumlah partisi topik yang ideal menggunakan target throughput global dibagi dengan kemampuan throughput konsumen tunggal terendah.

← Sebelumnya: Exactly-Once Semantics   Berikutnya: Large Message Problem →