Backend & Yazılım Mimarisi 6 dk okuma

ASP.NET Core Rate Limiting: 6 Adımda API Koruması

6 dk okuma

Giriş

ASP.NET Core Rate Limiting, bir API’nin belirli bir süre içinde kabul edeceği istek miktarını kontrol ederek kötüye kullanım, ani trafik sıçramaları ve kaynak tüketimi risklerini azaltmak için kullanılan yerleşik bir mekanizmadır. Özellikle herkese açık API’lerde yalnızca kimlik doğrulama yeterli değildir; geçerli bir kullanıcı da yanlış yapılandırılmış istemci, agresif retry döngüsü veya otomasyon nedeniyle sistemi aşırı yükleyebilir. Bu rehberde rate limiting’i politika seçimi, partitioning, 429 yanıtları, izleme, yük testi ve operasyonel iyileştirme perspektifiyle ele alıyoruz.

İçindekiler

  • Rate Limiting Nedir ve Neden Gereklidir?
  • NET Core Rate Limiting Temelleri
  • Fixed Window ve Sliding Window Politikaları
  • Token Bucket ve Concurrency Limiter
  • NET Core Rate Limiting 6 Adımda Nasıl Uygulanır?
  • IP, Kullanıcı ve API Anahtarına Göre Sınırlama
  • 429 Yanıtları ve Retry-After
  • İzleme, Metrikler ve Yük Testi
  • Sık Yapılan Hatalar ve Best Practices
  • Sonuç

1. Rate Limiting Nedir ve Neden Gereklidir?

Rate limiting, istemcilerin belirlenen bir zaman diliminde veya eşzamanlılık seviyesinde tüketebileceği kapasiteyi sınırlar. Amaç yalnızca saldırıları engellemek değildir. Hatalı retry politikaları, agresif botlar veya aynı hesabın çok sayıda paralel işlem başlatması da API kaynaklarını tüketebilir. Doğru limitler adil kullanım sağlar ve backend servislerinin öngörülebilir kapasitede çalışmasına yardımcı olur.

Rate limiting; authentication, authorization, WAF ve uygulama güvenliği kontrollerinin yerine geçmez. Bunları tamamlayan bir dayanıklılık katmanıdır. Limitleri iş gereksinimi ve ölçülen kapasiteye göre belirlemek gerekir.

2. ASP.NET Core Rate Limiting Temelleri

ASP.NET Core, rate limiting middleware’i üzerinden politika tabanlı sınırlama sağlar. Uygulama başlangıcında AddRateLimiter ile politikalar kaydedilir ve pipeline’a UseRateLimiter eklenir. Endpoint bazında RequireRateLimiting kullanarak farklı API gruplarına farklı politikalar atanabilir.

Politika tasarımında üç soru önemlidir: kapasite ne kadar, kapasite hangi sürede yenileniyor ve istemciler hangi anahtara göre birbirinden ayrılıyor? Bu son soru partitioning konusudur.

3. Fixed Window ve Sliding Window Politikaları

Fixed Window, belirli zaman blokları için sabit bir istek kotası tanımlar. Örneğin bir kullanıcıya her dakika 100 istek hakkı verilebilir. Uygulaması kolaydır; ancak pencere sınırlarında burst oluşabilir.

Sliding Window bu sınır etkisini yumuşatır. Pencereyi segmentlere bölerek önceki segmentlerdeki kullanımın bir bölümünü hesaba katar ve trafiği daha dengeli dağıtır.

4. Token Bucket ve Concurrency Limiter

Token Bucket zaman içinde belirli hızda token üretir ve her istek bir token tüketir. Bucket kapasitesi kısa süreli burst’lere izin verirken uzun dönem ortalama tüketimi sınırlar.

Concurrency Limiter ise zaman penceresinden ziyade aynı anda çalışan istek sayısını sınırlar. Özellikle pahalı rapor, dosya işleme, yapay zeka çağrısı veya uzun süren backend işlemlerinde yararlıdır.

5. ASP.NET Core Rate Limiting 6 Adımda Nasıl Uygulanır?

İlk adım gerçek trafik ve risk profilini ölçmektir. İkinci adım endpoint karakterine uygun Fixed Window, Sliding Window, Token Bucket veya Concurrency politikasını seçmektir. Üçüncü adım Program.cs içinde rate limiter servislerini ve middleware’i yapılandırmaktır.

Dördüncü adım partition anahtarını belirlemektir: anonim trafik için IP, oturum açmış kullanıcılar için kullanıcı kimliği veya B2B entegrasyonlarında API anahtarı/tenant kimliği kullanılabilir. Beşinci adım 429 Too Many Requests yanıtlarını, logları ve metrikleri izleyerek yük testi yapmaktır. Altıncı adım ise gerçek üretim verisine göre limitleri düzenli olarak iyileştirmektir.

6. IP, Kullanıcı ve API Anahtarına Göre Sınırlama

Tek bir partition anahtarı her sistem için doğru değildir. IP bazlı limit anonim servislerde hızlı başlangıç sağlar fakat NAT arkasındaki çok sayıda kullanıcı aynı IP’yi paylaşabilir. Proxy veya load balancer arkasında gerçek istemci IP’sinin güvenli biçimde çözümlendiğinden emin olmak gerekir.

Kimliği doğrulanmış sistemlerde kullanıcı veya tenant kimliği genellikle daha anlamlıdır. B2B API’lerde API key veya client id kullanılabilir.

7. 429 Yanıtları, Retry-After ve İstemci Davranışı

Limit aşıldığında istemciye anlaşılır bir 429 Too Many Requests yanıtı dönmek önemlidir. Uygun senaryolarda Retry-After bilgisi istemcinin ne zaman yeniden deneme yapabileceğini anlamasına yardımcı olur. İstemci tarafında kör retry yapmak yerine exponential backoff ve jitter gibi dayanıklı retry stratejileri tercih edilmelidir.

8. İzleme, Metrikler ve Yük Testi

Rate limiting’i etkinleştirip unutmak doğru yaklaşım değildir. 429 oranı, endpoint bazlı trafik, p95/p99 gecikme, CPU, bellek, downstream hata oranı ve kuyruk davranışı birlikte izlenmelidir.

Yük testinde yalnızca sabit RPS senaryosu kullanmayın. Burst, yavaş istemci, paralel istek, farklı tenant dağılımı ve retry davranışını da simüle edin.

9. Sık Yapılan Hatalar ve Best Practices

En sık hata tüm endpoint’lere aynı limiti uygulamaktır. Basit bir health endpoint ile ağır raporlama endpoint’i aynı maliyete sahip değildir. İkinci hata, kullanıcı kimliği mevcutken yalnızca IP bazlı sınırlama kullanmaktır. Üçüncü hata, 429 yanıtını istemci davranışını düşünmeden döndürmek ve retry storm oluşturmaktır.

Politikaları isimlendirin, endpoint gruplarına göre ayırın, limit değerlerini konfigürasyondan yönetmeyi değerlendirin ve değişiklikleri ölçümle doğrulayın.

10. Sonuç

ASP.NET Core Rate Limiting, API güvenliği ve performansının kesişiminde bulunan pratik bir kontrol mekanizmasıdır. Doğru politika, doğru partition anahtarı ve ölçülebilir limitler kullanıldığında hem kötüye kullanım etkisi azalır hem de yoğun trafik altında daha adil bir servis davranışı elde edilir. En iyi yapılandırma statik bir sayı değil, gerçek workload ile sürekli doğrulanan ve iyileştirilen bir kapasite politikasıdır.

Güvenilir Araştırma Kaynakları

Paylaş