Lonjakan trafik sering datang pada waktu yang tidak nyaman: promosi baru dimulai, artikel mendadak dibagikan banyak orang, atau aplikasi sedang dipakai serentak oleh seluruh tim. Pada kondisi seperti ini, satu server dengan kapasitas tetap bisa menjadi titik lemah. CPU penuh, waktu respons melambat, lalu pengguna mulai melihat error.
Autoscaling dirancang untuk menghadapi situasi tersebut. Secara sederhana, autoscaling adalah mekanisme yang menambah atau mengurangi kapasitas komputasi berdasarkan beban. Namun, fitur ini bukan tombol ajaib. Jika aplikasi tidak siap berjalan di lebih dari satu instance, database menjadi bottleneck, atau aturan scaling keliru, autoscaling hanya akan menambah biaya tanpa membuat layanan benar-benar lebih stabil.
Autoscaling berarti menyesuaikan kapasitas, bukan sekadar menambah server
Ada dua pendekatan umum untuk memperbesar kapasitas aplikasi. Vertical scaling berarti menaikkan spesifikasi mesin yang sama, misalnya menambah CPU atau RAM. Cara ini relatif mudah, tetapi tetap dibatasi ukuran mesin yang tersedia dan sering membutuhkan proses restart.
Horizontal scaling berarti menambah jumlah instance yang menjalankan aplikasi. Misalnya, aplikasi yang biasanya berjalan pada dua server dapat diperluas menjadi lima server saat trafik naik, lalu dikurangi kembali ketika beban turun. Layanan cloud umumnya menggunakan pendekatan ini karena lebih fleksibel untuk menghadapi perubahan trafik.
Dokumentasi Azure menjelaskan bahwa autoscale dapat memakai metrik seperti penggunaan CPU, panjang antrean, dan memori sebagai dasar pengambilan keputusan. Di Kubernetes, mekanisme Horizontal Pod Autoscaler dapat menyesuaikan jumlah pod berdasarkan metrik yang diamati. Artinya, autoscaling bukan menebak-nebak, melainkan bekerja dari sinyal yang dikonfigurasi sebelumnya.
Mengapa CPU saja sering bukan indikator yang cukup?
Aturan seperti “tambah server ketika CPU melewati 70 persen” memang mudah dipahami. Namun, CPU bukan selalu penyebab utama aplikasi lambat. Website toko online dapat mengalami antrean panjang karena database kehabisan koneksi. API pembayaran dapat tersendat karena layanan pihak ketiga lambat. Aplikasi pemrosesan gambar bisa menunggu disk atau storage, bukan prosesor.
Karena itu, metrik scaling perlu disesuaikan dengan cara aplikasi bekerja. Beberapa contoh yang lebih relevan antara lain:
- Request per second untuk layanan API yang menerima banyak permintaan singkat.
- Latency untuk aplikasi yang harus memberi respons cepat.
- Queue length untuk sistem yang memproses pekerjaan secara bertahap.
- Memory usage untuk aplikasi yang menyimpan banyak data di memori.
- Jumlah koneksi database ketika database menjadi bagian paling sibuk dari sistem.
Untuk pekerjaan berbasis antrean, jumlah pesan yang menunggu sering lebih berguna daripada CPU. Jika antrean terus bertambah, menambah worker mungkin lebih tepat daripada menambah instance web.
Bagian aplikasi yang harus siap sebelum scale out
Scale out hanya bekerja baik jika setiap instance dapat melayani permintaan secara relatif mandiri. Salah satu masalah umum adalah penyimpanan sesi pengguna di memori lokal server. Ketika pengguna berpindah dari Server A ke Server B, sesi tersebut tidak ditemukan dan pengguna bisa tiba-tiba dianggap logout.
Solusinya dapat berupa penyimpanan sesi terpusat, seperti Redis atau database, atau menggunakan mekanisme autentikasi yang tidak bergantung pada memori lokal. File upload juga sebaiknya tidak hanya disimpan di disk lokal instance. Ketika instance diganti atau dihapus, file tersebut bisa ikut hilang jika tidak disimpan pada object storage atau volume yang memang dirancang untuk dibagikan.
Perhatikan pula proses startup aplikasi. Instance baru tidak langsung siap menerima trafik. Aplikasi mungkin masih menjalankan migrasi, memuat konfigurasi, atau melakukan koneksi ke layanan lain. Gunakan health check dan readiness check agar load balancer hanya mengirim permintaan ke instance yang benar-benar siap.
Autoscaling tidak menyelesaikan bottleneck database
Menambah sepuluh server aplikasi tidak banyak membantu jika semuanya menunggu database yang sama. Bahkan, scale out yang terlalu agresif bisa memperburuk keadaan karena jumlah koneksi ke database meningkat dalam waktu singkat.
Sebelum mengaktifkan autoscaling, periksa beberapa hal berikut:
- Apakah query yang sering dipakai sudah memiliki indeks yang sesuai?
- Apakah connection pool memiliki batas yang masuk akal?
- Apakah data yang sering dibaca dapat dibantu dengan cache?
- Apakah pekerjaan berat bisa dipindahkan ke background worker?
- Apakah database memiliki batas kapasitas dan rencana peningkatan yang jelas?
Dalam banyak kasus, antrean pekerjaan, caching, dan perbaikan query memberikan hasil lebih besar daripada sekadar menambah server aplikasi.
Atur batas minimum, maksimum, dan kecepatan perubahan
Autoscaling memerlukan batas yang jelas. Nilai minimum menjaga agar aplikasi tetap memiliki kapasitas dasar, sedangkan nilai maksimum mencegah sistem terus menambah resource ketika ada anomali atau serangan trafik.
Kecepatan perubahan juga penting. Jika sistem langsung menambah banyak instance hanya karena CPU naik sebentar, kapasitas bisa berayun naik turun. Pola ini sering disebut thrashing: sistem terlalu cepat bereaksi terhadap perubahan kecil.
Gunakan periode evaluasi dan waktu tunggu yang wajar antara scale out dan scale in. Scale in biasanya perlu dibuat lebih lambat daripada scale out. Menambah kapasitas dengan cepat dapat membantu menjaga layanan, sedangkan menghapus kapasitas terlalu cepat berisiko membuat aplikasi kembali kewalahan.
Yang bisa dilakukan sekarang
- Catat pola trafik. Lihat jam sibuk, jumlah permintaan, latency, error rate, dan penggunaan resource selama beberapa hari.
- Tentukan metrik utama. Pilih metrik yang paling dekat dengan dampak pengguna, bukan hanya metrik yang paling mudah dilihat.
- Uji aplikasi dengan dua atau lebih instance. Pastikan sesi, upload, cache, dan konfigurasi tidak bergantung pada server tertentu.
- Tetapkan batas resource. Buat nilai minimum dan maksimum instance agar biaya tetap dapat diprediksi.
- Simulasikan lonjakan trafik. Jalankan load test secara terkontrol dan amati database, queue, storage, serta layanan eksternal.
- Siapkan alarm biaya dan performa. Autoscaling yang sehat harus dipantau dari dua sisi: apakah pengguna mendapat layanan yang lebih baik dan apakah pengeluaran tetap masuk akal.
Autoscaling yang baik bukan sistem yang selalu menambah server. Ia adalah sistem yang tahu kapan harus menambah kapasitas, kapan harus berhenti, dan kapan masalah sebenarnya berada di komponen lain.
Apa artinya bagi kita?
Untuk aplikasi kecil, autoscaling mungkin belum perlu diterapkan sejak hari pertama. Satu VPS yang terukur, backup yang baik, monitoring, dan prosedur pemulihan sering sudah cukup untuk tahap awal. Namun, ketika trafik mulai tidak bisa diprediksi atau downtime memiliki dampak bisnis yang besar, autoscaling dapat menjadi bagian penting dari desain infrastruktur.
Mulailah dari arsitektur aplikasi, bukan dari menu konfigurasi cloud. Pastikan aplikasi dapat berjalan di beberapa instance, pahami bottleneck utama, lalu buat aturan scaling berdasarkan data nyata. Dengan pendekatan itu, autoscaling menjadi alat untuk menjaga keandalan, bukan sekadar fitur mahal yang terlihat canggih.
Untuk membaca detail teknis, lihat dokumentasi autoscale Azure, dokumentasi AWS Auto Scaling, dan panduan Horizontal Pod Autoscaler Kubernetes.
Sumber & bacaan lebih lanjut
– Rio Yotto @rioyotto