ASP.NET Core'da production rate limiting
Production'da rate limiting, algoritmayla değil önce tükenen kaynakla başlar. Benjamin Abt concurrency ve zamana dayalı limitlerin nasıl katmanlanacağını, güvenli partition key seçimini, middleware sırasını ve replika sayısı arttığında in-memory state'in neyi garanti edemeyeceğini anlatıyor.
Kilit noktalar
- Zamana dayalı kota ile concurrency limiti farklı soruları yanıtlar; production API'lerde genellikle ikisi birlikte gerekir.
- Partition key tenant ID, OAuth client ID veya subject ID olmalı; API key, Authorization header ve query string key'e girmemeli.
- RejectionStatusCode açıkça ayarlanmalı: tükenen client kotası için 429, servis genelinde doygunluk için 503.
- Yerleşik limiter state'i process başına tutulur; dakikada 100 istek limitli 20 replika kabaca 2.000 isteği geçirir, bu yüzden gateway, distributed veya replika başına paylaşım modellerinden biri seçilip kapsamı yazılmalı.
- Servis süresi dağılımı ölçülmeden limiter queue uzunluğu sıfırda bırakılmalı.
- FixedWindowRateLimiter'ın Retry-After metadata'sı .NET 11 Preview 7'de bir sonraki pencere sınırına işaret edecek şekilde düzeltildi.
ASP.NET Core'da rate limiting örnekleri genellikle fixed window kaydıyla biter; oysa asıl soru hangi kaynağın önce tükendiğidir: veritabanı bağlantıları, CPU, bellek ya da çağrılan bir servis. Benjamin Abt bu noktadan başlayıp iki soruyu ayırıyor: bir client zaman içinde ne kadar iş gönderebilir ve aynı anda ne kadarı çalışabilir. Yalnızca zamana dayalı bir limit yavaş isteklerde, yalnızca concurrency limiti hızlı patlamalarda yetersiz kaldığı için ikisi birlikte kullanılıyor.
Partition key bir güvenlik sınırı sayılıyor: tenant ID, OAuth client ID veya subject ID; anonim trafik için normalize edilmiş remote IP. API key, Authorization header ya da query string key'e girmemeli. Middleware sırası forwarded headers, routing ve authentication'ı öne alıyor; in-memory state her process'te ayrı tutuluyor ve 429 ile 503 farklı anlamlara ayrılıyor.
Gerçek dünyada kullanımı
- Tenant başına kota ve rapor/export endpoint'lerinde daha sıkı bir concurrency tavanı isteyen çok kiracılı SaaS API.
- CDN ve WAF arkasındaki public API'de anonim çağrıları normalize edilmiş IP ile bölüp, kimlik doğrulamalı makineleri OAuth client ID ile ayırmak.
- Ücretli üçüncü taraf API'nin ticari kotasını yöneten bir servis; ağırlıklı maliyet, middleware sayacı yerine kalıcı iş mantığında hesaplanmalı.
- Çok sayıda replikada çalışan container API'de gateway kotası, Redis tabanlı atomik state veya dokümante edilmiş replika başına paylaşım arasında seçim yapmak.
Neden önemli
Eğitim örneğinden kopyalanan bir politika yavaş endpoint'leri ya da ani patlamaları geçirir ve gerçek kapasite sorunlarını gizler. Partition, status code ve kota kapsamı bilinçli tasarım kararları olduğunda koruma; replika ve tenant sayısı büyüdüğünde de doğru kalır.