Produksi: HA, Kapasitas & Upgrade — Belajar Kong API Gateway

🏗️ Ketersediaan Tinggi

DB-less (paling sederhana):
  LB  ──>  Kong-1 (baca kong.yaml)
      ──>  Kong-2 (baca kong.yaml)
      ──>  Kong-3 (baca kong.yaml)
  Tiap simpul mandiri. Tidak ada state bersama.
  Deploy = perbarui berkas + muat ulang.

Berbasis database:
  LB  ──>  Kong-1 ──┐
      ──>  Kong-2 ──┼──> PostgreSQL (primer + replika)
      ──>  Kong-3 ──┘
  Basis data menjadi komponen yang juga harus dibuat HA.

💡 DB-less membuat HA jauh lebih mudah

Tanpa basis data bersama, setiap simpul Kong berdiri sendiri sepenuhnya. Tidak ada failover basis data yang perlu diurus, tidak ada lag replikasi, dan menambah simpul cukup dengan menjalankan kontainer baru yang membaca berkas yang sama. Ini alasan kuat memilih DB-less untuk beban kerja yang konfigurasinya tidak berubah saat runtime.

⚙️ Penyetelan Kapasitas

KONG_NGINX_WORKER_PROCESSES: "auto"    # = jumlah inti CPU
KONG_NGINX_WORKER_CONNECTIONS: "16384"
KONG_MEM_CACHE_SIZE: "512m"            # cache konfigurasi di memori
KONG_UPSTREAM_KEEPALIVE_POOL_SIZE: "512"
KONG_UPSTREAM_KEEPALIVE_MAX_REQUESTS: "10000"
KONG_UPSTREAM_KEEPALIVE_IDLE_TIMEOUT: "60"

📌 Keepalive ke upstream sering terlupakan

Tanpa kolam keepalive yang memadai, Kong membuka koneksi TCP baru ke layanan Anda untuk hampir setiap permintaan. Pada trafik tinggi ini menambah latensi jabat tangan, menguras port ephemeral, dan membebani layanan di belakangnya. Menaikkan upstream_keepalive_pool_size sering memberi perbaikan latensi yang terasa tanpa mengubah apa pun di aplikasi.

# Sumber daya untuk kontainer Kong (titik awal)
resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    memory: 2Gi
    # CPU limit sengaja tidak disetel — throttling merusak latensi p99

🔄 Upgrade Tanpa Henti

# 1. Baca catatan rilis, terutama bagian perubahan yang merusak
# 2. Uji di staging dengan konfigurasi PRODUKSI yang sesungguhnya
deck gateway dump --kong-addr $PROD -o snapshot-produksi.yaml
deck gateway sync -s snapshot-produksi.yaml --kong-addr $STAGING

# 3. Untuk mode database: jalankan migrasi bertahap
kong migrations up        # aman, tidak merusak versi lama
# jalankan simpul versi baru berdampingan dengan yang lama
kong migrations finish    # SETELAH semua simpul naik versi

# 4. Rilis bergulir, satu simpul dalam satu waktu
# 5. Pantau tingkat error dan latensi di tiap langkah

⚠️ Jangan pernah menjalankan migrations finish terlalu cepat

Perintah up menerapkan perubahan skema yang masih kompatibel dengan versi Kong lama, sehingga kedua versi bisa berjalan bersamaan selama rilis bergulir. Perintah finish membuang struktur lama — dan begitu dijalankan, simpul versi lama yang masih hidup akan rusak. Pastikan seluruh simpul sudah naik versi lebih dulu.

🐛 Masalah yang Sering Terjadi

Gejala	Penyebab yang biasa
404 padahal route ada	`strip_path`, atau host/path tidak cocok persis
502 Bad Gateway	Upstream tidak terjangkau, atau nama DNS salah
504 Gateway Timeout	`read_timeout` lebih pendek dari waktu proses layanan
401 pada permintaan yang sah	Plugin auth di cakupan tak terduga menimpa yang lain
429 terlalu cepat	`policy: local` dengan hitungan tidak konsisten antar simpul
Latensi naik bertahap	Kolam keepalive habis, atau Redis rate-limit lambat
Memori terus naik	`mem_cache_size` terlalu besar, atau kebocoran plugin kustom

# Mendiagnosis satu permintaan sampai tuntas
curl -i http://localhost:8000/pesanan/123 \
  -H "X-Request-Id: uji-123"

# Periksa header respons:
#   X-Kong-Proxy-Latency    → waktu di Kong (plugin)
#   X-Kong-Upstream-Latency → waktu di layanan
#   Via                     → memastikan memang lewat Kong

# Route mana yang menangkap permintaan ini
curl -s http://localhost:8001/routes | jq '.data[] | {name, paths, hosts}'

# Log dengan tingkat detail lebih tinggi (sementara)
KONG_LOG_LEVEL=debug kong reload

✅ Kesiapan Produksi

Minimal 2 simpul di zona berbeda	Bertahan dari kegagalan satu zona
Probe kesehatan mengarah ke `/status`	Load balancer tahu simpul mana yang siap
Konfigurasi di Git, diterapkan lewat decK/CI	Dapat diaudit dan dipulihkan
Admin API terisolasi	Kendali gateway tidak terbuka
Metrik & alert terpasang	Masalah terdeteksi sebelum pengguna melapor
Rate limiting memakai policy terpusat	Batas akurat lintas simpul
Rencana rollback tertulis dan pernah dicoba	Insiden bukan waktu untuk belajar
Sertifikat diperbarui otomatis	Kedaluwarsa dapat dicegah sepenuhnya

🚫 Gateway adalah titik kegagalan tunggal — perlakukan sesuai

Ketika Kong mati, seluruh API Anda mati, bukan satu layanan saja. Konsekuensinya: redundansi bukan opsional, upgrade harus dilatih di staging lebih dulu, dan perubahan konfigurasi ke gateway layak mendapat kehati-hatian yang sama dengan perubahan basis data produksi.