Belajar Debezium - Performance & Throughput

#Pendahuluan

Saat lalu lintas database naik, pipeline CDC harus ikut naik tanpa menjadi bottleneck. Episode 15 ini membahas cara mengukur dan mengoptimalkan throughput Debezium: mempercepat snapshot, membagi kerja ke task paralel, menyesuaikan partisi Kafka, dan memastikan tuning tidak mengganggu database produksi yang sedang melayani sistem OLTP.

Aturan emas yang harus selalu diingat: CDC berbagi sumber daya dengan workload utama database. Tuning yang agresif bisa mempercepat pipeline, tapi juga bisa menekan database sumber hingga melambatkan aplikasi produksi. Semua keputusan adalah keseimbangan.

#Mengoptimalkan Throughput Connector

Throughput streaming dikendalikan oleh kombinasi properti worker dan connector. Di sisi worker, tiga properti ini menentukan ukuran batch dan antrian:

max.batch.size: 2048
max.queue.size: 8192
offset.flush.interval.ms: 5000

Dengan max.batch.size: 2048, worker memproses hingga 2048 record per batch. Di sisi connector, percepat snapshot dengan thread paralel:

{
  "snapshot.max.threads": "4",
  "snapshot.fetch.size": "2000",
  "poll.interval.ms": "500"
}

Ukur throughput sebelum dan sesudah tuning dengan metrik JMX MaximumLagInMs dan jumlah record per detik. Jangan menaikkan nilai secara membabi buta — uji bertahap.

#Parallelism, Task Configuration, dan Partisi Kafka

Throughput juga dibatasi oleh partisi topic. Satu partisi hanya bisa dibaca satu konsumen dalam satu group, dan event untuk satu baris selalu ke satu partisi:

docker exec -it kafka /opt/kafka/bin/kafka-topics.sh \
  --bootstrap-server localhost:9092 \
  --alter --topic dbserver1.inventory.customers \
  --partitions 12

Sesuaikan tasks.max dengan jumlah partisi agar task konsumen bisa memanfaatkannya. Namun untuk source connector seperti Debezium, satu task per database adalah normal — parallelism sejati diperoleh dengan menjalankan beberapa connector atau menambah worker, bukan sekadar menaikkan tasks.

#Tune Database Sumber untuk CDC Workload

Database sumber perlu dikonfigurasi agar log perubahan tersedia cukup lama dan tidak menjadi bottleneck:

Untuk MySQL, pastikan binlog berbasis row dan tidak cepat kedaluwarsa:

server-id = 1
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
binlog_expire_logs_seconds = 2592000

Dengan binlog_format = ROW, perubahan direkam per baris, bukan per statement — prasyarat Debezium. Untuk PostgreSQL, siapkan wal_level = logical, max_replication_slots, dan max_wal_senders yang cukup untuk slot Debezium.

#Meminimalkan Dampak ke Sistem OLTP

Sumber daya yang dipakai snapshot atau streaming adalah sumber daya yang tidak melayani aplikasi. Cara meminimalkan dampak:

• Jadwalkan snapshot pada jam sepi atau pakai incremental snapshot.
• Batasi ukuran batch agar beban per sesi terbatas.
• Pantau metrik database seperti thread count dan binlog throughput selama snapshot.

Untuk mengontrol beban, aktifkan batasan batching yang lebih konservatif pada connector produksi:

{
  "snapshot.fetch.size": "1000",
  "incremental.snapshot.chunk.size": "256",
  "max.batch.size": "500"
}

Nilai incremental.snapshot.chunk.size: "256" membuat chunk kecil sehingga jeda antar chunk memberi ruang bagi workload OLTP. Observasi metrik database selama beberapa menit setelah tuning untuk memastikan tidak ada lonjakan negatif.

#Pengukuran Sebelum dan Sesudah Tuning

Tanpa pengukuran, tuning hanyalah tebakan. Siapkan baseline sebelum mengubah apa pun:

• Catat throughput event per detik selama beban normal.
• Catat latency maksimum streaming dari metrik JMX.
• Catat beban database sumber — CPU, thread, dan I/O.

Setelah mengubah satu properti, bandingkan hasilnya dengan baseline. Jika throughput tidak naik tapi beban database melonjak, kembalikan perubahan dan cari penyebab lain — sering kali bottleneck ada di jaringan atau di partisi topic, bukan di worker.

Uji setiap perubahan di lingkungan staging terlebih dahulu, lalu terapkan ke produksi satu per satu. Perubahan kecil yang terukur lebih mudah dilacak dampaknya dibandingkan mengubah banyak properti sekaligus.

#Penutup

Episode 15 memberi kalian cara mengukur dan mengoptimalkan performa: tuning batch di worker, mempercepat snapshot dengan thread paralel, menyesuaikan partisi dan tasks, menyiapkan log database untuk CDC, dan membatasi beban agar tidak menekan sistem OLTP.

Inti yang harus dibawa pulang:

• Throughput dikendalikan max.batch.size, max.queue.size, dan snapshot.max.threads.
• Partisi topic membatasi parallelism konsumen; sesuaikan dengan kebutuhan.
• MySQL butuh binlog_format = ROW; PostgreSQL butuh wal_level = logical.
• Snapshot agresif menambah beban ke database sumber — jadwalkan dengan hati-hati.
• Ukur metrik database dan JMX sebelum dan sesudah setiap perubahan tuning.

Di episode 16 selanjutnya kita akan membahas multi-database dan multi-cluster CDC — menangani banyak sumber database dan topologi multi-cluster, konfigurasi connector untuk heterogeneous schema, dan pola integrasi data lintas database.