Praktik terbaik untuk skala otomatis

  • Artikel

Skala otomatis Azure Monitor hanya berlaku untuk Azure Virtual Machine Scale Sets, Azure Cloud Services, fitur Web Apps Azure App Service, dan Azure API Management.

Konsep skala otomatis

  • Sumber daya hanya dapat memiliki satu pengaturan skala otomatis.
  • Pengaturan skala otomatis dapat memiliki satu atau beberapa profil, dan setiap profil dapat memiliki satu atau beberapa aturan skala otomatis.
  • Pengaturan skala otomatis menskalakan instans secara horizontal, yang keluar dengan meningkatkan instans dan masuk dengan mengurangi jumlah instans.
  • Pengaturan skala otomatis memiliki nilai instans maksimum, minimum, dan default.
  • Pekerjaan penskalaan otomatis selalu membaca metrik terkait untuk diskalakan, memeriksa apakah telah melewati ambang yang dikonfigurasi untuk peluasan atau penyempitan skala. Anda dapat melihat daftar metrik yang dapat diskalakan secara otomatis di Metrik umum penskalaan otomatis Azure Monitor.
  • Semua ambang dihitung pada tingkat instans. Contohnya adalah "peluasan skala oleh satu instans ketika CPU > rata-rata 80% ketika jumlah instans adalah 2." Ini berarti peluasan skala ketika CPU rata-rata di semua instans lebih besar dari 80%.
  • Semua kegagalan skala otomatis dicatat ke log aktivitas. Anda kemudian dapat mengonfigurasi pemberitahuan log aktivitas sehingga Anda dapat diberi tahu melalui email, SMS, atau webhook setiap kali terjadi kegagalan skala otomatis.
  • Demikian pula, semua tindakan skala yang berhasil diposting ke log aktivitas. Anda kemudian dapat mengonfigurasi peringatan log aktivitas sehingga Anda dapat diberi tahu melalui email, SMS, atau webhook setiap kali ada tindakan penskalaan otomatis yang berhasil. Anda juga dapat mengonfigurasi pemberitahuan surel atau webhook agar diberi tahu untuk tindakan skala yang berhasil melalui tab pemberitahuan pada pengaturan skala otomatis.

Praktik terbaik skala otomatis

Gunakan praktik terbaik berikut saat Anda menggunakan skala otomatis.

Pastikan nilai maksimum dan minimum berbeda serta memiliki margin yang memadai di antaranya

Jika Anda memiliki pengaturan yang memiliki minimum=2, maksimum=2, dan jumlah instans saat ini adalah 2, tidak ada tindakan skala yang dapat terjadi. Simpan margin yang memadai antara jumlah instans maksimum dan minimum, yang inklusif. Skala otomatis selalu menskalakan di antara batas-batas ini.

Penskalan manual diatur ulang dengan skala otomatis minimum dan maksimum

Jika Anda memperbarui jumlah instans secara manual ke nilai di atas atau di bawah maksimum, mesin skala otomatis secara otomatis menskalakan kembali ke minimum (jika di bawah) atau maksimum (jika di atas). Misalnya, Anda mengatur rentang antara 3 dan 6. Jika Anda memiliki satu instans yang berjalan, mesin skala otomatis akan diskalakan ke tiga instans pada eksekusi berikutnya. Demikian juga, jika Anda mengatur skala secara manual ke delapan instans, pada skala otomatis eksekusi berikutnya akan menskalakannya kembali ke enam instans pada eksekusi berikutnya. Penskalan manual bersifat sementara kecuali Anda juga mengatur ulang aturan skala otomatis.

Selalu gunakan kombinasi aturan peluasan skala dan penyempitan skala yang melakukan peningkatan dan penurunan

Jika Anda hanya menggunakan satu bagian dari kombinasi, skala otomatis hanya mengambil tindakan dalam satu arah (peluasan skala atau masuk) hingga mencapai jumlah instans maksimum, atau minimum, seperti yang didefinisikan dalam profil. Situasi ini tidak optimal. Idealnya, Anda ingin sumber daya Anda diskalakan pada saat penggunaan tinggi untuk memastikan ketersediaan. Demikian pula, pada saat penggunaan rendah, Anda ingin sumber daya Anda untuk menskalakan sehingga Anda dapat mewujudkan penghematan biaya.

Saat Anda menggunakan aturan penyempurnaan dan peluasan skala, idealnya gunakan metrik yang sama untuk mengontrol keduanya. Jika tidak, ada kemungkinan bahwa kondisi scale-in dan scale-out dapat dipenuhi pada saat yang sama dan menghasilkan beberapa tingkat flapping. Misalnya, kami tidak merekomendasikan kombinasi aturan berikut karena tidak ada aturan penyempurnaan skala untuk penggunaan memori:

  • Jika CPU > 90%, peluasan skala sebesar 1
  • Jika Memori > 90%, peluasan skala sebesar 1
  • Jika CPU < 45%, skalakan sebesar 1

Dalam contoh ini, Anda dapat memiliki situasi yang mana penggunaan memori lebih dari 90% tetapi penggunaan CPU di bawah 45%. Skenario ini dapat menyebabkan flapping selama kedua kondisi terpenuhi.

Pilih statistik yang sesuai untuk metrik diagnostik Anda

Untuk metrik diagnostik, Anda dapat memilih di antara Rata-Rata, Minimum, Maksimum, dan Total sebagai metrik untuk diskalakan. Statistik yang paling umum adalah Rata-rata.

Pertimbangan untuk menskalakan nilai ambang batas untuk metrik khusus

Untuk metrik khusus seperti Azure Storage atau metrik panjang antrean Azure Service Bus, ambang batasnya adalah jumlah rata-rata pesan yang tersedia per jumlah instans saat ini. Pilih nilai ambang untuk metrik ini dengan hati-hati.

Mari kita ilustrasikan dengan contoh untuk memastikan Anda memahami perilaku dengan lebih baik:

  • Menambah instans sebesar 1 hitungan saat jumlah >pesan antrean Penyimpanan = 50
  • Mengurangi instans sebesar 1 hitungan saat jumlah <pesan antrean Penyimpanan = 10

Pertimbangkan urutan berikut ini:

  1. Ada dua instans antrean Storage.
  2. Pesan terus datang dan saat Anda meninjau antrean Storage, jumlah total berbunyi 50. Anda mungkin berasumsi bahwa skala otomatis harus memulai tindakan peluasan skala. Namun, perhatikan bahwa masih 50/2 = 25 pesan per instans. Jadi, peluasan skala tidak terjadi. Agar tindakan peluasan skala pertama terjadi, jumlah total pesan dalam antrean Storage harus 100.
  3. Selanjutnya, asumsikan bahwa jumlah pesan total mencapai 100.
  4. Instans antrean Penyimpanan ketiga ditambahkan karena tindakan peluasan skala. Tindakan peluasan skala berikutnya tidak akan terjadi sampai jumlah total pesan dalam antrean mencapai 150 karena 150/3 = 50.
  5. Kini jumlah pesan dalam antrean semakin kecil. Dengan tiga instans, tindakan penyempitan skala pertama terjadi ketika pesan total di semua antrean bertambah hingga 30 karena 30/3 = 10 pesan per instans, yang merupakan ambang penyempitan skala.

Pertimbangan untuk penskalaan saat beberapa aturan dikonfigurasi dalam profil

Ada beberapa kasus di mana Anda mungkin harus menetapkan beberapa aturan dalam profil. Aturan skala otomatis berikut digunakan oleh mesin skala otomatis saat beberapa aturan ditetapkan:

  • Pada peluasan skala, skala otomatis berjalan jika ada aturan yang terpenuhi.
  • Pada penyempurnaan skala, skala otomatis mengharuskan semua aturan terpenuhi.

Untuk mengilustrasikan, asumsikan bahwa Anda memiliki empat aturan skala otomatis:

  • Jika CPU < 30%, skalakan sebesar 1
  • Jika Memori < 50%, skalakan sebesar 1
  • Jika CPU > 75%, luaskan skala sebesar 1
  • Jika Memori > 75%, luaskan skala sebesar 1

Kemudian tindakan berikut terjadi:

  • Jika CPU 76% dan Memori 50%, kami meluaskan skala.
  • Jika CPU 50% dan Memori 76%, kami meluaskan skala.

Di sisi lain, jika CPU 25% dan Memori 51%, skala otomatis tidak menskalakan masuk. Untuk menskalakan, CPU harus 29% dan Memori 49%.

Selalu pilih jumlah instans default yang aman

Jumlah instans default penting karena penskalaan otomatis menskalakan layanan Anda ke jumlah tersebut saat metrik tidak tersedia. Akibatnya, pilih jumlah instans default yang aman untuk beban kerja Anda.

Mengonfigurasi pemberitahuan skala otomatis

Posting skala otomatis ke log aktivitas jika salah satu kondisi berikut terjadi:

  • Skala otomatis mengeluarkan operasi penskalaan.
  • Layanan skala otomatis berhasil menyelesaikan tindakan penskalaan.
  • Layanan skala otomatis gagal mengambil tindakan skalakan.
  • Metrik tidak tersedia untuk layanan penskalaan otomatis guna membuat keputusan penskalaan.
  • Metrik tersedia (pemulihan) lagi untuk membuat keputusan penskalaan.
  • Skala otomatis mendeteksi flapping dan membatalkan upaya penskalaan. Anda melihat jenis Flapping log dalam situasi ini. Jika Anda melihat jenis log ini, pertimbangkan apakah ambang Anda terlalu sempit.
  • Skala otomatis mendeteksi flapping tetapi masih dapat berhasil menskalakan. Anda melihat jenis FlappingOccurred log dalam situasi ini. Jika Anda melihat jenis log ini, mesin skala otomatis telah mencoba untuk menskalakan (misalnya, dari empat instans menjadi dua) tetapi telah menentukan bahwa perubahan ini akan menyebabkan flapping. Sebaliknya, mesin skala otomatis telah diskalakan ke jumlah instans yang berbeda (misalnya, menggunakan tiga instans, bukan dua), yang tidak lagi menyebabkan flapping, sehingga telah diskalakan ke jumlah instans ini.

Anda juga dapat menggunakan pemberitahuan log aktivitas untuk memantau kesehatan mesin skala otomatis. Salah satu contoh menunjukkan cara membuat pemberitahuan log aktivitas untuk memantau semua operasi mesin skala otomatis pada langganan Anda. Contoh lain menunjukkan cara membuat pemberitahuan log aktivitas untuk memantau semua operasi penyempurnaan/peluasan skala otomatis yang gagal pada langganan Anda.

Selain menggunakan pemberitahuan log aktivitas, Anda juga dapat mengonfigurasi pemberitahuan surel atau webhook untuk mendapatkan pemberitahuan untuk tindakan skala melalui tab pemberitahuan pada pengaturan skala otomatis.

Mengirim data dengan aman menggunakan TLS 1.2

Untuk memastikan keamanan data saat transit ke Azure Monitor, kami sangat menganjurkan Anda untuk mengonfigurasi agen agar menggunakan setidaknya Keamanan Lapisan Transportasi (TLS) 1.2. Versi TLS/Secure Sockets Layer (SSL) yang lebih lama telah ditemukan rentan. Meskipun saat ini mereka masih bekerja untuk memungkinkan kompatibilitas mundur, kami tidak merekomendasikannya. Industri ini dengan cepat bergerak untuk meninggalkan dukungan untuk protokol yang lebih lama ini.

Dewan Standar Keamanan PCI telah menetapkan tenggat waktu 30 Juni 2018, untuk menonaktifkan versi TLS/SSL yang lebih lama dan meningkatkan ke protokol yang lebih aman. Setelah Azure menghilangkan dukungan warisan, jika agen Anda tidak dapat berkomunikasi setidaknya melalui TLS 1.2, Anda tidak akan dapat mengirim data ke Log Azure Monitor.

Kami menyarankan agar Anda tidak secara eksplisit mengatur agen Anda untuk hanya menggunakan TLS 1.2 kecuali diperlukan. Sebaiknya Anda mengizinkan agar agen secara otomatis mendeteksi, menegosiasi, dan memanfaatkan standar keamanan di masa mendatang. Jika tidak, Anda mungkin melewatkan keamanan tambahan dari standar yang lebih baru dan mungkin mengalami masalah jika TLS 1.2 tidak digunakan lagi demi standar yang lebih baru tersebut.

Langkah berikutnya