Skip to main content

> api_ağ_geçidi_hız_sınırlama_ve_token_bucket_algoritmaları

API Ağ Geçidi Hız Sınırlama ve Token Bucket Algoritmaları

Yatay ölçeklenen API ağ geçitlerinde Token Bucket ve Kayan Pencere algoritmalarıyla, Redis kilit çekişmesi yaratmadan milisaniyenin altında dağıtık hız sınırlama nasıl uygulanır?

ÖZET VE TEKNİK CEVAP

Kota kontrollerini atomik Lua scriptleri ile merkezi Redis kümelerinde (veya toplu senkronize edilen yerel bellek kovalarda) çalıştırarak, anlık yük toleransını (burst) koruyup aşımlarda standart `RateLimit-*` başlıklarıyla HTTP 429 dönerek.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Hız sınırlama (Rate Limiting), alt sistemleri DoS saldırılarından, gürültülü komşulardan ve kontrolsüz veri çekmelerden korur. Token Bucket algoritması, maksimum kapasiteye (burst) sahip ve saniyede $r$ jetonla dolan bir kova tutar. Her istek 1 jeton tüketir; kova boşsa istek HTTP 429 ile reddedilir. Her kullanıcı için arka planda sürekli çalışan sayaçlar tutmak yerine, jetonlar istek anında dinamik hesaplanır: `jeton = min(kapasite, mevcut_jeton + (simdi - son_yenilenme) * dolum_hizi)`. Redis bu formülü tek bir atomik Lua scripti içinde 0.5 ms altında çalıştırarak yarış durumlarını (race condition) tamamen engeller.

2. Doğru Kullanım Senaryosu

Kenar API ağ geçitleri, genel geliştirici API'leri, ödeme bildirim uçları ve katı trafik şekillendirme gerektiren dahili mikroservis sınırları.

3. Prodüksiyon Arıza Modları

1) Merkezi Redis Çöküşü: Saniyede 50.000 istek alan ağ geçidinin tek bir Redis düğümüne yüklenip tüm sistemi kilitlemesi; 2) Sağlık Kontrolü Kısıtlama Krizi: Kubernetes pod sağlık kontrollerini (liveness probe) hız sınırından muaf tutmayı unutup tüm podların ölmesine yol açmak; 3) Yarış Durumu Kota Aşımı: Lua scripti yerine ayrı `GET` ve `SET` komutları çalıştırıp eşzamanlı isteklerde kotanın 10 kat aşılmasına izin vermek.

4. Teşhis ve Telemetri Sinyalleri

HTTP 429 Too Many Requests hata oranı dağılımı, Redis Lua scripti çalışma süresi (P99 gecikmesi), `RateLimit-Remaining` başlık doğruluğu ve ağ geçidinin jeton kontrolüne harcadığı CPU miktarı.

5. Önleme ve Mimari Bariyerler

Atomik Redis Lua scriptleri kullanın; olası Redis kesintilerinde sistemi ayakta tutmak için yerel bellek önbellekli ve asenkron senkronizasyonlu kova mimarisi kurun; iç sağlık kontrollerini muaf tutun ve mutlaka `Retry-After` başlığı dönün.

6. Mimari Ödünleşimler (Trade-offs)

Sistemin devasa trafik patlamalarında ayakta kalmasını sağlar ve zincirleme çökmeleri engeller; buna karşılık istek başına 0.5-2 ms ek gecikme ve Redis altyapı bağımlılığı getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Vaka 058: Hatalı bir müşteri scripti giriş API'sine saniyede 25.000 istek atarak arka plan veritabanı bağlantı havuzunu kilitledi. Envoy kenar ağ geçidine kurulan Token Bucket hız sınırlayıcı (dakikada 100 istek ve 20 anlık burst limiti), zararlı trafiğin %99.6'sını anında filtreleyerek gerçek kullanıcıları kesintiden kurtardı.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Token Bucket ile Leaky Bucket algoritmaları arasındaki temel fark nedir?

Token Bucket ortalama hızı korurken kova kapasitesi kadar anlık trafik patlamalarına (burst) izin verir; Leaky Bucket ise gelen yüke bakılmaksızın çıkış trafiğini kesinlikle sabit ve düz bir hızda tutar.
Q2

Dağıtık hız sınırlamada Redis Lua scripti çalıştırmak neden zorunludur?

Lua scriptleri Redis'in tek iş parçacıklı motorunda atomik olarak çalışır; böylece eşzamanlı ağ geçitleri arasında jeton kontrolü ile jeton düşme adımı arasındaki yarış durumlarını (race condition) engeller.
Q3

Bir API Ağ Geçidi istekleri kısıtlarken hangi standart HTTP başlıklarını dönmelidir?

`RateLimit-Limit` (izin verilen kota), `RateLimit-Remaining` (kalan jeton), `RateLimit-Reset` (yenilenmeye kalan saniye) ve 429 yanıtlarında `Retry-After`.

API Ağ Geçidi Hız Sınırlama ve Token Bucket Algoritmaları — Sıkça Sorulan Sorular

Kimliği doğrulanmamış genel uç noktalar nasıl hız sınırına tabi tutulur?

Güvenilmeyen vekilleri temizledikten sonra doğrulanan `X-Forwarded-For` üzerinden İstemci IP adresiyle veya tarayıcı parmak izi hash'leri ile sınırlandırarak.

Kayan Pencere Sayacı (Sliding Window Counter) algoritması nasıl çalışır?

Önceki zaman penceresinin istek sayısını kalan süre oranıyla çarparak mevcut pencereyle toplar; bu sayede sabit pencerelerin sınır çizgilerinde yaşanan iki katı ani yük patlamalarını engeller.

Eğer Redis hız sınırlayıcı kümesi tamamen çökerse gelen trafiğe ne yapılmalıdır?

Sistemi açık bırakın (Fail open). Kritik alarm verin, yerel bellek içi geçici kotalara dönün ve trafiğe izin verin; hız sınırlayıcı arızasının tüm şirketi durdurmasına izin vermeyin.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • Token Bucket algoritması, HTTP API'lerine uyarlanmadan önce telekomünikasyonda ağ paket yönlendirmesi için geliştirilmiştir.
  • Hız sınırlama; backend kaynak koruması, veritabanı bağlantı kararlılığı ve üçüncü taraf SaaS fatura kontrolü için ilk savunma hattıdır.

Yaygın Yanılgılar

  • Sabit Pencere (Fixed Window) sayaçlarının yeterli olduğunu sanmak; sabit pencereler, dakika sınırının hemen öncesi ve sonrasında 2 saniye içinde 200 isteğin geçmesine izin vererek sistemi boğar.

Karar Kılavuzu & Önceliklendirme

Kullanıcı API'lerinde doğal anlık yükleri karşılamak için Token Bucket; katı ücretlendirme kotalarında Kayan Pencere Sayacı kullanın; kontrolleri daima atomik Redis Lua ile çalıştırın.

Doğrulanmış Kaynaklar & Referanslar