Penskalaan Berjadual dan Penskalaan Ramalan

Dasar penskalaan dinamik (penjejakan sasaran dan penskalaan berperingkat) bersifat reaktif—ia bertindak balas selepas ambang metrik telah dilampaui. Untuk corak trafik yang diketahui dan boleh diramal seperti kemuncak waktu bekerja, pelaksanaan kelompok pada hujung bulan atau jualan Black Friday, penskalaan reaktif terlalu lambat kerana pelancaran dan pemanasan tika mengambil masa beberapa minit. Penskalaan Berjadual dan Penskalaan Ramalan menangani perkara ini dengan melaraskan kapasiti secara proaktif sebelum beban tiba.

Tindakan Penskalaan Berjadual mengubah kapasiti minimum, maksimum atau dikehendaki ASG pada tarikh dan waktu tertentu, atau mengikut jadual cron yang berulang. Ini sesuai apabila anda mengetahui dengan tepat waktu beban akan meningkat—contohnya, memanaskan sistem terlebih dahulu sebelum acara pemasaran yang dirancang atau mengurangkan skala pada waktu malam apabila trafik minimum untuk menjimatkan kos. Tindakan berjadual mengatasi kapasiti dikehendaki semasa pada waktu yang ditetapkan.

Tindakan berjadual menggunakan format cron Unix: minute hour day-of-month month day-of-week. Semua waktu adalah dalam UTC. Corak umum termasuk 0 8 * * 1-5 (pagi hari bekerja pada 08:00 UTC) untuk meningkatkan penskalaan dan 0 20 * * * (setiap malam pada 20:00 UTC) untuk mengurangkan penskalaan. Anda boleh mencipta beberapa tindakan berjadual pada ASG yang sama, contohnya satu untuk meningkatkan penskalaan dan satu lagi untuk mengurangkannya semula setiap hari.

Tindakan berjadual boleh berlaku sekali sahaja (dilaksanakan sekali pada waktu mula tertentu) atau berulang (dilaksanakan mengikut jadual cron). Tindakan sekali sahaja sesuai untuk acara masa hadapan yang diketahui, seperti pelancaran produk. Tindakan berulang mengendalikan corak tetap seperti kitaran trafik harian atau mingguan. Anda juga boleh menetapkan waktu mula dan waktu tamat pada tindakan berulang untuk mendayakan dan melumpuhkan jadual secara automatik dalam julat tarikh tertentu.

Tindakan berjadual dan dasar penskalaan dinamik boleh digunakan bersama. Tindakan berjadual menetapkan kapasiti asas baharu pada waktu yang dijadualkan. Selepas itu, dasar dinamik (penjejakan sasaran atau penskalaan berperingkat) terus melaraskan kapasiti dalam had min/maks yang dikemas kini. Contohnya: tindakan berjadual pada waktu pagi menetapkan min=4, desired=8; pada waktu siang, penjejakan sasaran meningkatkan penskalaan kepada 15 apabila beban tinggi; kemudian tindakan berjadual pada waktu petang menetapkan semula min=2, desired=2.

Predictive Scaling menggunakan pembelajaran mesin untuk menganalisis corak beban sejarah daripada metrik CloudWatch dan meramalkan keperluan kapasiti pada masa hadapan. Ia menjadualkan tindakan peningkatan penskalaan secara proaktif sebelum beban yang diramalkan tiba—biasanya 5-60 minit lebih awal. Penskalaan ramalan paling sesuai untuk beban kerja dengan kitaran trafik harian atau mingguan yang berulang. Sistem ini mengemas kini ramalannya secara berterusan apabila mengumpulkan lebih banyak data.

Anda mendayakan penskalaan ramalan dengan melampirkan dasar PredictiveScaling pada ASG anda. Anda menentukan pasangan metrik: metrik beban (perkara yang mendorong penskalaan, seperti CPU atau kiraan permintaan ALB) dan metrik penskalaan (perkara yang anda jejaki pada setiap tika). AWS kemudiannya meramalkan metrik beban dan mengira bilangan tika yang diperlukan untuk mengekalkan metrik penskalaan pada nilai sasaran anda.

Predictive Scaling mempunyai dua mod: ForecastOnly menjana ramalan tanpa mengubah kapasiti sebenar—berguna untuk menyemak ramalan sebelum menggunakan penskalaan automatik. ForecastAndScale menjana ramalan dan menggunakan perubahan kapasiti secara automatik. Mulakan dengan ForecastOnly selama beberapa minggu untuk mengesahkan ketepatan, kemudian tukar kepada ForecastAndScale. AWS memerlukan sekurang-kurangnya 24 jam data metrik sebelum menjana ramalan pertama.

Predictive Scaling melaksanakan tindakan peningkatan penskalaan lebih awal, tetapi anda boleh mengkonfigurasi SchedulingBufferTime untuk memanaskan tika terlebih dahulu. Nilai SchedulingBufferTime selama 5 minit bermakna kapasiti ditambah 5 minit sebelum ramalan menjangkakan kapasiti itu diperlukan. Anda juga boleh menetapkan MaxCapacityBuffer untuk membenarkan ASG melakukan penskalaan melebihi keperluan yang diramalkan mengikut peratusan tertentu, sekali gus menyediakan penimbal lebihan kapasiti bagi menghadapi ketidaktepatan ramalan.

Pola yang disyorkan untuk beban kerja yang berubah-ubah tetapi boleh diramal adalah dengan menggabungkan kedua-duanya: Predictive Scaling mengendalikan beban kitaran yang dijangka dengan menyediakan kapasiti lebih awal, manakala Target Tracking Scaling mengendalikan lonjakan tidak dijangka yang melebihi ramalan. Bersama-sama, kedua-duanya menyediakan perlindungan proaktif dan reaktif. ASG menggunakan cadangan peningkatan penskalaan yang paling konservatif antara kedua-dua dasar dengan selamat.

Gunakan Scheduled Scaling apabila lonjakan trafik boleh diramal sepenuhnya dan anda mengetahui waktu yang tepat (corak dipacu acara atau waktu perniagaan). Gunakan Predictive Scaling apabila corak berulang tetapi waktunya mungkin berubah—pembelajaran mesin mempelajari corak itu secara automatik. Gunakan Target Tracking sebagai jaringan keselamatan dinamik yang sentiasa aktif untuk beban tidak dijangka. Bagi beban yang sepenuhnya rawak, bergantung pada penjejakan sasaran atau penskalaan berperingkat sahaja. Peperiksaan SAA-C03 sering meminta anda memilih pendekatan yang paling cekap dari segi operasi, dan penskalaan ramalan merupakan pilihan terbaik untuk beban kerja kitaran yang berulang.

Dalam pelajaran ini, anda telah mempelajari bahawa: Scheduled Scaling menggunakan ungkapan cron untuk mengubah kapasiti ASG pada waktu yang diketahui, sesuai untuk acara yang boleh diramal atau corak waktu perniagaan yang berulang; Predictive Scaling menggunakan pembelajaran mesin pada data sejarah CloudWatch untuk meningkatkan penskalaan secara proaktif sebelum beban tiba; dan gabungan Predictive + Target Tracking menyediakan perlindungan proaktif serta reaktif untuk strategi penskalaan yang paling berdaya tahan. Seterusnya, kita akan meneroka Instance Refresh dan Lifecycle Hooks untuk penggunaan yang terkawal.