Belajar Apache Flink - Scaling & Resource Management

#Pendahuluan

Episode 13 mengajarkan cara mengamati sistem. Episode 14 ini menggunakan data itu untuk mengambil tindakan: menambah atau mengurangi sumber daya. Skala di Flink tidak otomatis — kalian harus memahami cara menyetel parallelism, ukuran slot, dan state backend agar pipeline mampu mengikuti beban.

Kita akan membahas parallelism dan task slot sizing, autoscaling untuk Flink on Kubernetes, pengendalian backpressure dan throughput, serta perbandingan mendalam state backend RocksDB versus memory. Ini episode tempat teori tuning mulai menyatu menjadi praktik.

#Parallelism dan Task Slot Sizing

#Aturan Dasar Slot

Jumlah slot yang dibutuhkan job sama dengan parallelism-nya. Dua model umum:

• Slot besar per TaskManager: satu slot per subtask besar — cocok untuk job stateful berat.
• Banyak slot kecil per TaskManager: subtask kecil yang saling berbagi proses — cocok untuk job ringan dan hemat resource.

DataStream<Order> orders = source
    .map(new ParseOrder()).setParallelism(8)
    .keyBy(Order::getUserId)
    .process(new Aggregator()).setParallelism(4)
    .sinkTo(sink).setParallelism(2);

setParallelism memberi parallelism berbeda per operator sesuai beban. Parse yang ringan bisa berlari 8 subtask, agregasi yang stateful cukup 4, dan sink dibatasi 2 agar tidak membebani database tujuan.

#Mengukur Slot yang Tepat

Mulai dari CPU dan memory per TaskManager, lalu bagi dengan jumlah slot. Jika satu TaskManager punya 4 CPU dan 8GB memory, empat slot dengan 2GB masing-masing adalah titik awal yang wajar. Pantau di dashboard: jika semua slot penuh dan backpressure tinggi, naikkan parallelism; jika idle berkepanjangan, turunkan.

#Autoscaling Flink on Kubernetes

#Reactive Mode

Flink mendukung reactive mode untuk scaling otomatis berdasarkan parallelism: ketika jumlah TaskManager berubah, job menyesuaikan parallelism-nya tanpa restart. Aktifkan di config.yaml:

jobmanager.scheduler: reactive
parallelism.default: 2
taskmanager.numberOfTaskSlots: 1

jobmanager.scheduler: reactive membuat JobManager menghitung ulang parallelism dari jumlah slot yang tersedia. Dengan slot bernilai 1, penambahan TaskManager otomatis menaikkan parallelism — fondasi autoscaling di Kubernetes.

#Menggabungkan dengan HPA

Di Kubernetes, kombinasikan reactive mode dengan Horizontal Pod Autoscaler yang memantau metric seperti CPU atau throughput. Saat beban naik, HPA menambah replica TaskManager; reactive mode menyerap paralelisme baru tanpa menghentikan job. Ini pola autoscaling yang paling praktis untuk Flink produksi.

Scaling tidak selalu berarti menambah. Saat beban turun — misalnya malam hari untuk e-commerce — HPA mengurangi replica TaskManager dan reactive mode menurunkan parallelism. Job tidak pernah berhenti; ia mengecil dulu lalu membesar lagi saat lalu lintas pulih. Pastikan metric yang dipakai HPA mencerminkan beban nyata, bukan sekadar CPU yang bisa menyesatkan pada job yang menunggu data.

#Mengontrol Backpressure dan Throughput

#Menyetel Network Buffer dan Latency

Backpressure sering lahir dari buffer jaringan yang terlalu kecil. Ukuran buffer dan batas latency disetel di config:

taskmanager.memory.network.min: 64mb
taskmanager.memory.network.max: 128mb
execution.buffer-timeout: 100ms

execution.buffer-timeout mengontrol seberapa cepat record dikirim antar operator. Nilai kecil menurunkan latency tetapi menaikkan overhead; nilai besar meningkatkan throughput dengan mengorbankan latency. Temukan titik tengah yang sesuai kebutuhan kalian.

#Membaca Throughput

Throughput diukur dari metric numRecordsInPerSecond dan numRecordsOutPerSecond per operator. Turunnya output sementara input normal adalah ciri khas bottleneck. Setelah operator diperbaiki (parallelism naik, query dioptimalkan), bandingkan angka sebelum dan sesudah untuk memverifikasi perbaikan.

curl -s "http://localhost:8081/jobs/<jobId>/metrics?get=numRecordsOutPerSecond"

Perintah curl -s .../metrics?get=numRecordsOutPerSecond membaca nilai metric tertentu secara langsung — jauh lebih cepat daripada menebak dari dashboard.

#State Backend Optimization

#RocksDB vs Memory

Pilihan state backend memengaruhi batas skala:

• HashMap (memory): state di heap — sangat cepat, tetapi dibatasi ukuran memory dan rentan GC.
• RocksDB: state di disk lokal dengan cache memory — mampu menyimpan state raksasa, sedikit lebih lambat.

state.backend.type: rocksdb
state.backend.incremental: true
state.backend.rocksdb.memory.managed: true
taskmanager.memory.managed.fraction: 0.6

taskmanager.memory.managed.fraction menentukan porsi memory untuk state. Nilai 0.6 berarti 60 persen memory TaskManager dialokasikan ke RocksDB. Untuk state kecil, backend hashmap lebih sederhana; untuk state puluhan gigabyte, RocksDB adalah satu-satunya pilihan realistis.

#Praktik Mengurangi State

Ukuran state adalah biaya tersembunyi setiap job. Kurangi dengan: memakai MapState alih-alih ValueState untuk entitas banyak, menetapkan TTL state (dibahas episode 15), dan merancang key dengan granularitas yang tidak berlebihan. State yang ramping berarti checkpoint lebih cepat dan scaling lebih mudah.

#Penutup

Episode 14 membekali kalian dengan kendali sumber daya: menyetel parallelism dan slot per operator, menerapkan reactive mode dengan HPA untuk autoscaling Kubernetes, mengontrol backpressure melalui buffer dan timeout, serta memilih dan mengoptimalkan state backend RocksDB versus memory.

Inti yang harus dibawa pulang:

• Total slot harus menutupi parallelism; setel parallelism per operator sesuai beban.
• Reactive mode menyesuaikan parallelism dari jumlah slot tanpa restart job.
• execution.buffer-timeout menyeimbangkan latency dan throughput.
• RocksDB untuk state besar, hashmap untuk state kecil; sesuaikan managed fraction.
• State yang ramping membuat checkpoint dan scaling lebih efisien.

Di episode 15 selanjutnya kita akan membahas performance tuning — mengoptimalkan job graph dan operator chaining, menyetel checkpoint interval dan ukuran state, tuning garbage collection, serta mengukur throughput dan end-to-end latency. Episode ini mengubah job yang berjalan menjadi job yang cepat.