pola Penyeimbangan BebanQueue-Based

Gunakan antrean yang bertindak sebagai buffer antara tugas dan layanan yang dipanggilnya. Pendekatan ini menghaluskan beban berat terputus-terputus yang dapat menyebabkan layanan gagal atau tugas kehabisan waktu. Ini membantu meminimalkan efek puncak permintaan pada ketersediaan dan responsivitas tugas dan layanan.

Konteks dan masalah

Banyak solusi di komputasi awan menjalankan tugas yang memanggil layanan. Di lingkungan ini, beban berat terputus-terputus dapat menyebabkan masalah performa atau keandalan untuk layanan.

Layanan mungkin merupakan bagian dari solusi yang sama dengan tugas yang menggunakannya, atau mungkin merupakan layanan mitra yang menyediakan akses ke sumber daya yang sering digunakan. Contoh jenis layanan ini termasuk cache atau layanan penyimpanan. Ketika beberapa tugas berjalan bersamaan dan menggunakan layanan yang sama, sulit untuk memprediksi volume permintaan kapan saja.

Layanan mungkin mengalami puncak permintaan yang membebaninya dan membuat layanan tidak dapat merespons permintaan dengan cepat. Membanjiri suatu layanan dengan banyak permintaan yang dikirim secara bersamaan juga dapat menyebabkan layanan tersebut gagal jika layanan itu tidak mampu menangani perebutan sumber daya yang ditimbulkan oleh permintaan-permintaan tersebut.

Solusi

Tempatkan antrean antara tugas dan layanan. Tugas dan layanan berjalan secara asinkron. Tugas tersebut mengirimkan pesan yang berisi data yang diperlukan oleh layanan ke antrean. Antrean bertindak sebagai buffer dan menyimpan pesan hingga layanan mengambilnya. Layanan mengambil pesan dari antrean dan memprosesnya. Permintaan dari beberapa tugas, yang dapat dihasilkan pada laju yang sangat bervariasi, dapat dikirim ke layanan melalui antrean pesan yang sama. Diagram berikut menunjukkan bagaimana antrean dapat meratakan beban pada layanan.

Diagram yang memperlihatkan bagaimana antrean pesan bertindak sebagai buffer antara tugas dan layanan.

Antrean memisahkan tugas dari layanan sehingga layanan dapat menangani pesan dengan kecepatannya sendiri bahkan ketika tugas bersamaan menghasilkan volume permintaan yang tinggi. Selain itu, tugas tidak tertunda jika layanan tidak tersedia saat memposting pesan ke antrean.

Pola ini memberikan manfaat sebagai berikut:

  • Ini membantu memaksimalkan ketersediaan karena penundaan layanan tidak segera dan langsung memengaruhi aplikasi. Aplikasi dapat terus memposting pesan ke antrean bahkan ketika layanan tidak tersedia atau saat ini tidak memproses pesan.

  • Ini membantu memaksimalkan skalabilitas karena jumlah antrean dan jumlah layanan dapat bervariasi untuk memenuhi permintaan.

  • Ini membantu mengontrol biaya karena Anda hanya memerlukan instans layanan yang cukup untuk memenuhi persyaratan untuk beban rata-rata daripada beban puncak.

Note

Beberapa layanan menerapkan pembatasan ketika permintaan mencapai ambang batas yang dapat menyebabkan kegagalan sistem. Pelambatan dapat mengurangi fungsi yang tersedia. Terapkan perataan beban dalam layanan ini untuk memastikan bahwa permintaan tidak mencapai ambang batas ini.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

  • Terapkan logika aplikasi yang mengontrol laju di mana layanan menangani pesan untuk menghindari kewalahan sumber daya target. Hindari penerusan lonjakan permintaan ke tahap sistem berikutnya. Uji sistem dalam kondisi berbeban untuk memastikan bahwa sistem memberikan perataan yang diperlukan. Untuk mencapai tingkatan yang diperlukan, sesuaikan jumlah antrean dan jumlah instans layanan yang menangani pesan.

  • Antrean pesan adalah mekanisme komunikasi satu arah. Jika tugas mengharapkan balasan dari layanan, Anda mungkin perlu menerapkan mekanisme yang dapat digunakan layanan untuk mengirim respons. Untuk informasi selengkapnya, lihat opsi olahpesan Asynchronous di Azure.

  • Penskalaan otomatis tanpa membatasi laju hilir agregat konsumen hanya memindahkan beban berlebih ke ketergantungan hilir. Beban berlebih ini dapat meningkatkan perebutan atas sumber daya yang digunakan bersama oleh layanan-layanan ini dan mengurangi efektivitas antrean dalam menyeimbangkan beban.

  • Jika laju produksi rata-rata Anda melebihi laju konsumsi, antrean akan terus bertambah dan latensi meningkat. Pantau kedalaman antrean dan tingkatkan jumlah konsumen sesuai batas aman, atau kurangi beban kerja di sisi produsen.

  • Pola ini tergantung pada durabilitas antrean untuk mencegah kehilangan pesan. Jika broker tidak menyimpan pesan secara persisten ke media penyimpanan yang tahan lama, kerusakan sistem atau batas kapasitas dapat menyebabkan data yang telah dimasukkan ke antrean hilang sebelum diproses oleh konsumen. Pilih layanan antrean yang menyimpan pesan ke disk atau penyimpanan yang direplikasi, dan pahami kuota ukuran dan batas retensinya. Untuk beban kerja yang mengharuskan pesan bertahan dari kegagalan regional, evaluasi opsi pemulihan bencana geografis.

  • Sebagian besar layanan antrean mengirimkan pesan dengan semantik setidaknya sekali, yang berarti bahwa konsumen dapat menerima pesan yang sama lebih dari sekali. Merancang logika konsumen menjadi idempogen sehingga memproses pesan yang sama beberapa kali menghasilkan hasil yang sama dan menghindari masalah seperti catatan duplikat atau biaya berulang.

  • Beberapa pesan tidak dapat diproses karena berisi data yang salah bentuk, referensi sumber daya yang hilang, atau memicu kesalahan persisten. Daripada membiarkan siklus pesan ini tanpa batas waktu dan memblokir antrean, rutekan ke antrean surat mati. Pantau jumlah pesan dalam antrean dead-letter agar tim operasi Anda dapat menyelidiki kegagalan, memperbaiki akar masalah, dan mengirim ulang pesan jika perlu.

  • Menambahkan antrean antara produsen dan konsumen tidak mempertahankan urutan pengajuan semula dalam semua situasi, terutama ketika beberapa konsumen memproses pesan secara paralel. Jika beban kerja Anda memerlukan urutan yang ketat, gunakan fitur seperti sesi pesan di Azure Service Bus. Jika pengurutan yang ketat tidak diperlukan, rancang konsumen agar dapat menangani pesan dalam urutan apa pun, yang menyederhanakan penskalaan.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

  • Beban kerja Anda memiliki lonjakan sesekali yang dapat membebani layanan hilir.

  • Anda perlu memisahkan asupan permintaan dari pemrosesan throughput untuk meningkatkan ketahanan dan kontrol biaya.

Pola ini mungkin tidak cocok ketika:

  • Pemanggil memerlukan respons latensi rendah dan sinkron.

  • Volume beban kerja dapat diprediksi rendah dan stabil, sehingga menambahkan kompleksitas antrean memberikan sedikit manfaat.

Desain beban kerja

Evaluasi cara menggunakan pola Queue-Based Load Leveling dalam desain beban kerja untuk mendukung tujuan dan prinsip yang dibahas dalam pilar-pilar Azure Well-Architected Framework. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Prinsip Dasar Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi. Pendekatan yang dijelaskan oleh pola ini dapat memberikan resiliensi terhadap lonjakan permintaan yang tiba-tiba dengan memisahkan kedatangan tugas dari pemrosesannya. Ini juga dapat mengisolasi malfungsi dalam pemrosesan antrean sehingga tidak memengaruhi penerimaan.

- PENSKALAKAN RE:06
Pengoptimalan Biaya berfokus pada mempertahankan dan meningkatkanpengembalian beban kerja Anda pada investasi. Karena pemrosesan beban dipisahkan dari permintaan atau asupan tugas, Anda dapat menggunakan pendekatan ini untuk mengurangi kebutuhan akan sumber daya provisi berlebih untuk menangani beban puncak.

- Biaya penskalan CO:12
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode. Pendekatan ini memungkinkan desain yang disengaja untuk performa throughput karena asupan permintaan tidak perlu berkorelasi dengan tingkat pemrosesan.

- PE:05 Penskalaan dan pemartisian

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Aplikasi web menulis data ke penyimpanan data eksternal. Jika beberapa instans aplikasi web berjalan bersamaan, penyimpanan data mungkin tidak dapat merespons permintaan dengan cukup cepat, yang menyebabkan permintaan kehabisan waktu, dibatasi, atau gagal. Diagram berikut menunjukkan penyimpanan data yang kewalahan oleh permintaan bersamaan dari instans aplikasi.

Diagram yang menunjukkan beberapa permintaan serentak dari instans aplikasi web hingga membebani layanan secara berlebihan.

Untuk mengatasi masalah ini, gunakan antrean untuk meratakan beban antara instans aplikasi dan penyimpanan data. Aplikasi Azure Functions membaca pesan dari antrean Bus Layanan dan melakukan permintaan baca/tulis ke penyimpanan data. Azure Functions dapat menskalakan instans berdasarkan backlog Bus Layanan dengan menggunakan penskalakan berbasis target, dalam batas penskalakan yang dikonfigurasi. Anda juga dapat menyesuaikan setelan konkurensi pemicu untuk melindungi penyimpanan data. Untuk panduan implementasi, lihat Penskalaan berbasis target dan Peluasan skala batas. Tanpa penyetelan ini, lapisan pekerja dapat memperkenalkan kembali pertikaian back-end.

Diagram yang memperlihatkan cara menggunakan antrean dan aplikasi fungsi untuk meratakan beban.

Sebagai variasi teknologi, Anda dapat menerapkan pola yang sama dengan menggunakan Azure Container Apps alih-alih Azure Functions. Dalam pendekatan itu, worker yang dikontainerkan memproses pesan dari Bus Layanan dan menulis ke penyimpanan data. Container Apps menyesuaikan skala pekerja antara jumlah minimum dan maksimum replika yang dikonfigurasi berdasarkan aturan penskalaan terkait antrean. Anda juga dapat menerapkan pendekatan yang sama dengan menggunakan Azure Queue Storage sebagai sumber peristiwa. Untuk panduan implementasi, lihat Mengatur aturan penskalaan di Container Apps dan Menyebarkan pekerjaan berbasis peristiwa dengan menggunakan Container Apps.

Langkah berikutnya

Panduan berikut mungkin juga relevan saat menerapkan pola ini:

  • Opsi perpesanan asinkron di Azure: Antrean pesan pada dasarnya bersifat asinkron. Anda mungkin perlu mendesain ulang logika aplikasi tugas jika berkomunikasi langsung dengan layanan. Demikian juga, Anda mungkin perlu memfaktorkan ulang sebuah layanan agar dapat menerima permintaan dari antrean pesan.

  • Memilih antara layanan olahpesan Azure: Dapatkan informasi selengkapnya untuk membantu Anda memilih mekanisme olahpesan dan antrean dalam aplikasi Azure.

  • Rekomendasi untuk mengembangkan pekerjaan latar belakang: Terapkan pola ini ke pekerjaan latar belakang sehingga antrean pesan dapat menyimpan permintaan untuk tugas latar belakang saat aplikasi mengalami beban tinggi.

  • Gaya arsitektur Web-Queue-Worker: Aplikasi web dan worker keduanya tidak menyimpan status. Status sesi dapat disimpan dalam cache terdistribusi. Pekerja melakukan pekerjaan jangka panjang secara asinkron dan dapat dipicu oleh pesan pada antrean atau berjalan sesuai jadwal pemrosesan batch.

  • Pola Konsumen Bersaing: Mungkin saja menjalankan beberapa instans dari suatu layanan, yang masing-masing bertindak sebagai konsumen pesan dari antrean penyeimbang beban. Anda dapat menggunakan pendekatan ini untuk menyesuaikan tingkat penerimaan dan pengiriman pesan ke layanan.

  • Pola pembatasan laju: Cara sederhana untuk menerapkan pembatasan laju dalam suatu layanan adalah dengan menggunakan penyeimbangan beban berbasis antrean dan mengarahkan semua permintaan ke layanan tersebut melalui antrean pesan. Layanan ini dapat memproses permintaan pada laju yang memastikan layanan tidak menguras sumber daya yang diperlukan dan mengurangi potensi perebutan sumber daya.