Autoscaling #
Autoscaling adalah mekanisme yang secara otomatis menambah atau mengurangi kapasitas komputasi berdasarkan kondisi yang kamu definisikan — tanpa intervensi manual. Ini adalah implementasi konkret dari elastisitas cloud yang sesungguhnya. Tanpa autoscaling, kamu harus memilih antara over-provisioning (buang uang) atau under-provisioning (risiko down saat lonjakan). Dengan autoscaling yang dikonfigurasi dengan baik, kapasitas selalu mendekati apa yang dibutuhkan — tidak lebih, tidak kurang.
Cara Kerja Autoscaling #
Autoscaling pada dasarnya adalah control loop yang terus memantau kondisi sistem dan membuat keputusan scaling berdasarkan policy yang kamu definisikan.
Control Loop Autoscaling:
┌─────────────────────────────────────────────┐
│ 1. MONITOR │
│ Collect metrics (CPU, request count, │
│ queue depth, custom metric) │
└──────────────────────┬──────────────────────┘
│
┌──────────────────────▼──────────────────────┐
│ 2. EVALUATE │
│ Bandingkan metric dengan threshold │
│ yang didefinisikan di policy │
└──────────────────────┬──────────────────────┘
│
┌──────────────────────▼──────────────────────┐
│ 3. DECIDE │
│ Scale out / Scale in / No action │
└──────────────────────┬──────────────────────┘
│
┌──────────────────────▼──────────────────────┐
│ 4. ACT │
│ Tambah atau kurangi instance │
│ (dengan cooldown period) │
└──────────────────────┬──────────────────────┘
│
kembali ke step 1
Jenis Scaling Policy #
Target Tracking — Paling Sederhana dan Direkomendasikan #
Target Tracking Policy:
"Pertahankan metrik ini di nilai target tertentu"
Contoh:
Target: CPU utilization = 50%
Saat ini: 3 instance, CPU avg = 75% → scale out ke 5 instance
Setelah: 5 instance, CPU avg = 48% → dalam range target, no action
Saat ini: 5 instance, CPU avg = 20% → scale in ke 3 instance
Setelah: 3 instance, CPU avg = 33% → dalam range target, no action
Keuntungan:
✓ Paling mudah dikonfigurasi — hanya definisikan target
✓ Platform otomatis hitung berapa instance yang dibutuhkan
✓ Bereaksi proporsional — lonjakan besar = scale lebih banyak
✓ Pilihan pertama yang harus dicoba
Step Scaling — Kontrol Lebih Granular #
Step Scaling Policy:
"Jika metrik melewati threshold, tambah/kurangi N instance"
Policy scale out:
CPU 50–70%: tambah 1 instance
CPU 70–85%: tambah 2 instance
CPU > 85%: tambah 4 instance (respons lebih agresif)
Policy scale in:
CPU 30–50%: kurangi 1 instance
CPU < 30%: kurangi 2 instance
Keuntungan:
✓ Kontrol lebih presisi — definisikan respons per range
✓ Cocok untuk workload yang responnya butuh di-tune secara khusus
Kekurangan:
✗ Lebih kompleks untuk dikonfigurasi dan di-maintain
✗ Threshold perlu di-tune berdasarkan observasi workload
Scheduled Scaling — Untuk Pola yang Predictable #
Scheduled Scaling:
"Pada waktu X, set kapasitas ke N instance"
Contoh pola beban yang predictable:
Senin–Jumat 07:00: set minimum = 5 instance (antisipasi jam kerja)
Senin–Jumat 21:00: set minimum = 1 instance (jam sepi)
Sabtu–Minggu: set minimum = 2 instance
Keuntungan:
✓ Tidak ada lag — kapasitas sudah naik sebelum beban datang
✓ Cocok untuk aplikasi dengan pola beban yang sangat predictable
✓ Bisa dikombinasikan dengan target tracking untuk fleksibilitas
✗ Tidak responsif jika pola beban berubah dari biasanya
Prasyarat Autoscaling yang Efektif #
Autoscaling tidak bekerja sendiri. Ada prasyarat arsitektur yang harus dipenuhi agar autoscaling berfungsi dengan baik.
1. Aplikasi Stateless
✓ Instance baru harus langsung bisa melayani request
✗ Jika state ada di memori instance → instance baru tidak punya
state yang diperlukan → error atau session terputus
2. Fast Startup Time
✓ Instance baru harus healthy dan siap dalam hitungan detik
✗ Jika startup butuh 5 menit → saat lonjakan tiba,
instance baru tidak bisa bantu selama 5 menit tersebut
Cara mempercepat startup:
→ Container image yang sudah baked dengan dependensi
→ Lazy loading untuk inisialisasi yang tidak kritis
→ Pre-warming pool (beberapa instance standby)
3. Accurate Health Check
✓ Load balancer harus tahu kapan instance siap menerima trafik
✗ Jika health check pass terlalu cepat (sebelum siap) →
trafik dikirim ke instance yang belum siap → error
4. Graceful Shutdown
✓ Instance yang di-terminate harus selesaikan request yang
sedang diproses sebelum mati (connection draining)
✗ Jika terminate langsung → request yang sedang diproses putus
Cooldown Period dan Stabilisasi #
Cooldown period adalah jeda waktu setelah scaling event, di mana autoscaling tidak akan membuat keputusan scaling baru. Ini mencegah “flapping” — situasi di mana sistem terus scale out dan scale in tanpa stabil.
Masalah tanpa Cooldown:
Detik 0: CPU 80% → scale out: 3→5 instance
Detik 30: Instance baru mulai, CPU turun ke 35%
Detik 30: Tanpa cooldown → langsung scale in: 5→3 instance
Detik 60: Kembali ke situasi awal, CPU naik lagi
→ Flapping: scale terus tanpa pernah stabil
Dengan Cooldown (misalnya 5 menit):
Detik 0: CPU 80% → scale out: 3→5 instance
Detik 30: Instance baru online, CPU turun ke 35%
Detik 30-300: Cooldown aktif, tidak ada scaling action
Detik 300: Evaluasi ulang — CPU masih 35%?
→ Jika ya → scale in ke 4 instance
→ Cooldown aktif lagi selama 5 menit
Panduan cooldown:
Scale out cooldown: lebih pendek (1-3 menit)
→ Kamu ingin scale out responsif saat beban naik
Scale in cooldown: lebih panjang (5-15 menit)
→ Kamu ingin lebih yakin beban memang turun sebelum scale in
Metrik untuk Autoscaling #
CPU utilization adalah metrik paling umum, tapi bukan satu-satunya yang tepat untuk semua situasi.
CPU Utilization:
✓ Cocok untuk: compute-bound workload, web server umum
✗ Tidak cocok jika: bottleneck bukan CPU (misalnya: I/O bound,
atau aplikasi yang memproses request dengan banyak network call)
Request per Second (RPS) / Request Count:
✓ Lebih langsung mengukur beban aktual
✓ Cocok untuk: API server, web application
→ "Scale out jika ada lebih dari 1000 req/second per instance"
Queue Depth:
✓ Cocok untuk: worker yang memproses dari message queue
→ "Scale out jika ada lebih dari 100 pesan menunggu di queue"
→ Sangat responsif terhadap beban kerja aktual
Memory Utilization:
✓ Cocok jika memory jadi bottleneck, bukan CPU
✗ Hati-hati: beberapa aplikasi (JVM) me-manage memory sendiri,
utilisasi memori tidak langsung mencerminkan kekurangan kapasitas
Custom Metric:
→ Apapun yang bisa kamu ukur bisa jadi trigger scaling
→ Contoh: panjang antrian database connection pool,
latency rata-rata request, jumlah user aktif
Ringkasan #
- Autoscaling adalah control loop: monitor → evaluate → decide → act — berjalan terus secara otomatis berdasarkan policy yang kamu definisikan.
- Target tracking adalah policy yang paling sederhana dan direkomendasikan — cukup tentukan target metrik, platform hitung berapa instance yang dibutuhkan.
- Scheduled scaling untuk pola beban yang predictable — antisipasi lonjakan sebelum terjadi, bukan bereaksi setelah terjadi.
- Stateless app + fast startup + accurate health check = autoscaling yang efektif — ketiga prasyarat ini harus ada agar autoscaling bekerja dengan benar.
- Cooldown period mencegah flapping — scale out cooldown lebih pendek, scale in cooldown lebih panjang untuk stabilitas yang lebih baik.
- Pilih metrik yang mencerminkan bottleneck nyata — CPU tidak selalu tepat; queue depth atau request count sering lebih akurat untuk workload tertentu.
← Sebelumnya: Managed Compute Berikutnya: Spot/Preemptible Instance →