Kebijakan Penskalaan: Pelacakan Target dan Penskalaan Bertahap

Kapasitas yang diinginkan secara statis berfungsi saat beban tetap, tetapi lalu lintas di dunia nyata berfluktuasi. Kebijakan penskalaan memungkinkan Auto Scaling Group menyesuaikan kapasitas yang diinginkan secara otomatis sebagai respons terhadap metrik. AWS menyediakan tiga jenis kebijakan dinamis utama: Target Tracking, Step Scaling, dan Simple Scaling. Untuk ujian SAA-C03, pelacakan target dan penskalaan bertahap adalah yang paling penting untuk dipahami.

Target Tracking Scaling bekerja seperti termostat: Anda menentukan metrik dan nilai target, lalu AWS secara otomatis menghitung jumlah instans yang perlu ditambahkan atau dihapus agar metrik tetap berada pada target tersebut. Misalnya, jika Anda menargetkan pemakaian CPU rata-rata 50% dan pemakaian meningkat menjadi 80%, ASG akan menambahkan instans yang cukup untuk mengembalikan CPU ke 50%. AWS mengelola tindakan scale-out dan scale-in untuk Anda.

Target Tracking mendukung beberapa metrik bawaan secara langsung: ASGAverageCPUUtilization, ASGAverageNetworkIn, ASGAverageNetworkOut, dan ALBRequestCountPerTarget yang khusus untuk ALB. Untuk KPI khusus aplikasi (kedalaman antrean, koneksi aktif, metrik bisnis kustom), Anda dapat menyediakan metrik CloudWatch kustom. Metrik kustom memberi Anda kendali yang jauh lebih terperinci atas hal-hal yang mendorong keputusan penskalaan.

Setelah peristiwa scale-out, ASG menunggu periode cooldown (default 300 detik) sebelum mengevaluasi scale-out berikutnya. Hal ini memberi waktu kepada instans yang baru diluncurkan untuk mulai menangani lalu lintas sehingga metrik dapat stabil. Demikian pula, cooldown scale-in mencegah pengakhiran terlalu dini segera setelah kapasitas ditambahkan. Untuk pelacakan target, AWS juga merekomendasikan penggunaan periode pemanasan agar instans baru tidak memengaruhi metrik secara berlebihan sebelum sepenuhnya diinisialisasi.

Step Scaling merespons alarm CloudWatch dengan menambahkan atau menghapus jumlah instans tertentu berdasarkan seberapa jauh metrik melampaui ambang batas. Anda menentukan beberapa penyesuaian bertahap—setiap tahap mencakup rentang metrik dan menentukan perubahan kapasitas. Contohnya: jika CPU 60–70%, tambahkan 1 instans; jika CPU 70–90%, tambahkan 3 instans; jika CPU melebihi 90%, tambahkan 5 instans. Dengan demikian, Anda memperoleh respons bertahap dan proporsional terhadap tingkat beban yang berbeda.

Step scaling memerlukan alarm CloudWatch yang sudah ada. Alarm tersebut memantau metrik dan beralih ke status ALARM saat ambang batas terlewati. Kebijakan penskalaan kemudian menggunakan penyesuaian bertahap yang dirujuk berdasarkan nilai metrik relatif terhadap ambang alarm. Anda dapat mengonfigurasi apakah jenis penyesuaiannya adalah ChangeInCapacity (menambahkan N), ExactCapacity (menetapkan ke N), atau PercentChangeInCapacity (menskalakan sebesar N%).

Setiap step adjustment memiliki MetricIntervalLowerBound dan, secara opsional, MetricIntervalUpperBound. Batas-batas tersebut bersifat relatif terhadap ambang alarm. Jika ambang alarm adalah CPU 60%: LowerBound=0, UpperBound=10 dijalankan saat CPU 60–70%; LowerBound=10, UpperBound=null dijalankan saat CPU melebihi 70%. Pendekatan berlapis ini memastikan lonjakan lalu lintas besar segera mendapatkan penambahan kapasitas besar, alih-alih menunggu beberapa siklus alarm.

Simple Scaling adalah pendahulu step scaling. Seperti step scaling, fitur ini memerlukan alarm CloudWatch, tetapi saat dipicu, fitur ini menambahkan atau menghapus jumlah instans tetap, lalu menunggu seluruh periode cooldown berakhir sebelum melakukan evaluasi lagi. Hal ini membuatnya lambat dalam menghadapi beban yang berubah cepat. Step Scaling lebih disarankan karena dapat terus dijalankan saat kondisi memburuk tanpa menunggu cooldown penuh, dan merespons secara proporsional.

Terkadang Anda ingin mencegah instans tertentu diakhiri selama scale-in—misalnya, instans yang menjalankan pekerjaan batch berdurasi panjang. Anda dapat mengaktifkan perlindungan scale-in instans pada instans individual melalui konsol atau CLI. Saat ASG memilih kandidat untuk diakhiri, ASG akan melewati instans yang dilindungi. Ingatlah untuk menghapus perlindungan setelah pekerjaan selesai, atau ASG mungkin sama sekali tidak dapat melakukan scale-in jika semua instans dilindungi.

Anda dapat menghubungkan beberapa kebijakan penskalaan ke satu ASG. Jika terdapat kebijakan target tracking dan step scaling, ASG menggunakan kebijakan mana pun yang merekomendasikan tindakan scale-out lebih besar (paling konservatif). Untuk scale-in, kebijakan yang merekomendasikan penghapusan paling sedikit instans akan menang. Hal ini mencegah sistem berosilasi antara keadaan dengan penyediaan berlebih dan kurang. Pola yang umum adalah menggunakan kebijakan target tracking untuk kondisi stabil dan kebijakan step scaling untuk perlindungan terhadap lonjakan darurat.

Untuk sebagian besar aplikasi web, mulailah dengan target tracking berdasarkan CPU atau jumlah permintaan per target—konfigurasinya minimal dan AWS mengelola perhitungannya. Gunakan step scaling saat Anda memerlukan respons bertahap dan proporsional terhadap intensitas beban yang berbeda. Selalu tetapkan kapasitas minimum yang cukup tinggi untuk menangani lalu lintas dasar tanpa bergantung pada scale-out, karena penskalaan memerlukan waktu. Pantau metrik CloudWatch GroupDesiredCapacity dan GroupInServiceInstances untuk memverifikasi bahwa kebijakan Anda bekerja sesuai harapan.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari bahwa: Target Tracking Scaling secara otomatis menghitung dan menerapkan tindakan scale-out/in untuk menjaga metrik pada nilai yang diinginkan (seperti CPU 50%); Step Scaling menjalankan respons yang semakin besar secara proporsional saat metrik melewati ambang yang lebih tinggi, menggunakan penyesuaian bertahap berbasis alarm CloudWatch; dan penggabungan kebijakan pada satu ASG aman—ASG menggunakan rekomendasi scale-out yang paling konservatif dan rekomendasi scale-in yang paling tidak agresif. Selanjutnya, kita akan membahas penskalaan terjadwal dan prediktif untuk pola lalu lintas yang diketahui.