Autoscaling #

Elastisitas adalah karakteristik pembeda utama yang membuat komputasi cloud jauh lebih unggul dibandingkan dengan pusat data tradisional (on-premise). Layanan utama yang mewujudkan elastisitas ini secara nyata adalah Autoscaling. Autoscaling adalah mekanisme otomatis yang bertugas untuk menambah atau mengurangi kapasitas daya komputasi (seperti instans Virtual Machine atau kontainer) secara dinamis berdasarkan metrik beban kerja riil di lapangan, tanpa memerlukan intervensi manual dari administrator jaringan. Tanpa autoscaling, kita terpaksa harus memilih di antara dua keputusan buruk: melakukan penyediaan berlebih (over-provisioning) yang membuang-buang anggaran finansial, atau penyediaan kurang (under-provisioning) yang berisiko membuat aplikasi kita crash saat lonjakan trafik tiba. Artikel ini akan membahas secara mendalam mekanisme kerja siklus rekonsiliasi autoscaling, tipe-tipe kebijakan penskalan, prasyarat arsitektur kode aplikasi, serta optimasi stabilitas sistem menggunakan periode pendinginan (cooldown period).

Cara Kerja Autoscaling: Rekonsiliasi Kontrol Loop #

Di balik layar, sistem autoscaling (seperti Auto Scaling Group di AWS atau Virtual Machine Scale Sets di Azure) berjalan sebagai sebuah loop kontrol berkelanjutan (continuous reconciliation control loop) yang bekerja secara berulang untuk mencocokkan kapasitas berjalan dengan status ideal yang diinginkan.

flowchart TD
    subgraph ControlLoop ["Siklus Rekonsiliasi Autoscaling"]
        direction TB
        Monitor["1. MONITOR METRICS<br>(Kumpulkan metrik dari CloudWatch/Monitor: CPU, Request Count, Queue Depth)"]
        Evaluate["2. EVALUATE THRESHOLD<br>(Bandingkan rata-rata metrik dengan aturan kebijakan scaling)"]
        Decide["3. DECIDE ACTION<br>(Hitung jumlah instans baru yang dibutuhkan atau dilepaskan)"]
        Act["4. ACTIVATE CHANGE<br>(Jalankan API untuk luncurkan VM baru atau hapus VM lama)"]
        
        Monitor --> Evaluate
        Evaluate --> Decide
        Decide --> Act
        Act -->|"Tunggu Cooldown selesai"| Monitor
    end

Langkah demi Langkah Siklus: #

1. Monitor: Sistem monitoring cloud mengumpulkan data telemetri (misal: utilisasi CPU rata-rata dari seluruh VM di dalam grup) setiap 1 menit sekali.
2. Evaluate: Aturan kebijakan scaling mengevaluasi metrik. Misalkan, kita memiliki aturan: “Pertahankan utilisasi CPU di angka 60%”. Jika sistem mencatat rata-rata CPU berada di angka 85%, ini memicu sinyal alarm untuk penambahan kapasitas (Scale-out).
3. Decide: Layanan autoscaling melakukan perhitungan matematika untuk menentukan berapa jumlah instans VM tambahan yang harus diluncurkan agar utilisasi CPU kembali ke angka target 60%.
4. Act: Sistem memicu API komputasi cloud untuk meluncurkan instans baru, memasukkannya ke dalam Load Balancer, dan setelah instans tersebut dinyatakan sehat (healthy), trafik mulai dialihkan ke instans baru tersebut.

Tipe Kebijakan Penskalaan (Scaling Policies) #

Kita dapat mengonfigurasi beberapa jenis kebijakan penskalaan berdasarkan karakteristik pola trafik aplikasi kita:

1. Target Tracking Scaling #

Model ini bekerja mirip dengan cara kerja termostat ruangan. Kita menetapkan satu target metrik yang spesifik, dan sistem cloud secara mandiri akan menghitung dan menyesuaikan jumlah instans untuk menjaga kestabilan metrik tersebut.

• Contoh: Kita menetapkan target: CPU Utilization = 50%.
• Perhitungan: Jika saat ini kita memiliki 3 VM dengan utilisasi rata-rata 80%, sistem akan menghitung: $$\text{Jumlah Instans Baru} = \text{Jumlah Saat Ini} \times \left( \frac{\text{Metrik Saat Ini}}{\text{Metrik Target}} \right)$$ $$\text{Jumlah Instans Baru} = 3 \times \left( \frac{80%}{50%} \right) = 4.8 \approx 5 \text{ Instans}$$ Sistem secara otomatis akan menambah 2 VM baru untuk menurunkan rata-rata CPU kembali mendekati 50%.

2. Step Scaling #

Mekanisme ini memungkinkan kita membuat respons bertahap (steps) yang lebih agresif ketika mendeteksi lonjakan trafik yang ekstrem.

• Contoh:
  • Jika CPU antara 50% - 70%: tambah 1 VM.
  • Jika CPU antara 70% - 85%: tambah 2 VM.
  • Jika CPU > 85%: tambah 4 VM secara agresif.
• Keunggulan: Memberikan waktu reaksi yang sangat cepat ketika aplikasi diserang oleh lonjakan traffic mendadak secara masif.

3. Scheduled Scaling #

Kebijakan ini digunakan ketika kita memiliki pola beban kerja yang sangat dapat diprediksi berdasarkan kalender waktu kerja.

• Contoh: Aplikasi HR internal perusahaan diakses sangat padat setiap hari kerja pukul 08:00 pagi saat karyawan melakukan absensi masuk, dan sepi di akhir pekan.
• Konfigurasi:
  • Setiap Senin - Jumat pukul 07:30: naikkan kapasitas minimum grup menjadi 10 VM (antisipasi beban sebelum terjadi).
  • Setiap Senin - Jumat pukul 18:00: turunkan kapasitas minimum menjadi 1 VM (mengurangi biaya di malam hari).

4. Predictive Scaling #

Menggunakan algoritma machine learning bawaan dari cloud provider untuk memindai riwayat trafik selama beberapa minggu terakhir, mendeteksi pola berulang harian atau mingguan, dan menjadwalkan penambahan kapasitas secara otomatis 15-30 menit sebelum lonjakan trafik yang diprediksikan tersebut benar-benar tiba.

Perbandingan Kebijakan Scaling #

Prasyarat Arsitektural Agar Autoscaling Berfungsi Efektif #

Autoscaling tidak akan berfungsi dengan benar jika aplikasi di dalam instans kita tidak dirancang khusus untuk mendukung arsitektur elastis. Berikut adalah prasyarat arsitektur wajib:

1. Aplikasi Harus Bersifat Stateless #

Ini adalah aturan paling kritis. Instans VM baru yang diluncurkan oleh autoscaling harus dapat melayani request pengguna secara acak tanpa bergantung pada sesi yang disimpan di memori lokal instans tersebut.

• ANTI-PATTERN: Menyimpan file session login pengguna di RAM lokal VM. Saat autoscaling mematikan VM tersebut untuk mengurangi kapasitas, sesi pengguna akan terputus dan mereka terpaksa login kembali.
• BENAR: Simpan sesi pengguna di database bersama terpusat atau caching memory terdistribusi (seperti Redis) yang berada di luar kluster autoscaling VM.

2. Startup Time yang Sangat Cepat (Fast Bootstrapping) #

Jika instans VM kita membutuhkan waktu 10 menit untuk booting (karena harus mengunduh kode dari internet, menginstal dependensi NPM, dan mengonfigurasi database saat start-up), maka ketika lonjakan traffic tiba, aplikasi kita akan mati sebelum VM baru siap membantu melayani trafik.

• Mitigasi: Gunakan image VM siap pakai (Golden Image / AMI yang di-bake menggunakan Packer) atau gunakan arsitektur kontainer. Semua kode dan dependensi harus sudah ada di dalam image, sehingga VM/kontainer dapat siap melayani trafik dalam waktu kurang dari 30 detik sejak dinyalakan.

3. Graceful Shutdown (Connection Draining) #

Saat beban trafik menurun, autoscaling akan memicu penghapusan VM (Scale-in). Kita harus memastikan instans tidak dimatikan secara mendadak saat masih memproses transaksi pengguna.

• Connection Draining: Load Balancer harus dikonfigurasi untuk langsung menghentikan pengiriman request baru ke VM yang ditargetkan mati, tetapi memberikan waktu toleransi (misal 30 detik) agar VM tersebut dapat menyelesaikan request transaksi yang saat itu sedang berjalan di dalamnya.

// Contoh penanganan sinyal terminasi OS (SIGTERM) untuk Graceful Shutdown di Go
package main

import (
	"context"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func main() {
	server := &http.Server{Addr: ":8080"}

	go func() {
		if err := server.ListenAndServe(); err != http.ErrServerClosed {
			log.Fatalf("HTTP server ListenAndServe error: %v", err)
		}
	}()

	// Menunggu sinyal pemutusan dari Autoscaler OS (SIGTERM atau SIGINT)
	stop := make(chan os.Signal, 1)
	signal.Notify(stop, syscall.SIGTERM, syscall.SIGINT)
	<-stop

	log.Println("Sinyal terminasi diterima, memulai graceful shutdown...")

	// Memberikan toleransi waktu 30 detik (Connection Draining window)
	ctx, cancel := context.WithTimeout(context.Background(), 30*time.Time(time.Second))
	defer cancel()

	if err := server.Shutdown(ctx); err != nil {
		log.Fatalf("Server Graceful Shutdown gagal: %v", err)
	}
	log.Println("Server berhasil dimatikan dengan aman tanpa memutuskan koneksi aktif.")
}

Mekanisme Cooldown Period dan Stabilisasi (Anti-Flapping) #

Tantangan operasional terbesar dalam autoscaling adalah mengontrol stabilitas agar tidak terjadi kondisi tidak stabil yang disebut Flapping (Osilasi).

Flapping terjadi ketika kapasitas instans terus-menerus bertambah (scale-out) dan berkurang (scale-in) secara berulang-ulang dalam waktu singkat akibat fluktuasi metrik sesaat, membuang biaya startup VM dan merusak performa aplikasi.

Kronologi Kejadian Flapping (Tanpa Cooldown):
Menit 01: CPU rata-rata 85% ────> Scale-out dipicu: tambah 2 VM baru (total 4 VM).
Menit 02: VM baru booting, CPU rata-rata drop mendadak ke 25%.
Menit 02: Deteksi CPU 25% ─────> Scale-in dipicu: kurangi 2 VM baru (total 2 VM).
Menit 03: VM dimatikan, CPU naik lagi ke 85% ────> Memicu Scale-out kembali.
(Osilasi tanpa henti ini memicu overhead dan ketidakstabilan sistem)

Peran Cooldown Period #

Untuk mencegah osilasi, kita wajib menetapkan Cooldown Period (Periode Pendinginan). Cooldown adalah jeda waktu setelah sebuah aksi scaling terjadi, di mana autoscaling akan mengunci sistem dan menolak untuk melakukan aksi scaling baru meskipun metrik melewati batas threshold.

• Scale-out Cooldown (Lebih Pendek, misal 60-120 detik): Ketika beban naik, kita ingin server baru diluncurkan dengan responsif. Kita memberikan waktu cooldown pendek agar sistem memantau apakah penambahan pertama sudah cukup untuk menurunkan CPU sebelum melakukan penambahan instans berikutnya.
• Scale-in Cooldown (Lebih Panjang, misal 300-600 detik): Ketika beban terdeteksi turun, kita ingin berhati-hati. Kita menunggu setidaknya 5 hingga 10 menit untuk memastikan bahwa penurunan beban tersebut memang stabil dan bukan sekadar penurunan sesaat, sebelum mulai menghapus VM dari kluster.

Pemilihan Metrik yang Tepat #

Menggunakan metrik yang salah untuk memicu autoscaling dapat berujung pada kegagalan sistem. Kita harus mencocokkan metrik dengan jenis batasan utama (bottleneck) dari aplikasi kita.

1. CPU Utilization #

• Cocok untuk: Aplikasi yang melakukan banyak perhitungan matematika atau kompilasi (misal video processing server, database indexing).
• Masalah: Tidak cocok untuk aplikasi yang bersifat I/O bound (seperti server API Node.js yang sebagian besar waktunya menunggu database query selesai, di mana CPU tetap rendah meski trafik sangat padat).

2. Request Count per Target (RPS) #

• Cocok untuk: Web server dan API RESTful umum. Kita menetapkan aturan: “Scale-out jika trafik melebihi 1000 request per detik per instans”. Metrik ini sangat akurat karena mengukur beban traffic riil secara langsung.

3. Queue Depth (Panjang Antrean) #

• Cocok untuk: Server worker yang memproses tugas asinkron dari message queue (seperti RabbitMQ, AWS SQS, atau Kafka).
• Formula Penskalan: $$\text{Jumlah Instans Ideal} = \frac{\text{Jumlah Pesan di Antrean}}{\text{Target Pesan per Worker}}$$ Jika ada 5.000 pesan di antrean dan kita menargetkan 1 worker memproses maksimal 50 pesan sekaligus, autoscaler otomatis menetapkan kapasitas berjalan ke 100 instans worker.

Ringkasan #

• Autoscaling bekerja berbasis control loop tertutup yang memantau metrik secara konstan dan menyesuaikan kapasitas instans agar sesuai dengan aturan kebijakan kita.
• Kebijakan Target Tracking adalah opsi default terbaik karena otomatis menghitung jumlah instans yang diperlukan secara proporsional mirip termostat.
• Aplikasi stateless adalah prasyarat mutlak agar perpindahan instans oleh autoscaling tidak memutus sesi login pengguna secara tidak sengaja.
• Terapkan Golden Image (pre-baked images) untuk memastikan startup time VM berjalan cepat (kurang dari 30 detik) saat memproses lonjakan trafik.
• Atur Cooldown Period untuk mencegah flapping — gunakan waktu cooldown pendek untuk scale-out demi respon cepat, dan cooldown panjang untuk scale-in demi menjaga stabilitas kapasitas.
• Pilih metrik trigger scaling yang mencerminkan bottleneck nyata — gunakan Queue Depth untuk pemrosesan asinkron, dan Request Count untuk API server.

← Sebelumnya: Managed Compute   Berikutnya: Spot/Preemptible Instance →