Neden Rate Limit (kullanım sınırı) gerekir?
- Çok sayıda katılımcının olduğu bir Twitch sohbetinde tek bir spammer varsa, kullanım sınırı yoksa spammer konuşmayı domine edebilir.
- Kullanım sınırı sayesinde her kullanıcı adil biçimde katılım fırsatı elde edebilir.
- Rate Limiter (kullanım sınırlayıcı), belirli bir süre içinde belirlenen sınırı aşan istekleri engelleyerek servisin trafiğini kontrol eder. Bu, sohbette spam kontrolünün ötesinde de faydalıdır.
- Örneğin, giriş formunda kullanım sınırı sayesinde brute force saldırıları bastırılırken az sayıda hatalı tahmine de izin verilebilir.
- API endpoint'lerine de sık sık kullanım sınırı uygulanır; böylece tek bir kullanıcı kaynakları tekeline alamaz.
- Kullanıcının pahalı bir API endpoint'ini dakikada yalnızca 100 kez çağırabilmesini sağlarsanız, dakikada 100 vuruşu takip etmek için bir sayaç kullanılır ve sonrasındaki istekler engellenir.
- Bu, en basit kullanım sınırı algoritmalarından biri olan sabit pencere sınırlayıcısıdır (Fixed Window Limiter).
- Servis trafiğini kontrol etmenin yaygın bir yoludur.
Fixed windows algoritması
- İstek sayısı sabit bir zaman penceresi içinde sınırlandırılır.
- Her zaman penceresinin başında istek sayacı 0'a sıfırlanır.
- Avantajları
- Uygulaması ve anlaşılması kolaydır.
- Kullanıcı için öngörülebilirdir.
- Dezavantajları
- İstekler zaman penceresinin sonuna doğru başlarsa, sınırın 2 katına kadar istek patlamasına (burst) izin verilebilir.
- Gerçek örnek: GitHub API, saatte 5.000 isteğe izin veren sabit zaman pencereli bir rate limiter kullanır.
- Zaman penceresinin başlangıç zamanını sabit aralıklarla belirlemek yerine, her zaman penceresi kullanıcının o pencere içindeki ilk isteği anında oluşturulabilir.
- Bu yaklaşımda, kullanıcıya bir sonraki zaman penceresine ne kadar süre kaldığını bildirmek özellikle önemlidir.
Sliding windows algoritması
- Tüm kapasiteyi bir anda yenilemek yerine, sliding window kapasiteyi her seferinde bir istek olacak şekilde doldurur.
- Avantajları
- İstek trafiğinin dağılımını yumuşatır.
- Yüksek yük için uygundur.
- Dezavantajları
- Sabit zaman penceresine göre kullanıcı için daha az öngörülebilirdir.
- Her isteğin zaman damgasını saklamak kaynak açısından yoğundur.
- Sliding window en çok yüksek trafik senaryolarında faydalı olduğu için, temel algoritmanın kaynak yoğun olması ters etki yaratır.
- Bu nedenle gerçek dünyadaki sliding window rate limiter'ların çoğu yaklaşık hesaplama (approximation) kullanır.
- Yaklaşık hesaplama yaklaşımı, önceki sabit zaman penceresinde izin verilen istek sayısı ile mevcut sabit zaman penceresinde izin verilen istek sayısını hesaplar; ardından önceki pencerenin izin verdiği istekleri, şu anda biten kayan zaman penceresiyle çakışma oranına göre ağırlıklandırır.
- Bu yaklaşım, istekleri neredeyse aynı oranda sınırlandırırken çok daha verimlidir.
- Gerçek örnek: Cloudflare'ın yapılandırılabilir rate limiter'ı yaklaşık sliding window kullanır.
Token bucket algoritması
- Zaman penceresinin süresi yerine, sabit hızda "token" ile dolan bir kova hayal edilir.
- Her istek bu kovadan bir token çeker; kova boşsa sonraki istek engellenir.
- Kovanın kapasitesi, burst sırasında desteklenebilecek en yüksek istek sayısını gösterir.
- Yenileme aralığı, uzun vadede izin verilen ortalama istek aralığını gösterir.
- Birden fazla rate limiter kullanmadan ayrı burst ve ortalama kapasite tanımlayabilmek, bu algoritmanın başlıca avantajlarından biridir.
- Avantajları
- Yüksek trafikteki burst'lere izin verirken uzun vadeli ortalama istek hızını uygular.
- Kullanıcı için daha esnektir; izin verilen sınırlar içinde trafik sıçramalarına izin verir.
- Dezavantajları
- Sabit zaman penceresine kıyasla kullanıcıya sınırlar ve yenileme zamanını aktarmak daha zordur.
- Gerçek örnekler
- Stripe, kullanıcı başına 500 sınır ve 0.01 saniyelik yenileme aralığına sahip bir token bucket kullanarak saniyede 100 isteğe sürekli izin verirken en fazla 500 isteklik burst'e izin verir.
- OpenAI'ın GPT-3.5 ücretsiz katmanı, 200 sınır ve 86400 saniye/200 yenileme aralığına sahip bir token bucket kullanır; böylece günde 200 istekle sınırlanır.
Rate limit uygulanırken dikkat edilmesi gerekenler
- Rate limiter için kalıcı bir depolama oluşturulmalıdır.
- Sunucunun kalıcı depolamaya bağlantısı başarısız olursa, istekleri engellemeden hepsine izin verilmelidir.
- İsteğe bağlı olarak burst trafiği düzenlenebilir.
- Uygun anahtar seçilmelidir (kullanıcı ID'si, API anahtarı vb.).
- Faydalı rate limit hata mesajları gösterilmelidir (bir sonraki isteğe kadar bekleme süresi, 429 HTTP durum kodu,
x-ratelimit-* yanıt başlıkları vb.)
2 yorum
Korece özetlenmiş yazıyı okuyup, "Tamam ne olduğunu anladım ama hepsi aynı şey değil mi?" diye düşündükten sonra kaynak bağlantıdaki yazıyı okuyunca, gerçekten çok iyi açıklanmış olduğunu ve görselleştirmelerin de fazlasıyla tatmin edici olduğunu gördüm! 👍👍👍
Hacker News görüşleri
Hacker News yorum derlemesi özeti
Uzun deneyimden çıkan ek değerlendirmeler:
Çok kiracılı ortamlarda DoS saldırılarını önlemek için en iyi yaklaşım adil kuyruklamadır: Her istemciye kendi kuyruğu atanır ve bir arka plan rutini her kuyruğu döngüsel olarak dolaşarak istekleri işler. Spam istek gönderen istemci yalnızca kendi kuyruğunu tıkar.
İstemci işleme kodu geliştirme deneyimi: Rate limit'e ulaşıldığında en iyi backoff stratejisinin ne olduğu hep merak konusuydu. Hizmet perspektifindeki trade-off'ları okumak ilginçti.
Tebrik mesajı: Kısa bir içerik için gördüğüm en iyi görselleştirme; son derece bilgilendirici ve ana noktaları çok iyi düzenlenmiş bir yazı.
GCRA algoritması: Rate limiting için daha iyi bir algoritma olduğunu düşünüyorum. Daha yaygın bilinip kullanılsa keşke.
Harika iş: Bu yazıya çok zaman ve emek verildiği hissediliyor. Eline sağlık.
AWS Lambda'da rate-limiting sorunu: NodeJS'de rate-limiting uygulamaya çalıştım, ancak AWS Lambda'da zamanlayıcılar garip çalıştığı için hedef aşılıyor. Yereldeki testlerde geçiyordu ama Lambda'da başarısız oldu. Sorunun zamanlayıcıdan mı yoksa kütüphaneden mi kaynaklandığı belirsiz.
Rate limiting katmanı doygunluğa ulaştığında ne yapılmalı: CF dışında başka seçenekler olup olmadığını merak ediyorum. Küçük bir VPS'te DoS saldırılarına karşı nftable kurallarının ne kadar etkili olduğunu da merak ediyorum.
Bu kaynağa ihtiyaç duyduğum anlar olmuştu: Kariyerim boyunca defalarca ihtiyaç duyduğum bir kaynak. Artık var olmasına sevindim.
Veri görselleştirme hayranı: D3 kullanılıp kullanılmadığını merak ediyorum.