.Net 7 ve Yenilikleri (Rate Limiter)
Hız parametresi genellikle backend organizasyonları için bir başarı kriteri olarak kabul edilir. Bazı senaryolarda çok hızlı olmak avantaj yerine dezavantaj oluşturabilir. Bu senaryolar organizasyonlara göre farklılık gösterebilir. Yapılan analizler sonucunda bazen uygulamalarımızın aşırı hızlı olmasını engellemek isteyebiliriz. Tam bu noktada Rate Limiter kavramı hayatımıza giriyor.
Rate Limiting temel olarak kullanıcıların kaynaklarınıza ne kadar erişebileceğini sınırlama operasyonudur. Örneğin, geliştirdiğimiz bir uygulamada veri tabanının dakikada/saniyede/saatte vb. 10K isteği işleyebileceğini yaptığımız yük testleri ile kanıtladığımızı düşünelim. Daha fazla istek gerçekleşirse uygulamamızın hata verme potansiyeli artıyor. Bu noktada uygulamamızı korumak istediğimizde Rate Limiting kavramı bize yardımcı olacaktır. Rate Limiting implementasyonu gerçekleştirerek uygulamamızı potansiyel arızalardan koruyabiliriz.
.Net 7 Preview 4 ile birlikte Microsoft tarafından official bir kütüphane geliştirildi. Bu sürümden
önce third-party kütüphaneler ile bu implementasyonu gerçekleştirebiliyorduk ancak bugün .Net 7 Preview 4 sürümü ile gelen kütüphaneyi inceleyeceğiz.
Bu sürümün bir preview olduğunu unutmamak gerekiyor. Bu yapı bazı değişikliklere uğrayabilir. Sonraki sürümlerde daha farklı özellikleri barındırabilir.
Rate Limiting implementasyonunu gerçekleştirebileceğimiz 4 farklı senaryo bulunuyor.
- Concurrency Limit
- Token Bucket Limit
Rate Limiter yapısını kullanabilmek için Nuget üzerinden Microsoft.AspNetCore.RateLimiting kütüphanesini indirmemiz gerekiyor.
Concurrency Limit
Eğer uygulamanıza eş zamanlı olarak gelen istekleri sınırlamak istiyorsanız Concurrency Limit seçeneğini kullanmalısınız.
Yukarıda bulunan ekran görüntüsünde Concurrency Limiter konfigürasyonu bulunmaktadır. Konfigürasyon içerisinde en önemli parça Concurrency Limiter Options nesnesinin içerdiği parametrelerdir.
Permit Limitparametresi eş zamanlı olarak yürütülecek maksimum izin sayısını temsil etmektedir.
Queue Processing Order parametresi ile eş zamanlı istekler yürütülürken isteklerin işleneceği kuyruk yapısının çalışma mantığını temsil eder. Bu parametre iki adet seçenek barındırır.
- Oldest First (LIFO-Last in first out)
- Newest First (FIFO-First in first out)
Queue Limit parametresi ise kuyruğun kapasitesini temsil etmektedir.
Rejected senaryosunda yani kuyruğun kapasitesi dolduğunda kullanıcıların nasıl bir hata senaryosu ile karşı karşıya kalacağı oldukça önemlidir.
Default olarak Status503ServiceUnavailable yani 503 hata kodu işletilecektir. Bu hata kodunu customize etmek için aşağıdaki örnek koda bakabilirsiniz.
429 status code Too Many Request anlamını taşımaktadır. 503 status code ise çok daha genel bir anlam içermektedir. Kullanıcılara bu noktada doğru kodlar ile bilgi vermek daha iyi olacaktır.
Rate Limiter Middleware aktif edildiğinde belirlenen kurallar tüm endpointler için geçerli olacaktır. Bazı endpointleri bu kurallardan muaf tutmak isteyebiliriz. Bu noktada NoLimiter extension metodunu kullanmalıyız.
Token Bucket Limit
Benim en çok hoşuma giden limit yapısı Token Bucket Limit oldu. Oldukça basit bir mantığı var. Bir cüzdanınız varmış gibi düşünün. İçerisinde 10 adet token var. İstek geldiğinde bir adet token harcanır ve belirli bir süre geçene kadar tahsis edilir. Bu jetonları yapacağınız implementasyon sayesinde satın alınabilir bir yapıya dönüştürebilirsiniz. Konfigürasyon için aşağıdaki örnek koda bakabilirsiniz.
Konfigürasyon için gerekli parametreler;
Token Limit-Bucket içerisinde bulunabilecek maksimum token sayısı.Queue Processing Order-Token yönetimi yapılırken kuyruğun çalışma mantığı.Queue Limit-İşlenmemiş jetonlar için maksimum bekleme sayısı.Replenishment Period-Bucket içerisinde tokenların tekrar doldurulması için geçen süre.Tokens Per Period-Replenishment Period vakti geldiğinde kovaya kaç jeton ekleneceğini belirler.Auto Replenishment-bool bir değer alır. False ise implementasyon içerisinde manuel bir şekilde kovaya ikmal yapılmalıdır. True ise otomatik olarak Replenishment Period geldiğinde bucket doldurulur.
Henüz preview sürümlerinde olduğumuz için bu yapı bazı değişikliklere uğrayabilir. Endişelenmeye gerek yok. Temel yapı aynı kalacaktır. Belki bazı methodlar eklenir veya güncellenir.
Özellikle Token Bucket Limit yöntemi distributed yapılarda bazı sorunlar çıkarabilir. Belki ilerleyen sürümlerde distributed yapılarda nasıl çalışacağını daha detaylı örneklerle açıklarlar. Muhtemelen Redis gibi bir provider yardımıyla distributed yapılarda çıkacak sorunları minimize edeceklerdir. Bekleyip göreceğiz.
Bu özelliği derinlemesine takip etmek isteyenler buraya tıklayabilir.
Geliştirdiğiniz endpointler limitli çalışsın. Rate Limiting sizi korusun. 🙏
