Fase 9 · Deploy di AWS

Application Load Balancer

ALB adalah satu-satunya pintu masuk ke task-mu. Tiga setelannya — health check, deregistration delay, dan keep-alive — menentukan apakah pengguna melihat error saat kamu men-deploy.

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

Intisari

TLS berhenti di ALB; sertifikatnya dari ACM dan diperbarui otomatis.
Target group berisi task-task yang sehat; ALB hanya mengirim lalu lintas ke sana.
deregistration_delay memberi waktu permintaan yang sedang berjalan untuk selesai.
Keep-alive penting untuk worker mode — koneksi yang dibuka ulang menghapus sebagian keuntungannya.
Idle timeout ALB harus lebih pendek daripada timeout aplikasi, bukan sebaliknya.

Bentuk lalu lintas

internet
  │
  ├─ :80  → listener HTTP  → redirect 301 ke HTTPS
  └─ :443 → listener HTTPS (sertifikat ACM)
              │
              └─ target group "portal-web" (port 8000)
                   ├─ task 1  ✓ sehat
                   ├─ task 2  ✓ sehat
                   └─ task 3  ✗ tidak sehat → tidak dikirimi lalu lintas

Health check target group

Path                 : /up
Port                 : traffic-port
Protokol             : HTTP
Kode sukses          : 200
Interval             : 15 detik
Timeout              : 5 detik
Healthy threshold    : 2
Unhealthy threshold   : 3

Setelan	Terlalu agresif	Terlalu longgar
Interval	Beban tambahan yang tidak perlu	Task rusak tetap menerima lalu lintas lama
Unhealthy threshold	Gangguan sesaat memicu penggantian task	Task rusak bertahan terlalu lama
Timeout	Task yang sedang sibuk dianggap mati	Deteksi kegagalan jadi lambat

Health check yang terlalu agresif bisa menyebabkan kegagalan berantai. Saat lalu lintas melonjak dan semua task menjadi lambat, health check ikut lambat dan gagal. ALB mengeluarkan task-task itu, sehingga beban yang sama menimpa task yang lebih sedikit — yang lalu ikut gagal. Endpoint /up yang ringan dan tidak menyentuh database adalah pertahanan pertama terhadap pola ini.

Deregistration delay

deregistration_delay.timeout_seconds = 30

Saat sebuah task akan dihentikan, ALB berhenti mengirim permintaan baru ke sana, lalu menunggu selama nilai ini sebelum benar-benar memutuskannya. Tanpa jeda ini, permintaan yang sedang diproses akan terputus di tengah jalan — dan pengguna melihat 502.

Nilai	Akibat
0 detik	Permintaan berjalan terputus. Deploy selalu menghasilkan sejumlah 502
30 detik	Titik awal yang baik untuk aplikasi web
300 detik (default)	Aman, tapi deploy jadi sangat lambat

Nilai ini harus selaras dengan stopTimeout ECS. Urutan yang benar: ALB berhenti mengirim permintaan baru → menunggu deregistration delay → ECS mengirim SIGTERM → aplikasi menyelesaikan sisanya dalam stopTimeout. Kalau stopTimeout lebih pendek daripada deregistration delay, task dibunuh sebelum ALB selesai menunggu — dan jeda itu jadi sia-sia.

Keep-alive dan idle timeout

idle_timeout.timeout_seconds = 60          # ALB
routing.http.desync_mitigation_mode = defensive

Keep-alive penting untuk worker mode. Dokumentasi RoadRunner menyebut peningkatan performa sekitar 40% dengan koneksi keep-alive. ALB memakainya secara default terhadap target; yang perlu kamu pastikan adalah aplikasi tidak menutup koneksi lebih dulu. Sebagai aturan, idle timeout di sisi aplikasi harus lebih panjang daripada idle timeout ALB, supaya ALB yang memutuskan kapan koneksi berakhir — bukan aplikasi yang menutup koneksi yang sedang dipakai ALB, yang berakhir sebagai 502 sporadis.

Aturan listener

Prioritas 10  path /health/deep     → target group, hanya dari IP internal
Prioritas 20  host api.portal.com   → target group "portal-api"
Prioritas 30  path /horizon/*       → target group web (dilindungi juga di aplikasi)
Default       *                     → target group "portal-web"

# Listener HTTP: selalu alihkan ke HTTPS
:80 → redirect 301 → https://#{host}:443/#{path}?#{query}

Header yang diteruskan

Header	Isinya	Dibaca Laravel sebagai
`X-Forwarded-For`	IP asli klien	`$request->ip()`
`X-Forwarded-Proto`	`https`	`$request->isSecure()`
`X-Forwarded-Port`	443	URL yang dihasilkan
`X-Amzn-Trace-Id`	ID pelacakan	Berguna untuk korelasi log

// bootstrap/app.php — tanpa ini, tautanmu memakai http:// dan rate limit salah sasaran
$middleware->trustProxies(at: '*');

Metrik yang perlu dipasangi alarm

Metrik	Artinya
`HTTPCode_Target_5XX_Count`	Aplikasimu melempar error
`HTTPCode_ELB_5XX_Count`	ALB tidak menemukan target sehat — lebih serius
`TargetResponseTime` (p95)	Latensi sesungguhnya yang dirasakan pengguna
`UnHealthyHostCount`	Task yang dikeluarkan dari rotasi
`RejectedConnectionCount`	ALB mencapai batas koneksi
`TargetConnectionErrorCount`	Task menutup koneksi lebih dulu — periksa keep-alive

Bedakan dua metrik 5XX yang pertama. Target_5XX berarti aplikasimu menjawab dengan error — ada bug. ELB_5XX berarti ALB sendiri tidak bisa mendapatkan jawaban — tidak ada target sehat, atau semuanya menolak koneksi. Yang kedua biasanya menandakan masalah deploy atau kapasitas, dan layak memicu alarm yang membangunkan orang.

Latihan: pasang ALB dengan health check ke /up dan deregistration_delay=30. Lalu jalankan curl berulang tiap 200 ms sambil memicu deploy, dan hitung berapa banyak respons non-200 yang muncul. Angka nol adalah target; angka selain itu berarti ada setelan yang belum selaras.

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