Belajar Multigress - Performance Tuning & Scalability

#Pendahuluan

Gateway yang lambat membuat semua service di belakangnya ikut lambat. Episode 15 membahas performance tuning dan scalability Multigress: menyetel resource dan concurrency, mengoptimalkan evaluasi route serta koneksi ke backend, dan men-skalakan gateway secara horizontal dengan autoscaling.

Tujuan episode ini sederhana: gateway harus menangani traffic sebanyak mungkin dengan resource sekecil mungkin, tanpa mengorbankan latensi.

#Resource Sizing dan Concurrency

#Menentukan CPU dan Memory

Mulailah dari nilai yang wajar lalu ukur. Konfigurasi resource gateway dilakukan lewat values Helm, dan bisa disetel tanpa mengubah kode.

helm upgrade multigress multigress/multigress \
  --namespace multigress-system \
  --set gateway.resources.requests.cpu=500m \
  --set gateway.resources.requests.memory=512Mi \
  --set gateway.resources.limits.cpu=2000m \
  --set gateway.resources.limits.memory=2Gi

Request 500m CPU menjamin jatah CPU di scheduler, sedangkan limit 2000m membatasi pemakaian maksimal. Nilai requests yang terlalu kecil membuat pod berbagi CPU dengan sesama dan menimbulkan latensi yang tidak stabil.

#Concurrency dan Worker Threads

Data plane berbasis Envoy memproses request dengan worker thread. Jumlah worker diidealkan mendekati jumlah core node, karena thread yang terlalu sedikit menyia-nyiakan CPU dan yang terlalu banyak memicu kontensi scheduler.

helm upgrade multigress multigress/multigress \
  --namespace multigress-system \
  --set gateway.concurrency=4

Nilai concurrency ini disuntikkan sebagai jumlah worker thread. Setelah berubah, pantau latensi P95 selama beban normal: kalau menurun saat worker ditambah, berarti gateway sebelumnya kekurangan thread.

#Optimasi Route Evaluation dan Koneksi Backend

#Connection Pool

Membuka koneksi TCP baru untuk setiap request itu mahal. Multigress memakai connection pool untuk mengulang koneksi ke backend, dan kalian bisa menyetel batasnya.

apiVersion: gateway.multigress.io/v1
kind: BackendTrafficPolicy
metadata:
  name: backend-pool
  namespace: platform
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: api-route
  connectionPool:
    tcp:
      maxConnections: 512
      connectTimeout: 5s
    http:
      h2MaxConcurrentStreams: 100
      maxRequestsPerConnection: 1000

maxConnections: 512 membatasi koneksi TCP simultan ke satu backend, sedangkan h2MaxConcurrentStreams mengatur banyaknya stream HTTP/2 dalam satu koneksi. Konfigurasi ini melindungi backend dari lonjakan sekaligus menjaga reuse koneksi.

#Timeout untuk Melindungi Backend

Timeout mencegah request yang macet menggantung koneksi. Kombinasi request timeout dan idle timeout menjaga pool tetap sehat.

apiVersion: gateway.multigress.io/v1
kind: BackendTrafficPolicy
metadata:
  name: backend-timeouts
  namespace: platform
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      name: api-route
  timeouts:
    requestTimeout: 10s
    idleTimeout: 60s

Nilai requestTimeout: 10s memutuskan request yang melebihi 10 detik, dan idleTimeout menutup koneksi yang menganggur terlalu lama. Backend yang lambat tidak akan pernah menguras pool selamanya.

#Horizontal Scaling dan Autoscaling

#Scale Manual dan HPA

Mulai dengan scale manual untuk menguji konfigurasi, lalu beralih ke HorizontalPodAutoscaler agar jumlah pod menyesuaikan beban.

kubectl scale deployment multigress-gateway -n multigress-system --replicas=4
kubectl rollout status deployment multigress-gateway -n multigress-system

#Autoscaling Berbasis CPU

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: multigress-gateway
  namespace: multigress-system
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: multigress-gateway
  minReplicas: 2
  maxReplicas: 8
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA menambah replica ketika pemakaian CPU rata-rata melewati 70 persen dan menyusutkannya kembali saat beban turun. Batas minReplicas: 2 menjaga availability minimal, dan maxReplicas: 8 membatasi biaya.

#Benchmark untuk Menemukan Bottleneck

Perubahan tuning harus dibuktikan dengan beban. Alat sederhana seperti hey sudah cukup untuk membedakan konfigurasi yang lebih baik.

hey -n 10000 -c 200 http://api.example.com/health
kubectl get hpa multigress-gateway -n multigress-system

Perintah hey -n 10000 -c 200 menekan endpoint health dengan 200 koneksi paralel. Sambil berjalan, amati HPA menambah replica dan bandingkan latensi P95 sebelum serta sesudah tuning.

#Penutup

Episode 15 membuat gateway kalian siap menahan beban: resource dan concurrency disetel berdasarkan pengukuran, connection pool dan timeout menjaga koneksi backend tetap efisien, serta HPA membuat kapasitas mengikuti permintaan.

Inti yang harus dibawa pulang:

• Resource request menjamin jatah; limit membatasi pemakaian maksimal.
• Worker thread ideal mendekati jumlah core node.
• Connection pool mengurangi biaya membuka koneksi baru.
• Timeout mencegah request macet menggantung pool.
• HPA berbasis CPU menambah replica saat pemakaian melewati target.
• Benchmark diperlukan untuk membuktikan setiap keputusan tuning.

Di episode 16 selanjutnya kita akan membahas extensions & plugin ecosystem — integrasi dengan Envoy filters dan custom plugin, advanced filter chain untuk transformasi request, serta memanfaatkan tools pihak ketiga untuk keamanan dan observability. Gateway yang sudah cepat akan kalian perpanjang dengan kemampuan baru.