Pola pelambatan

Azure

Mengontrol penggunaan sumber daya yang digunakan oleh instans aplikasi, penyewa individu, atau seluruh layanan. Ini dapat memungkinkan sistem untuk terus berfungsi dan memenuhi tujuan tingkat layanan (SLA), bahkan ketika peningkatan permintaan menempatkan beban ekstrem pada sumber daya.

Konteks dan masalah

Beban pada aplikasi cloud biasanya bervariasi dari waktu ke waktu berdasarkan jumlah pengguna aktif atau jenis aktivitas yang mereka lakukan. Misalnya, lebih banyak pengguna cenderung aktif selama jam kerja, atau sistem mungkin diminta untuk melakukan analitik yang mahal secara komputasi di akhir setiap bulan. Mungkin juga ada ledakan aktivitas yang tiba-tiba dan tak terduga. Jika persyaratan pemrosesan sistem melebihi kapasitas sumber daya yang tersedia, itu akan mengalami performa yang buruk dan bahkan dapat gagal. Jika sistem harus memenuhi tingkat layanan yang disepakati, kegagalan seperti itu tidak dapat diterima.

Ada banyak strategi yang tersedia untuk menangani berbagai beban di cloud, tergantung pada tujuan bisnis untuk aplikasi. Salah satu strateginya adalah menggunakan autoscaling untuk mencocokkan sumber daya yang disediakan dengan kebutuhan pengguna pada waktu tertentu. Hal ini berpotensi memenuhi permintaan pengguna secara konsisten, sekaligus mengoptimalkan biaya operasional. Namun, meskipun penskalaan otomatis dapat memicu provisi lebih banyak sumber daya, provisi ini tidak langsung. Jika permintaan tumbuh dengan cepat, akan ada jendela waktu di mana terjadi defisit sumber daya.

Solusi

Strategi alternatif untuk penskalaan otomatis adalah mengizinkan aplikasi menggunakan sumber daya hanya hingga batas tertentu, dan kemudian membatasinya saat batas ini tercapai. Sistem harus memantau cara menggunakan sumber daya sehingga, saat penggunaan melebihi ambang batas, sistem dapat membatasi permintaan dari satu atau beberapa pengguna. Ini memungkinkan sistem untuk terus berfungsi dan memenuhi tujuan tingkat layanan (SLA) apa pun yang ada. Untuk informasi lebih lanjut tentang pemantauan penggunaan sumber daya, lihat Bimbingan Instrumentasi dan Telemetri.

Sistem dapat menerapkan beberapa strategi pelambatan, termasuk:

• Menolak permintaan dari pengguna individual yang telah mengakses API sistem lebih dari n kali per detik selama periode waktu tertentu. Hal ini mengharuskan sistem untuk mengukur penggunaan sumber daya pada setiap penyewa atau pengguna yang menjalankan aplikasi. Untuk informasi selengkapnya, lihat Panduan Pengukuran Layanan.

• Menonaktifkan atau menurunkan fungsionalitas layanan non-esensial yang dipilih sehingga layanan esensial dapat berjalan tanpa hambatan dengan sumber daya yang memadai. Misalnya, jika aplikasi mengalirkan output video, hal tersebut bisa beralih ke resolusi yang lebih rendah.

• Menggunakan perataan beban untuk memperlancar volume aktivitas (pendekatan ini dibahas secara lebih rinci oleh pola Perataan Beban Berbasis Antrian ). Dalam lingkungan multipenyewa, pendekatan ini akan mengurangi performa untuk setiap penyewa. Jika sistem harus mendukung campuran penyewa dengan SLA yang berbeda, pekerjaan dapat segera dilakukan bagi penyewa yang bernilai tinggi. Permintaan untuk penyewa lain dapat ditunda, dan ditangani ketika backlog telah berkurang. Pola Antrean Prioritas dapat digunakan untuk membantu menerapkan pendekatan ini, karena dapat mengekspos titik akhir yang berbeda untuk berbagai tingkat/prioritas layanan.

• Menunda operasi yang dilakukan atas nama aplikasi atau penyewa yang memiliki prioritas lebih rendah. Operasi ini bisa ditangguhkan atau dibatasi, dengan pengecualian yang dibuat untuk memberi tahu penyewa bahwa sistem sedang sibuk dan operasi tersebut harus dicoba lagi nanti.

• Anda harus berhati-hati saat mengintegrasikan dengan beberapa layanan pihak ketiga yang mungkin menjadi tidak tersedia atau mengembalikan kesalahan. Kurangi jumlah permintaan bersamaan yang sedang diproses sehingga log tidak perlu diisi dengan kesalahan. Anda juga menghindari biaya yang terkait dengan percobaan kembali pemrosesan permintaan yang akan gagal karena layanan pihak ke-3 tersebut. Kemudian, ketika permintaan berhasil diproses, kembali ke pemrosesan permintaan normal tanpa pembatasan. Salah satu pustaka yang mengimplementasikan fungsionalitas ini adalah NServiceBus.

Gambar tersebut menunjukkan grafik area untuk penggunaan sumber daya (kombinasi memori, CPU, bandwidth, dan faktor lainnya) terhadap waktu untuk aplikasi yang menggunakan tiga fitur. Fitur adalah area fungsionalitas, seperti komponen yang melakukan serangkaian tugas tertentu, sepotong kode yang melakukan perhitungan kompleks, atau elemen yang menyediakan layanan seperti cache dalam memori. Fitur-fitur ini diberi label A, B, dan C.

Area tepat di bawah garis untuk fitur menunjukkan sumber daya yang digunakan oleh aplikasi saat mereka memanggil fitur ini. Misalnya, area di bawah garis untuk Fitur A menunjukkan sumber daya yang digunakan oleh aplikasi yang menggunakan Fitur A, dan area di antara garis untuk Fitur A dan Fitur B menunjukkan sumber daya yang digunakan oleh aplikasi yang menggunakan Fitur B. Menggabungkan area untuk setiap fitur menunjukkan total penggunaan sumber daya sistem.

Gambar sebelumnya menunjukkan efek menunda operasi. Tepat sebelum waktu T1, total sumber daya yang dialokasikan untuk semua aplikasi yang menggunakan fitur-fitur ini mencapai ambang batas. Ambang batas tersebut mewakili batas penggunaan sumber daya. Pada titik ini, aplikasi berada dalam bahaya menghabiskan sumber daya yang tersedia. Dalam sistem ini, Fitur B kurang penting daripada Fitur A atau Fitur C, sehingga dinonaktifkan sementara dan sumber daya yang digunakan dirilis. Antara waktu T1 dan T2, aplikasi yang menggunakan Fitur A dan Fitur C terus berjalan seperti biasa. Akhirnya, penggunaan sumber daya dari kedua fitur ini berkurang ke titik ketika, pada waktu T2, ada kapasitas yang cukup untuk mengaktifkan Fitur B lagi.

Pendekatan penyelarasan otomatis dan throttling juga dapat digabungkan untuk membantu menjaga responsivitas aplikasi dan agar tetap sesuai dengan Perjanjian Tingkat Layanan (SLA). Jika permintaan diperkirakan akan tetap tinggi, throttling memberikan solusi sementara sambil sistem melakukan penyebaran skala. Pada titik ini, fungsionalitas penuh sistem dapat dipulihkan.

Gambar berikut menunjukkan grafik area penggunaan sumber daya keseluruhan oleh semua aplikasi yang berjalan dalam sistem seiring dengan waktu, serta mengilustrasikan bagaimana pembatasan dapat dikombinasikan dengan penyesuaian skala otomatis.

Pada waktu T1, ambang batas yang menentukan batas lunak penggunaan sumber daya tercapai. Pada titik ini, sistem dapat mulai menskalakan. Namun, jika sumber daya baru tidak tersedia cukup cepat, maka sumber daya yang ada mungkin habis dan sistem bisa gagal. Untuk mencegah hal ini terjadi, sistem dibatasi sementara, seperti yang dijelaskan sebelumnya. Ketika penyesuaian skala otomatis telah selesai dan sumber daya tambahan tersedia, pembatasan dapat dilonggarkan.

Masalah dan pertimbangan

Anda harus mempertimbangkan poin berikut saat memutuskan cara menerapkan pola ini:

• Membatasi aplikasi, dan strategi yang akan digunakan, adalah keputusan arsitektur yang memengaruhi seluruh desain sistem. Pembatasan harus dipertimbangkan secara dini dalam proses desain aplikasi karena tidak mudah untuk ditambahkan begitu sistem telah diterapkan.

• Pembatasan harus dilakukan dengan cepat. Sistem harus mampu mendeteksi peningkatan aktivitas dan bereaksi sesuai dengan hal tersebut. Sistem juga harus dapat kembali ke keadaan semula dengan cepat setelah beban mereda. Ini memerlukan agar data kinerja yang tepat terus-menerus ditangkap dan dipantau.

• Jika layanan perlu menolak permintaan pengguna untuk sementara waktu, layanan harus mengembalikan kode kesalahan tertentu seperti 429 ("Terlalu banyak permintaan") dan 503 ("Server Terlalu Sibuk") sehingga aplikasi klien dapat memahami bahwa alasan penolakan untuk melayani permintaan disebabkan oleh pembatasan.

  • HTTP 429 menunjukkan aplikasi panggilan mengirim terlalu banyak permintaan dalam jendela waktu dan melebihi batas yang telah ditentukan.
  • HTTP 503 menunjukkan layanan belum siap untuk menangani permintaan. Penyebab umumnya adalah layanan mengalami lonjakan beban yang lebih sementara dari yang diharapkan.

Aplikasi klien dapat menunggu beberapa saat sebelum mencoba kembali permintaan. Header Retry-After HTTP harus disertakan, untuk mendukung klien dalam memilih strategi coba lagi.

• Pembatasan dapat digunakan sebagai langkah sementara saat sistem menjalankan penskalaan otomatis. Dalam beberapa kasus, lebih baik untuk membatasi daripada menskalakan jika lonjakan aktivitas tiba-tiba dan diperkirakan tidak berlangsung lama karena penskalakan dapat menambah biaya yang signifikan untuk menjalankan.

• Jika pembatasan digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis, dan jika permintaan sumber daya meningkat dengan sangat cepat, sistem mungkin tidak dapat terus berfungsi—bahkan saat beroperasi dalam mode pembatasan. Jika hal ini tidak dapat diterima, pertimbangkan untuk mempertahankan cadangan kapasitas yang lebih besar dan mengonfigurasi penskalaan otomatis yang lebih agresif.

• Menormalkan biaya sumber daya untuk operasi yang berbeda karena umumnya tidak membawa biaya eksekusi yang sama. Misalnya, batas pembatasan mungkin lebih rendah untuk operasi baca dan lebih tinggi untuk operasi tulis. Tidak mempertimbangkan biaya operasi dapat mengakibatkan kapasitas habis dan mengekspos vektor serangan potensial.

• Perubahan konfigurasi dinamis perilaku pembatasan pada runtime diinginkan. Jika sistem menghadapi beban abnormal yang tidak dapat ditangani oleh konfigurasi yang diterapkan, batas pembatasan mungkin perlu ditingkatkan atau dikurangi untuk menstabilkan sistem dan menyesuaikan dengan lalu lintas saat ini. Penyebaran yang mahal, berisiko, dan lambat tidak diinginkan pada saat ini. Menggunakan pola Penyimpanan Konfigurasi Eksternal, konfigurasi pembatasan dieksternalisasi dan dapat diubah serta diterapkan tanpa penyebaran.

Kapan menggunakan pola ini

Gunakan pola ini:

• Untuk memastikan bahwa sistem terus memenuhi tujuan tingkat layanan (SLA).

• Untuk mencegah penyewa tunggal memonopoli sumber daya yang disediakan oleh aplikasi.

• Untuk menangani lonjakan dalam aktivitas.

• Untuk membantu mengoptimalkan biaya sistem dengan membatasi tingkat sumber daya maksimum yang diperlukan agar tetap berfungsi.

• Untuk mengurangi pemrosesan komputasi bernilai rendah selama periode intensitas karbon tinggi di jaringan energi.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Throttling dapat digunakan dalam desain beban kerja arsitektur mereka untuk memenuhi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. Contohnya:

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain terkait keandalan membantu beban kerja Anda menjadi tangkas terhadap kerusakan dan memastikan bahwa beban kerja tersebut pulih ke status operasional penuh setelah kegagalan terjadi.	Anda merancang batas untuk membantu mencegah kelelahan sumber daya yang mungkin menyebabkan kerusakan. Anda juga dapat menggunakan pola ini sebagai mekanisme kontrol dalam rencana degradasi yang anggun. - RE:07 Perlindungan Diri
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda.	Anda dapat merancang batas untuk membantu mencegah kelelahan sumber daya yang dapat mengakibatkan penyalahgunaan otomatis sistem. - SE:06 Kontrol jaringan - Penguatan sumber daya SE:08
Pengoptimalan Biaya difokuskan untuk mempertahankan dan meningkatkanpengembalian investasi beban kerja Anda.	Batas yang diberlakukan dapat menginformasikan pemodelan biaya dan bahkan dapat langsung terikat dengan model bisnis aplikasi Anda. Mereka juga menempatkan batas atas yang jelas pada pemanfaatan, yang dapat diperhitungkan ke dalam ukuran sumber daya. - Model biaya CO:02 - Biaya penskalan CO:12
Efisiensi Performa membantu beban kerja Anda memenuhi tuntutan secara efisien melalui pengoptimalan dalam penskalaan, data, kode.	Ketika sistem berada di bawah permintaan tinggi, pola ini membantu mengurangi kemacetan yang dapat menyebabkan penyempitan performa. Anda juga dapat menggunakannya untuk secara proaktif menghindari skenario tetangga yang berisik. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian

Seperti halnya keputusan desain apa pun, pertimbangkan kompromi terhadap tujuan lain dari pilar-pilar tersebut yang mungkin diperkenalkan oleh pola ini.

Contoh

Gambar terakhir menggambarkan bagaimana pembatasan konsumsi dapat diimplementasikan dalam sistem multipenyewa. Pengguna dari masing-masing organisasi penyewa mengakses aplikasi yang dihosting cloud tempat mereka mengisi dan mengirimkan survei. Aplikasi ini berisi instrumentasi yang memantau tingkat di mana pengguna mengirimkan permintaan ke aplikasi.

Untuk mencegah pengguna dari satu penyewa mempengaruhi responsivitas dan ketersediaan aplikasi bagi semua pengguna lain, batasan diterapkan pada jumlah permintaan per detik yang dapat diajukan oleh pengguna dari penyewa tersebut. Aplikasi memblokir permintaan yang melebihi batas ini.

Langkah berikutnya

Panduan berikut bisa jadi relevan saat menerapkan pola berikut ini:

• Instrumentasi dan Panduan Telemetri. Pelambatan tergantung pada pengumpulan informasi tentang seberapa intensif layanan sedang digunakan. Menjelaskan cara menghasilkan dan menangkap informasi pemantauan khusus.
• Panduan Pengukuran Layanan. Menjelaskan cara mengukur penggunaan layanan untuk mendapatkan pemahaman tentang cara layanan digunakan. Informasi ini dapat berguna dalam menentukan cara mengatur layanan.
• Panduan Penskalaan Otomatis. Pembatasan dapat digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis, atau untuk menghilangkan kebutuhan sistem untuk penskalaan otomatis. Berisi informasi tentang strategi penskalaan otomatis.

Sumber daya terkait

Pola berikut mungkin juga relevan saat menerapkan pola ini:

• Pola Pemerataan Beban Berdasarkan Antrean. Penyeimbangan muatan berbasis antrean adalah mekanisme yang umum digunakan untuk menerapkan pengendalian laju. Antrian dapat bertindak sebagai buffer yang membantu meratakan kecepatan permintaan yang dikirim oleh aplikasi ke layanan.
• Pola Antrean Prioritas. Suatu sistem dapat menggunakan antrian prioritas sebagai bagian dari strategi pembatasannya untuk mempertahankan kinerja untuk aplikasi yang penting atau bernilai lebih tinggi, sekaligus mengurangi kinerja aplikasi yang kurang penting.
• Pola Penyimpanan Konfigurasi Eksternal. Memusatkan dan mengeksternalkan kebijakan pengaturan kecepatan menyediakan kemampuan untuk mengubah konfigurasi selama runtime tanpa perlu penerapan ulang. Layanan dapat berlangganan perubahan konfigurasi, yang segera menerapkan konfigurasi baru, untuk menstabilkan sistem.

Mengontrol penggunaan sumber daya yang digunakan oleh instans aplikasi, penyewa individu, atau seluruh layanan. Ini dapat memungkinkan sistem untuk terus berfungsi dan memenuhi tujuan tingkat layanan (SLA), bahkan ketika peningkatan permintaan menempatkan beban ekstrem pada sumber daya.

Konteks dan masalah

Beban pada aplikasi cloud biasanya bervariasi dari waktu ke waktu berdasarkan jumlah pengguna aktif atau jenis aktivitas yang mereka lakukan. Misalnya, lebih banyak pengguna cenderung aktif selama jam kerja, atau sistem mungkin diminta untuk melakukan analitik yang mahal secara komputasi di akhir setiap bulan. Mungkin juga ada ledakan aktivitas yang tiba-tiba dan tak terduga. Jika persyaratan pemrosesan sistem melebihi kapasitas sumber daya yang tersedia, itu akan mengalami performa yang buruk dan bahkan dapat gagal. Jika sistem harus memenuhi tingkat layanan yang disepakati, kegagalan seperti itu tidak dapat diterima.

Ada banyak strategi yang tersedia untuk menangani berbagai beban di cloud, tergantung pada tujuan bisnis untuk aplikasi. Salah satu strateginya adalah menggunakan autoscaling untuk mencocokkan sumber daya yang disediakan dengan kebutuhan pengguna pada waktu tertentu. Hal ini berpotensi memenuhi permintaan pengguna secara konsisten, sekaligus mengoptimalkan biaya operasional. Namun, meskipun penskalaan otomatis dapat memicu provisi lebih banyak sumber daya, provisi ini tidak langsung. Jika permintaan tumbuh dengan cepat, akan ada jendela waktu di mana terjadi defisit sumber daya.

Solusi

Strategi alternatif untuk penskalaan otomatis adalah mengizinkan aplikasi menggunakan sumber daya hanya hingga batas tertentu, dan kemudian membatasinya saat batas ini tercapai. Sistem harus memantau cara menggunakan sumber daya sehingga, saat penggunaan melebihi ambang batas, sistem dapat membatasi permintaan dari satu atau beberapa pengguna. Ini memungkinkan sistem untuk terus berfungsi dan memenuhi tujuan tingkat layanan (SLA) apa pun yang ada. Untuk informasi lebih lanjut tentang pemantauan penggunaan sumber daya, lihat Bimbingan Instrumentasi dan Telemetri.

Sistem dapat menerapkan beberapa strategi pelambatan, termasuk:

• Menolak permintaan dari pengguna individual yang telah mengakses API sistem lebih dari n kali per detik selama periode waktu tertentu. Hal ini mengharuskan sistem untuk mengukur penggunaan sumber daya pada setiap penyewa atau pengguna yang menjalankan aplikasi. Untuk informasi selengkapnya, lihat Panduan Pengukuran Layanan.

• Menonaktifkan atau menurunkan fungsionalitas layanan non-esensial yang dipilih sehingga layanan esensial dapat berjalan tanpa hambatan dengan sumber daya yang memadai. Misalnya, jika aplikasi mengalirkan output video, hal tersebut bisa beralih ke resolusi yang lebih rendah.

• Menggunakan perataan beban untuk memperlancar volume aktivitas (pendekatan ini dibahas secara lebih rinci oleh pola Perataan Beban Berbasis Antrian ). Dalam lingkungan multipenyewa, pendekatan ini akan mengurangi performa untuk setiap penyewa. Jika sistem harus mendukung campuran penyewa dengan SLA yang berbeda, pekerjaan dapat segera dilakukan bagi penyewa yang bernilai tinggi. Permintaan untuk penyewa lain dapat ditunda, dan ditangani ketika backlog telah berkurang. Pola Antrean Prioritas dapat digunakan untuk membantu menerapkan pendekatan ini, karena dapat mengekspos titik akhir yang berbeda untuk berbagai tingkat/prioritas layanan.

• Menunda operasi yang dilakukan atas nama aplikasi atau penyewa yang memiliki prioritas lebih rendah. Operasi ini bisa ditangguhkan atau dibatasi, dengan pengecualian yang dibuat untuk memberi tahu penyewa bahwa sistem sedang sibuk dan operasi tersebut harus dicoba lagi nanti.

• Anda harus berhati-hati saat mengintegrasikan dengan beberapa layanan pihak ketiga yang mungkin menjadi tidak tersedia atau mengembalikan kesalahan. Kurangi jumlah permintaan bersamaan yang sedang diproses sehingga log tidak perlu diisi dengan kesalahan. Anda juga menghindari biaya yang terkait dengan percobaan kembali pemrosesan permintaan yang akan gagal karena layanan pihak ke-3 tersebut. Kemudian, ketika permintaan berhasil diproses, kembali ke pemrosesan permintaan normal tanpa pembatasan. Salah satu pustaka yang mengimplementasikan fungsionalitas ini adalah NServiceBus.

Gambar tersebut menunjukkan grafik area untuk penggunaan sumber daya (kombinasi memori, CPU, bandwidth, dan faktor lainnya) terhadap waktu untuk aplikasi yang menggunakan tiga fitur. Fitur adalah area fungsionalitas, seperti komponen yang melakukan serangkaian tugas tertentu, sepotong kode yang melakukan perhitungan kompleks, atau elemen yang menyediakan layanan seperti cache dalam memori. Fitur-fitur ini diberi label A, B, dan C.

Area tepat di bawah garis untuk fitur menunjukkan sumber daya yang digunakan oleh aplikasi saat mereka memanggil fitur ini. Misalnya, area di bawah garis untuk Fitur A menunjukkan sumber daya yang digunakan oleh aplikasi yang menggunakan Fitur A, dan area di antara garis untuk Fitur A dan Fitur B menunjukkan sumber daya yang digunakan oleh aplikasi yang menggunakan Fitur B. Menggabungkan area untuk setiap fitur menunjukkan total penggunaan sumber daya sistem.

Gambar sebelumnya menunjukkan efek menunda operasi. Tepat sebelum waktu T1, total sumber daya yang dialokasikan untuk semua aplikasi yang menggunakan fitur-fitur ini mencapai ambang batas. Ambang batas tersebut mewakili batas penggunaan sumber daya. Pada titik ini, aplikasi berada dalam bahaya menghabiskan sumber daya yang tersedia. Dalam sistem ini, Fitur B kurang penting daripada Fitur A atau Fitur C, sehingga dinonaktifkan sementara dan sumber daya yang digunakan dirilis. Antara waktu T1 dan T2, aplikasi yang menggunakan Fitur A dan Fitur C terus berjalan seperti biasa. Akhirnya, penggunaan sumber daya dari kedua fitur ini berkurang ke titik ketika, pada waktu T2, ada kapasitas yang cukup untuk mengaktifkan Fitur B lagi.

Pendekatan penyelarasan otomatis dan throttling juga dapat digabungkan untuk membantu menjaga responsivitas aplikasi dan agar tetap sesuai dengan Perjanjian Tingkat Layanan (SLA). Jika permintaan diperkirakan akan tetap tinggi, throttling memberikan solusi sementara sambil sistem melakukan penyebaran skala. Pada titik ini, fungsionalitas penuh sistem dapat dipulihkan.

Gambar berikut menunjukkan grafik area penggunaan sumber daya keseluruhan oleh semua aplikasi yang berjalan dalam sistem seiring dengan waktu, serta mengilustrasikan bagaimana pembatasan dapat dikombinasikan dengan penyesuaian skala otomatis.

Pada waktu T1, ambang batas yang menentukan batas lunak penggunaan sumber daya tercapai. Pada titik ini, sistem dapat mulai menskalakan. Namun, jika sumber daya baru tidak tersedia cukup cepat, maka sumber daya yang ada mungkin habis dan sistem bisa gagal. Untuk mencegah hal ini terjadi, sistem dibatasi sementara, seperti yang dijelaskan sebelumnya. Ketika penyesuaian skala otomatis telah selesai dan sumber daya tambahan tersedia, pembatasan dapat dilonggarkan.

Masalah dan pertimbangan

Anda harus mempertimbangkan poin berikut saat memutuskan cara menerapkan pola ini:

• Membatasi aplikasi, dan strategi yang akan digunakan, adalah keputusan arsitektur yang memengaruhi seluruh desain sistem. Pembatasan harus dipertimbangkan secara dini dalam proses desain aplikasi karena tidak mudah untuk ditambahkan begitu sistem telah diterapkan.

• Pembatasan harus dilakukan dengan cepat. Sistem harus mampu mendeteksi peningkatan aktivitas dan bereaksi sesuai dengan hal tersebut. Sistem juga harus dapat kembali ke keadaan semula dengan cepat setelah beban mereda. Ini memerlukan agar data kinerja yang tepat terus-menerus ditangkap dan dipantau.

• Jika layanan perlu menolak permintaan pengguna untuk sementara waktu, layanan harus mengembalikan kode kesalahan tertentu seperti 429 ("Terlalu banyak permintaan") dan 503 ("Server Terlalu Sibuk") sehingga aplikasi klien dapat memahami bahwa alasan penolakan untuk melayani permintaan disebabkan oleh pembatasan.

  • HTTP 429 menunjukkan aplikasi panggilan mengirim terlalu banyak permintaan dalam jendela waktu dan melebihi batas yang telah ditentukan.
  • HTTP 503 menunjukkan layanan belum siap untuk menangani permintaan. Penyebab umumnya adalah layanan mengalami lonjakan beban yang lebih sementara dari yang diharapkan.

Aplikasi klien dapat menunggu beberapa saat sebelum mencoba kembali permintaan. Header Retry-After HTTP harus disertakan, untuk mendukung klien dalam memilih strategi coba lagi.

• Pembatasan dapat digunakan sebagai langkah sementara saat sistem menjalankan penskalaan otomatis. Dalam beberapa kasus, lebih baik untuk membatasi daripada menskalakan jika lonjakan aktivitas tiba-tiba dan diperkirakan tidak berlangsung lama karena penskalakan dapat menambah biaya yang signifikan untuk menjalankan.

• Jika pembatasan digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis, dan jika permintaan sumber daya meningkat dengan sangat cepat, sistem mungkin tidak dapat terus berfungsi—bahkan saat beroperasi dalam mode pembatasan. Jika hal ini tidak dapat diterima, pertimbangkan untuk mempertahankan cadangan kapasitas yang lebih besar dan mengonfigurasi penskalaan otomatis yang lebih agresif.

• Menormalkan biaya sumber daya untuk operasi yang berbeda karena umumnya tidak membawa biaya eksekusi yang sama. Misalnya, batas pembatasan mungkin lebih rendah untuk operasi baca dan lebih tinggi untuk operasi tulis. Tidak mempertimbangkan biaya operasi dapat mengakibatkan kapasitas habis dan mengekspos vektor serangan potensial.

• Perubahan konfigurasi dinamis perilaku pembatasan pada runtime diinginkan. Jika sistem menghadapi beban abnormal yang tidak dapat ditangani oleh konfigurasi yang diterapkan, batas pembatasan mungkin perlu ditingkatkan atau dikurangi untuk menstabilkan sistem dan menyesuaikan dengan lalu lintas saat ini. Penyebaran yang mahal, berisiko, dan lambat tidak diinginkan pada saat ini. Menggunakan pola Penyimpanan Konfigurasi Eksternal, konfigurasi pembatasan dieksternalisasi dan dapat diubah serta diterapkan tanpa penyebaran.

Kapan menggunakan pola ini

Gunakan pola ini:

• Untuk memastikan bahwa sistem terus memenuhi tujuan tingkat layanan (SLA).

• Untuk mencegah penyewa tunggal memonopoli sumber daya yang disediakan oleh aplikasi.

• Untuk menangani lonjakan dalam aktivitas.

• Untuk membantu mengoptimalkan biaya sistem dengan membatasi tingkat sumber daya maksimum yang diperlukan agar tetap berfungsi.

• Untuk mengurangi pemrosesan komputasi bernilai rendah selama periode intensitas karbon tinggi di jaringan energi.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Throttling dapat digunakan dalam desain beban kerja arsitektur mereka untuk memenuhi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. Contohnya:

Pilar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain terkait keandalan membantu beban kerja Anda menjadi tangkas terhadap kerusakan dan memastikan bahwa beban kerja tersebut pulih ke status operasional penuh setelah kegagalan terjadi.	Anda merancang batas untuk membantu mencegah kelelahan sumber daya yang mungkin menyebabkan kerusakan. Anda juga dapat menggunakan pola ini sebagai mekanisme kontrol dalam rencana degradasi yang anggun. - RE:07 Perlindungan Diri
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda.	Anda dapat merancang batas untuk membantu mencegah kelelahan sumber daya yang dapat mengakibatkan penyalahgunaan otomatis sistem. - SE:06 Kontrol jaringan - Penguatan sumber daya SE:08
Pengoptimalan Biaya difokuskan untuk mempertahankan dan meningkatkanpengembalian investasi beban kerja Anda.	Batas yang diberlakukan dapat menginformasikan pemodelan biaya dan bahkan dapat langsung terikat dengan model bisnis aplikasi Anda. Mereka juga menempatkan batas atas yang jelas pada pemanfaatan, yang dapat diperhitungkan ke dalam ukuran sumber daya. - Model biaya CO:02 - Biaya penskalan CO:12
Efisiensi Performa membantu beban kerja Anda memenuhi tuntutan secara efisien melalui pengoptimalan dalam penskalaan, data, kode.	Ketika sistem berada di bawah permintaan tinggi, pola ini membantu mengurangi kemacetan yang dapat menyebabkan penyempitan performa. Anda juga dapat menggunakannya untuk secara proaktif menghindari skenario tetangga yang berisik. - Perencanaan kapasitas PE:02 - PE:05 Penskalaan dan pemartisian

Seperti halnya keputusan desain apa pun, pertimbangkan kompromi terhadap tujuan lain dari pilar-pilar tersebut yang mungkin diperkenalkan oleh pola ini.

Contoh

Gambar terakhir menggambarkan bagaimana pembatasan konsumsi dapat diimplementasikan dalam sistem multipenyewa. Pengguna dari masing-masing organisasi penyewa mengakses aplikasi yang dihosting cloud tempat mereka mengisi dan mengirimkan survei. Aplikasi ini berisi instrumentasi yang memantau tingkat di mana pengguna mengirimkan permintaan ke aplikasi.

Untuk mencegah pengguna dari satu penyewa mempengaruhi responsivitas dan ketersediaan aplikasi bagi semua pengguna lain, batasan diterapkan pada jumlah permintaan per detik yang dapat diajukan oleh pengguna dari penyewa tersebut. Aplikasi memblokir permintaan yang melebihi batas ini.

Langkah berikutnya

Panduan berikut bisa jadi relevan saat menerapkan pola berikut ini:

• Instrumentasi dan Panduan Telemetri. Pelambatan tergantung pada pengumpulan informasi tentang seberapa intensif layanan sedang digunakan. Menjelaskan cara menghasilkan dan menangkap informasi pemantauan khusus.
• Panduan Pengukuran Layanan. Menjelaskan cara mengukur penggunaan layanan untuk mendapatkan pemahaman tentang cara layanan digunakan. Informasi ini dapat berguna dalam menentukan cara mengatur layanan.
• Panduan Penskalaan Otomatis. Pembatasan dapat digunakan sebagai tindakan sementara saat sistem melakukan penskalaan otomatis, atau untuk menghilangkan kebutuhan sistem untuk penskalaan otomatis. Berisi informasi tentang strategi penskalaan otomatis.

Sumber daya terkait

Pola berikut mungkin juga relevan saat menerapkan pola ini:

• Pola Pemerataan Beban Berdasarkan Antrean. Penyeimbangan muatan berbasis antrean adalah mekanisme yang umum digunakan untuk menerapkan pengendalian laju. Antrian dapat bertindak sebagai buffer yang membantu meratakan kecepatan permintaan yang dikirim oleh aplikasi ke layanan.
• Pola Antrean Prioritas. Suatu sistem dapat menggunakan antrian prioritas sebagai bagian dari strategi pembatasannya untuk mempertahankan kinerja untuk aplikasi yang penting atau bernilai lebih tinggi, sekaligus mengurangi kinerja aplikasi yang kurang penting.
• Pola Penyimpanan Konfigurasi Eksternal. Memusatkan dan mengeksternalkan kebijakan pengaturan kecepatan menyediakan kemampuan untuk mengubah konfigurasi selama runtime tanpa perlu penerapan ulang. Layanan dapat berlangganan perubahan konfigurasi, yang segera menerapkan konfigurasi baru, untuk menstabilkan sistem.