Pola Pembatasan Tarif

Kontrol laju saat aplikasi Anda mengirim permintaan ke layanan sehingga Anda tetap berada dalam batas pembatasan layanan dan kapasitas keseluruhan. Pendekatan ini membantu Anda menghindari atau meminimalkan error throttling dan memprediksi throughput dengan lebih akurat.

Pembatasan laju sesuai dalam banyak skenario, tetapi sangat membantu untuk tugas otomatis berskala besar dan berulang seperti pemrosesan batch.

Konteks dan masalah

Melakukan sejumlah besar operasi terhadap layanan yang dibatasi dapat mengakibatkan peningkatan lalu lintas dan pengurangan throughput, karena Anda perlu melacak permintaan yang ditolak lalu mencoba kembali operasi. Ketika jumlah operasi meningkat, batas pelambatan mungkin mengharuskan beberapa kali pengiriman ulang data, sehingga berdampak lebih besar pada kinerja.

Misalnya, pertimbangkan proses coba lagi kesalahan bermasalah berikut untuk menyerap data ke dalam Azure Cosmos DB:

1. Aplikasi Anda perlu menyerap 10.000 rekaman ke Azure Cosmos DB. Setiap catatan memerlukan 10 unit permintaan (RU) untuk diproses, sehingga diperlukan total 100.000 RU untuk menyelesaikan tugas.

2. Instans Azure Cosmos DB Anda memiliki kapasitas yang disediakan 20.000 RU.

3. Anda mengirim semua 10.000 rekaman ke Azure Cosmos DB. 2.000 rekaman berhasil ditulis dan 8.000 rekaman ditolak.

4. Anda mengirim 8.000 rekaman yang tersisa ke Azure Cosmos DB. 2.000 rekaman berhasil ditulis dan 6.000 rekaman ditolak.

5. Anda mengirim 6.000 rekaman yang tersisa ke Azure Cosmos DB. 2.000 rekaman berhasil ditulis dan 4.000 rekaman ditolak.

6. Anda mengirim 4.000 rekaman yang tersisa ke Azure Cosmos DB. 2.000 rekaman berhasil ditulis dan 2.000 rekaman ditolak.

7. Anda mengirim 2.000 rekaman yang tersisa ke Azure Cosmos DB. Semuanya ditulis dengan sukses.

Pekerjaan penyerapan berhasil diselesaikan, tetapi hanya setelah mengirim 30.000 rekaman ke Azure Cosmos DB. Seluruh himpunan data hanya terdiri dari 10.000 rekaman.

Ada faktor lain yang perlu dipertimbangkan dalam contoh ini:

• Sejumlah besar kesalahan juga dapat mengakibatkan pekerjaan ekstra untuk mencatat kesalahan ini dan memproses data log yang dihasilkan. Pendekatan sebelumnya menangani 20.000 kesalahan, dan mencatat kesalahan ini mungkin memberlakukan biaya pemrosesan, memori, atau sumber daya penyimpanan.

• Karena Anda tidak tahu batas pembatasan layanan penyerapan, Anda tidak memiliki cara untuk menetapkan harapan berapa lama pemrosesan data membutuhkan waktu. Pembatasan laju dapat membantu Anda menghitung waktu yang diperlukan untuk ingestion.

Solusi

Pembatasan tarif dapat mengurangi lalu lintas Anda dan berpotensi meningkatkan throughput dengan mengurangi jumlah catatan yang dikirim ke layanan selama periode waktu tertentu.

Layanan dapat membatasi permintaan berdasarkan metrik yang berbeda dari waktu ke waktu, seperti:

• Jumlah operasi (misalnya, 20 permintaan per detik).
• Jumlah data (misalnya, 2 GiB per menit).
• Biaya operasi relatif (misalnya, 20.000 RUs per detik).

Terlepas dari metrik yang Anda gunakan untuk pembatasan, implementasi pembatasan tarif Anda akan melibatkan pengendalian jumlah dan/atau ukuran operasi yang dikirim ke layanan selama periode waktu tertentu. Pembatasan tarif mengoptimalkan penggunaan layanan tanpa melebihi kapasitas pembatasannya.

Dalam skenario di mana API Anda dapat menangani permintaan lebih cepat dari batas yang dapat diterima oleh layanan penyerapan data, Anda harus mengatur seberapa cepat Anda menggunakan layanan tersebut. Memperlakukan penahanan laju hanya sebagai ketidakcocokan laju data dan men-buffer permintaan penyerapan hingga layanan pulih dapat menyebabkan risiko. Jika aplikasi Anda berhenti merespons dalam skenario ini, data buffer apa pun mungkin hilang.

Untuk menghindari risiko ini, pertimbangkan untuk mengirim catatan Anda ke sistem pesan tahan lama yang dapat menangani tingkat konsumsi Anda secara penuh. (Layanan seperti Azure Event Hubs dapat menangani jutaan operasi per detik.) Anda kemudian dapat menggunakan satu atau beberapa pemroses tugas untuk membaca catatan dari sistem perpesanan dengan laju yang terkendali agar tetap berada dalam batas pembatasan layanan. Mengirimkan catatan ke sistem olahpesan dapat menyimpan memori internal dengan memungkinkan Anda untuk menghapus catatan tertentu yang dapat diproses selama interval waktu tertentu.

Azure menyediakan beberapa layanan pesan tahan lama yang dapat Anda gunakan dengan pola ini, termasuk:

• Azure Service Bus
• Azure Queue Storage
• Event Hubs

Alur dimulai dengan pengguna yang mengirim batch 10.000 pesan ke komponen API. API meneruskan semua pesan ke komponen layanan olahpesan yang tahan lama. Dari layanan perpesanan persisten, tiga alur terpisah menuju tiga komponen pemroses tugas. Setiap aliran diberi label x100 / detik, yang menunjukkan bahwa setiap pemroses tugas mengambil pesan dari antrean pada laju terkontrol 100 pesan per detik. Ketiga komponen pemroses tugas terhubung ke komponen layanan yang dibatasi lajunya. Layanan yang dibatasi lajunya dan diberi label "dibatasi pada 300 record per detik", yang setara dengan keluaran gabungan dari tiga prosesor.

Saat Anda mengirim catatan, rentang waktu yang Anda gunakan untuk mengirimkannya mungkin lebih terperinci daripada rentang waktu yang digunakan layanan untuk melakukan pembatasan laju. Sistem sering menetapkan batasan berdasarkan rentang waktu yang mudah Anda pahami dan gunakan. Namun, untuk komputer yang menjalankan layanan, jangka waktu ini mungkin sangat panjang dibandingkan dengan seberapa cepat komputer dapat memproses informasi. Misalnya, sebuah sistem mungkin menerapkan pembatasan per detik atau per menit, tetapi umumnya kode memproses dalam orde nanodetik atau milidetik.

Meskipun tidak diperlukan, sering disarankan untuk mengirim jumlah rekaman yang lebih kecil lebih sering untuk meningkatkan throughput. Jadi, daripada mencoba mengumpulkan rekaman untuk rilis sekali per detik atau sekali per menit, Anda bisa lebih terperinci daripada itu untuk menjaga konsumsi sumber daya Anda (memori, CPU, dan jaringan) mengalir pada tingkat yang lebih merata. Pendekatan ini mencegah potensi hambatan yang disebabkan oleh ledakan permintaan yang tiba-tiba. Misalnya, jika layanan mengizinkan 100 operasi per detik, implementasi pembatas tarif bahkan dapat mengeluarkan permintaan dengan merilis 20 operasi setiap 200 milidetik, seperti yang ditunjukkan dalam grafik berikut.

Grafik ini berjudul "Rate Limited Flow". Ini memplot jumlah operasi pada sumbu y dari 0 hingga 25 terhadap tanda waktu pada sumbu x dari 0,0 hingga 4,0. Dari tanda waktu 0,0 hingga 0,2, jumlah operasi adalah 0, yang menunjukkan bahwa tidak ada operasi yang dikirim. Antara 0,2 dan 0,4, garis naik tajam hingga 20, yang menunjukkan bahwa pembatas laju mencapai batas maksimum yang dikonfigurasi. Pada tanda waktu 3.0, garis turun tajam kembali ke 0, yang menunjukkan bahwa pekerjaan selesai atau bahwa pembatas laju berhenti merilis rekaman. Dari 3,2 hingga 3,8, nilai tetap pada 0. Dataran tinggi datar antara 0,4 dan 3,0 adalah fitur utama bagan. Ini menunjukkan bahwa pembatasan laju menghasilkan throughput yang konsisten dan dapat diprediksi, alih-alih lonjakan dan penurunan yang terkait dengan pendekatan mencoba ulang saat terjadi kesalahan yang bermasalah.

Selain itu, terkadang beberapa proses yang tidak saling terkoordinasi perlu berbagi layanan dengan pembatasan laju. Untuk menerapkan pembatasan tarif dalam skenario ini, Anda dapat secara logis mempartisi kapasitas layanan dan kemudian menggunakan sistem pengecualian bersama terdistribusi untuk mengelola kunci eksklusif pada partisi tersebut. Proses yang tidak terkoordinasi kemudian dapat bersaing untuk mengunci partisi tersebut kapan pun mereka membutuhkan kapasitas. Untuk setiap partisi yang untuknya suatu proses memegang kunci, diberikan sejumlah kapasitas tertentu.

Misalnya, jika sistem yang dibatasi lajunya mengizinkan 500 permintaan per detik, Anda dapat membuat 20 partisi, masing-masing dengan kapasitas 25 permintaan per detik. Jika proses diperlukan untuk mengeluarkan 100 permintaan, mungkin meminta sistem pengecualian bersama terdistribusi untuk empat partisi. Sistem mungkin memberikan dua partisi selama 10 detik. Proses kemudian akan menilai batas hingga 50 permintaan per detik, menyelesaikan tugas dalam dua detik, dan kemudian melepaskan kunci.

Salah satu cara untuk menerapkan pola ini adalah dengan menggunakan Azure Storage. Dalam skenario ini, Anda membuat satu gumpalan 0-byte per partisi logis dalam kontainer. Aplikasi Anda kemudian dapat memperoleh sewa eksklusif langsung terhadap blob tersebut untuk waktu yang singkat (misalnya, 15 detik). Untuk setiap sewa yang diberikan aplikasi, aplikasi dapat menggunakan jumlah kapasitas partisi tersebut. Aplikasi kemudian perlu melacak waktu sewa sehingga, ketika waktu kedaluwarsa, aplikasi dapat berhenti menggunakan kapasitas yang diberikan. Ketika menerapkan pola ini, Anda akan sering ingin setiap proses mencoba menyewa partisi acak saat membutuhkan kapasitas.

Untuk lebih mengurangi latensi, Anda mungkin mengalokasikan sejumlah kecil kapasitas eksklusif untuk setiap proses. Sebuah proses kemudian hanya akan mencoba memperoleh hak sewa atas kapasitas bersama jika perlu melampaui kapasitas yang dicadangkan.

Diagram menunjukkan empat proses yang bersaing untuk sewa eksklusif pada enam partisi blob bernomor yang disimpan dalam Blob Storage. Keempat proses tersebut diberi label A, B, C, dan D. Blob Storage berisi enam partisi blob bernomor 0 hingga 5. Dari proses A, panah hijau menunjuk ke partisi 0, menunjukkan keberhasilan akuisisi sewa. Panah merah menunjuk dari proses A ke partisi 1, menunjukkan upaya sewa yang gagal, karena proses lain sudah menyimpan partisi tersebut. Dari proses D, satu panah hijau menunjuk ke partisi 1, menunjukkan bahwa proses D memegang sewa pada partisi tersebut. Itu sebabnya upaya proses A pada partisi 1 gagal. Panah hijau kedua menunjuk dari proses D ke partisi 4, yang menunjukkan hak sewa kedua yang dimiliki proses D. Tidak ada panah yang dikaitkan dengan proses B dan C karena keduanya tidak memiliki hak sewa. Partisi 2, 3, dan 5 juga belum disewa.

Sebagai alternatif untuk Azure Storage, Anda juga dapat menerapkan sistem manajemen sewa semacam ini dengan menggunakan teknologi seperti ZooKeeper, etcd, dan Redis/Redsync.

Masalah dan pertimbangan

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

• Meskipun pola Pembatasan Laju dapat mengurangi jumlah kesalahan akibat pembatasan laju, aplikasi Anda tetap perlu menangani kesalahan tersebut dengan tepat jika sewaktu-waktu terjadi.

• Pastikan bahwa percobaan ulang dikoordinasikan dengan pembatasan laju. Percobaan ulang yang sembarangan atau terlalu agresif dapat meningkatkan beban dan memicu badai percobaan ulang, jadi teruskan sinyal back-pressure (misalnya, HTTP 429 dengan Retry-After) dan gunakan jumlah percobaan ulang yang terbatas dengan penundaan acak kecil di antara setiap percobaan.

• Jika aplikasi Anda memiliki beberapa alur kerja yang mengakses layanan yang dibatasi yang sama, Anda perlu mengintegrasikan semuanya ke dalam strategi pembatasan tarif Anda. Misalnya, Anda mungkin mendukung pemuatan rekaman massal ke dalam database tetapi juga mengkueri untuk rekaman dalam database yang sama. Anda dapat mengelola kapasitas dengan memastikan bahwa semua aliran kerja terjaga melalui mekanisme pembatasan tarif yang sama. Atau, Anda dapat memesan kumpulan kapasitas terpisah untuk setiap aliran kerja.

• Layanan yang dibatasi mungkin digunakan dalam beberapa aplikasi. Dalam beberapa kasus, dimungkinkan untuk mengoordinasikan penggunaan tersebut (seperti yang ditunjukkan sebelumnya dalam artikel ini). Jika Anda mulai melihat jumlah kesalahan throttling yang lebih besar dari perkiraan, peningkatan jumlah tersebut mungkin mengindikasikan adanya perebutan sumber daya di antara aplikasi yang mengakses suatu layanan. Dalam hal ini, Anda mungkin perlu mempertimbangkan untuk sementara mengurangi throughput yang ditetapkan oleh mekanisme pembatasan laju Anda hingga penggunaan oleh aplikasi lain menurun.

Kapan menggunakan pola ini

Gunakan pola ini ketika:

• Anda perlu mengurangi error throttling yang dihasilkan oleh layanan dengan pembatasan laju.

• Anda ingin meminimalkan trafik dibandingkan dengan pendekatan sederhana yang mencoba lagi saat terjadi kesalahan.

• Anda perlu mengurangi konsumsi memori dengan menghapus rekaman antrean hanya ketika ada kapasitas yang memadai untuk memprosesnya.

Pola ini mungkin tidak cocok ketika:

• Operasi ini membutuhkan penyelesaian segera dan sinkron dengan latensi yang sangat rendah dan tidak dapat mentolerir antrean atau pemrosesan yang ditangguhkan.

• Hambatan utama bukan tingkat permintaan, tetapi sebaliknya adalah konkurensi atau ketidakcocokan sumber daya (misalnya, saturasi CPU atau pekerjaan dalam penerbangan yang berjalan lama). Dalam kasus ini, kontrol penskalaan atau konkurensi lebih tepat.

Desain beban kerja

Evaluasi cara menggunakan pola Pembatasan Tarif dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. 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.	Taktik ini melindungi klien dengan mengakui dan menghormati batasan dan biaya berkomunikasi dengan layanan ketika layanan lebih suka menghindari penggunaan yang berlebihan. - RE:07 Perlindungan Diri

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

Example

Contoh aplikasi berikut memungkinkan pengguna untuk mengirimkan berbagai jenis catatan ke API. Setiap jenis catatan memiliki prosesor pekerjaan unik yang melakukan langkah-langkah berikut:

1. Validasi
2. Pengayaan
3. Penyisipan rekaman ke dalam database

Semua komponen aplikasi (API, prosesor pekerjaan A, dan prosesor pekerjaan B) adalah proses terpisah yang dapat diskalakan secara independen. Proses tidak langsung berkomunikasi satu sama lain.

Diagram menunjukkan dua pengguna mengirimkan rekaman melalui API bersama. Setiap jenis catatan dirutekan ke antrean terpisah, diproses oleh pemroses tugas khusus, dan ditulis ke database yang laju tulisnya dibatasi dengan laju yang terkontrol, yang diatur oleh sewa partisi blob di Azure Storage. Kedua pengguna masing-masing mengirim batch pesan ke komponen API. Satu pengguna mengirimkan 10.000 pesan dan yang lain mengirimkan 5.000 pesan. API merutekan 10.000 pesan ke antrean A dan 5.000 pesan ke antrean B. Antrean A tersambung ke prosesor pekerjaan A, dan antrean B tersambung ke prosesor pekerjaan B. Prosesor pekerjaan A menulis ke database dengan laju 300 rekaman per detik. Pemroses pekerjaan B menulis ke basis data dengan kecepatan 500 catatan per detik. Kedua pemroses job terhubung ke komponen basis data yang diberi label "dibatasi pada 800 catatan per detik." Di bawah dua prosesor pekerjaan, Azure Storage berisi delapan partisi blob berlabel 0 hingga 7. Catatan menunjukkan bahwa setiap partisi bernilai 100 rekaman per detik. Beberapa panah menghubungkan pemroses tugas ke partisi blob. Panah hijau menunjuk dari prosesor pekerjaan A ke partisi 0, 4, dan 6, yang menunjukkan bahwa prosesor menyimpan sewa pada tiga partisi tersebut. Kontrak sewa ini menjelaskan laju 300 catatan per detiknya. Panah hijau menunjuk dari prosesor pekerjaan B ke partisi 1, 2, 3, 5, dan 7. Panah ini menunjukkan bahwa prosesor ini menyimpan sewa pada lima partisi. Kontrak sewa ini menjelaskan laju 500 catatan per detik. Upaya sewa yang gagal ditampilkan sebagai panah merah yang menyeberang ke partisi yang sudah dipegang oleh prosesor lain. Panah ini mewakili resolusi perselisihan. Diagram menunjukkan bahwa jumlah semua partisi yang ditahan di kedua prosesor sama dengan 800 rekaman per detik, yang cocok dengan batas pembatasan database.

Dalam contoh ini, setiap sewa blob mewakili bagian tetap dari throughput database yang diizinkan. Prosesor hanya dapat mengambil dari antrean dan menulis dengan laju gabungan dari sewa yang saat ini dimilikinya. Seiring prosesor memperoleh atau kehilangan hak sewa dari waktu ke waktu, laju penulisan yang diizinkan berubah, sehingga total trafik database tetap berada dalam batas yang dikonfigurasi sambil tetap memungkinkan semua pekerjaan dalam antrean terus diproses.

Diagram ini menggabungkan alur kerja berikut:

1. Pengguna mengirimkan 10.000 catatan tipe A ke API.
2. API mengantrekan 10.000 rekaman tersebut dalam antrean A.
3. Pengguna mengirimkan 5.000 rekaman tipe B ke API.
4. API mengantrekan 5.000 rekaman tersebut dalam antrean B.
5. Pemroses pekerjaan A melihat bahwa antrean A berisi rekaman dan mencoba memperoleh sewa eksklusif atas blob 2.
6. Pemroses pekerjaan B melihat bahwa antrean B memiliki catatan dan mencoba memperoleh sewa eksklusif atas blob 2.
7. Pemroses pekerjaan A gagal memperoleh lease.
8. Pemroses pekerjaan B memperoleh lease atas blob 2 selama 15 detik. Sekarang dapat menilai permintaan batas ke database pada tingkat 100 per detik.
9. Prosesor pekerjaan B mengambil 100 catatan dari antrean B lalu menulisnya.
10. Satu detik berlalu.
11. Pemroses pekerjaan A melihat bahwa antrean A memiliki lebih banyak catatan dan berupaya memperoleh sewa eksklusif atas blob 6.
12. Pemroses pekerjaan B melihat bahwa antrean B berisi lebih banyak rekaman dan mencoba memperoleh sewa eksklusif atas blob 3.
13. Pemroses pekerjaan A memperoleh lease atas blob 6 selama 15 detik. Sekarang dapat menilai permintaan batas ke database pada tingkat 100 per detik.
14. Pemroses pekerjaan B memperoleh lease atas blob 3 selama 15 detik. Sekarang dapat menilai permintaan batas ke database pada tingkat 200 per detik. (Ini juga memegang hak sewa untuk blob 2.)
15. Prosesor pekerjaan A mengambil 100 catatan dari antrean A lalu menuliskannya.
16. Prosesor pekerjaan B mengambil 200 rekaman dari antrean B lalu menuliskannya.
17. Satu detik berlalu.
18. Pemroses pekerjaan A melihat bahwa antrean A memiliki lebih banyak catatan dan mencoba memperoleh sewa eksklusif atas blob 0.
19. Pemroses pekerjaan B melihat bahwa antrean B memiliki lebih banyak rekaman dan mencoba memperoleh lease eksklusif pada blob 1.
20. Pemroses pekerjaan A memperoleh lease atas blob 0 selama 15 detik. Sekarang dapat menilai permintaan batas ke database pada tingkat 200 per detik. (Ini juga memegang hak sewa atas blob 6.)
21. Pemroses pekerjaan B memperoleh lease atas blob 1 selama 15 detik. Sekarang dapat menilai permintaan batas ke database pada tingkat 300 per detik. (Ini juga memegang hak sewa untuk blob 2 dan 3.)
22. Pemroses pekerjaan A mengeluarkan 200 rekaman dari antrean A dan menuliskannya.
23. Prosesor pekerjaan B mengambil 300 catatan dari antrean B lalu menuliskannya.
24. Dan sebagainya.

Setelah 15 detik, satu atau kedua pekerjaan masih belum selesai. Saat sewa kedaluwarsa, prosesor juga harus mengurangi jumlah permintaan yang didequeue dan menulis.

Implementasi pola ini tersedia dalam bahasa pemrograman yang berbeda:

• Implementasi Go tersedia di GitHub.
• Implementasi Java tersedia di GitHub.

Langkah berikutnya

Panduan berikut mungkin juga relevan ketika Anda menerapkan pola ini:

• Pembatasan permintaan tingkat lanjut dengan Azure API Management. Gunakan ini sebagai kontrol penerimaan tepi pelengkap untuk memberlakukan batas dan kuota laju panggilan per kunci, dan untuk mengembalikan sinyal tekanan balik yang konsisten kepada klien.

• Memilih di antara layanan olahpesan Azure. Pilih infrastruktur messaging persisten terbaik untuk buffering dan ingesti terkontrol.

• Menangani kesalahan sementara dalam aplikasi Azure. Rancang mekanisme percobaan ulang agar klien dapat mengurangi frekuensi permintaan dengan benar saat batas tercapai.

Sumber daya terkait

Pola dan panduan berikut mungkin juga relevan ketika Anda menerapkan pola ini:

• Throttling. Pola Pembatasan Tarif biasanya diterapkan sebagai respons terhadap layanan yang dibatasi.

• Retry. Ketika permintaan ke layanan yang dibatasi lajunya menghasilkan error pembatasan laju, umumnya tepat untuk mencoba kembali permintaan tersebut setelah jeda yang sesuai.

• Queue-Based Load Leveling mirip dengan pola Pembatasan Laju tetapi berbeda dalam beberapa cara utama:

  • Pembatasan tarif tidak perlu menggunakan antrean untuk mengelola beban, tetapi perlu menggunakan layanan pesan yang tahan lama. Misalnya, pola Pembatasan Tarif dapat menggunakan layanan seperti Apache Kafka atau Event Hubs.

  • Pola Pembatasan Laju memperkenalkan konsep sistem eksklusi mutual terdistribusi di seluruh partisi, yang memungkinkan Anda mengelola kapasitas untuk beberapa proses yang tidak terkoordinasi dan berkomunikasi dengan layanan yang sama yang dikenai pembatasan laju.

  • Pola Queue-Based Load Leveling berlaku setiap kali ada ketidakcocokan performa antara layanan atau Anda ingin meningkatkan ketahanan. Jadi, ini adalah pola yang lebih luas daripada pembatasan laju, yang secara lebih khusus berfokus pada akses yang efisien ke layanan yang dikenai pembatasan laju.