MCP Sunucularında Ölçekte Rate Limiting ve Kaynak Yönetişimi
MCP orchestration sunucuları için rate limiting ve kaynak yönetişimini anlatan bir üretim yazısı: tek bir tenant'ın burst trafiği ortak LLM token kotasını tüketip diğer herkesi aç bırakabiliyor. Yaygın limiter algoritmalarını karşılaştırıp Redis tabanlı state ve kotaya duyarlı refill hızı olan per-tenant token bucket çözümünde karar kılıyor.
Kilit noktalar
- Sistem çapında kesintinin nedeni ölçek değil, tenant trafiğinin amplifikasyonu: tek bir tenant dakikada 10 bin istek gönderip token kotasını yüzde 100'e çıkardı.
- Token bucket token ağırlıklı LLM trafiğine, leaky bucket sabit yüksek RPS'e uygun; yalnızca fixed window pencere sınırlarında thundering herd yaratıyor.
- tenant_id claim'i üzerinden RateLimitPartition ile per-tenant bölümleme, gürültülü istemcinin havuzu tüketmesini engelliyor; bedeli tenant başına limiter state.
- Dağıtık token bucket atomiklik ister; genellikle Redis Lua script'i ve saat kaymasını önlemek için senkronize saat gerekir.
- Bucket boşaldığında kuyruğa almak yerine retry-after başlığıyla HTTP 429 dönün ve kuyruk derinliğine sert bir üst sınır koyun.
- Worker'ları peak RPS'e göre değil, kuyruk derinliği ve CPU (yüzde 70 kullanım, 100'ün üzerinde kuyruk) metrikleriyle ölçekleyin.
MCP (Model Context Protocol) orchestration sunucularında tek bir tenant'ın trafiği tüm bölgeyi çökertebiliyor. Yazı token bucket, sliding window, fixed window ve leaky bucket algoritmalarını burst yumuşatma ile state maliyeti açısından karşılaştırıyor; gürültülü bir istemcinin diğerlerini aç bırakmasını engelleyen şeyin per-tenant bölümleme olduğunu savunuyor.
Somut reçete şöyle: ASP.NET Core'da AddRateLimiter ve JWT'den türetilen tenant anahtarıyla token bucket, node'lar arası atomiklik için Redis Lua script'i, Azure OpenAI kota kullanımı yüzde 80'i geçince düşürülen refill hızı ve CPU ile kuyruk uzunluğuna bakan Kubernetes autoscaling. Kuyruğa sessizce almak yerine HTTP 429 ve retry-after ile fail-fast öneriliyor.
Gerçek dünyada kullanımı
- Tek bir müşterinin batch job'unun tüm subscription'ın Azure OpenAI kotasını tüketebildiği çok kiracılı LLM orchestration API'si.
- Pazarlama duyurusu sonrası trafiği patlayan ve inference worker'lara ulaşmadan tenant başına sert bir üst sınır gereken bir chat ürünü.
- Peak GPU kapasitesine para ödemek yerine kuyruk derinliğine göre ölçeklenmesi gereken, Kubernetes üzerinde çalışan tool-calling servisi.
- Pahalı tool çağrılarının daha ucuz CPU-only havuza yönlendirildiği maliyet hassas vector search backend'i.
Neden önemli
Per-tenant limit ve paylaşılan limiter state olmadan gürültülü tek bir istemci tüm bölgenin token kotasını tüketebilir; trafik artışı kesintiye ve kontrolden çıkan bir faturaya dönüşür.