Rate Limit ve Throttling
Rate limit ve throttling genellikle birbirinin yerine kullanılır ve her ikisi de API’ye gelen isteklerin hızını kontrol etme sürecine atıfta bulunur. Zaman Ölçeği: Genellikle saniye veya dakika cinsinden ölçülür. Örnekler:- Saniyede 100 istek
- Dakikada 1000 istek
- Ani trafik artışlarına karşı API’leri korumak
- Kısa zaman dilimlerinde birden fazla müşteri arasında adil kullanım sağlamak
- Kötüye kullanım veya DoS saldırılarını önlemek
Kota Yönetimi
Kota yönetimi, benzer amaçlarla çalışsa da, farklı bir ölçek ve hedefle çalışır. Zaman Ölçeği: Genellikle saat, gün veya ay olarak ölçülür. Örnekler:- Günde 10.000 istek
- Aylık 1.000.000 istek
- Cache: Gerçek zamanlı kota kontrolleri için birincil kaynak, her API çağrısı ile eşzamanlı olarak güncellenir.
- Veritabanı: İkincil, kalıcı depolama için veri tabanı kullanılır. API yanıt süresini azaltmak için asenkron olarak güncellenir, sistem yeniden başlatıldığında veya önbellek hatası durumunda veri kalıcılığı sağlar.
- İş düzeyinde API kullanım limitlerini zorunlu kılmak
- API tüketimi için faturalandırma ve muhasebe
- Uzun vadeli kullanım analizi ve planlaması
Throttling ve Kota Yönetimi İş Akışı
API kullanım kotalarını izlemek ve yönetmek için çok katmanlı bir yaklaşım kullanır. Bu sistem dört temel bileşen üzerinden çalışır: Client (İstemci), API Gateway, Distributed Cache (Dağıtık Önbellek) ve Database (Veritabanı). İşlem akışı şu şekilde gerçekleşir:- İlk İstek Kontrolü: Client’tan gelen her API isteği öncelikle API Gateway üzerinden geçer. Gateway, isteğin kotaya uygunluğunu kontrol etmek için hızlı bir şekilde Distributed Cache’e başvurur.
- Önbellek Katmanı: Distributed Cache, kota bilgilerini yüksek performanslı ve düşük gecikmeli bir şekilde tutar. Bu katman, sistemin hızlı yanıt vermesini sağlayan kritik bir bileşendir. Cache’den gelen güncel kota durumu, API Gateway tarafından değerlendirilir.
-
Karar Mekanizması: API Gateway, cache’den aldığı bilgiler doğrultusunda iki farklı yol izler:
- Başarılı Senaryo: Eğer kota limiti aşılmamışsa, istek işlenir ve client’a başarılı yanıt döner. Ardından, kota sayacı güncellenir.
- Başarısız Senaryo: Kota aşılmışsa, istek reddedilir ve client’a uygun bir hata mesajı gönderilir.
-
Veri Senkronizasyonu: Başarılı işlemlerde, kota bilgileri iki aşamada güncellenir:
- Öncelikle Distributed Cache hızlıca güncellenir (senkron)
- Ardından veritabanı güncellemesi asenkron olarak gerçekleştirilir
- Dayanıklılık ve Tutarlılık: Veritabanı, uzun vadeli kota takibi ve sistem yeniden başlatmaları durumunda veri sürekliliğini sağlar. Asenkron güncelleme yaklaşımı, API performansını etkilemeden veri dayanıklılığını garanti eder.
Kritik “Interval Window Type” Parametresi
Hem throttling hem de kota yönetiminin iş mantığının merkezindeInterval Window Type parametresi bulunur.
Bu parametre, isteklerin sayıldığı zaman penceresinin nasıl yönetileceğini ve güncelleneceğini belirler.
Olası Değerler
- Sabit Pencere
- Kayan Pencere
Sabit Pencere
Sabit Pencere yaklaşımında, zaman sabit, çakışmayan periyotlara bölünür. Davranış:- Belirli bir periyot içindeki tüm istekler birlikte sayılır.
- Sayaç, her yeni periyot başladığında sıfırlanır.
- Önbellek girdisinin TTL (Yaşam Süresi), mevcut periyottaki kalan süre olarak ayarlanır.
- Eğer periyot 1 dakika olarak ayarlanmışsa ve 12:00:00’da başlıyorsa:
- 12:00:00 ile 12:00:59 arasındaki istekler aynı pencerede sayılır.
- 12:01:00’da yeni bir pencere başlar ve sayaç sıfırlanır.
Kayan Pencere
Kayan Pencere yaklaşımında, her istek kendi zaman penceresini başlatır. Davranış:- Pencere, her yeni istekle birlikte “kayar”.
- Geçmiş periyot süresindeki tüm istekleri sayar ve sürekli günceller.
- Önbellek girdisinin TTL değeri her zaman tam periyot uzunluğu olarak ayarlanır.
- Eğer periyot 1 dakika olarak ayarlanmışsa:
- 12:00:30’daki bir istek, 11:59:30 ile 12:00:30 arasındaki tüm istekleri sayar.
- 12:00:45’teki bir istek, 11:59:45 ile 12:00:45 arasındaki tüm istekleri sayar.
Daha Uzun Zaman Aralıklarının Yönetimi
Özellikle kota yönetimi için daha uzun zaman aralıklarıyla çalışırken, sabit pencerelerin hesaplanması daha karmaşık hale gelir. İşte farklı senaryolar için nasıl yönetileceği: Bir Günden Daha Kısa Aralıklar İçin (ör. 15 dakika, 12 saat) Formül: Pencere Başlangıcı = Gün Başlangıcı + (Geçen Periyotlar * Periyot Süresi) Örnek: 15 dakikalık bir periyot için:- Mevcut zaman: 14:37
- Hesaplama:
- Gün Başlangıcı: 00.00
- Geçen 15 dakikalık periyotlar: 58
- Pencere başlangıcı: 14:30
- Bu istek, 14:30 - 14:44:59 penceresine aittir.
- Mevcut tarih: 2023-10-15
- Hesaplama:
- Unix epoch’tan beri geçen günler: 19,645
- Geçen 3 günlük aralıklar: 6,548 (19,645 / 3, aşağıya yuvarlanmış)
- Pencere başlangıcı: 2023-10-13 00:00:00
- Bu istek 2023-10-13 00:00:00 - 2023-10-15 23:59:59 aralığına aittir.
Not: Zaman dilimi değerini gün geçişlerini yönetmek için ayarlamaya dikkat edin!
Dinamik Anahtar Üretimi ile Esnek Sınırlamalar
Rate limit, throttling ve kota uygulamamızdaki önemli bir özellik, gelen isteğin çeşitli yönlerine dayalı olarak kısıtlama anahtarlarını dinamik olarak üretme yeteneğidir. Bu yaklaşım, karmaşık kod değişikliklerine ihtiyaç duymadan API kullanımını daha ayrıntılı ve esnek bir şekilde kontrol etmeyi sağlar.
İşte mevcut sistemimizde bunun nasıl gerçekleştirildiğine dair bir genel bakış:
-
Esnek Anahtar Bileşenleri: Sistem, sınırlama anahtarlarının herhangi bir kombinasyonu kullanılarak oluşturulmasına izin verir:
- Kimlik bilgileri (örneğin, kullanıcı kimliği, API anahtarı)
- İstek meta verileri (örneğin, IP adresi, istek başlıkları)
- İstek yükünden içerik
-
Dinamik Anahtar Oluşturma:
- Sistem, her istekte belirtilen bileşenleri dinamik olarak okur ve anahtar oluşturur.
- Bu okuma, yapılandırmada belirlenen önceden tanımlı yollar veya kalıplara dayanır.
-
Anahtar Birleştirme:
- Çıkarılan bileşenler, sınırlama anahtarını oluşturmak için tek bir dizeye birleştirilir.
- Anahtar içindeki farklı bileşenleri ayırmak için tutarlı bir ayırıcı (örneğin, ”-”) kullanılır.
-
Senaryo Tabanlı Anahtarlar: Bu yaklaşım, çeşitli sınırlama senaryolarını mümkün kılar:
- Kullanıcı başına sınırlamalar: Anahtar olarak kullanıcı kimliğini kullanma
- Uç nokta başına sınırlamalar: API uç noktasının kimliğini kullanıcı kimliğiyle birleştirme
- İçeriğe dayalı sınırlamalar: Anahtar içinde isteğin yükünden belirli alanları dahil etme
-
Ölçeklenebilirlik ve Performans:
- Anahtar üretim süreci hafif ve hızlı olacak şekilde tasarlanmıştır.
- İstek işleme zamanına minimal etki sağlamak için karmaşık hesaplamalardan kaçınılır.
-
Güvenlik Hususları:
- Sistem, üretilen anahtarlarda hassas bilgilerin ifşa edilmemesini sağlar.
-
Hizmetler Arasında Tutarlılık:
- Bu anahtar üretim mantığı, tüm API uç noktalarında tutarlı bir şekilde uygulanır.
- Genellikle, tüm uç noktaların faydalanabileceği merkezi bir hizmet veya yardımcı program olarak uygulanır.

