Fase 10 · Deploy di AWS

Application Load Balancer

ALB menerima TLS, memilih target sehat, dan meneruskan permintaan. Sebagian besar masalah "502 acak" dan "beberapa permintaan gagal setiap deploy" berasal dari ketidakcocokan antara setelan ALB dan setelan aplikasi Go-mu.

Sumber asli docs.aws.amazon.com Resmi Rangkuman ~7 menit baca

Intisari

IdleTimeout aplikasi harus lebih besar daripada idle timeout ALB — kalau tidak, 502 acak.
Deregistration delay harus ≥ durasi permintaan terpanjang, dan sejalan dengan graceful shutdown.
Health check target group menunjuk endpoint yang tidak menyentuh database.
Algoritma least outstanding requests biasanya lebih baik daripada round-robin untuk API.
ALB menerima trafik hanya dari CloudFront di depan situs publik — batasi lewat security group atau header rahasia.

Setelan yang harus selaras

Setelan ALB	Nilai	Harus selaras dengan
Idle timeout	60 dtk	`IdleTimeout` Go = 65 dtk (lebih besar)
Deregistration delay	30 dtk	≥ permintaan terpanjang; ≤ `stopTimeout` ECS
Health check interval	10 dtk	interval × ambang < jeda tidur shutdown
Healthy threshold	2	—
Unhealthy threshold	2	—
Health check timeout	5 dtk	< interval
Health check path	`/sehat`	Tidak menyentuh database

Baris pertama menjelaskan hampir semua "502 acak". Kalau server Go menutup koneksi keep-alive lebih dulu daripada ALB menyadarinya, ALB bisa mengirim permintaan ke koneksi yang sedang ditutup — dan hasilnya 502 untuk pengguna sungguhan, dengan log aplikasi yang bersih total karena permintaannya memang tidak pernah sampai. Aturannya: IdleTimeout aplikasi selalu beberapa detik lebih besar daripada idle timeout ALB (Fase 3).

Anatomi deploy tanpa 502

t=0    ECS memulai task baru
t=15   Task baru lolos health check (2 × 10 dtk) → didaftarkan ke target group
t=15   ALB mulai mengirim trafik ke task baru
t=15   ECS mengirim SIGTERM ke task lama
t=15   Task lama: /siap membalas 503 (readiness)
t=25   ALB menandai task lama unhealthy → berhenti mengirim permintaan BARU
t=25   Task lama mulai srv.Shutdown() → selesaikan yang sedang berjalan
t=45   Deregistration delay habis; task lama sudah keluar
t=45   ✅ nol permintaan yang terpotong

Kalau salah	Gejalanya
Deregistration delay terlalu pendek	Permintaan yang sedang berjalan terpotong saat deploy
Aplikasi tidak punya readiness	ALB mengirim permintaan ke task yang sedang mati
`stopTimeout` < graceful shutdown	SIGKILL memotong transaksi di tengah
Health check terlalu lambat mendeteksi	Trafik terus dikirim ke task yang sudah menutup
Task baru terdaftar sebelum siap	503 di awal deploy

Algoritma penyeimbangan

Algoritma	Cocok untuk
Round robin	Permintaan berdurasi seragam
Least outstanding requests	API dengan durasi bervariasi — mencegah task lambat kebanjiran
Weighted random	Distribusi khusus

Header yang ditambahkan ALB

X-Forwarded-For     : IP klien (bisa berupa rantai)
X-Forwarded-Proto   : https
X-Forwarded-Port    : 443
X-Amzn-Trace-Id     : Root=1-63f...  ← untuk X-Ray dan korelasi log

// Ambil IP klien dengan benar: hitung dari KANAN sebanyak proxy
// tepercayamu. Elemen paling kiri bisa diketik sendiri oleh klien (Fase 6).
func ipKlien(r *http.Request, jumlahProxy int) string { ... }

// Jejak ALB layak dicatat: ia yang menghubungkan log aplikasimu
// dengan log akses ALB.
log.InfoContext(ctx, "permintaan",
	"amzn_trace_id", r.Header.Get("X-Amzn-Trace-Id"))

Membatasi ALB hanya menerima dari CloudFront

Tanpa pembatasan, penyerang bisa memanggil ALB LANGSUNG dan melewati:
  • aturan AWS WAF yang dipasang di CloudFront
  • cache CDN (sehingga setiap permintaan menembus ke origin)
  • pembatasan geografis

Dua cara membatasinya:

  A. Security group yang merujuk daftar prefix terkelola CloudFront
     (com.amazonaws.global.cloudfront.origin-facing)

  B. Header rahasia bersama: CloudFront menambahkan X-Origin-Verify,
     ALB listener rule menolak permintaan tanpa nilai yang benar

Aturan listener

Prioritas 1  Host: api.contoh.id           → target group toko-api
Prioritas 2  Path: /admin/*                → target group toko-admin
Prioritas 3  Header: X-Origin-Verify salah → 403 tetap
Default                                     → target group toko-server

HTTP :80 → redirect permanen ke HTTPS :443

ALB memakai kuota bersama: 100 aturan per listener, 5 kondisi per aturan. Untuk routing yang lebih rumit dari itu, lakukan di aplikasi — router Go-mu (Fase 3) jauh lebih fleksibel, bisa diuji, dan ikut ke dalam git.

Metrik ALB yang layak dialarmkan

Metrik	Artinya
`HTTPCode_ELB_5XX_Count`	ALB sendiri yang gagal — biasanya tidak ada target sehat
`HTTPCode_Target_5XX_Count`	Aplikasimu yang membalas 5xx
`TargetResponseTime` p95/p99	Latensi sungguhan yang dirasakan pengguna
`UnHealthyHostCount`	> 0 secara berkelanjutan = masalah
`RejectedConnectionCount`	Batas koneksi tercapai
`TargetConnectionErrorCount`	Ketidakcocokan idle timeout

Bedakan dua metrik 5xx pertama saat insiden. ELB_5XX berarti masalahnya di lapisan load balancer — biasanya semua target dinyatakan tidak sehat. Target_5XX berarti aplikasimu berjalan dan membalas error. Keduanya butuh tindakan yang sama sekali berbeda.

Latihan: setel idle timeout ALB ke 60 detik dan IdleTimeout Go ke 30 detik, lalu kirim permintaan berulang lewat koneksi keep-alive selama beberapa menit — cari 502 di log akses ALB. Naikkan IdleTimeout Go ke 65 dan ulangi.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.