Fase 9 · Deploy di AWS

Autoscaling ECS

Penskalaan otomatis yang salah metrik lebih buruk daripada tidak ada sama sekali: ia menambah kapasitas terlambat, lalu menghapusnya tepat sebelum puncak berikutnya. Yang menentukan adalah memilih sinyal yang benar.

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

Intisari

Target tracking adalah bentuk yang paling sederhana dan paling tepat untuk kebanyakan kasus.
Untuk service web, ALBRequestCountPerTarget lebih baik daripada CPU.
Untuk worker antrean, skalakan dari panjang antrean, bukan dari CPU.
Naik cepat, turun lambat — scale-in cooldown harus jauh lebih panjang daripada scale-out.
Task baru butuh waktu untuk menyala dan lulus health check; autoscaling bukan obat untuk lonjakan mendadak.

Target tracking untuk service web

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/portal/portal-web \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 --max-capacity 20

aws application-autoscaling put-scaling-policy \
  --policy-name web-request-count \
  --service-namespace ecs \
  --resource-id service/portal/portal-web \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 800,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "app/portal-alb/abc/targetgroup/portal-web/def"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

Metrik	Cocok untuk	Kelemahan
`ALBRequestCountPerTarget`	Service web	Tidak melihat permintaan yang mahal secara tidak wajar
`ECSServiceAverageCPUUtilization`	Beban terikat CPU	Aplikasi Laravel sering menunggu I/O — CPU rendah padahal penuh
`ECSServiceAverageMemoryUtilization`	Deteksi kebocoran	Memori jarang mencerminkan beban
Metrik kustom (panjang antrean)	Worker	Perlu dipasang sendiri

Kenapa CPU sering menyesatkan untuk Laravel. Permintaan yang menunggu database atau API luar hampir tidak memakai CPU, tapi tetap menahan satu worker. Kamu bisa berada dalam kondisi setiap worker sibuk dan antrean permintaan mengular, sementara CPU menunjukkan 30% — dan autoscaling berbasis CPU tidak melakukan apa-apa. Jumlah permintaan per target mengukur beban yang sebenarnya.

Worker antrean: skalakan dari panjang antrean

aws application-autoscaling put-scaling-policy \
  --policy-name worker-antrean \
  --service-namespace ecs \
  --resource-id service/portal/portal-worker \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 100,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Dimensions": [{ "Name": "QueueName", "Value": "portal-default" }],
      "Statistic": "Average"
    },
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

Metrik yang lebih baik lagi: backlog per task. "100 pesan menunggu" berarti hal berbeda saat ada 2 worker dibandingkan saat ada 20. Metrik kustom pesan_menunggu / jumlah_task menskalakan dengan benar di kedua ujung. Untuk memulai, panjang antrean saja sudah jauh lebih baik daripada CPU.

Naik cepat, turun lambat

	Scale out	Scale in
Cooldown	60 detik	300 detik
Kalau salah	Bayar kapasitas berlebih sebentar	Kapasitas hilang tepat sebelum puncak berikutnya
Sikap yang tepat	Agresif	Konservatif

Asimetri ini disengaja. Biaya salah menambah task adalah beberapa sen; biaya salah mengurangi task adalah halaman yang lambat atau error saat lalu lintas kembali naik. Lalu lintas jarang naik dengan mulus — ia bergelombang, dan penurunan yang terlalu cepat membuatmu terus tertinggal di setiap gelombang.

Penskalaan terjadwal

aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/portal/portal-web \
  --scalable-dimension ecs:service:DesiredCount \
  --scheduled-action-name pagi \
  --schedule "cron(30 22 * * ? *)" \
  --scalable-target-action MinCapacity=6,MaxCapacity=30

Untuk lalu lintas yang polanya bisa diperkirakan, penskalaan terjadwal mengalahkan yang reaktif. Kalau kamu tahu lalu lintas melonjak setiap pagi, menaikkan kapasitas minimum sepuluh menit sebelumnya jauh lebih baik daripada menunggu metrik memberi tahu — karena saat metrik bergerak, penggunamu sudah lebih dulu merasakan lambatnya. Perhatikan zona waktu: cron di sini memakai UTC.

Batas yang sesungguhnya

Waktu yang dibutuhkan	Perkiraan
Alarm CloudWatch bereaksi	1–3 menit
Fargate menyediakan task	30–60 detik
Kontainer menarik image (dengan cache)	10–30 detik
Aplikasi menyala dan lulus health check	15–45 detik
Total	2–5 menit

Konsekuensinya: autoscaling tidak menyelamatkanmu dari lonjakan mendadak. Artikel yang tiba-tiba viral menaikkan lalu lintas dalam hitungan detik, bukan menit. Yang melindungimu di jendela itu adalah kapasitas minimum yang memadai dan — jauh lebih penting untuk situs konten — cache CDN, yang menyerap lonjakan tanpa menyentuh satu pun task. Autoscaling menangani perubahan bertahap; CDN menangani yang mendadak.

Menghemat biaya

Pakai Fargate Spot untuk service worker — pekerjaannya bisa diulang, jadi gangguan bisa diterima.
Jangan pakai Spot untuk service web kecuali kamu benar-benar siap dengan penggantian task mendadak.
ARM (Graviton) lebih murah per unit performa; PHP berjalan baik di atasnya — pastikan image dibangun untuk arm64.
Turunkan kapasitas minimum di malam hari lewat penskalaan terjadwal.
Compute Savings Plan untuk kapasitas dasar yang selalu berjalan.

Latihan: pasang target tracking berbasis ALBRequestCountPerTarget dengan target 800, lalu jalankan uji beban yang menaikkan lalu lintas bertahap. Catat berapa lama dari lonjakan sampai task baru benar-benar melayani permintaan — angka itu adalah kapasitas cadangan yang harus selalu kamu siapkan.

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