Mengapa Rate Limit (pembatasan penggunaan) diperlukan?
- Dalam chat Twitch dengan banyak peserta, jika ada satu spammer dan tidak ada pembatasan penggunaan, spammer tersebut dapat mendominasi percakapan.
- Dengan pembatasan penggunaan, setiap pengguna bisa memiliki kesempatan yang adil untuk berpartisipasi.
- Rate Limiter (pembatas penggunaan) mengendalikan traffic layanan dengan memblokir request yang melebihi batas yang ditetapkan dalam periode tertentu. Ini berguna bukan hanya untuk mengendalikan spam di chat.
- Sebagai contoh, pada form login, pembatasan penggunaan dapat menekan serangan brute force sambil tetap mengizinkan sejumlah kecil tebakan yang salah.
- Endpoint API juga sering diberi pembatasan penggunaan agar satu pengguna tidak dapat memonopoli resource.
- Jika pengguna hanya boleh memanggil endpoint API yang mahal 100 kali per menit, kita bisa memakai counter untuk melacak 100 hit per menit, lalu memblokir request setelah itu.
- Ini adalah salah satu algoritme pembatasan penggunaan paling sederhana, yaitu Fixed Window Limiter.
- Ini adalah cara umum untuk mengendalikan traffic layanan.
Algoritme Fixed windows
- Jumlah request dibatasi dalam jendela waktu (window) yang tetap.
- Pada awal setiap jendela waktu, counter request di-reset ke 0.
- Kelebihan
- Mudah diimplementasikan dan dipahami.
- Mudah diprediksi oleh pengguna.
- Kekurangan
- Jika request mulai menumpuk mendekati akhir jendela waktu, lonjakan (burst) hingga 2x batas dapat terjadi.
- Contoh nyata: GitHub API menggunakan rate limiter jendela waktu tetap yang mengizinkan 5.000 request per jam.
- Alih-alih menetapkan waktu mulai jendela pada interval tetap, setiap jendela waktu bisa dibuat pada saat request pertama pengguna dalam jendela tersebut.
- Dalam pendekatan ini, sangat penting untuk memberi tahu pengguna sisa waktu hingga jendela berikutnya.
Algoritme Sliding windows
- Alih-alih mengisi ulang seluruh kapasitas sekaligus, sliding window mengembalikan kapasitas satu request pada satu waktu.
- Kelebihan
- Membuat distribusi traffic request lebih halus.
- Cocok untuk beban tinggi.
- Kekurangan
- Lebih sulit diprediksi oleh pengguna dibanding jendela waktu tetap.
- Menyimpan timestamp setiap request memakan banyak resource.
- Karena sliding window paling berguna dalam skenario traffic tinggi, fakta bahwa algoritme dasarnya boros resource justru menjadi kontraproduktif.
- Karena itu, sebagian besar rate limiter sliding window di dunia nyata menggunakan pendekatan aproksimasi.
- Pendekatan aproksimasi menghitung jumlah request yang diizinkan pada jendela waktu tetap sebelumnya dan jendela waktu tetap saat ini, lalu memberi bobot pada request yang diizinkan dari jendela sebelumnya secara proporsional terhadap tumpang tindihnya dengan jendela mengambang yang berakhir pada waktu sekarang.
- Pendekatan aproksimasi ini membatasi request dengan rasio yang hampir sama, tetapi jauh lebih efisien.
- Contoh nyata: rate limiter yang dapat dikonfigurasi milik Cloudflare menggunakan sliding window aproksimasi.
Algoritme Token buckets
- Alih-alih durasi jendela waktu, bayangkan sebuah bucket yang diisi dengan "token" pada laju tetap.
- Setiap request mengambil satu token dari bucket ini, dan jika bucket kosong, request berikutnya akan diblokir.
- Kapasitas bucket menunjukkan jumlah maksimum request yang dapat didukung dalam sebuah burst.
- Interval pengisian ulang menunjukkan jarak rata-rata jangka panjang antar request yang diizinkan.
- Salah satu keunggulan utama algoritme ini adalah dapat memiliki kapasitas burst dan rata-rata yang terpisah tanpa perlu beberapa rate limiter.
- Kelebihan
- Mengizinkan burst traffic tinggi sambil tetap menerapkan laju request rata-rata jangka panjang.
- Lebih fleksibel bagi pengguna karena memungkinkan lonjakan traffic dalam batas yang masih diizinkan.
- Kekurangan
- Lebih sulit menyampaikan batasan dan waktu pengisian ulang kepada pengguna dibanding jendela waktu tetap.
- Contoh nyata
- Stripe menggunakan token bucket dengan batas 500 dan interval pengisian ulang 0,01 detik per pengguna, sehingga memungkinkan 100 request per detik secara berkelanjutan, tetapi tetap mengizinkan burst hingga 500 request.
- Free tier GPT-3.5 dari OpenAI menggunakan token bucket dengan batas 200 dan interval pengisian ulang 86400 detik/200, sehingga dibatasi menjadi 200 request per hari.
Hal-hal yang perlu dipertimbangkan saat menerapkan rate limit
- Perlu membuat penyimpanan persisten untuk rate limiter.
- Jika koneksi server ke penyimpanan persisten gagal, semua request sebaiknya tetap diizinkan alih-alih diblokir.
- Secara opsional, burst traffic bisa diatur.
- Harus memilih key yang tepat (ID pengguna, API key, dll.).
- Harus menampilkan error rate limit yang berguna (waktu tunggu hingga request berikutnya, status HTTP 429, header respons
x-ratelimit-*, dll.).
2 komentar
Saya membaca artikel yang diringkas dalam bahasa Korea, lalu berpikir, "Oke, saya paham maksudnya, tapi bukankah semuanya sama saja?" Namun setelah membaca artikel di tautan asli, penjelasannya benar-benar sangat bagus dan visualisasinya juga sangat memuaskan! 👍👍👍
Opini Hacker News
Ringkasan kumpulan komentar Hacker News
Pertimbangan tambahan dari pengalaman panjang:
Dalam lingkungan multi-tenant, fair queueing adalah pendekatan terbaik untuk mencegah serangan DoS: Setiap klien diberi queue sendiri, lalu rutin latar belakang berputar melalui tiap queue untuk memproses permintaan. Klien yang mengirim permintaan spam hanya akan membuat queue miliknya sendiri macet.
Pengalaman mengimplementasikan kode pemrosesan klien: Selalu penasaran tentang strategi backoff terbaik saat mencapai rate limit. Menarik membaca trade-off dari sudut pandang layanan.
Ucapan selamat: Ini adalah visualisasi terbaik untuk konten singkat, sangat informatif dan poin-poinnya tersusun rapi.
Algoritma GCRA: Menurut saya ini algoritma yang lebih baik untuk rate limiting. Semoga lebih dikenal luas dan lebih banyak digunakan.
Kerja yang luar biasa: Terasa jelas bahwa banyak waktu dan usaha dicurahkan ke postingan ini. Kerja bagus.
Masalah rate-limiting di AWS Lambda: Pernah mencoba mengimplementasikan rate-limiting di NodeJS, tetapi di AWS Lambda timer bekerja aneh sehingga melampaui target. Lulus dalam pengujian lokal, tetapi gagal di Lambda. Tidak yakin apakah ini masalah timer atau masalah library.
Cara menangani saat lapisan rate limiting jenuh: Penasaran apakah ada opsi lain selain CF. Juga ingin tahu seberapa efektif aturan nftable untuk mempertahankan VPS kecil dari serangan DoS.
Momen saat sumber daya seperti ini dibutuhkan: Ini adalah sumber daya yang saya perlukan berkali-kali sepanjang karier. Senang sekarang ini sudah ada.
Penggemar visualisasi data: Penasaran apakah ini menggunakan D3.