Belajar KEDA - Best Practice & Cost

#Pendahuluan

Di episode 14 kita mengamankan KEDA untuk pemakaian multi-tim dengan RBAC, admission webhook, dan policy. Sekarang pertanyaan yang paling sering diajukan: berapa besar biaya yang benar-benar bisa dihemat? Jawabannya ada di konfigurasi, bukan di tool-nya. Dua ScaledObject dengan workload identik bisa berbeda biaya 40% hanya karena tuning activationThreshold dan cooldownPeriod yang berbeda. Episode ini membahas Best Practice & Cost — FinOps untuk workload event-driven dan cara menjaganya tetap andal saat skala berubah.

#FinOps: Scale-to-Zero untuk Batch & AI Inference

Scale-to-zero adalah kemenangan terbesar FinOps dengan KEDA. Workload batch dan AI inference punya karakteristik alami: sibuk tinggi, lalu diam lama. Menjaga 10 GPU atau 20 CPU online padahal antrian kosong sama dengan membakar uang.

Keda rujukan: CNCF graduated project, versi stabil v2.20.2 (Juli 2026). Konfigurasi minReplicaCount: 0 membuat replika turun ke nol saat tidak ada event. Berikut ScaledObject untuk worker inference berbasis Redis list:

scaledobject-inference.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: inference-worker
  namespace: ml
spec:
  scaleTargetRef:
    name: inference-worker
  pollingInterval: 15
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: redis
      metadata:
        address: redis.ml.svc:6379
        listName: inference-jobs
        listLength: "10"

#Berapa Besar Penghematannya?

Angka 40-60% itu bukan klaim kosong — persentase ekivalen dengan proporsi waktu idle yang berhasil dipotong. AI inference yang hanya sibuk 4 jam per hari dan dikurangi ke nol di luar itu menghemat sekitar 60% biaya compute, karena CPU/GPU hanya dibayar saat bekerja.

#Activation & Menghindari Thrashing

activationThreshold adalah kunci agar KEDA tidak menyalakan replika karena noise. Tanpa activation, satu pesan tunggal bisa memicu scale-up — replika hidup, tidak ada pesan berikutnya, lalu turun lagi. Naik-turun berulang seperti ini disebut thrashing.

Pada contoh SQS di bawah, activationThreshold: 5 berarti replika hanya dinyalakan saat lebih dari 5 pesan mengantre — menyaring lonjakan sementara:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-worker
  namespace: orders
spec:
  scaleTargetRef:
    name: order-worker
  pollingInterval: 15
  cooldownPeriod: 180
  minReplicaCount: 0
  maxReplicaCount: 30
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.ap-southeast-1.amazonaws.com/1234/orders
        queueLength: "10"
      authenticationRef:
        name: sqs-auth

Padukan dengan cooldownPeriod yang cukup (180-300 detik): periode tanpa event sebelum replika diturunkan. Terlalu pendek membuat workload turun-ngebut; terlalu panjang menahan replika idle dan membuang biaya. Tuning keduanya adalah aktivitas iteratif — pantau dengan grafana.

#Reliability: Fallback & Min Replicas untuk Critical Path

Scale-to-zero menghemat biaya, tapi harus disertai jaring pengaman. KEDA punya fallback: saat scaler gagal (misal Prometheus tidak bisa di-query atau queue timeout), fallback.replicas menjaga replika minimum tanpa menunggu recovery scaler.

fallback-config.yaml

spec:
  scaleTargetRef:
    name: order-worker
  minReplicaCount: 0
  maxReplicaCount: 30
  fallback:
    failureThreshold: 3
    replicas: 4
  pollingInterval: 15

Arti konfigurasi di atas: jika scaler gagal 3 kali berturut-turut (failureThreshold: 3), KEDA menetapkan HPA ke 4 replika (fallback.replicas: 4) dan terus mencoba kembali. Ini perbedaan penting antara reliability dan resilience: scaler mungkin sedang down, tapi layanan tetap melayani.

Untuk critical path — payment processor, order intake, autentikasi — jangan set minReplicaCount: 0. Cold start dari nol bisa memakan 30-60 detik; latensi itu tidak bisa ditoleransi. Gunakan minReplicaCount kecil (misal 2) sebagai garis dasar, dan biarkan KEDA menambah replika di atasnya sesuai event. Biaya sedikit untuk jaminan ketersediaan jauh lebih murah daripada incident.

#Monitoring Aktivasi Scaler

Tidak ada yang lebih berbahaya dari autoscaler yang sering salah aktif — replika selalu menyala, tagihan membengkak, dan tidak ada yang sadar. Pantau metrik ekspos KEDA via Prometheus. Operator KEDA mengekspos metrik keda_scaler_* pada port 8080:

kubectl port-forward -n keda deploy/keda-operator 8080:8080
curl localhost:8080/metrics | grep keda_scaler_errors_total
kubectl get scaledobject -n orders

Metrik yang paling berguna — cek status cepat dengan kubectl get scaledobject -n orders lalu bandingkan dengan nilai metriknya:

Alarm sederhana yang menangkap thrashing: keda_scaler_activity berubah lebih dari beberapa kali per jam di satu workload, atau keda_scaler_errors_total bertambah terus. Pasang alert saat keda_scaledobject_ready bernilai 0 lebih dari 5 menit — ScaledObject yang tidak ready berarti autoscaling mati diam-diam.

#Kesalahan Umum

1. cooldownPeriod terlalu pendek — workload naik-turun terus, biaya naik karena startup tiap siklus.
2. activationThreshold = 0 default — setiap pesan memicu scale-up. Atur di atas noise normal.
3. Scale-to-zero di critical path tanpa fallback — satu kegagalan scaler menjadi outage layanan.
4. Tidak memantau keda_scaledobject_ready — autoscaling rusak diam-diam, replika tidak pernah naik saat antrean penuh.
5. Lupa cold start budget — image besar + GPU scheduling membuat pod butuh waktu lama; hitung dalam target responsivitas.

#Penutup

Episode ini menghubungkan biaya dan keandalan: scale-to-zero dengan minReplicaCount: 0 menghemat 40-60% untuk batch dan AI inference, activationThreshold mencegah thrashing, cooldownPeriod menjaga kestabilan, dan fallback plus min replicas melindungi critical path.

Poin yang harus kalian bawa:

• Scale-to-zero menghemat biaya sebesar proporsi waktu idle workload.
• activationThreshold + cooldownPeriod adalah dua tuning paling berdampak pada biaya.
• Fallback (failureThreshold + replicas) menjaga layanan saat scaler gagal.
• Critical path memakai minReplicaCount kecil, bukan nol.
• Pantau keda_scaler_* dan keda_scaledobject_ready — autoscaling yang tak terlihat adalah bom waktu.

Setelah cost dan reliability tertata, waktunya mengoptimalkan infrastruktur di balik pod. Di episode 16 selanjutnya kita membahas Integrasi dengan Karpenter: bagaimana KEDA menskalakan pod berdasarkan event sementara Karpenter menyediakan node dalam hitungan detik — dengan optimasi biaya gabungan spot dan consolidation. Sampai jumpa di episode 16!