Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
REL05-BP02 Permintaan Throttle
Batasi permintaan untuk mengurangi keletihan sumber daya karena peningkatan permintaan yang tidak terduga. Permintaan di bawah laju pembatasan diproses sementara permintaan di atas batas yang ditentukan ditolak dengan pesan balasan yang menunjukkan permintaan telah dibatasi.
Hasil yang diinginkan: Lonjakan volume dalam jumlah besar baik dari peningkatan lalu lintas pelanggan yang naik tiba-tiba, serangan membanjir, atau banjir percobaan ulang akan diminimalkan dengan throttling permintaan, sehingga beban kerja dapat melanjutkan pemrosesan volume permintaan normal yang didukung.
Anti-pola umum:
-
APIthrottle endpoint tidak diimplementasikan atau dibiarkan pada nilai default tanpa mempertimbangkan volume yang diharapkan.
-
APItitik akhir tidak diuji beban atau batas pelambatan tidak diuji.
-
Lakukan throttling terhadap angka permintaan tanpa mempertimbangkan ukuran atau kompleksitas permintaan.
-
Melakukan uji laju permintaan maksimum atau uji ukuran permintaan maksimum, tetapi tidak menguji keduanya bersama-sama.
-
Sumber daya tidak disediakan untuk batas yang sama yang ditetapkan dalam pengujian.
-
Rencana penggunaan belum dikonfigurasi atau dipertimbangkan untuk konsumen aplikasi ke aplikasi (A2A)API.
-
Tidak ada konfigurasi pengaturan konkurensi maksimum pada konsumen antrean yang mengalami penskalaan horizontal.
-
Pembatasan tingkat untuk setiap alamat IP belum diimplementasikan.
Manfaat menerapkan praktik terbaik ini: Beban kerja yang menetapkan batas throttling dapat beroperasi secara normal dan berhasil memproses beban permintaan yang diterima saat terjadi lonjakan volume yang tidak terduga. Lonjakan permintaan dan antrian yang tiba-tiba atau berkelanjutan dibatasi APIs dan tidak menghabiskan sumber daya pemrosesan permintaan. Batas tarif membatasi pemohon individu sehingga volume lalu lintas yang tinggi dari satu alamat IP atau API konsumen tidak akan menghabiskan sumber daya berdampak pada konsumen lain.
Tingkat risiko yang terjadi jika praktik terbaik ini tidak diterapkan: Tinggi
Panduan implementasi
Layanan-layanan harus dirancang untuk memproses kapasitas permintaan yang diketahui; kapasitas ini dapat ditetapkan melalui pengujian beban. Jika laju kedatangan permintaan sudah melampaui batas, maka respons yang tepat menandakan bahwa permintaan telah mengalami throttling. Hal ini akan memungkinkan konsumen untuk menangani kesalahan dan mencoba ulang di lain waktu.
Saat layanan-layanan Anda memerlukan implementasi throttling, pertimbangkan untuk mengimplementasikan algoritme bucket token, yang menghitung satu token sebagai satu permintaan. Token diisi ulang dengan laju throttling per detik dan dikosongkan secara tidak selaras dengan satu token per permintaan.
Algoritme bucket token.
Amazon API Gateway
Langkah-langkah implementasi
Anda dapat mengonfigurasi API Gateway dengan batas pelambatan untuk 429 Too Many Requests kesalahan Anda APIs dan mengembalikan saat batas terlampaui. Anda dapat menggunakan AWS WAF dengan titik akhir AWS AppSync dan API Gateway Anda untuk mengaktifkan pembatasan tarif berdasarkan per alamat IP. Selain itu, apabila sistem Anda dapat memberikan toleransi terhadap pemrosesan tidak selaras, Anda dapat memasukkan pesan ke dalam antrean atau aliran guna mempercepat respons terhadap klien layanan, yang memungkinkan Anda untuk melakukan lonjakan ke tingkat throttling yang lebih tinggi.
Dengan pemrosesan asinkron, ketika Anda telah mengonfigurasi Amazon SQS sebagai sumber peristiwa AWS Lambda, Anda dapat mengonfigurasi konkurensi maksimum untuk menghindari tingkat kejadian tinggi dari penggunaan kuota eksekusi bersamaan akun yang tersedia yang diperlukan untuk layanan lain di beban kerja atau akun Anda.
Meskipun API Gateway menyediakan implementasi token bucket yang terkelola, jika Anda tidak dapat menggunakan API Gateway, Anda dapat memanfaatkan implementasi sumber terbuka khusus bahasa (lihat contoh terkait di Sumber Daya) dari keranjang token untuk layanan Anda.
-
Memahami dan mengonfigurasi batas pembatasan API Gateway di tingkat akun per wilayah, API per tahap, dan API kunci per level paket penggunaan.
-
Terapkan aturan pembatasan AWS WAF tarif
ke API Gateway dan AWS AppSync titik akhir untuk melindungi dari banjir dan memblokir bahaya. IPs Aturan pembatasan tarif juga dapat dikonfigurasi pada AWS AppSync API kunci untuk konsumen A2A. -
Pertimbangkan apakah Anda memerlukan lebih banyak kontrol pelambatan daripada pembatasan laju untuk AWS AppSync APIs, dan jika demikian, konfigurasikan API Gateway di depan titik akhir Anda AWS AppSync .
-
Saat SQS antrian Amazon disiapkan sebagai pemicu bagi konsumen antrian Lambda, tetapkan konkurensi maksimum ke nilai yang cukup diproses untuk memenuhi tujuan tingkat layanan Anda tetapi tidak menggunakan batas konkurensi yang memengaruhi fungsi Lambda lainnya. Pertimbangkan untuk menetapkan konkurensi cadangan pada fungsi Lambda lain di akun dan wilayah yang sama saat Anda menggunakan antrean dengan Lambda.
-
Gunakan API Gateway dengan integrasi layanan asli ke Amazon SQS atau Kinesis untuk menyangga permintaan.
-
Jika Anda tidak dapat menggunakan API Gateway, lihat pustaka khusus bahasa untuk mengimplementasikan algoritma token bucket untuk beban kerja Anda. Periksa bagian contoh dan lakukan riset sendiri untuk menemukan pustaka yang sesuai.
-
Uji batas yang ingin Anda tetapkan, atau yang ingin Anda izinkan untuk ditingkatkan, dan buatlah dokumentasi dari batas-batas yang diuji.
-
Jangan tingkatkan batas melebihi apa yang Anda tetapkan dalam pengujian. Saat meningkatkan batas, pastikan bahwa sumber daya yang disediakan sudah setara atau lebih besar daripada yang ada dalam skenario pengujian sebelum menerapkan peningkatan.
Sumber daya
Praktik-praktik terbaik terkait:
Dokumen terkait:
Contoh terkait:
Video terkait:
Alat terkait:
