Belajar Cloud Engineer - Auto-scaling & Reliability

#Pendahuluan

Di episode 20 kita memastikan infrastruktur bisa bangkit dari bencana. Sekarang pertanyaan sebaliknya: bagaimana infrastruktur menyesuaikan diri dengan beban yang tidak pernah datar? Bayangkan toko online kalian dibahas media sosial dan trafik melonjak 10x dalam sejam. Tanpa auto-scaling, dua kemungkinan: server kelebihan beban (site down), atau server berlebih (boros — dan episode 16 sudah mengajarkan betapa mahalnya itu).

Episode 21 membahas auto-scaling & reliability: auto-scaling groups, target tracking (scaling berbasis metrik), cooldown, dan kapasitas min/maks. Kalian juga akan merancang arsitektur multi-AZ high availability — sistem yang kehilangan satu instance atau satu AZ tanpa user menyadarinya.

#Mengapa Auto-Scaling, Bukan Server Tetap

Beban aplikasi web berbentuk gelombang, bukan garis datar: puncak pagi, sepi tengah malam, lonjakan saat promo. Memakai server tetap berarti membayar untuk puncak (mahal, episode 16) atau berharap tidak pernah ada puncak (sombong). Auto-scaling menempatkan kapasitas sedikit di atas kebutuhan aktual, terus-menerus.

Dua bagian yang bekerja bersama:

1. Auto Scaling Group — kumpulan instance yang dianggap satu unit; menentukan instance type, min, max, dan desired capacity.
2. Scaling policy — aturan kapan menambah/mengurangi instance, berbasis metrik atau jadwal.

#Auto Scaling Group (AWS) / MIG (GCP) / VMSS (Azure)

Konsepnya sama di semua provider — sekelompok instance yang diatur sebagai satu kesatuan:

Pola pemakaian di AWS:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name lab-web-asg \
  --launch-template LaunchTemplateName=lab-web-lt \
  --min-size 2 --max-size 8 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-1,subnet-2" \
  --availability-zones ap-southeast-1a ap-southeast-1b
 
aws autoscaling attach-load-balancer-target-groups \
  --auto-scaling-group-name lab-web-asg \
  --target-group-arns arn:aws:elasticloadbalancing:...:lab-web-tg

Kunci yang wajib dipahami:

• Min size — lantai kapasitas; tidak pernah turun di bawah ini (melindungi dari memori terhapus semua).
• Max size — plafon; mengontrol biaya maksimum saat lonjakan gila.
• Desired capacity — target kondisi normal; autoscaling berusaha menjaganya.

#Target Tracking: Scaling Berbasis Metrik

Target tracking adalah pola scaling paling umum: pilih metrik dan target, sistem menyesuaikan instance agar metrik itu terjaga — seperti termostat ruangan. Contoh: jaga CPU average di 60%.

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name lab-web-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration file://cpu-policy.json

cpu-policy.json berisi {"TargetValue": 60.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"}}.

Kelebihan target tracking: kalian tidak perlu memikirkan berapa instance untuk CPU 60% — sistem menghitungnya dari metrik yang ada. Metrik yang umum: CPU, request per target, atau metrik kustom dari aplikasi (misal panjang antrian — ingat episode 13).

#Cooldown dan Stability

Scaling tidak boleh reaktif berlebihan: instance baru butuh waktu untuk panas (startup, deploy aplikasi), dan metrik akan naik sementara. Cooldown memberi jeda antara aksi scaling agar sistem tidak "goyang" — menambah dan mengurangi instance secara bergantian seperti pendulum. Ada juga scheduled scaling untuk pola yang bisa diprediksi: pasang 5 instance sebelum jam promo, turunkan setelahnya.

#Arsitektur Multi-AZ High Availability

Auto-scaling menangani jumlah instance. High availability (HA) menangani lokasi instance: jika satu datacenter (Availability Zone) bermasalah, instance di AZ lain tetap melayani. Pola dasar HA di cloud:

Aturannya:

1. Sebar instance di minimal 2-3 AZ — ASG dengan subnet di beberapa AZ.
2. Load balancer di depan — meneruskan trafik hanya ke instance sehat (episode 5).
3. Database managed multi-AZ — RDS Multi-AZ / Cloud SQL HA / Azure SQL zone redundant, failover otomatis.
4. Stateless apps — instance bisa mati kapan pun; state (session, file) dipindah ke storage/Db eksternal.

Prinsip yang menjiwai semuanya: desain untuk kegagalan. Instance dianggap ternak, bukan hewan peliharaan — saat mati, yang lahir pengganti dari template, bukan yang dirawat. Ini juga alasan statelessness penting: instance yang mati tidak membawa data apa pun yang hilang.

#Praktik: Auto-Scaling Produksi

Mari pasang auto-scaling untuk aplikasi lab-ecommerce di tiga AZ:

1. Buat launch template / instance template — AMI + script bootstrap + security group (episode 3, 5).
2. Buat ASG — 2 AZ, min 2, max 6, desired 2, attach ke target group load balancer (episode 5).
3. Pasang target tracking CPU 60% dengan cooldown 300 detik.
4. Tambahkan scheduled scaling untuk jam promo (misal 08:00-20:00 → 4 instance).
5. Uji scale-out: jalankan stress-ng --cpu 4 di semua instance (ingat episode 9), amati ASG menambah instance.
6. Uji scale-in: hentikan stress, amati instance berkurang setelah cooldown.
7. Uji HA: matikan satu instance secara paksa, pastikan load balancer langsung menghapusnya dan ASG menggantinya.

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name lab-web-asg \
  --query 'Activities[].{Action:Description,Status:StatusCode}'

Ketika scale-out berjalan otomatis saat trafik naik, dan instance mati digantikan tanpa disadari user — infrastruktur kalian sudah menyandang dua gelar sekaligus: elastis dan tersedia.

#Kesalahan Umum (Common Pitfalls)

1. Statelessness diabaikan — session di memori instance; instance baru tidak membawa session user, koneksi putus.
2. Min dan max tidak masuk akal — min 1 (HA ilusi) atau max terlalu kecil (lonjakan tak tertampung).
3. Scaling reaktif tanpa cooldown — sistem goyang menambah-mengurangi secara bergantian.
4. Database single-AZ — aplikasi HA tapi database satu lokasi = titik gagal tunggal.
5. Metrik scaling salah — scale dari CPU padahal bottleneck-nya antrian (episode 13); pilih metrik yang mencerminkan beban.
6. Lupa HA di region yang sama dengan DR — DR region kedua (episode 20) tetap diperlukan; HA di satu region tidak menggantikan DR lintas region.

#Penutup

Inti yang harus dibawa pulang:

• Auto Scaling Group mengatur jumlah instance sebagai satu kesatuan dengan min/max/desired.
• Target tracking menjaga metrik (misal CPU 60%) secara otomatis — termostat untuk infrastruktur.
• Multi-AZ HA: instance tersebar di beberapa AZ, load balancer di depan, DB managed multi-AZ.
• Stateless apps adalah syarat scaling yang sehat; instance adalah ternak, bukan peliharaan.
• Uji scale-out, scale-in, dan kegagalan instance — jangan tunggu produksi.

Di episode 22 selanjutnya kita akan memperluas cakrawala: multi-cloud & hybrid architecture — portabilitas lintas provider, Terraform multi-provider, dan strategi hybrid, lalu membangun infrastruktur yang berjalan di lebih dari satu cloud. Sampai jumpa di episode 22!