Praktik terbaik untuk desain kebijakan penskalaan

Menggabungkan kebijakan penskalaan

Banyak pelanggan memilih untuk menggabungkan berbagai jenis kebijakan penskalaan dalam satu armada untuk meningkatkan daya dan fleksibilitas Auto Scaling AppStream di 2.0. Misalnya, Anda dapat mengonfigurasi kebijakan penskalaan terjadwal untuk meningkatkan minimum armada Anda pada pukul 6:00 pagi untuk mengantisipasi pengguna memulai hari kerja mereka, dan untuk mengurangi minimum armada pada pukul 16:00 sebelum pengguna berhenti bekerja. Anda dapat menggabungkan kebijakan penskalaan terjadwal ini dengan pelacakan target atau kebijakan penskalaan langkah untuk mempertahankan tingkat pemanfaatan tertentu dan penskalaan atau -out pada siang hari untuk menangani penggunaan runcing. Kombinasi penskalaan terjadwal dan penskalaan pelacakan target dapat membantu mengurangi dampak peningkatan tajam dalam tingkat pemanfaatan ketika kapasitas dibutuhkan segera.

Hindari penskalaan churn

Pertimbangkan apakah armada Anda mungkin mengalami churn tingkat tinggi karena kasus penggunaan Anda. Churn terjadi ketika sejumlah besar pengguna memulai dan kemudian mengakhiri sesi dalam waktu singkat. Ini mungkin terjadi ketika banyak pengguna secara bersamaan mengakses aplikasi di armada Anda hanya beberapa menit sebelum menandatangani.

Dalam situasi seperti itu, ukuran armada Anda mungkin turun jauh di bawah kapasitas yang diinginkan, karena instance berakhir ketika pengguna mengakhiri sesi mereka. Kebijakan penskalaan langkah mungkin tidak menambahkan instance dengan cukup cepat untuk mengimbangi churn dan, akibatnya, armada Anda macet pada ukuran tertentu.

Anda dapat mengidentifikasi churn dengan memeriksa CloudWatch metrik untuk armada Anda. Periode waktu ketika armada Anda memiliki kapasitas tertunda bukan nol tanpa perubahan (atau dengan sedikit perubahan) dalam kapasitas yang diinginkan menunjukkan bahwa churn tinggi kemungkinan terjadi. Untuk memperhitungkan situasi churn yang tinggi, gunakan kebijakan penskalaan pelacakan target dan pilih pemanfaatan target sehingga (100 - persen pemanfaatan target) lebih dari tingkat churn dalam periode 15 menit. Misalnya, jika 10% armada Anda akan berakhir dalam periode 15 menit karena omset pengguna, tetapkan target pemanfaatan kapasitas 90% atau kurang untuk mengimbangi churn tinggi.

Memahami tingkat penyediaan maksimum

Pelanggan yang mengelola AppStream 2.0 armada untuk sejumlah besar pengguna harus mempertimbangkan batas tarif penyediaan. Batas ini akan berdampak pada seberapa cepat instance dapat ditambahkan ke armada atau di semua armada dalam sebuah armada. Akun AWS

Ada dua batasan yang perlu dipertimbangkan:

• Untuk satu armada, AppStream 2.0 ketentuan dengan kecepatan maksimum 20 instance per menit.

• Untuk satuAkun AWS, ketentuan AppStream 2.0 dengan kecepatan 60 instance per menit (dengan ledakan 100 instance per menit).

Jika lebih dari tiga armada ditingkatkan secara paralel, batas tingkat penyediaan akun dibagi di seluruh armada ini (misalnya, enam armada penskalaan secara paralel dapat masing-masing menyediakan hingga 10 instance per menit). Selain itu, pertimbangkan jumlah waktu instans streaming tertentu untuk menyelesaikan penyediaan sebagai respons terhadap peristiwa penskalaan. Untuk armada yang tidak bergabung dengan domain Active Directory, ini biasanya 15 menit. Untuk armada yang bergabung dengan domain Active Directory, ini bisa memakan waktu selama 25 menit.

Mengingat kendala tersebut, pertimbangkan contoh-contoh berikut:

• Jika Anda ingin menskalakan satu armada dari 0 hingga 1000 instans, dibutuhkan waktu 50 menit (1000 instans/20 instans per menit) agar penyediaan selesai, dan kemudian tambahan 15-25 menit agar semua instans tersedia untuk pengguna akhir, dengan total 65-75 menit.

• Jika Anda ingin secara bersamaan menskalakan tiga armada dari 0 hingga 333 instance (untuk total 999 instance dalamAkun AWS), dibutuhkan sekitar 17 menit (999/60 instans per menit) untuk semua armada untuk menyelesaikan penyediaan dan kemudian tambahan 15 menit agar instans tersebut tersedia untuk pengguna akhir, dengan total 32-42 menit.

Memanfaatkan beberapa Availability Zone

Pilih beberapa AZ di Wilayah untuk penyebaran armada Anda. Ketika Anda memilih beberapa AZ untuk armada Anda, Anda meningkatkan kemungkinan armada Anda akan dapat menambahkan instance sebagai respons terhadap peristiwa penskalaan. CloudWatch Metrik PendingCapacity ini merupakan titik awal untuk menilai seberapa optimal desain armada AZ dalam penyebaran armada besar. Nilai yang tinggi dan berkelanjutan untuk PendingCapacity dapat menunjukkan kebutuhan untuk memperluas penskalaan horizontal (melintasi AZ). Untuk informasi selengkapnya, lihat Memantau Sumber Daya Amazon AppStream 2.0.

Misalnya, jika penskalaan otomatis mencoba menyediakan instans untuk meningkatkan ukuran armada Anda dan AZ yang dipilih memiliki kapasitas yang tidak mencukupi, penskalaan otomatis akan menambahkan instance di AZ lain yang telah Anda tentukan untuk armada Anda. Untuk informasi selengkapnya tentang Availability Zones dan desain AppStream 2.0, lihat Availability Zone dalam dokumen ini.

Pantau metrik Kesalahan Kapasitas Tidak Cukup

“Kesalahan Kapasitas Tidak Cukup” adalah CloudWatch metrik untuk armada AppStream 2.0. Metrik ini menentukan jumlah permintaan sesi yang ditolak karena kurangnya kapasitas.

Ketika Anda membuat perubahan pada kebijakan penskalaan Anda, akan sangat membantu untuk membuat CloudWatch alarm untuk memberi tahu Anda ketika terjadi Kesalahan Kapasitas Tidak Cukup. Ini memungkinkan Anda menyesuaikan kebijakan penskalaan dengan cepat untuk mengoptimalkan ketersediaan bagi pengguna. Panduan administrasi memberikan langkah-langkah rinci untuk memantau sumber daya AppStream 2.0 Anda.