Rate Limit, Throttling ve Quota Management'a Kapsamlı Bir Bakış

API geliştirme ve yönetiminin dinamik dünyasında, gelen isteklerin akışını kontrol etmek sistem stabilitesini korumak, adil kullanımı sağlamak ve kötüye kullanımı önlemek için çok önemlidir.

Apinizer, gelişmiş rate limit, throttling ve quota management özellikleri sayesinde bu zorluklara kolay kullanışlı ve yüksek performanslı çözümler sunar.

Bu yazımızda, bu temel kavramları inceleyerek Apinizer'daki uygulamalarını anlatacağız.

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

Uygulama: Apinizer, ilgili kural hesaplamalarını yapabilmek sonuçlarını tutabilmek ve farklı sistemler arasında dağıtabilmek için Distributed Cache kullanır.

Veri Depolama: Sadece önbelleğe dayanır. Bu, verilerin geçici olduğu ve sistem yeniden başlatıldığında kaybolabileceği anlamına gelir; kısa vadeli sınırlar için bu kabul edilebilirdir.

Kullanım Alanları:

• 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

Uygulama: Hızlı erişim ve gerçek zamanlı güncellemeler için cache, kalıcı uzun vadeli depolama için veritabanı kombinasyonu kullanır.

Veri Depolama:

• 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.

Kullanım Alanları:

• İş 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:

1. İ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.

2. Ö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.

3. 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.

4. 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

5. 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.

Bu akış, yüksek performans ve veri tutarlılığı arasında optimal bir denge kurar. Cache kullanımı hızlı yanıt sürelerini sağlarken, veritabanı desteği veri kalıcılığını garanti eder. Asenkron veritabanı güncellemeleri ise sistem performansını korurken güvenilir bir kota takibi sunar.

Bu akışı özetleyen görsele aşağıda yer verilmiştir:

Kritik "Interval Window Type" Parametresi

Hem throttling hem de kota yönetiminin iş mantığının merkezinde Interval 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.

Örnek:

• 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.

Örnek:

• 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.

Bir Gün veya Daha Uzun Aralıklar İçin (ör. 3 gün)

Formül: Pencere Başlangıcı = Unix Epoch + (Geçen Periyotlar * Periyot Süresi)

Örnek: 3 günlük periyot için:

• 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.

Bu esnek anahtar üretim yaklaşımını uygulayarak, sistemimiz, kod değişikliklerine ihtiyaç duymadan çeşitli oran sınırlama ve sınırlama gereksinimlerine uyum sağlayabilir. Farklı türdeki işlemler için farklı sınırlamalar uygulamak, kullanıcı rolleri temelinde erişimi kontrol etmek veya karmaşık çok faktörlü sınırlama kurallarını uygulamak olsun, sistem, yalnızca yapılandırma değişiklikleri aracılığıyla bu ihtiyaçları karşılayabilir.

Bu düzeydeki esneklik, API kullanımını ince ayar yapma imkanı sağlar ve işletmelere adil kullanım politikaları uygulama, kötüye kullanımı önleme ve kaynak tahsisini etkili bir şekilde optimize etme imkanı tanır. Ayrıca, değişen iş ihtiyaçlarına veya gözlemlenen kullanım kalıplarına yanıt olarak sınırlama stratejilerini hızla ayarlama kabiliyeti sunar.

Sonuç

Etkili API trafik kontrolü, istek sınırlaması, throttling ve kota yönetimi aracılığıyla, sağlam, adil ve ölçeklenebilir API hizmetleri oluşturmak için esastır. Sabit ve kayan pencerelerin inceliklerini anlayarak, uygun zaman ölçekleri stratejileri uygulayarak ve en iyi uygulamaları takip ederek, API'lerinizin performanslı, korunaklı ve kârlı kalmasını sağlayabilirsiniz.

Unutmayın, istek sınırlama stratejileri ile Interval Window Type yapılandırması arasındaki seçim, özel kullanım durumunuza, trafik kalıplarınıza ve iş gereksinimlerinize dayanmalıdır. Bu parametrelerin düzenli olarak gözden geçirilmesi ve ayarlanması, API hizmetleriniz için koruma ve erişilebilirlik arasında optimal bir denge sağlamanıza yardımcı olacaktır.