Rekomendasi untuk merancang strategi penskalaan yang andal
Berlaku untuk rekomendasi daftar periksa Keandalan Azure Well-Architected Framework ini:
| RE:06 | Terapkan strategi penskalakan yang tepat waktu dan andal di tingkat aplikasi, data, dan infrastruktur. |
|---|
Panduan terkait:Pemartisian data
Panduan ini menjelaskan rekomendasi untuk merancang strategi penskalaan yang andal.
Definisi
| Istilah | Definisi |
|---|---|
| Penskalaan Vertikal | Pendekatan penskalaan yang menambahkan kapasitas komputasi ke sumber daya yang ada. |
| Penskalaan horizontal | Pendekatan penskalaan yang menambahkan instans dari jenis sumber daya tertentu. |
| Penskalaan otomatis | Pendekatan penskalaan yang secara otomatis menambahkan atau menghapus sumber daya saat serangkaian kondisi terpenuhi. |
Catatan
Operasi penskalaan dapat statis (penskalaan harian yang dijadwalkan secara teratur untuk mengakomodasi pola beban normal), otomatis (proses otomatis sebagai respons terhadap kondisi yang terpenuhi), atau manual (operator melakukan operasi penskalaan satu kali sebagai reaksi terhadap perubahan beban yang tidak diantisipasi). Penskalaan vertikal dan horizontal dapat dilakukan melalui salah satu metode ini. Namun, penskalaan vertikal otomatis memerlukan pengembangan otomatisasi kustom tambahan dan dapat menyebabkan waktu henti tergantung pada sumber daya yang diskalakan.
Strategi desain utama
Untuk merancang strategi penskalaan yang andal untuk beban kerja Anda, fokus pada identifikasi pola beban untuk pengguna dan alur sistem untuk setiap beban kerja yang mengarah ke operasi penskalaan. Berikut adalah contoh pola beban yang berbeda:
Statis: Setiap malam pukul 23.00 EST, jumlah pengguna aktif di bawah 100 dan pemanfaatan CPU untuk server aplikasi turun 90% di semua simpul.
Dinamis, teratur, dan dapat diprediksi: Setiap Senin pagi, 1000 karyawan di beberapa wilayah masuk ke sistem ERP.
Dinamis, tidak teratur, dan dapat diprediksi: Peluncuran produk terjadi pada hari pertama dalam sebulan dan ada data historis dari peluncuran sebelumnya tentang bagaimana lalu lintas meningkat dalam situasi ini.
Dinamis, tidak teratur, dan tidak dapat diprediksi: Peristiwa skala besar menyebabkan lonjakan permintaan produk. Misalnya, perusahaan yang memproduksi dan menjual dehumidifier dapat mengalami lonjakan lalu lintas yang tiba-tiba setelah badai atau peristiwa banjir lainnya ketika orang-orang di daerah yang terkena dampak perlu mengeringkan kamar di rumah mereka.
Setelah mengidentifikasi jenis pola beban ini, Anda dapat:
Identifikasi bagaimana perubahan beban yang terkait dengan setiap pola memengaruhi infrastruktur Anda.
Bangun otomatisasi untuk mengatasi penskalaan dengan andal.
Untuk contoh sebelumnya, strategi penskalaan Anda bisa:
Statis: Anda memiliki skala simpul komputasi terjadwal hingga jumlah minimum (2) antara pukul 23.00 dan 06.00 EST.
Dinamis, reguler, dan dapat diprediksi: Anda memiliki skala terjadwal dari simpul komputasi Anda ke kapasitas harian normal sebelum wilayah pertama mulai berfungsi.
Dinamis, tidak teratur, dan dapat diprediksi: Anda menentukan peningkatan skala terjadwal satu kali instans komputasi dan database Anda pada pagi hari peluncuran produk, dan Anda menurunkan skala kembali setelah satu minggu.
Dinamis, tidak teratur, dan tidak dapat diprediksi: Anda memiliki ambang skala otomatis yang ditentukan untuk memperhitungkan lonjakan lalu lintas yang tidak diencana.
Saat merancang otomatisasi penskalaan Anda, pastikan untuk mempertangungjawabkan masalah ini:
Bahwa semua komponen beban kerja Anda harus menjadi kandidat untuk implementasi penskalaan. Dalam kebanyakan kasus, layanan global seperti Microsoft Entra SKALA ID secara otomatis dan transparan kepada Anda dan pelanggan Anda. Pastikan untuk memahami kemampuan penskalaan pengontrol masuk dan keluar jaringan Anda serta solusi penyeimbangan beban Anda.
Komponen-komponen yang tidak dapat diskalakan. Contohnya adalah database relasional besar yang tidak mengaktifkan sharding dan tidak dapat direfaktor tanpa dampak signifikan. Dokumenter batas sumber daya yang diterbitkan oleh penyedia cloud Anda dan pantau sumber daya tersebut dengan cermat. Sertakan sumber daya khusus tersebut dalam perencanaan masa depan Anda untuk bermigrasi ke layanan yang dapat diskalakan.
Waktu yang diperlukan untuk melakukan operasi penskalakan sehingga Anda menjadwalkan operasi dengan benar agar terjadi sebelum beban tambahan mencapai infrastruktur Anda. Misalnya, jika komponen seperti API Management membutuhkan waktu 45 menit untuk diskalakan, menyesuaikan ambang penskalaan menjadi 65% alih-alih 90% mungkin membantu Anda menskalakan lebih awal dan mempersiapkan peningkatan beban yang diantisipasi.
Hubungan komponen alur dalam hal urutan operasi skala. Pastikan Anda tidak secara tidak sengaja membebani komponen hilir dengan menskalakan komponen upstream terlebih dahulu.
Setiap elemen aplikasi stateful yang mungkin terganggu oleh operasi penskalaan dan afinitas sesi apa pun (atau kelekatan sesi) yang diterapkan. Kelekatan dapat membatasi kemampuan penskalaan Anda dan memperkenalkan satu titik kegagalan.
Potensi penyempitan. Perluasan skala tidak memperbaiki setiap masalah performa. Misalnya, jika database backend Anda adalah penyempitan, tidak membantu menambahkan lebih banyak server web. Identifikasi dan atasi hambatan dalam sistem terlebih dahulu sebelum hanya menambahkan lebih banyak instans. Bagian stateful dari sistem adalah penyebab paling mungkin dari penyempitan.
Mengikuti pola desain stempel penyebaran membantu manajemen infrastruktur Anda secara keseluruhan. Mendinginkan desain penskalaan Anda pada stempel sebagai unit skala juga bermanfaat. Ini membantu Anda mengontrol operasi penskalaan dengan ketat di beberapa beban kerja dan subset beban kerja. Daripada mengelola jadwal penskalaan dan ambang penskalaan otomatis dari banyak sumber daya yang berbeda, Anda dapat menerapkan serangkaian definisi penskalaan terbatas ke stempel penyebaran dan kemudian mencerminkannya di seluruh stempel sesuai kebutuhan.
Tradeoff: Peningkatan skala memiliki implikasi biaya, jadi optimalkan strategi Anda untuk menurunkan skala sesegera mungkin untuk membantu menjaga biaya tetap terkendali. Pastikan bahwa otomatisasi yang Anda gunakan untuk meningkatkan skala juga memiliki pemicu untuk menurunkan skala.
Fasilitasi Azure
Fitur autoscaling tersedia di banyak layanan Azure. Ini memungkinkan Anda dengan mudah mengonfigurasi kondisi untuk menskalakan instans secara otomatis secara horizontal. Beberapa layanan memiliki fungsionalitas terbatas atau tidak ada fungsi bawaan untuk menskalakan secara otomatis, jadi pastikan untuk mendokumen kasus ini dan menentukan proses untuk menangani penskalakan.
Banyak layanan Azure menawarkan API yang dapat Anda gunakan untuk merancang operasi penskalakan otomatis kustom menggunakan Azure Automation, seperti sampel kode di Skala otomatis Azure IoT Hub Anda. Anda dapat menggunakan alat seperti KEDA untuk penskalaan otomatis berbasis peristiwa, yang tersedia di Azure Kubernetes Service dan Azure Container Apps.
Skala otomatis Azure Monitor menyediakan serangkaian fungsionalitas penskalaan otomatis umum untuk Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps, dan banyak lagi. Penskalakan dapat dilakukan sesuai jadwal atau berdasarkan metrik runtime, seperti penggunaan CPU atau memori. Lihat panduan Azure Monitor untuk praktik terbaik.
Tradeoffs
Pertimbangan penskalaan otomatis
Penskalaan otomatis bukanlah solusi instan. Cukup menambahkan sumber daya ke sistem atau menjalankan lebih banyak contoh proses tidak menjamin bahwa performa sistem akan meningkat. Pertimbangkan poin-poin berikut saat merancang strategi penskalaan otomatis:
Sistem harus dirancang agar dapat diskalakan secara horizontal. Hindari membuat asumsi tentang afinitas instans. Jangan merancang solusi yang mengharuskan kode selalu berjalan dalam contoh proses tertentu. Saat menskalakan layanan cloud atau situs web secara horizontal, jangan berasumsi bahwa serangkaian permintaan dari sumber yang sama selalu dirutekan ke instans yang sama. Untuk alasan yang sama, rancang layanan menjadi tanpa status guna menghindari serangkaian permintaan dari aplikasi untuk selalu dirutekan ke instans layanan yang sama. Saat merancang layanan yang membaca pesan dari antrean dan memprosesnya, jangan membuat asumsi tentang layanan mana yang menangani pesan tertentu. Penskalaan otomatis dapat memulai lebih banyak instans layanan saat panjang antrean tumbuh. Pola Konsumen yang Bersaing menjelaskan cara menangani skenario ini.
Jika solusi mengimplementasikan tugas yang berjalan lama, rancang tugas ini untuk mendukung peluasan dan penyempitan skala. Tanpa berhati-hati, tugas seperti itu dapat mencegah instans proses dimatikan dengan bersih ketika sistem menskalakan masuk. Atau, itu bisa kehilangan data jika proses berakhir secara paksa. Idealnya, refaktor tugas yang sudah berjalan lama dan pisahkan pemrosesan yang dijalankannya menjadi gugus yang lebih kecil dan terpisah. Pola Pipa dan Filter memberikan contoh bagaimana Anda dapat mencapai solusi ini.
Atau, Anda dapat menerapkan mekanisme titik pemeriksaan yang merekam informasi status tentang tugas secara berkala. Anda kemudian dapat menyimpan status ini dalam penyimpanan tahan lama yang dapat diakses oleh instans apa pun dari proses yang menjalankan tugas. Dengan cara ini, jika proses dimatikan, pekerjaan yang dilakukannya dapat dilanjutkan dari titik pemeriksaan terakhir oleh instans lain. Ada pustaka yang menyediakan fungsionalitas ini, seperti NServiceBus dan MassTransit. Mereka secara transparan mempertahankan status, di mana interval selaras dengan pemrosesan pesan dari antrean dalam Azure Service Bus.
Saat tugas latar belakang berjalan pada instans komputasi terpisah, seperti dalam peran pekerja dari aplikasi yang dihosting layanan cloud, Anda mungkin perlu menskalakan berbagai bagian aplikasi dengan menggunakan kebijakan penskalaan yang berbeda. Misalnya, Anda mungkin perlu menyebarkan instans komputasi antarmuka pengguna (UI) tambahan tanpa meningkatkan jumlah instans komputasi latar belakang, atau sebaliknya. Jika Anda menawarkan tingkat layanan yang berbeda, seperti paket layanan dasar dan premium, Anda mungkin perlu menskalakan sumber daya komputasi untuk paket layanan premium secara lebih agresif daripada paket layanan dasar untuk memenuhi perjanjian tingkat layanan (SLA).
Pertimbangkan panjang antrean di mana UI dan instans komputasi latar belakang berkomunikasi. Gunakan sebagai kriteria untuk strategi penskalaan otomatis Anda. Masalah ini adalah salah satu indikator kemungkinan ketidakseimbangan atau perbedaan antara beban saat ini dan kapasitas pemrosesan tugas latar belakang. Atribut yang sedikit lebih kompleks tetapi lebih baik untuk mendasarkan keputusan penskalakan adalah menggunakan waktu antara kapan pesan dikirim dan kapan pemrosesannya selesai. Interval ini dikenal sebagai waktu kritis. Jika nilai waktu kritis ini di bawah ambang batas bisnis yang bermakna, maka tidak perlu untuk menskalakan, bahkan jika panjang antrean panjang.
Misalnya, mungkin ada 50.000 pesan dalam antrean. Tetapi waktu kritis pesan tertua adalah 500 md, dan titik akhir berurusan dengan integrasi dengan layanan web pihak ketiga untuk mengirim email. Pemangku kepentingan bisnis kemungkinan akan menganggap bahwa sebagai periode waktu yang tidak akan membenarkan pengeluaran uang tambahan untuk penskalaan.
Di sisi lain, mungkin ada 500 pesan dalam antrean, dengan waktu kritis 500 ms yang sama, tetapi titik akhir adalah bagian dari jalur kritis dalam beberapa game online real-time di mana pemangku kepentingan bisnis menentukan waktu respons 100 ms atau kurang. Dalam hal ini, perluasan skala akan masuk akal.
Untuk menggunakan waktu penting dalam keputusan penskalaan otomatis, ada baiknya membuat pustaka secara otomatis menambahkan informasi yang relevan ke header pesan saat dikirim dan diproses. Salah satu pustaka yang menyediakan fungsionalitas ini adalah NServiceBus.
Jika Anda mendasarkan strategi penskalaan otomatis Anda pada penghitung yang mengukur proses bisnis, seperti jumlah pesanan yang ditempatkan per jam atau waktu berjalan rata-rata transaksi yang kompleks, pastikan Anda sepenuhnya memahami hubungan antara hasil dari jenis penghitung ini dan persyaratan kapasitas komputasi yang sebenarnya. Mungkin perlu untuk menskalakan lebih dari satu komponen atau unit komputasi sebagai respons terhadap perubahan penghitung proses bisnis.
Untuk mencegah sistem mencoba menskalakan secara berlebihan, dan untuk menghindari biaya yang terkait dengan menjalankan ribuan instans, pertimbangkan untuk membatasi jumlah maksimum instans yang ditambahkan secara otomatis. Sebagian besar mekanisme penskalaan otomatis memungkinkan Anda menentukan jumlah instans minimum dan maksimum untuk aturan. Selain itu, pertimbangkan untuk menurunkan fungsionalitas yang disediakan sistem dengan baik jika jumlah maksimum instans telah disebarkan dan sistem masih kelebihan beban.
Perlu diingat bahwa autoscaling mungkin bukan mekanisme yang paling tepat untuk menangani ledakan tiba-tiba dalam beban kerja. Perlu waktu untuk menyediakan dan memulai instans baru layanan atau menambahkan sumber daya ke sistem, dan permintaan puncak mungkin berlalu pada saat sumber daya tambahan ini tersedia. Dalam skenario ini, mungkin lebih baik untuk membatasi layanan. Untuk informasi selengkapnya, lihat Pola pembatasan.
Sebaliknya, jika Anda membutuhkan kapasitas untuk memproses semua permintaan ketika volume berfluktuasi dengan cepat, dan biaya bukanlah faktor kontribusi utama, pertimbangkan untuk menggunakan strategi penskalaan otomatis agresif yang memulai lebih banyak instans dengan lebih cepat. Anda juga dapat menggunakan kebijakan terjadwal yang memulai jumlah instans yang cukup untuk memenuhi beban maksimum sebelum beban tersebut terpenuhi.
Mekanisme penskalaan otomatis harus memantau proses penskalaan otomatis dan mencatat detail setiap peristiwa penskalaan otomatis (apa yang memicunya, sumber daya apa yang ditambahkan atau dihapus, dan kapan). Jika Anda membuat mekanisme penskalaan otomatis kustom, pastikan mekanisme tersebut menyertakan kemampuan ini. Analisis informasi untuk membantu mengukur efektivitas strategi penskalaan otomatis, dan sesuaikan jika perlu. Anda dapat menyesuaikan keduanya dalam jangka pendek, ketika pola penggunaan menjadi lebih jelas, dan dalam jangka panjang, ketika bisnis bertambah besar atau persyaratan aplikasi berkembang. Jika aplikasi mencapai batas atas yang ditentukan untuk penskalaan otomatis, mekanisme mungkin juga memberi tahu operator yang dapat memulai lebih banyak sumber daya secara manual jika perlu. Dalam keadaan ini, operator mungkin juga bertanggung jawab untuk menghapus sumber daya ini secara manual setelah beban kerja mudah.
Contoh
Lihat panduan penskalaan arsitektur referensi garis besar AKS.
Tautan terkait
Daftar periksa keandalan
Lihat serangkaian rekomendasi lengkap.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk