Rate limiting, bir API'ye belirli bir zaman aralığında yapılabilecek istek sayısını sınırlayarak kaynakların kötüye kullanımını engeller ve sistem kararlılığını korur. Bu yazıda token bucket ve leaky bucket gibi yaygın algoritmaları adım adım inceleyecek, pratik uygulama ipuçları ve karşılaşılan hataları ele alacağız.
Rate Limiting Nedir ve Neden Önemlidir?
Rate limiting, bir istemcinin belirli bir zaman penceresinde API'ye göndereceği istek sayısını kontrol eden bir mekanizmadır. Olmazsa kötü niyetli saldırılar, hatalı kod döngüleri veya aşırı trafik sunucuyu çökertebilir. Doğru rate limiting ile:
- Sunucu kaynakları adil kullanılır.
- Hizmet reddi saldırıları (DoS) engellenir.
- Faturalandırma ve kota yönetimi kolaylaşır.
- Kullanıcı deneyimi tutarlı kalır.
Yaygın Rate Limiting Algoritmaları
1. Token Bucket (Jeton Kovası)
Bir kova sabit kapasitede jeton tutar. Her istek bir jeton tüketir. Belirli aralıklarla kovaya yeni jetonlar eklenir (ör. saniyede 10 jeton). Kova boşalırsa istek reddedilir. Bu algoritma anlık ani trafik patlamalarına izin verirken uzun vadede ortalama hızı sınırlar.
2. Leaky Bucket (Sızdıran Kova)
İstekler bir kuyruğa girer ve sabit bir hızla işlenir (kovanın dibindeki delik). Kova aşırı dolarsa (kuyruk maksimum boyuta ulaşırsa) yeni istekler reddedilir. Leaky bucket trafiği düzgünleştirir, ani patlamaları yumuşatır.
3. Fixed Window (Sabit Pencere)
Zaman periyotlarına (ör. 1 dakika) bölünür. Her pencerede belirli sayıda isteğe izin verilir. Basittir ancak pencere sınırlarında trafik sıçramaları olabilir.
4. Sliding Window (Kayan Pencere)
Sabit pencere sorununu çözmek için isteklerin zaman damgalarını kaydeder ve sürekli hareket eden bir zaman diliminde sayaç tutar. Daha adildir ancak daha fazla bellek gerektirir.
Hangi Algoritmayı Seçmelisiniz?
Seçim, iş gereksinimlerinize bağlıdır. Token bucket anlık patlamalara izin vermesiyle esnektir; leak bucket trafiği sabitler. Aşağıdaki tablo karar vermenize yardımcı olabilir:
| Özellik | Token Bucket | Leaky Bucket | Fixed Window | Sliding Window |
|---|---|---|---|---|
| Patlama toleransı | Yüksek | Düşük | Orta | Orta |
| Uygulama karmaşıklığı | Düşük | Orta | Çok düşük | Yüksek |
| Bellek kullanımı | Düşük | Orta | Düşük | Yüksek |
| Adillik | İyi | İyi | Zayıf | Çok iyi |
Pratik Uygulama İpuçları ve Kontrol Listesi
- İstemci kimliğini doğru belirleyin: API anahtarı, kullanıcı ID'si veya IP adresi kullanın. IP adresi NAT arkasında hatalı olabilir; API anahtarı daha güvenilirdir.
- Rate limit başlıklarını ekleyin: HTTP yanıtlarına X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset gibi başlıklar koyun. İstemciler kalan limiti görsün.
- Durum kodu 429 Too Many Requests döndürün: Limit aşıldığında 429 yanıtıyla birlikte Retry-After başlığı ekleyin. Bu, standart HTTP durum kodları ile uyumludur.
- Dağıtık sistemlerde merkezi bir sayaç kullanın: Redis gibi hızlı bir veri deposu, tüm sunucular arasında tutarlı sayaç tutar. Token bucket için Redis'te Lua scripti idealdir.
- Token bucket uygularken jeton ekleme hızını sürekli enjekte edin: Periyodik bir zamanlayıcı yerine, her istek anında geçen süreyi hesaplayıp jeton ekleyin (daha performanslı).
- Leaky bucket için kuyruk boyutunu ve çıkış hızını dikkatli ayarlayın: Kuyruk çok büyükse gecikme artar; çok küçükse istekler sık reddedilir.
- Farklı kullanıcı rollerine farklı limitler koyun: Ücretsiz kullanıcılara 100 istek/saat, premium kullanıcılara 1000 istek/saat gibi.
- Limit aşımı durumunda uygun hata mesajı döndürün: JSON formatında
{ "error": "rate_limit_exceeded", "message": "Too many requests. Please try again in 60 seconds." }. - Test edin ve izleyin: Yük testi araçlarıyla farklı senaryoları deneyin. Prometheus ve Grafana ile limit aşım metriklerini takip edin.
Sık Yapılan Hatalar
- Tüm uç noktalara aynı limiti uygulamak: Login gibi kritik uç noktalar daha düşük limit ister; veri çekme uç noktaları daha yüksek.
- Rate limiting'in veri doğrulaması ile karıştırılması: Rate limiting istek sayısını, veri doğrulama ise içeriği kontrol eder. İkisini ayrı katmanlarda uygulayın.
- Yanıt başlıklarını unutmak: İstemciler neden reddedildiğini bilemezse kötü kullanıcı deneyimi oluşur.
- IP adresine göre limit koyarken proxy'leri hesaba katmamak: CDN veya yük dengeleyici arkasındaki istemcilerin gerçek IP'sini X-Forwarded-For başlığından alın.
- Küresel limit yerine kullanıcı başına limit uygulamamak: Aynı IP altındaki farklı kullanıcılar etkilenebilir.
OAuth 2.0 ile Entegrasyon
Rate limiting, OAuth 2.0 ile güvence altına alınmış API'lerde de kritiktir. Yetkilendirme sunucusuna yapılan token isteklerine (ör. client credentials grant) ayrı, daha katı limitler koyun. OAuth 2.0 Authorization Code Flow gibi akışlarda token yenileme isteklerini de sınırlayın.
Sonuç
Doğru rate limiting stratejisi, API'nizin güvenilirliğini ve sürdürülebilirliğini artırır. Token bucket ve leak bucket en popüler iki algoritmadır; ancak ihtiyacınıza göre sliding window gibi alternatifleri de değerlendirin. Yukarıdaki kontrol listesini uygulayarak sık hatalardan kaçının ve sisteminizi sürekli izleyin.
Sık Sorulan Sorular
Rate limiting ile throttling arasındaki fark nedir?
Rate limiting, belirli bir zaman diliminde izin verilen maksimum istek sayısını belirler; throttling ise isteklerin işlenme hızını düşürerek (örneğin kuyruğa alarak) zorlar. Throttling, rate limiting'in bir uygulama biçimi olabilir.
Token bucket algoritmasında kova boyutu ve dolum hızı nasıl belirlenir?
Kova boyutu (maksimum istek patlaması), sistemin kaldırabileceği anlık tepe yüke göre ayarlanır. Dolum hızı (saniyede eklenen jeton sayısı) ise ortalama kabul edilebilir istek hızını temsil eder. Örneğin 100 jetonluk kova, saniyede 10 jeton dolumu ile dakikada ortalama 600 isteğe izin verir.
Rate limiting için Redis kullanmak avantajlı mı?
Evet, Redis çok hızlı ve atomik işlemler (INCR, EXPIRE) sunduğu için dağıtık sistemlerde merkezi sayaç olarak idealdir. Token bucket için Redis Lua scriptleri ile thread-safe uygulama yapılabilir.
429 Too Many Requests yanıtında Retry-After başlığı zorunlu mu?
Zorunlu değildir ancak şiddetle önerilir. İstemci kaç saniye beklemesi gerektiğini bilirse gereksiz yere tekrar denemez ve kaynaklar daha verimli kullanılır.
Rate limiti aşan kullanıcılara kalıcı yasak uygulanmalı mı?
Genellikle geçici engelleme (örneğin 1 saat) yeterlidir. Kalıcı yasak, kötü niyetli saldırganlar için düşünülebilir ancak çoğu durumda orantılı yaptırım (kademeli limit düşürme veya IP engelleme) daha uygundur.
