Belajar Apache Spark - Operational Readiness & Runbooks

#Pendahuluan

Pipeline yang berjalan tanpa masalah selama berbulan-bulan tetap harus siap menghadapi kegagalan. Episode 19 ini membahas operational readiness: apa yang dilakukan sebelum, saat, dan setelah sesuatu rusak. Ini adalah perbedaan antara tim yang panik saat job gagal dan tim yang menangani kegagalan secara tenang dan sistematis.

Kegagalan dalam data engineering jarang berupa ledakan tunggal. Biasanya berlapis: job retry terus, data korup di tengah malam, cluster kehabisan disk, atau perubahan skema menyebabkan pipeline diam-diam menghasilkan output salah. Tanpa runbook dan prosedur, setiap kejadian berubah menjadi investigasi improvisasi yang panjang.

Episode ini membahas empat topik: menyusun runbook untuk job failure dan recovery, incident response untuk cluster dan data corruption, backup konfigurasi dan artifacts, serta chaos testing pada Spark pipelines.

#Menyusun Runbook untuk Job Failure, Retries, dan Recovery

#Struktur Runbook

Runbook adalah dokumen langkah-demi-langkah yang dipakai saat sistem bermasalah. Setiap runbook yang baik punya bagian:

• Gejala: cara mengenali masalah — error message, metrik, atau alert.
• Severity: dampak — misalnya P1 (produksi berhenti) sampai P4 (dampak kecil).
• Langkah triase: pemeriksaan cepat untuk mempersempit penyebab.
• Tindakan remediasi: perintah untuk memulihkan layanan.
• Escalation path: siapa yang dihubungi jika langkah tidak berhasil.

1. Gejala   → alert SparkJobFailed, status aplikasi failed
2. Cek      → log driver, Spark UI, resource cluster
3. Diagnosis → apakah retry transient (OOM, jaringan) atau bug kode
4. Tindakan → restart dengan resource lebih besar / fix kode dan redeploy
5. Escalasi → oncall data platform jika lebih dari 30 menit

#Retry dan Backoff

Job batch yang gagal sebaiknya dijadwalkan ulang dengan retry dengan backoff, bukan restart manual tanpa batas. Di Kubernetes, ini bisa diatur lewat Job retry policy; di scheduler seperti Airflow, lewat parameter retries dan retry_delay. Batasi retry maksimum agar kegagalan permanen tidak menghabiskan resource.

#Incident Response untuk Cluster Issues dan Data Corruption

#Menangani Cluster Issue

Saat cluster tidak sehat, ikuti urutan triase:

1. Periksa kesehatan node: metrik CPU, memory, disk, dan network di dashboard.
2. Periksa scheduler: apakah executor tidak bisa diluncurkan karena resource habis.
3. Periksa aplikasi: apakah satu job boros dan memblokir yang lain.
4. Tindakan: isolasi job bermasalah, naikkan resource, atau tunda workload non-prioritas.

kubectl top nodes
kubectl top pods -n spark-jobs

kubectl top nodes menampilkan pemakaian resource — titik awal yang cepat untuk melihat apakah cluster kekurangan CPU atau memori.

#Menangani Data Corruption

Data korup lebih berbahaya karena tidak selalu terlihat. Tindakan yang benar:

• Jangan langsung menimpa: identifikasi extent kerusakan dengan sampling dan checksum.
• Cari sumber: cek apakah kode baru, perubahan schema, atau penulisan paralel yang menyebabkan.
• Pulihkan dari versi baik: pakai time travel (Delta/Iceberg) atau backup terakhir yang valid.
• Root cause: perbaiki proses — bukan hanya datanya — supaya tidak terulang.

#Backup Config, Metadata, dan Artifacts

#Apa yang Perlu Dibackup

Bukan hanya data yang perlu dilindungi:

• Konfigurasi: spark-defaults.conf, metrics.properties, dan properti deployment.
• Metadata: event logs, catalog metadata (misalnya metastore Hive), dan schema registry.
• Artifacts: jar library dan versi image yang dipakai untuk rebuild.

spark-defaults.conf, spark-env.sh   → konfigurasi
event logs / metastore dump          → metadata
jar library + image digests          → artifacts
notebook & kode pipeline             → source of truth

#Strategi Backup yang Baik

• Version control untuk semua konfigurasi dan kode — bukan salinan manual.
• Snapshot berkala untuk metastore dan metadata yang berubah.
• Image digests disimpan agar bisa merekonstruksi lingkungan yang sama persis.
• Uji pemulihan (restore test) secara berkala — backup yang tidak pernah diuji adalah ilusi keamanan.

#Chaos Testing pada Spark Pipelines

#Konsep Chaos Engineering

Chaos testing adalah sengaja memasukkan kegagalan ke sistem untuk menemukan kelemahan sebelum kegagalan itu terjadi sendiri. Untuk Spark, ini bisa berarti:

• Membunuh executor secara acak saat job berjalan.
• Memutus jaringan antar node.
• Menghentikan Kafka atau database di tengah streaming.
• Menguras disk hingga hampir penuh.

kubectl delete pod spark-executor-xxx --grace-period=1

kubectl delete pod ... --grace-period=1 memaksa executor mati secara mendadak. Spark harus me-restart task yang terdampak dan job tetap selesai — kalau tidak, itu temuan yang perlu diperbaiki.

#Menjalankan Chaos Secara Terkontrol

Praktik yang aman:

• Lakukan di environment staging terlebih dahulu.
• Mulai dengan kegagalan kecil (satu executor) lalu naikkan tingkatnya.
• Ukur metrik seperti recovery time dan data loss setelah setiap percobaan.
• Dokumentasikan temuan dan perbaiki kelemahan yang muncul.

#Penutup

Episode 19 menuntaskan kesiapan operasional: runbook memberi langkah yang jelas saat job gagal, incident response menangani cluster dan data corruption secara sistematis, backup melindungi konfigurasi dan artifacts, dan chaos testing menguji asumsi tentang ketahanan sebelum produksi membuktikan sebaliknya.

Inti yang harus dibawa pulang:

• Runbook adalah langkah tertulis untuk gejala, triase, remediasi, dan escalation.
• Retry memakai backoff dan batas maksimum, bukan restart tanpa batas.
• Data corruption ditangani tanpa menimpa sebelum identifikasi sumber.
• Backup mencakup konfigurasi, metadata, artifacts, dan kode — bukan hanya data.
• Chaos testing mengungkap kelemahan dengan kegagalan yang disengaja dan terkontrol.

Di episode 20 selanjutnya kita akan membahas real-world use cases dan patterns — contoh pipeline ETL, real-time analytics, dan recommendation systems, design patterns untuk reliabilitas pipeline, monitoring business metrics dan data quality, serta arsitektur end-to-end untuk batch dan streaming.