API Rate Limiting Nedir ve Neden Gereklidir?
API Rate Limiting (hız sınırlama), belirli bir zaman diliminde bir istemcinin yapabileceği API istek sayısını kontrol eden bir mekanizmadır. Modern web mimarilerinde rate limiting, hizmet kalitesini korumak, kötüye kullanımı önlemek ve sistem kaynaklarını adil bir şekilde dağıtmak için kritik öneme sahiptir.
Rate limiting olmadan API'niz şu risklerle karşı karşıya kalır:
- DDoS saldırıları: Aşırı istek yükü ile hizmetin çökertilmesi
- Kaynak tükenmesi: Sunucu CPU, bellek ve bant genişliğinin tükenmesi
- Haksız kullanım: Tek bir istemcinin tüm kaynakları tüketmesi
- Maliyet artışı: Bulut altyapı maliyetlerinin kontrolsüz yükselmesi
- Veri kazıma: Otomatik botlarla toplu veri çekilmesi
Rate Limiting Algoritmaları
1. Token Bucket Algoritması
Token bucket, en yaygın kullanılan rate limiting algoritmalarından biridir. Kavramsal olarak bir kova ve jetonlardan oluşur:
- Kova sabit kapasiteye sahiptir (maksimum jeton sayısı)
- Jetonlar sabit bir hızda kovaya eklenir
- Her istek bir jeton tüketir
- Jeton yoksa istek reddedilir veya kuyruğa alınır
- Kova doluysa yeni jetonlar atılır
Token bucket'ın avantajları:
- Burst traffic'e izin verir: Biriken jetonlarla kısa süreli yoğunluklar karşılanabilir
- Basit implementasyon: Anlaşılması ve uygulanması kolaydır
- Bellek verimliliği: Yalnızca jeton sayısı ve son dolum zamanı saklanır
Amazon API Gateway, AWS WAF ve nginx gibi yaygın kullanılan altyapılar token bucket algoritmasını kullanır. Bu algoritmayı anlamak, bulut hizmetlerinin rate limiting davranışını da anlamanızı sağlar.
2. Leaky Bucket Algoritması
Leaky bucket (sızdıran kova), istekleri sabit bir hızda işleyen bir kuyruk sistemidir. Token bucket'tan farklı olarak, çıkış hızı her zaman sabittir:
- İstekler kovaya (kuyruğa) eklenir
- İstekler sabit bir hızda kuyruktan çıkarılır ve işlenir
- Kuyruk doluysa yeni istekler reddedilir
Leaky bucket'ın öne çıkan özellikleri:
- Sabit çıkış hızı: Downstream hizmetlere düzenli bir istek akışı sağlar
- Burst koruması: Ani yüklenmeleri düzgünleştirir
- Dezavantaj: Burst traffic'e izin vermez, düşük trafik dönemlerinde kapasite israf olabilir
3. Fixed Window Counter
En basit rate limiting yöntemidir. Zaman sabit pencerelere bölünür ve her pencerede istek sayısı sayılır:
- Örnek: Dakikada 100 istek limiti
- Her dakika başında sayaç sıfırlanır
- Sayaç limite ulaştığında istekler reddedilir
Bu yaklaşımın bilinen sorunu "boundary problem"dir: İki pencere arasındaki sınırda, kullanıcı kısa bir sürede limitin iki katı istek yapabilir. Örneğin, 100 isteği 0:59'da ve 100 isteği 1:00'da yaparak 2 saniyede 200 istek gerçekleştirebilir.
4. Sliding Window Log
Fixed window'un sınır problemini çözmek için geliştirilen bu algoritmada, her isteğin zaman damgası kaydedilir:
- Her istek geldiğinde zaman damgası loglanır
- Mevcut zaman penceresinin dışındaki loglar temizlenir
- Pencere içindeki log sayısı kontrol edilir
- Limit aşılmışsa istek reddedilir
Dezavantajı, büyük miktarda zaman damgası saklaması gerektiğinden bellek tüketiminin yüksek olmasıdır.
5. Sliding Window Counter
Fixed window counter ve sliding window log yaklaşımlarının avantajlarını birleştirir:
- Mevcut ve önceki penceredeki istek sayıları saklanır
- Ağırlıklı ortalama ile mevcut pencere içindeki istek sayısı hesaplanır
- Hem bellek verimli hem de sınır problemini büyük ölçüde çözer
Rate Limiting Algoritma Karşılaştırması
| Algoritma | Burst Desteği | Bellek Kullanımı | Doğruluk | Karmaşıklık |
|---|---|---|---|---|
| Token Bucket | Evet | Düşük | Yüksek | Düşük |
| Leaky Bucket | Hayır | Orta | Yüksek | Düşük |
| Fixed Window | Hayır | Düşük | Düşük | Çok Düşük |
| Sliding Window Log | Hayır | Yüksek | Çok Yüksek | Orta |
| Sliding Window Counter | Hayır | Düşük | Yüksek | Orta |
HTTP Rate Limit Başlıkları
IETF RFC 6585 ve draft-ietf-httpapi-ratelimit-headers standardı, rate limiting bilgisini HTTP başlıkları ile iletmenin yollarını tanımlar:
Standart Başlıklar
- RateLimit-Limit: Toplam izin verilen istek sayısı
- RateLimit-Remaining: Kalan istek sayısı
- RateLimit-Reset: Limitin sıfırlanacağı zaman (Unix timestamp)
- Retry-After: 429 yanıtlarında, yeniden deneme öncesi beklenmesi gereken süre (saniye)
HTTP 429 Too Many Requests
Rate limit aşıldığında sunucunun döndürmesi gereken HTTP durum kodudur. Bu yanıt, istemciye limit aşıldığını bildirmenin standart yoludur. Yanıt gövdesinde faydalı hata mesajları ve Retry-After başlığı ile yeniden deneme bilgisi sunulmalıdır.
Redis ile Rate Limiting Implementasyonu
Redis, yüksek performanslı rate limiting uygulamaları için ideal bir veri deposudur. Atomik operasyonları ve TTL (Time-To-Live) desteği sayesinde dağıtık sistemlerde bile tutarlı rate limiting sağlar.
Redis Komutları
- INCR: Sayacı atomik olarak artırır
- EXPIRE: Anahtar için TTL ayarlar
- MULTI/EXEC: Atomik transaction sağlar
- Lua Scripting: Atomik çoklu komut çalıştırma
Dağıtık Rate Limiting Zorlukları
Birden fazla sunucu örneğinde rate limiting uygulamak ek zorluklar getirir:
- Tutarlılık: Tüm örneklerde aynı sayaç değerinin görülmesi
- Gecikme: Merkezi veri deposuna ağ gecikmesi
- Hata toleransı: Redis çöktüğünde ne olacağı
- Yarış koşulları: Eşzamanlı isteklerde sayaç doğruluğu
Redis Cluster kullanırken, aynı istemcinin rate limit anahtarlarının aynı shard üzerinde olmasını sağlamak için hash tag'leri kullanın. Bu, atomik operasyonların doğru çalışmasını garanti eder.
API Gateway'lerde Rate Limiting
Modern API gateway'ler yerleşik rate limiting özellikleri sunar:
Popüler API Gateway Çözümleri
| Gateway | Rate Limiting Yöntemi | Öne Çıkan Özellik |
|---|---|---|
| Kong | Plugin tabanlı | Redis destekli dağıtık limiting |
| AWS API Gateway | Token bucket | Otomatik ölçekleme |
| nginx | Leaky bucket | Yüksek performans |
| Envoy | Token bucket | Global ve lokal limiting |
| Azure API Management | Sliding window | Policy tabanlı yapılandırma |
Rate Limiting Stratejileri
Katmanlı Rate Limiting
Farklı seviyelerde rate limit uygulamak en etkili stratejidir:
- Global limit: Tüm API'ye uygulanan genel limit
- Kullanıcı bazlı limit: Her kullanıcı için ayrı limit
- Endpoint bazlı limit: Kritik endpoint'ler için özel limitler
- IP bazlı limit: Anonim istekler için IP tabanlı sınırlama
Dinamik Rate Limiting
Sabit limitler yerine, sistem yüküne göre dinamik olarak ayarlanan limitler daha esnek bir yaklaşım sunar. Sunucu CPU kullanımı, bellek durumu ve kuyruk uzunluğu gibi metriklere göre limitler otomatik olarak artırılıp azaltılabilir.
En İyi Uygulamalar
- Rate limit bilgisini her yanıtta HTTP başlıkları ile iletin
- 429 yanıtlarında anlamlı hata mesajları ve Retry-After başlığı döndürün
- API dokümantasyonunuzda rate limit politikalarını açıkça belirtin
- Farklı API planları için farklı limitler sunun
- Rate limiting metriklerini izleyin ve alarmlar kurun
- Graceful degradation uygulayın, kritik olmayan özellikleri devre dışı bırakın
- İstemci tarafında exponential backoff ve jitter kullanarak yeniden deneme stratejisi uygulayın
- Test ortamında rate limitlerini simüle edin
Sonuç
API rate limiting, modern API tasarımının temel taşlarından biridir. Token bucket, leaky bucket ve sliding window gibi algoritmaları anlamak, doğru stratejiyi seçmenizi sağlar. Redis gibi yüksek performanslı veri depoları ile dağıtık rate limiting uygulamak, ölçeklenebilir ve güvenilir API'ler oluşturmanın anahtarıdır. Rate limiting'i sadece bir güvenlik önlemi olarak değil, hizmet kalitesini koruyan ve adil kaynak dağılımı sağlayan stratejik bir bileşen olarak değerlendirin.
