Ketika jumlah pengunjung naik, solusi yang sering terdengar adalah mengaktifkan autoscaling. Secara sederhana, autoscaling memungkinkan cloud menambah atau mengurangi jumlah server sesuai beban kerja. Ide ini masuk akal: saat ramai, kapasitas bertambah; saat sepi, resource dikurangi agar biaya tidak terus berjalan.
Masalahnya, autoscaling bukan tombol ajaib. Jika aplikasi menyimpan sesi di satu server, database sudah menjadi hambatan, atau lonjakan trafik selesai sebelum server baru siap, menambah instance justru bisa membuat sistem lebih rumit dan tagihan meningkat. Autoscaling bekerja baik bila fondasi aplikasi, pengukuran, dan batas pengeluarannya sudah dipikirkan.
Apa sebenarnya yang dilakukan autoscaling?
Ada dua pendekatan umum. Scale up berarti menaikkan kapasitas satu mesin, misalnya mengganti VPS dengan spesifikasi CPU dan RAM yang lebih besar. Scale out berarti menambah beberapa instance agar beban dibagi ke banyak mesin.
Autoscaling biasanya lebih dekat dengan scale out. Cloud memantau metrik seperti penggunaan CPU, jumlah request, panjang antrean, atau metrik khusus dari aplikasi. Jika kondisi tertentu terpenuhi, sistem menambah instance. Ketika beban turun, sebagian instance dapat dihentikan.
Dokumentasi arsitektur cloud umumnya menekankan bahwa scale out membutuhkan aplikasi yang mampu berjalan di lebih dari satu instance. Artinya, request pengguna tidak boleh bergantung pada satu server tertentu. Aplikasi juga sebaiknya bersifat stateless, yaitu informasi sesi dan status penting disimpan di layanan bersama, bukan hanya di memori satu mesin.
Mengapa CPU saja sering menjadi sinyal yang buruk?
CPU mudah dipahami dan tersedia hampir di semua layanan cloud. Namun, CPU bukan selalu penyebab utama lambatnya aplikasi.
- Aplikasi katalog bisa mengalami antrean database meskipun CPU masih rendah.
- Worker pemroses gambar mungkin lebih tepat diskalakan berdasarkan panjang antrean.
- API pembayaran sebaiknya dipantau melalui latency, error rate, dan jumlah request yang sedang diproses.
- Aplikasi berbasis Node.js dapat terlihat tidak terlalu sibuk di beberapa core, tetapi tetap mengalami penumpukan event loop.
Karena itu, metrik autoscaling sebaiknya dikaitkan dengan cara aplikasi bekerja. Untuk layanan web, jumlah request per detik atau latency p95—waktu respons yang mencakup 95 persen request tercepat—kadang lebih relevan daripada CPU. Untuk sistem berbasis antrean, jumlah pesan yang belum diproses dapat menjadi indikator yang lebih masuk akal.
Analisis: metrik terbaik bukan yang paling mudah ditemukan di dashboard, melainkan yang paling dekat dengan pengalaman pengguna atau kapasitas bisnis. Jika pelanggan menunggu terlalu lama karena antrean order, CPU 45 persen tidak berarti sistem baik-baik saja.
Autoscaling tidak terjadi seketika
Salah satu salah kaprah yang sering muncul adalah menganggap server baru langsung tersedia begitu metrik melewati ambang batas. Kenyataannya, sistem perlu mendeteksi kondisi, mengambil keputusan, membuat instance, menjalankan proses boot, memasang konfigurasi, lalu memasukkan instance tersebut ke belakang load balancer.
Proses ini dapat memakan waktu. Jika lonjakan trafik hanya berlangsung satu atau dua menit, server tambahan mungkin baru siap ketika beban sudah turun. Untuk pola trafik yang bisa diprediksi, scheduled scaling lebih masuk akal. Contohnya, menambah kapasitas 15 menit sebelum jam promosi dimulai.
Untuk lonjakan yang tidak bisa diprediksi, autoscaling reaktif tetap berguna, tetapi perlu dipadukan dengan cache, CDN, antrean, pembatasan request, atau mekanisme graceful degradation. Fitur yang tidak kritis, seperti rekomendasi produk atau laporan real-time, dapat ditunda sementara agar fungsi utama tetap berjalan.
Atur batas minimum dan maksimum dengan sengaja
Konfigurasi minimum dan maksimum bukan sekadar angka teknis. Nilai minimum menentukan kapasitas dasar yang selalu tersedia, sedangkan maksimum menjadi pagar agar sistem tidak menambah resource tanpa batas.
Minimum yang terlalu rendah dapat menyebabkan cold start, antrean panjang, atau hilangnya kapasitas redundan. Sebaliknya, minimum yang terlalu tinggi membuat biaya tetap besar bahkan ketika trafik sedang sepi.
Batas maksimum juga perlu disesuaikan dengan kemampuan komponen lain. Jika aplikasi dapat membuka hingga 50 instance, tetapi database hanya sanggup melayani 10 koneksi aktif per instance, autoscaling compute bisa mempercepat kerusakan di lapisan database.
Menambah server aplikasi tidak sama dengan menambah kapasitas seluruh sistem.
Mulailah dengan angka konservatif. Pantau penggunaan resource, waktu respons, error rate, dan biaya selama beberapa minggu. Setelah itu, naikkan batas secara bertahap berdasarkan data nyata, bukan perkiraan optimistis.
Waspadai flapping dan tagihan yang ikut naik
Flapping terjadi ketika sistem terlalu sering scale out dan scale in karena ambang batasnya terlalu berdekatan. Misalnya, aplikasi menambah instance saat CPU melewati 70 persen, lalu langsung menghapusnya ketika turun ke 65 persen. Jika beban berubah-ubah di sekitar angka tersebut, jumlah instance bisa naik turun berkali-kali.
Gunakan jarak yang cukup antara aturan scale out dan scale in. Beri pula waktu agar instance baru benar-benar menerima trafik sebelum keputusan berikutnya dibuat. Beberapa platform menyediakan cooldown atau kontrol laju scale-in untuk mencegah pengurangan kapasitas terlalu agresif.
Jangan hanya mengirim notifikasi ketika autoscaling berhasil. Catat juga kapan metrik tidak tersedia, kapan batas maksimum tercapai, dan kapan aksi scaling gagal. Tanpa log ini, tim bisa mengira sistem sudah elastis padahal aplikasi terus bekerja pada kapasitas minimum.
Checklist sebelum mengaktifkan autoscaling
- Pastikan aplikasi bisa berjalan di banyak instance. Hindari menyimpan sesi pengguna, file upload sementara, atau state penting hanya di disk lokal server.
- Tentukan metrik berdasarkan bottleneck nyata. Bandingkan CPU, memory, latency, request per detik, koneksi database, dan panjang antrean.
- Uji scale out dan scale in. Pastikan instance baru mendapat konfigurasi yang benar dan instance yang dihapus tidak memutus pekerjaan aktif.
- Tetapkan minimum, maksimum, dan default yang aman. Batas ini harus mempertimbangkan kapasitas database, cache, queue, dan anggaran.
- Siapkan perlindungan biaya. Gunakan budget alert, notifikasi ketika batas maksimum tercapai, dan review tagihan setelah pengujian.
- Siapkan rencana saat kapasitas maksimum tercapai. Throttling, antrean, atau penonaktifan fitur nonkritis lebih baik daripada membiarkan semua request gagal bersamaan.
Apa artinya bagi kita?
Untuk blog, company profile, atau aplikasi kecil dengan trafik stabil, autoscaling mungkin belum menjadi prioritas. Caching, optimasi query, CDN, dan satu konfigurasi server yang sehat sering memberi hasil lebih besar dengan kompleksitas lebih rendah.
Autoscaling mulai menarik ketika pola beban berubah, biaya kapasitas cadangan terasa berat, atau aplikasi perlu tetap melayani pengguna saat trafik meningkat. Namun, manfaatnya baru terasa jika sistem sudah dapat diukur dan komponennya tidak bergantung pada satu mesin.
Langkah paling aman bukan langsung menaikkan batas instance, melainkan membuat uji beban kecil. Ukur kapan latency mulai memburuk, komponen mana yang menjadi bottleneck, berapa lama instance baru siap, dan berapa biaya tambahan yang muncul. Dari sana, autoscaling menjadi keputusan berbasis data—bukan sekadar fitur yang dicentang karena tersedia di dashboard cloud.
Sumber & bacaan lebih lanjut
- Autoscaling Guidance - Azure Architecture Center
- Best practices for autoscale - Azure Monitor
- Autoscaling groups of instances - Google Cloud Documentation
- Scaling cooldowns for Amazon EC2 Auto Scaling
– Rio Yotto @rioyotto