Belajar Microservices - Scaling: KEDA, HPA & Kapasitas

#Pendahuluan

Tokokita sekarang bisa dilihat (observability, episode 20). Pertanyaan selanjutnya, saat traffic naik: bagaimana cara menumbuhkan kapasitas tanpa over-provision? Episode ini membahas scaling — mekanisme horizontal, kapan tiap mekanisme tepat, dan bagaimana tidak membeli cluster yang tidak terpakai.

Mengapa episode ini penting? Karena skala yang salah adalah pemborosan dalam dua arah: under-provision = outage saat lonjakan; over-provision = uang terbakar untuk CPU yang menganggur. Pola scaling yang benar bergantung pada jenis layanan — API memiliki pemicu berbeda dari worker Kafka.

#HPA: Autoscale dari CPU / Request Rate

Horizontal Pod Autoscaler (HPA) menambah/mengurangi jumlah pod berdasarkan metrik. Dua sumber utama:

• CPU/memory utilization — naikkan replica saat CPU rata-rata pod menembus target.
• Custom metrics — misal request-per-second dari Prometheus (lewat Prometheus Adapter).

apiVersion: autoscaling.k8s.io/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-gateway-hpa
  namespace: tokokita
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-gateway
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "200"

Semakin sering custom metrics dipakai, semakin baik reactive terhadap apa yang user rasakan (request rate & latency) dibanding CPU yang bisa tersembunyi oleh inefficiency.

#KEDA: Scale dari Event Queue Length

Webservice diskala karena request masuk. Worker berbeda nasibnya: dia diskala karena antrian. Antrian-nya adalah consumer lag Kafka — berapa banyak pesan yang belum diproses. Di situlah KEDA (Kubernetes Event-Driven Autoscaling) bekerja: ia membaca metrik sumber (scaler) dan meminta HPA menyesuaikan pod worker.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: notification-worker-scaler
  namespace: tokokita
spec:
  scaleTargetRef:
    name: notification-service
  pollingInterval: 15
  minReplicaCount: 1
  maxReplicaCount: 20
  triggers:
    - type: kafka
      metadata:
        topic: order-events
        bootstrapServers: kafka:9092
        consumerGroup: notification-service
        lagThreshold: "100"   # scale naik jika lag > 100 pesan

Ketika order-events menumpuk 10.000 pesan saat flash sale, worker otomatis menanjak ke 20 pod; saat antrian kosong, kembali ke 1. Inilah lompatan besar dari "autoscale CPU" konvensional — sinyalnya ekonomi dan sengaja berlag: lag adalah permintaan yang belum terlayani, bukan sekadar beban CPU.

#Pola Scaling per Tipe

Tiga profil layanan tokokita dan pemicunya:

Database adalah kasus khusus. Autoscale horisontal MySQL/PG tidak sesederhana app stateless. Jalan yang benar berurutan: naikkan resource (scale-up) → tambah read replica untuk baca → sharding/partitioning bila perlu → pindahkan service ke database masing-masing. Tokokita sudah database-per-service sejak episode 2 — langkah terakhir tidak pernah terlalu jauh.

#Capacity Planning: Request vs Limit

Sebelum HPA bisa men-skalakan, kalian harus tahu berapa "unit" pod. Ini hidup atau mati capacity planning:

• requests (jaminan minimum, dipakai scheduler untuk memutuskan penempatan) dan limits (batas maksimum, berpotensi throttle).
• Kesalahan umum: requests == limits (boros), atau tanpa request (scheduler memenangkan pods riskan "evicted saat cluster penuh").

product-service:  request {cpu 100m, mem 128Mi} / limit {cpu 400m, mem 512Mi}
notification:     worker sifatnya memory-light → request mem kecil, retry jangan pancarkan CPU
api-gateway:      latency-sensitive → request CPU lebih besar + HPA custom (RPS)

Untuk menghitung skala: dari kapasitas 1 pod dan target p95, hitung replica = peak_RPS / (RPS_per_pod × util_target). Data RPS per pod datang dari metrik (episode 20).

#Monitoring Utilization

Terakhir — jangan lupa memantau siklus scaling itu sendiri:

• Permission: dashboard HPA (kubectl get hpa + metrics detail).
• Awas flapping: scaling naik-turun tidak stabil (churn) itu mahal; atur cooldown/stabilizationWindow di HPA dan pollingInterval KEDA.
• Idle cost: aturan minReplicas yang pas (2 untuk HA, bukan 1 apalagi 20).

#Penutup

Episode 21 mengatur skala tokokita:

• HPA: skala dari CPU/utilisasi & request rate (custom metrics via Prometheus).
• KEDA: worker diskala dari consumer lag Kafka (queue length) — sinyal permintaan tak terlayani.
• Pola scaling: web/API → HPA; worker → KEDA; database → scale-up + read replica dulu.
• Capacity planning: request vs limit per service; replica = peak_RPS / (RPS per pod × target util).
• Pantau: churn/flapping, idle cost, minReplicas yang realistis.

Di episode 22 selanjutnya, giliran testing microservices — unit test untuk handler dan use-case, contract testing dengan Pact agar deploy independen tetap aman, integration/e2e lewat Compose penuh, Testcontainers untuk boot PostgreSQL/Kafka saat CI, dan quality gate per service. Sampai jumpa di episode 22!