Belajar Apache Flink - Operational Readiness & Runbooks

#Pendahuluan

Semua teknik di series ini berujung pada satu pertanyaan praktis: ketika job produksi gagal di tengah malam, apakah kalian tahu apa yang harus dilakukan? Episode 19 ini menjawabnya dengan runbook — prosedur terdokumentasi yang membuat respons insiden menjadi refleks, bukan improvisasi.

Kita akan menyusun runbook untuk kegagalan job, merespons checkpoint failure dan job crash, menyiapkan backup serta disaster recovery, dan menutup dengan chaos testing untuk menguji ketahanan sistem secara sengaja. Tujuan akhirnya sederhana: kegagalan tidak mengejutkan tim kalian lagi.

#Menyusun Runbook

#Anatomi Runbook yang Baik

Runbook adalah dokumen langkah-demi-langkah untuk menangani situasi tertentu. Setiap runbook yang baik berisi:

• Gejala — apa yang dilihat tim saat incident terjadi.
• Penyebab umum — daftar hipotesis paling mungkin.
• Prosedur pemulihan — perintah persis yang harus dijalankan.
• Rollback — cara kembali ke kondisi stabil.

./bin/flink list -a
tail -n 100 $FLINK_HOME/log/taskexecutor.log
./bin/flink run -d -s /backups/savepoint-latest target/app.jar

./bin/flink list -a menunjukkan status job, tail -n 100 membaca log terakhir, dan ./bin/flink run -d -s me-restore dari savepoint. Runbook yang baik menuliskan langkah persis seperti ini — lengkap dengan contoh output yang diharapkan.

#Menulis dengan Cepat Dibaca

Simpan runbook di tempat yang bisa diakses dari mana saja saat incident. Format pendek lebih baik daripada lengkap: poin, perintah, dan expected output. Runbook yang terlalu panjang justru tidak dibaca saat sistem sedang bermasalah.

#Incident Response: Checkpoint Failure dan Job Crash

#Checkpoint Failure

Checkpoint yang terus gagal adalah peringatan dini. Penyebab umum: storage tidak bisa menampung state, ukuran state membesar cepat, atau waktu checkpoint melewati timeout. Respons yang benar:

1. Cek log untuk error spesifik saat snapshot.
2. Periksa kapasitas storage tempat checkpoint disimpan.
3. Jika state membengkak, terapkan TTL (episode 15) dan periksa hot key.

execution.checkpointing.interval: 5min
execution.checkpointing.min-pause: 2min
execution.checkpointing.tolerable-failed-checkpoints: 3

execution.checkpointing.tolerable-failed-checkpoints menoleransi beberapa kegagalan checkpoint sebelum job gagal total — memberi waktu untuk menangani penyebab tanpa panic.

#Job Crash dan Restart

Ketika job gagal, restart strategy menentukan pemulihan otomatis:

restart-strategy.type: exponential-delay
restart-strategy.exponential-delay.initial-backoff: 10s
restart-strategy.exponential-delay.max-backoff: 1min
restart-strategy.exponential-delay.backoff-multiplier: 2.0
restart-strategy.exponential-delay.reset-backoff-threshold: 1h

exponential-delay memperlama jeda antar percobaan restart — mencegah sistem hilir kebanjiran retry saat masalah belum selesai. Jika job berhenti karena crash berulang, jangan hanya restart: cari akar masalah di log dulu.

#Backup, Cluster Snapshots, dan Disaster Recovery

#Backup Savepoint

Savepoint adalah artefak yang harus dicadangkan. Kirim ke object storage yang terpisah dari cluster:

./bin/flink savepoint <jobId> s3://flink-backup/savepoints

./bin/flink savepoint dengan target s3:// menyimpan savepoint langsung ke lokasi tahan lama. Susun kebijakan: buat savepoint rutin sebelum upgrade besar dan pertahankan beberapa versi terakhir.

#Disaster Recovery Plan

Disaster recovery bukan hanya soal backup, tetapi urutan pemulihan yang teruji:

• Rebuild cluster di region atau environment baru.
• Restore konfigurasi dari versi control (git).
• Restore state dari savepoint terbaru.
• Verifikasi data mengalir dan metrik normal.

Tanpa latihan, plan DR hanyalah dokumen. Uji secara berkala agar urutannya terekam di ingatan tim.

#Chaos Testing

#Memutuskan Hal yang Sependapatnya Benar

Chaos testing sengaja memutuskan komponen untuk menguji ketahanan sistem:

./bin/taskmanager.sh stop
./bin/flink list -a

./bin/taskmanager.sh stop mematikan satu TaskManager secara paksa. Job yang sehat akan restart subtask-nya di sisa slot dan pulih dari checkpoint — jika tidak, ada celah yang perlu diperbaiki.

#Skenario Chaos yang Bernilai

Fokus pada skenario yang paling berdampak, bukan yang paling dramatis:

• Satu TaskManager mati mendadak.
• Jaringan antar TaskManager terputus sesaat.
• Storage checkpoint penuh atau lambat.
• Kafka down selama beberapa menit.

Catat hasil setiap percobaan ke runbook: apa yang terjadi, berapa lama recovery, dan apa yang diperbaiki. Chaos testing mengubah pengetahuan teoretis tentang fault tolerance menjadi bukti empiris.

#Penutup

Episode 19 menutup sisi operasional: menyusun runbook yang bisa dijalankan saat gempa, merespons checkpoint failure dan job crash dengan tenang, menyiapkan backup dan disaster recovery yang teruji, serta memvalidasi ketahanan melalui chaos testing.

Inti yang harus dibawa pulang:

• Runbook berisi gejala, penyebab, prosedur, dan rollback — ditulis pendek.
• Checkpoint failure sering berasal dari storage dan ukuran state; cek sebelum panik.
• Savepoint dicadangkan ke object storage sebagai fondasi disaster recovery.
• Plan DR harus diuji, bukan sekadar ditulis.
• Chaos testing mengubah klaim fault tolerance menjadi bukti.

Di episode 20 selanjutnya kita akan membahas real-time analytics & use cases — membangun dashboard monitoring dan alerting, menerapkan fraud detection, real-time recommendation, dan IoT processing, serta merancang end-to-end streaming pipeline dengan data enrichment dan stream joins. Semua teori yang sudah kalian pelajari akan dipertemukan dalam satu arsitektur nyata.