Belajar KEDA - Database & HTTP Scalers

#Pendahuluan

Di episode 8 kita membahas scaler untuk queue dan stream — sumber sinyal paling populer. Namun tidak semua sistem memakai broker. Banyak workload legacy menyimpan "antrean" langsung di database: baris pesanan yang belum diproses, tabel job yang berstatus pending. Di episode ini kita belajar membaca sinyal itu lewat database scalers, lalu mengenal KEDA HTTP Add-on yang membuat scale-to-zero untuk workload HTTP menjadi aman.

#Database Scalers: Metrik dari Data Langsung

Kadang sumber kebenaran sebuah workload adalah baris data di database, bukan pesan di broker. Database scaler mengeksekusi query pada setiap polling dan menggunakan hasilnya sebagai metrik.

#PostgreSQL: Query-Based Scaling

ScaledObject PostgreSQL

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: postgres-auth
spec:
  secretTargetRef:
    - parameter: connection
      name: postgres-secret
      key: connection
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: report-worker-scaler
spec:
  scaleTargetRef:
    name: report-worker
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: postgresql
      authenticationRef:
        name: postgres-auth
      metadata:
        query: SELECT COUNT(*) FROM pending_reports WHERE status = 'queued'
        targetQueryValue: "50"
        activationQueryValue: "5"

Query dijalankan pada setiap pollingInterval. Hasilnya dibagi targetQueryValue untuk menentukan jumlah replika — 120 baris dengan target 50 berarti 2 replika. Pantau statusnya lewat kubectl get scaledobject -n production.

#MySQL

Identik dengan PostgreSQL, ganti type dan parameter koneksinya — pola secretTargetRef tetap sama.

Trigger MySQL

    - type: mysql
      authenticationRef:
        name: mysql-auth
      metadata:
        query: SELECT COUNT(*) FROM invoices WHERE status = 'pending'
        targetQueryValue: "100"

#Redis List Length

Redis list bekerja seperti queue primitif: LPUSH menambahkan pekerjaan, RPOP mengambil. KEDA mengukur panjang list tersebut, dengan pola secret yang sama seperti PostgreSQL.

    - type: redis
      authenticationRef:
        name: redis-auth
      metadata:
        listName: thumbnail-jobs
        listLength: "5"
        activationListLength: "2"

#MongoDB

MongoDB diskalakan berdasarkan jumlah dokumen yang cocok dengan query JSON.

Trigger MongoDB

    - type: mongodb
      authenticationRef:
        name: mongodb-auth
      metadata:
        dbName: app
        collection: jobs
        query: '{ "status": "queued" }'
        queryValue: "20"

#Kapan Database Scaler Tepat Digunakan

Database scaler paling pas saat: data sudah hidup di tabel atau collection dan migrasi ke broker terlalu mahal; workload batch kecil yang jarang; atau proses yang bisa dihitung dengan query ringan. Sebaliknya, hindari untuk pipeline throughput tinggi — broker seperti Kafka atau Redis Streams tetap pilihan utama karena lebih ringan untuk polling.

#HTTP Add-on dan HTTPScaledObject

#Mengapa Perlu HTTP Add-on

Scaler http di episode 7 hanya membaca metrik — ia tidak menahan request. Konsekuensinya, scale-to-zero untuk workload HTTP berisiko: saat nol pod, request yang masuk langsung gagal. KEDA HTTP Add-on menyelesaikan masalah ini dengan menyisipkan interceptor di depan aplikasi.

#Arsitektur Singkat

Ketika pod turun ke nol, interceptor tetap hidup. Ia menahan (buffer) request yang masuk, menghitungnya sebagai pending requests, lalu memberi tahu scaler. Begitu jumlah pending melewati ambang, pod dinaikkan dan request dibebaskan.

#HTTPScaledObject

HTTPScaledObject

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: web-app
spec:
  hosts:
    - api.contoh.com
  scaleTargetRef:
    deployment: web-app
    service: web-app-svc
    port: 8080
  replicas:
    min: 0
    max: 10
    activation: 20
  scalingMetric:
    targetPendingRequests: 100

hosts menentukan domain yang dialihkan ke interceptor. replicas.activation: 20 berarti pod baru dibangunkan dari nol ketika ada 20 request pending, dan targetPendingRequests: 100 menargetkan satu pod per 100 request yang sedang menunggu.

#Penutup

• PostgreSQL/MySQL: scaling berbasis query COUNT, cocok untuk workload berbasis tabel.
• Redis list: queue primitif dengan listLength dan activationListLength.
• MongoDB: scaling berdasarkan jumlah dokumen yang cocok dengan query JSON.
• Database scaler untuk sistem berbasis data; broker tetap juara untuk throughput tinggi.
• HTTP Add-on memperkenalkan HTTPScaledObject: interceptor menahan request saat scale-to-zero dengan targetPendingRequests, min, dan max.

Semua scaler sejauh ini sudah built-in di KEDA. Di episode 10 kita naik level: membuat custom scaler gRPC untuk sistem internal kalian sendiri, memahami jalur komunikasi KEDA dengan HPA melalui External Metrics API, dan meracik kombinasi multi-trigger AND/OR dalam satu ScaledObject. Sampai jumpa!