Belajar Apache Flink - Performance Tuning

#Pendahuluan

Episode 14 mengatur sumber daya; episode 15 ini mengoptimalkan cara kerja internal Flink. Banyak job "berjalan" tetapi boros: operator yang mestinya bisa digabung malah terpisah, checkpoint yang terlalu sering menggerus throughput, atau state yang membengkak tanpa batas. Tuning adalah ilmu menghilangkan pemborosan itu.

Kita akan mengoptimalkan job graph dan operator chaining, menyetel checkpoint interval dan ukuran state, tuning garbage collection, dan menutup dengan cara mengukur throughput serta latency end-to-end. Seluruh praktik di episode ini mengikuti satu prinsip: ukur dulu, ubah, lalu ukur lagi.

#Optimasi Job Graph dan Operator Chaining

#Chaining Mengurangi Overhead

Flink menggabungkan operator berdekatan tanpa state menjadi satu task untuk menghindari overhead serialisasi antar operator. Hasilnya: throughput naik, latency turun, dan resource lebih hemat. Chaining terjadi otomatis — dan bisa kalian kendalikan:

source
    .map(new ParseOrder()).startNewChain()
    .keyBy(Order::getUserId)
    .window(TumblingEventTimeWindows.of(Time.minutes(1)))
    .reduce(new SumOrder()).disableChaining()
    .sinkTo(sink);

startNewChain() memaksa operator map memulai rantai baru, dan disableChaining() memisahkan reduce agar tidak bergabung dengan operator berikutnya. Aturan praktis: biarkan chaining default, dan pisahkan hanya saat kalian ingin isolation (misalnya untuk parallelism berbeda).

#Membaca Job Graph

Di web dashboard, job graph memperlihatkan chaining sebagai blok-blok task. Semakin sedikit blok untuk beban kerja yang sama, semakin efisien. Jika kalian melihat banyak operator kecil terpisah yang seharusnya bisa berantai, pertimbangkan menyederhanakan pipeline.

#Checkpoint Interval dan State Size

#Menyetel Interval dengan Bijak

Checkpoint melindungi kalian dari kegagalan, tetapi setiap checkpoint mengonsumsi resource. Interval yang terlalu sering menurunkan throughput; yang terlalu jarang memperpanjang waktu recovery.

execution.checkpointing.interval: 2min
execution.checkpointing.min-pause: 30s
execution.checkpointing.tolerable-failed-checkpoints: 2
execution.checkpointing.unaligned.enabled: true

execution.checkpointing.unaligned.enabled memungkinkan checkpoint tanpa menunggu barrier menyebar — mempercepat checkpoint pada job dengan backpressure tinggi, dengan trade-off ukuran state naik. Gunakan hanya jika standard checkpoint melambat.

#Membatasi Ukuran State dengan TTL

State yang tak pernah kedaluwarsa adalah pemborosan paling umum. Beri TTL pada state:

import org.apache.flink.api.common.state.StateTtlConfig;
import org.apache.flink.api.common.time.Time;
 
StateTtlConfig ttlConfig = StateTtlConfig
    .newBuilder(Time.hours(24))
    .setUpdateType(StateTtlConfig.UpdateType.OnReadAndWrite)
    .cleanupInRocksdbCompactFilter(1000)
    .build();

cleanupInRocksdbCompactFilter membersihkan state kedaluwarsa saat compaction RocksDB — tanpa itu, TTL hanya ditandai dan tidak benar-benar dibuang sampai ada akses. State yang ramping membuat checkpoint lebih ringan dan GC lebih senang.

#Garbage Collection Tuning

#Mengurangi Pause GC

Job dengan banyak objek sementara memicu garbage collection yang bisa membuat latency melonjak. JVM options untuk TaskManager disetel di config.yaml:

env.java.opts.taskmanager: -XX:+UseG1GC -Xms1g -Xmx1g
taskmanager.memory.managed.fraction: 0.4

env.java.opts.taskmanager menyuntikkan flag JVM. G1GC adalah default modern yang membagi heap menjadi region dan meminimalkan pause. Kurangi alokasi sementara di kode (misalnya reuse objek di operator) karena itu berdampak lebih besar daripada flag JVM apa pun.

#Menyeimbangkan Managed Memory

taskmanager.memory.managed.fraction mempartisi heap untuk state. Semakin besar untuk RocksDB, semakin kecil untuk objek dan GC — temukan keseimbangan dengan mengamati metric heap usage dan durasi GC di dashboard.

#Benchmarking Throughput dan Latency

#Mengukur dengan DataGen

Untuk benchmark, gunakan DataGen sebagai sumber agar beban terkendali:

./bin/flink run -d -p 4 target/bench-job.jar

Setelah berjalan, baca metric dari REST API:

curl -s http://localhost:8081/jobs/overview

curl -s http://localhost:8081/jobs/overview memberi daftar job; dari sana metric numRecordsOutPerSecond menunjukkan throughput, dan metric latency watermark menampilkan delay end-to-end. Catat baseline sebelum tuning dan bandingkan setelah setiap perubahan.

#Latency End-to-end

Latency end-to-end diukur dari metric watermark: selisih antara event time terbaru dan processing time saat ini menunjukkan seberapa jauh pipeline tertinggal. Latency yang naik bersama backpressure biasanya menunjuk operator tertentu — perbaiki operator itu, bukan menyetel global.

ukur baseline → ubah satu variabel → ukur ulang → pertahankan yang lebih baik

#Penutup

Episode 15 mengubah job yang berjalan menjadi job yang efisien: menyusun job graph dengan chaining yang tepat, menyetel interval checkpoint dan TTL state, tuning GC lewat JVM options, serta benchmarking throughput dan latency dengan metrik yang terukur.

Inti yang harus dibawa pulang:

• Biarkan chaining default; pisahkan hanya saat butuh isolation.
• Interval checkpoint menyeimbangkan throughput dan waktu recovery.
• TTL state dengan cleanup RocksDB mencegah state membengkak.
• Flag JVM membantu, tetapi mengurangi alokasi di kode lebih efektif.
• Ukur baseline, ubah satu variabel, lalu bandingkan hasilnya.

Di episode 16 selanjutnya kita akan membahas savepoints, upgrades & migration — memahami siklus hidup savepoint dan kompatibilitas versi, melakukan job upgrades dan migrasi state, strategi rollback, serta menguji restore savepoint di staging. Kalian akan belajar mengubah job produksi tanpa kehilangan satu pun state.