Genel Bakış
API Bazlı Throttling politikası, API’lere gelen isteklerin kısa zaman aralıklarında (saniye, dakika) sınırlandırılmasını sağlar. Bu politika ile:- Belirli bir zaman diliminde izin verilen maksimum istek sayısını kontrol edebilirsiniz.
- Farklı hedefler için özel hız sınırları tanımlayabilirsiniz.
- API’lerinizi aşırı yüklenmeye karşı koruyabilirsiniz.
- Kullanıcı bazında veya değişken bazında hız sınırlaması uygulayabilirsiniz.
Throttling: Kısa süreli (saniye/dakika) hız kontrolü sağlar, sadece cache kullanır, sistem yeniden başlatıldığında sayaçlar sıfırlanır, burst protection ve DDoS koruması için idealdir.Kota: Uzun dönemli (saat/gün/hafta/ay) toplam kullanım limitlerini yönetir, cache + veritabanı kombinasyonu kullanır, kalıcı veri depolama sağlar, faturalama ve abonelik yönetimi için kullanılır.
Amacı Nedir?
- Sistem Koruması ve Kaynak Yönetimi: Backend sistemlerini aşırı yüklenmeye karşı korur, kaynak tükenmesini önler ve sunucu kapasitesinin adil kullanımını sağlar.
- DDoS ve Bot Saldırısı Önleme: DDoS saldırıları, bot trafiği ve kötü niyetli istek bombardımanına karşı sistem güvenliğini sağlar.
- İş Modeli ve SLA Desteği: Farklı kullanıcı segmentleri için özelleştirilmiş hizmet seviyeleri sunar (Free, Premium, Enterprise), servis seviyesi sözleşmelerini yerine getirir.
- Maliyet Kontrolü ve Performans Optimizasyonu: Cloud servis maliyetlerini optimize eder, gereksiz API çağrılarını sınırlar, sonsuz döngü ve yanlış implementasyonları erken tespit eder.
Çalışma Prensibi
- İstek Gelişi: API Gateway’e gelen her HTTP/HTTPS isteği için, istemin kaynak bilgileri (IP, kullanıcı, API key vb.) tespit edilir.
- Politika Kontrolü: API bazlı Hız Sınırlama politikası aktif ise, sistem aşağıdaki sırayla kontrol yapar:
- Politika aktif mi (active=true)?
- Condition (koşul) tanımlı mı? Varsa koşul sağlanıyor mu?
- Variable kullanılıyor mu yoksa default ayarlarda mı?
- Throttling Key Oluşturma ve Sayaç Kontrolü: Her istek için benzersiz bir throttling anahtarı oluşturulur (format:
throttling:{policy_id}:{apply_by_value}:{window}). Apply By parametresi varsa (IP adresi, kullanıcı adı, API key vs.), bu değer anahtara dahil edilir. Cache’den mevcut istek sayacı sorgulanır. Detail List tanımlıysa, hedef değer ile karşılaştırılır ve eşleşen kuralın limiti kullanılır, yoksa varsayılan limit uygulanır. - Karar Verme:
Limit Aşılmadıysa:
- Sayaç 1 artırılır ve cache’e senkron olarak yazılır.
- İstek backend’e iletilir.
- Rate limit statistics aktifse response header’larına kota bilgisi eklenir (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Limit Aşıldıysa:
- HTTP 403 hatası dönülür, akış kesilir, hata hattına geçer. Cache’e erişim hatası olursa:
- Cache Error Handling politikası devreye girer (ALLOW: akış devam eder, REJECT: akış kesilir).
- Hata İşleme: Politika kuralına uymayan istekler için özelleştirilebilir HTTP durum kodu ve hata mesajı döndürülür.
Veri Depolama Stratejisi
API Bazlı Throttling politikası, yüksek performans için sadece cache bazlı depolama kullanır: Cache - Tek Katman:- Tüm throttling sayaçları sadece cache’de tutulur.
- Her API isteğinde senkron olarak güncellenir.
- Minimum gecikme ve maksimum performans sağlar.
- Dağıtık sistemlerde tüm Gateway instance’ları aynı sayaçları paylaşır.
- Throttling politikası veritabanına yazma yapmaz.
- Veriler geçicidir ve cache’in TTL (Time-To-Live) süresi dolduğunda otomatik silinir.
- Sistem yeniden başlatıldığında throttling sayaçları sıfırlanır.
- Bu tasarım kısa süreli hız kontrolü için yeterlidir ve maksimum performans sağlar.
Özellikler ve Yetenekler
Temel Özellikler
- Mesaj Sayısı Limiti: Belirli bir zaman diliminde izin verilen maksimum istek sayısını belirler (minimum 1, tam sayı).
- Esnek Zaman Aralığı Desteği: Saniye ve dakika bazında zaman periyotları tanımlama. Periyot uzunluğu çarpanı ile özelleştirilebilir zaman aralıkları (örn: 3 saniye, 5 dakika).
- Apply By Değişkeni: Throttling’in hangi kritere göre uygulanacağını belirler (IP adresi, kullanıcı adı, API Key veya seçeceğiniz herhangi bir header/parametre/body değeri bazlı). Her değişken değeri için ayrı sayaç tutulur.
- Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu kolayca değiştirme (active/passive toggle). Pasif durumda politika uygulanmaz ancak yapılandırması kullanıma hazır şekilde bekler.
- Koşul Bazlı Uygulama: Condition ile politikanın hangi durumlarda uygulanacağını belirleme (örn: sadece belirli endpoint’lere veya header değerlerine göre).
İleri Düzey Özellikler
- Hedef Bazlı Farklı Limitler (Detail List): Belirli kurallara göre belirli limitler belirtmek (kullanıcı seviyeleri, IP aralıkları, API key’ler). Regex desteği ile esnek hedef eşleşmeleri. Her hedef için ayrı mesaj sayısı ve zaman aralığı.
- Interval Window Type Desteği: SLIDING (Kayan Pencere) - Her istek zamanından ileriye doğru pencere uygulanır, daha hassas kontrol sağlanır. FIXED (Sabit Pencere) - Belirli zaman dilimlerinde sayaç sıfırlanır, daha performanslı.
- Cache Bağlantı ve Hata Yönetimi: Cache sunucusu bağlantı timeout süresi ayarlama (saniye). Cache erişilemezse davranış belirleme: ALLOW (kullanılabilirlik öncelikli) veya REJECT (güvenlik öncelikli).
- Rate Limit İstatistikleri: Response header’larında kalan kota bilgisi gösterme (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Client’ların kendi kotalarını takip edebilmesi.
- Dağıtık Mimari Desteği: Merkezi cache kullanımı sayesinde birden fazla Gateway instance’ı aynı sayaçları paylaşır. Kullanıcı hangi gateway’e bağlanırsa bağlansın tutarlı hız sınırlama sağlanır.
- Export/Import Özelliği: Politika yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) veya API Proxy’lere import etme.
- Policy Group ve Proxy Group Desteği: Birden fazla politikayı Policy Group içinde yönetme ve Proxy Group içerisinde politika kullanımıyla merkezi güncelleme ve deploy işlemleri.
- Deploy ve Versiyonlama: API Proxy’lerdeki Deployment History özelliği ile versiyonlama yapılması. Global politika veya Policy Group kullanımı ile hangi API Proxy’lerde kullanıldığını görme.
Kullanım Senaryoları
API Bazlı Throttling politikası, API trafiğini yönetmek ve sistem kaynaklarını korumak amacıyla istek oranlarını kontrol eder. Aşağıdaki örnek senaryolar, farklı kullanım durumlarında bu politikanın nasıl uygulanabileceğini göstermektedir. Her senaryo, belirli bir ihtiyaca karşılık gelen konfigürasyon örneğiyle birlikte açıklanmıştır.| Senaryo | Durum | Çözüm (Politika Uygulaması) | Beklenen Davranış / Sonuç |
|---|---|---|---|
| Basit API Rate Limiting | Tüm kullanıcılar için genel bir hız sınırı koymak istiyorsunuz | Mesaj Sayısı: 100, Periyot: 1 Dakika, Apply By: Boş, Interval Window Type: SLIDING | Her kullanıcı dakikada maksimum 100 istek atabilir. Tüm istekler aynı limiti paylaşır |
| IP Bazlı Hız Sınırlama | Her IP adresi için ayrı limit belirlemek istiyorsunuz | Apply By: {client.ip}, Mesaj Sayısı: 50, Periyot: 1 Dakika | Her IP adresi dakikada maksimum 50 istek atabilir. IP’ler birbirinden bağımsız sayılır |
| Kullanıcı Seviyesi Bazlı Farklı Limitler | Premium kullanıcılara daha yüksek limit vermek istiyorsunuz | Apply By: {user.tier}, Mesaj Sayısı: 100, Detail List: premium=1000/dk, enterprise=5000/dk, free=100/dk | Free: 100 istek/dk, Premium: 1000 istek/dk, Enterprise: 5000 istek/dk |
| Belirli Endpoint’ler İçin Farklı Limitler | Resource-intensive endpoint’lere daha düşük limit uygulamak istiyorsunuz | Politika 1: Mesaj: 10/dk, Koşul: {request.path} CONTAINS '/api/heavy'. Politika 2: Mesaj: 100/dk, Koşul: diğerleri | /api/heavy/* endpoint’leri 10 istek/dk, diğer endpoint’ler 100 istek/dk sınırına sahip olur |
| API Key Bazlı Throttling | Her API key için ayrı kota tanımlamak ve müşterilerin kotalarını takip etmelerini sağlamak istiyorsunuz | Apply By: {request.header.X-API-Key}, Mesaj Sayısı: 500, Periyot: 1 Saat, Show Rate Limit Statistics: Aktif | Her API key saatte 500 istek atabilir. Response header’larında kalan kota gösterilir (X-RateLimit-Remaining) |
| İç ve Dış Kullanıcılar İçin Farklı Limitler | İç ağdan gelen isteklere daha yüksek limit vermek istiyorsunuz | Apply By: {client.ip}, Mesaj: 100/dk (varsayılan), Detail List: 192.168.=10000/dk (regex), 10.=10000/dk (regex) | İç ağ (192.168., 10.) 10000 istek/dk, dış kullanıcılar 100 istek/dk sınırına sahip olur |
| Burst Protection ile Günlük Kota | Hem anlık burst koruması hem de günlük toplam kota uygulamak istiyorsunuz | Throttling Politikası: 10 istek/saniye (SLIDING) Kota Politikası: 10000 istek/gün (FIXED) | Throttling anlık hız kontrolü sağlar (10 istek/sn), Kota günlük toplam kullanımı kontrol eder (10K istek/gün). İki politika birlikte kullanılarak hem kısa vadeli hem uzun vadeli koruma sağlanır |
Politika Parametrelerini Yapılandırma
Bu bölümde, yeni bir API Based Throttling politikasının oluşturulması için kullanılan alanlar ve yapılandırma adımları yer almaktadır. Politika parametreleri, isteklerin hangi ölçüte göre sınırlandırılacağını, zaman penceresinin nasıl hesaplanacağını ve limit aşımlarında sistemin nasıl davranacağını belirler.Yeni API bazlı Hız Sınırlama Politikası Oluşturma
Yapılandırma Adımları
| Adım | Açıklama / İşlem |
|---|---|
| Adım 1: Oluşturma Sayfasına Gitme | - Sol menüden Development → Global Settings → Global Policies → API Based Throttling bölümüne gidin. - Sağ üstteki [+ Create] butonuna tıklayın. |
| Adım 2: Temel Bilgileri Girme | Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) Zorunlu: Örnek: Production_API_Throttling- Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: “Canlı ortam için dakikada 100 istek limiti” - Maks. 1000 karakter. - Politikanın amacını açıklayın. |
| Adım 3: Throttling Ayarlarını Yapılandırma | Rate Limit İstatistiklerini Response Header’da Göster: Varsayılan değeri kapalı. - Toggle switch ile aktif/pasif yapın. - Aktif olduğunda response header’larında X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset bilgileri gösterilir.Uygulama Değişkeni (Apply By): Varsayılan değeri kapalı. - “Değişken Seç” butonuna tıklayın. - Throttling’in hangi kritere göre uygulanacağını belirler. - Değişken seçilmezse tüm istekler aynı limiti paylaşır. Mesaj Sayısı: Zorunlu, Minimum: 1. - İzin verilen maksimum istek sayısı. - Örnek: 100 Periyot Uzunluğu: Zorunlu, Minimum: 1. - Zaman aralığının çarpanı. - Örnek: 1 Zaman Birimi: Zorunlu - Saniye, Dakika - Örnek: Dakika ⚠️ Not: Throttling politikası kısa süreli hız kontrolü içindir. Saat veya gün bazlı uzun dönem kontrolü için API Based Quota politikasını kullanın. |
| Adım 4: Hedef Bazlı Kurallar Tanımlama (İsteğe Bağlı) | Hedef Bazlı Throttling Kuralları (Target-Specific Throttling Rules): - Farklı hedef değerler için özel limitler tanımlayın. [+] butonuna tıklayarak yeni satır ekleyin. Tablo Kolonları: - Hedef Değer: Zorunlu. Değişken değeri (örn: “premium”, “192.168.1.*”, “test_user”) - Regex İfade: Hedef değerin regex olup olmadığı - Toggle (Boolean) - Mesaj Sayısı: Bu hedef için istek limiti - Number (Min: 1) - Periyot Uzunluğu: Zaman aralığı çarpanı - Number (Min: 1) - Zaman Birimi: Saniye/Dakika/Saat/Gün - Dropdown Kullanım Senaryoları: - Premium kullanıcılara daha yüksek limit: premium → 1000 istek/dakika- Belirli IP aralıkları: 192.168.* (regex aktif) → 500 istek/dakika- Test kullanıcıları: test_user → 10000 istek/dakikaSilme: Satır sonundaki çöp kutusu ikonu ile satırı kaldırın. |
| Adım 5: Gelişmiş Ayarları Yapılandırma | Interval Window Type: Zorunlu - SLIDING (Kayan Pencere): Her istek zamanından geriye doğru pencere uygulanır, daha hassas kontrol. Örnek: Son 60 saniyedeki istek sayısı. - FIXED (Sabit Pencere): Belirli zaman dilimlerinde sıfırlanır, daha performanslı. Örnek: Her dakika başında sayaç sıfırlanır. Cache Bağlantı Timeout: Zorunlu, Minimum: 1 saniye - Cache sunucusuna bağlantı timeout süresi. - Timeout durumunda hata yönetimi politikası devreye girer. - Önerilen: 1-3 saniye Cache Hata Yönetimi Tipi: Zorunlu - REJECT: İsteği reddet, hata dön. Güvenlik öncelikli yaklaşım. SLA garantisi önemli sistemler için. - ALLOW: İsteğe izin ver, devam et. Kullanılabilirlik öncelikli yaklaşım. Cache geçici arızalarda servis devam eder. Interval Window Hesaplama (FIXED): Bir dakikadan kısa aralıklar için (örn: 10 saniye): - Formül: Pencere Başlangıcı = Dakika Başlangıcı + (Geçen Periyotlar × Periyot Süresi)- Örnek: Saat 14:37:25’teki bir istek, 10 saniyelik periyotta → 14:37:20-14:37:29 penceresine aittir Bir dakika veya daha uzun aralıklar için (örn: 5 dakika): - Formül: Pencere Başlangıcı = Saat Başlangıcı + (Geçen Periyotlar × Periyot Süresi)- Örnek: Saat 14:37’deki bir istek, 5 dakikalık periyotta → 14:35:00-14:39:59 penceresine aittir Performans Önerisi: Yüksek trafikli API’lerde FIXED window tercih edilmelidir. SLIDING window her istek için cache okuması yaparken, FIXED sadece sayaç artırımı yapar ve daha performanslıdır. |
| Adım 6: Koşul Tanımlama (İsteğe Bağlı) | - Condition sekmesine geçin. - Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler: - Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production- API Key bazlı: Header = X-API-Key, Starts With = PROD-- Endpoint bazlı: Path = /api/admin/*Koşul tanımlamazsa politika her zaman aktif |
| Adım 7: Hata Mesajı Özelleştirme (İsteğe Bağlı) | - Error Message Customization sekmesine gidin. - Erişim reddedildiğinde dönecek mesajı özelleştirin. Varsayılan: { "statusCode": 429, "message": "Too Many Requests" }Özel: { "statusCode": 429, "errorCode": "THROTTLE_LIMIT_EXCEEDED", "message": "Dakikalık istek limitiniz aşıldı. Lütfen 60 saniye sonra tekrar deneyin." } |
| Adım 8: Kaydetme | - Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: Benzersiz isim. Zorunlu alanlar dolu. En az bir mesaj sayısı ve zaman aralığı tanımlı Sonuç: - Politika listeye eklenir. - API’lere bağlanabilir. - Global politikaysa otomatik uygulanır. |
Politikayı Silme
Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Yönetimi sayfasındaki Akıştan Politika Kaldırma bölümüne bakabilirsiniz.Politikayı Dışa/İçe Aktarma
Bu politikanın dışa aktarma (Export) ve içe aktarma (Import) adımları için Export/Import sayfasına bakabilirsiniz.Politikayı API’ye Bağlama
Bu politikanın API’lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API’ye Bağlama bölümüne bakabilirsiniz.İleri Düzey Özellikler
Bu bölümde kullanıcı, API Based Throttling politikasının gelişmiş yönetim kabiliyetlerini kullanarak daha esnek, dinamik ve kurumsal seviyede kontrol elde eder. Değişken yönetimi, hedefe özel kural tanımları, koşullu aktivasyon ve özelleştirilebilir hata mesajları gibi ileri düzey özellikler sayesinde politikalar dinamik şekilde uyarlanabilir, farklı senaryolara göre optimize edilebilir.| Özellik | Açıklama ve Adımlar |
|---|---|
| Regex ile Hedef Eşleştirme | - Detail List tablosunda yeni bir satır ekleyin. - Hedef Değer alanına regex pattern girin (örn: premium_user_.*).- Regex İfade toggle’ını aktif edin ve özel limit tanımlayın. - Bu sayede birden fazla hedef tek bir kuralla eşleştirilir. |
| Çoklu Politika Kombinasyonu | - Bir API’ye birden fazla throttling politikası atayın (örn: burst protection + günlük kota). - İlk politika: 10 istek/saniye (SLIDING) - burst koruması. - İkinci politika: 10000 istek/gün (FIXED) - günlük kota. - Tüm politikalar sırayla çalışır ve birbirini tamamlar. |
| Dinamik Variable Kullanımı | - Custom header, JWT claim veya context değişkeni oluşturun. - Apply By alanında bu değişkeni seçin (örn: {jwt.user_tier}).- Her değişken değeri için ayrı sayaç tutulur, dinamik segmentasyon sağlanır. |
İpuçları ve En İyi Uygulamalar
Yapılması Gerekenler ve En İyi Uygulamalar
| Kategori | Açıklama / Öneriler |
|---|---|
| Anlamlı İsimler Kullanın | Kötü: policy1, rate-limit, throttle-testİyi: Standard_User_Throttle, Premium_Service_Limit, Emergency_Burst_Control |
| Limit Değerleri Belirleme | Kötü: Çok düşük limitler (5 istek/dakika) - normal kullanıcıları engeller İyi: Gerçek kullanım istatistiklerine göre limitler (100 istek/dakika) En İyi: A/B testi ile optimal limitleri belirleyin, kullanıcı geri bildirimlerini değerlendirin ve metriklerle sürekli optimize edin |
| Window Type Seçimi | Kötü: Her senaryo için FIXED kullanmak - hassas kontrol eksikliği İyi: Performans kritikse FIXED, hassas kontrol gerekiyorsa SLIDING En İyi: Kritik endpoint’ler için SLIDING, yüksek trafikli endpoint’ler için FIXED kullanarak dengeli yaklaşım benimseyin |
| Apply By Değişkeni | Kötü: Değişken kullanmamak - tüm kullanıcılar aynı limiti paylaşır İyi: IP bazlı throttling - her IP için ayrı sayaç En İyi: Kullanıcı ID veya API Key ile kişiselleştirilmiş limitler, adil kaynak dağılımı ve abuse önleme |
| Detail List Kullanımı | Kötü: Tüm kullanıcılar için tek limit - esneklik yok İyi: Premium/Free ayrımı - iki seviye En İyi: Çok katmanlı tier sistemi (Free/Basic/Premium/Enterprise), regex ile dinamik gruplar, özel müşteriler için custom limitler |
| Rate Limit Header’ları | Kötü: Header’ları göstermemek - kullanıcılar limit aşımını beklenmedik şekilde yaşar İyi: Sadece external API’lerde header göstermek En İyi: Tüm throttling’lerde header aktif, dokümantasyonda client’lara nasıl kullanacakları anlatılmış, retry-after bilgisi sağlanmış |
Throttling ve Kota Politikalarını Birlikte Kullanma
Throttling ve Kota politikaları birbirini tamamlar ve birlikte kullanıldığında en etkili koruma sağlar: Throttling (Kısa Vadeli Koruma):- Saniye/dakika bazlı hız kontrolü
- Burst saldırılarını anında engeller
- Sadece cache kullanır, maksimum performans
- Sistem yeniden başlatmalarından etkilenir
- Saat/gün/ay bazlı toplam kullanım kontrolü
- Faturalama ve abonelik yönetimi
- Cache + veritabanı, kalıcı veri
- Raporlama ve analitik desteği
Güvenlik En İyi Uygulamaları
| Güvenlik Alanı | Açıklama / Uyarılar |
|---|---|
| DDoS Koruması | Burst protection için saniye bazında düşük limitler tanımlayın (örn: 10 istek/saniye). Uzun süreli saldırıları engellemek için Throttling ile birlikte Kota politikası kullanın (örn: Throttling: 10/sn + Kota: 10000/gün). Şüpheli IP’ler için daha sıkı limitler uygulayın. Sadece Throttling kullanıyorsanız sistem yeniden başlatıldığında sayaçlar sıfırlanacağını unutmayın. |
| API Key Sızıntısı Koruması | API Key bazlı throttling ile sızan key’lerin zararını sınırlayın. Anormal kullanım paternlerini tespit etmek için monitoring kurun. Key rotation stratejisi uygulayın. |
| Cache Güvenliği | Cache sunucusunu güvenli ağda tutun. Cache hatalarında varsayılan olarak REJECT tercih edin (güvenlik öncelikli). |
| Koşullu Sınırlama | Production ortamında daha sıkı limitler uygulayın. Test/Dev ortamları için ayrı politikalar oluşturun. Internal IP’ler için gevşek, external IP’ler için sıkı limitler. |
| Monitoring ve Alerting | 429 hata oranlarını sürekli izleyin. Limit aşımlarında alert oluşturun. Anormal trafik artışlarını tespit edecek metrikler kurun. |
Kaçınılması Gerekenler
| Kategori | Açıklama / Uyarılar |
|---|---|
| Çok Yüksek Cache Timeout | Neden kaçınılmalı: Cache sunucusu yanıt vermediğinde uzun süre beklenir, request latency artar, kullanıcı deneyimi bozulur Alternatif: 1-3 saniye arası timeout kullanın, cache sağlığını monitoring ile takip edin, failover mekanizması kurun |
| ALLOW Modu Her Yerde Kullanımı | Neden kaçınılmalı: Cache hatalarında throttling devre dışı kalır, güvenlik açığı oluşur, abuse saldırıları başarılı olabilir Alternatif: Kritik sistemlerde REJECT kullanın, cache high availability sağlayın, sadece read-only API’lerde ALLOW tercih edin |
| Değişken Kullanmadan Hedef Kuralları | Neden kaçınılmalı: Apply By olmadan Detail List çalışmaz, hedef eşleştirmesi yapılamaz, kurallar etkisiz kalır Alternatif: Mutlaka Apply By değişkeni tanımlayın, değişken değerleri ile hedef değerleri eşleştirin |
| Çok Karmaşık Regex Kullanımı | Neden kaçınılmalı: Her istek için regex işlenir, performans düşer, CPU kullanımı artar, latency eklenir Alternatif: Basit string eşleştirme kullanın, gerekmedikçe regex aktif etmeyin, prefix/suffix kontrolü tercih edin |
Performans İpuçları
| Kriter | Öneri / Etki |
|---|---|
| FIXED Window Tercihi | Öneri: Yüksek trafikli API’lerde FIXED window kullanın, saniye bazında SLIDING yerine dakika bazında FIXED tercih edin Etki: Cache okuması azalır, işlem maliyeti düşer, throughput %20-40 artar |
| Cache Key Expiration | Öneri: Throttling için cache key’lerde uygun TTL değerleri kullanın, periyot süresi + 10 saniye buffer ekleyin (örn: 60 saniye periyot için 70 saniye TTL) Etki: Gereksiz veri birikmesi önlenir, cache memory kullanımı optimize edilir, eski pencere verilerinin manuel silinmesine gerek kalmaz |
| Detail List Optimizasyonu | Öneri: Detail List’i 10-15 kuralla sınırlayın, sık kullanılan kuralları üstte tutun, gereksiz regex kullanmayın Etki: Kural eşleştirme hızlanır, CPU kullanımı azalır, ortalama latency 5ms’den az kalır |
| Cache Key Stratejisi | Öneri: Kısa ve unique key formatları kullanın, gereksiz bilgi key’e eklemeyin, key expiration süreleri optimize edin Etki: Cache memory kullanımı azalır, key lookup hızlanır, performansı artar |
| Monitoring ve Tuning | Öneri: Throttling metriklerini toplayın (hit rate, rejection rate), latency dağılımını analiz edin, cache performansını izleyin Etki: Bottleneck’ler erken tespit edilir, optimal konfigürasyon belirlenir, proaktif optimizasyon yapılır |
Sık Sorulan Sorular (SSS)
| Kategori | Soru | Cevap |
|---|---|---|
| Genel | Bir API’ye birden fazla throttling politikası eklenebilir mi? | Evet, birden fazla throttling politikası eklenebilir. Örneğin bir politika saniye bazında burst protection sağlarken (10 istek/saniye), diğeri günlük toplam kotayı kontrol edebilir (10000 istek/gün). Tüm politikalar sırayla çalışır ve herhangi biri limit aşımı tespit ederse istek reddedilir. |
| Genel | Detail List olmadan Apply By kullanılabilir mi? | Evet, Apply By değişkeni tek başına kullanılabilir. Bu durumda her değişken değeri için politikada tanımlanan varsayılan limit uygulanır. Detail List, belirli değişken değerleri için farklı limitler tanımlamak istediğinizde kullanılır. |
| Teknik | Cache sunucusu neden gereklidir? | Throttling sayaçlarını tutmak için merkezi bir cache sunucusu kullanılır. Dağıtık sistemlerde (birden fazla Gateway instance) tutarlı sayım için gereklidir. Cache olmadan her Gateway kendi sayacını tutar ve limitler doğru uygulanamaz. |
| Teknik | Throttling verileri neden veritabanına yazılmıyor? | Throttling kısa süreli (saniye/dakika) hız kontrolü sağlar ve yüksek performans gerektirir. Veritabanı yazma işlemi her istek için 5-20ms gecikme ekler, bu da throttling’in amacını bozar. Cache-only yaklaşım 1ms’den az gecikme ile çalışır. Veriler geçicidir ve sistem yeniden başlatıldığında sıfırlanır, bu kısa vadeli limitler için kabul edilebilir bir durumdur. Uzun vadeli kullanım takibi gerekiyorsa API Based Quota politikası kullanılmalıdır. |
| Teknik | Sistem yeniden başlatıldığında throttling sayaçları ne olur? | Throttling sadece cache kullandığı için sistem yeniden başlatıldığında veya cache temizlendiğinde tüm sayaçlar sıfırlanır. Bu tasarım gereğidir ve kısa süreli hız kontrolü için sorun oluşturmaz. Pencere süreleri zaten kısa (saniye/dakika) olduğu için kullanıcı deneyimini etkilemez. Kalıcı sayaç tutulması gerekiyorsa Kota politikası kullanılmalıdır. |
| Kullanım | Saat veya gün bazlı throttling yapabilir miyim? | Teknik olarak mümkün olsa da önerilmez. Throttling kısa süreli hız kontrolü (saniye/dakika) için tasarlanmıştır. Saat veya gün bazlı kontrole ihtiyacınız varsa API Based Quota politikasını kullanın. Quota politikası veritabanı desteği ile uzun vadeli limitleri daha güvenilir şekilde yönetir ve faturalama için gerekli kalıcılığı sağlar. |
| Teknik | SLIDING ve FIXED window arasındaki fark nedir? | SLIDING: Her istek anında geriye doğru pencere açar (son 60 saniye). Daha hassas kontrol ama daha fazla cache okuması. FIXED: Belirli zaman dilimlerinde sıfırlanır (her dakika başı). Daha performanslı ama burst’lere daha az duyarlı. |
| Kullanım | Rate limit header’larını göstermezsem ne olur? | Politika normal çalışır ancak client’lar kalan kotalarını göremez. Bu durumda kullanıcılar limit aşımını sadece 429 hatası aldıklarında anlar. Header’lar aktifse client’lar proaktif olarak request rate’lerini ayarlayabilir ve daha iyi kullanıcı deneyimi sağlanır. |
| Kullanım | Kullanıcı limitini aştığında ne olur? | HTTP 429 (Too Many Requests) hatası dönülür ve istek işlenmez. Rate limit header’ları aktifse response’da X-RateLimit-Reset bilgisi ile ne zaman tekrar deneyebileceği belirtilir. Özel hata mesajı tanımlanmışsa o mesaj gösterilir. |