Lab 03 / 09Yük dengeleme ve otomatik ölçekleme laboratuvarı
Yük Altında Durumsuz
Yapışkan oturumlu ve durumsuz MCP sunucularına yan yana trafik bas; sıcak noktaların, ölçeklemenin ve p95 gecikmenin nasıl ayrıştığını izle.
Sticky session
Stateful MCP · Mcp-Session-Id tek replica’ya sabit
- p95
- —
- Hata
- 0.0%
- Replica
- 3
- En sıcak
- 0%
0 yeniden gönderildi · 0 başarısız
Stateless MCP
2026-07-28 spec · her request’i her replica karşılar
- p95
- —
- Hata
- 0.0%
- Replica
- 3
- En sıcak
- 0%
0 yeniden gönderildi · 0 başarısız
Simülasyon · aynı request akışı iki tarafa da gidiyor · replica başına 100 req/s · 5 sn cold start · %60 ortalama CPU hedefleyen HPA tarzı autoscaler · sayılar modellenmiştir, ölçülmemiştir
Melih Kızmaz yaptı · tamamen tarayıcında çalışır
Burada ne görüyorsunuz
İki taraf da birebir aynı agent request akışını alıyor. Solda load balancer her agent session’ını, initialize çağrısını karşılayan replica’ya sabitliyor — 2026-07-28 revizyonu protokol seviyesindeki session’ları kaldırmadan önce stateful bir MCP server’ın ihtiyaç duyduğu kurulum bu. Sağda ise her request ihtiyacı olan her şeyi kendisi taşıyor, dolayısıyla sıradan bir round-robin balancer herhangi bir çağrıyı herhangi bir replica’ya gönderebiliyor. Agent’ların hepsi aynı derecede konuşkan değil: birkaç uzun ömürlü session çağrıların büyük kısmını üretiyor. Bu yüzden her replica eşit sayıda session tutsa bile sticky tarafta hot spot oluşuyor.
Scaling, cold start ve öldürülen replica’lar
Autoscaler bir Kubernetes HPA gibi davranıyor: ortalama CPU’ya bakıyor; bu değer, sticky replica’lardan biri alev alev yanarken bile sağlıklı görünebilir. Yeni replica’lar cold start’ı bitirdiğinde stateless taraf onları hemen kullanıyor; sticky taraf ise onlara sadece yenisession’ları yönlendiriyor, yani sıcak replica kuyruk biriktirmeye devam ediyor. Bir replica’yı öldürdüğünüzde solda ona sabitlenmiş bütün session’lar düşüyor; sağda ise client, spec’in istediği gibi in-flight request’leri yeni request ID’leriyle tekrar gönderiyor ve başka bir replica cevaplıyor.
Simülasyon ve ölçüm
Bu laboratuvardaki sayılar simülasyon. Ölçülmüş olanlar Melih Kızmaz’ın yazısında: lokal bir kind cluster’ında üç NestJS replica’sının önünde round-robin varken, ucuz bir tool için yatay ölçekleme latency’de hiçbir kazanç sağlamadı (600 req/s’te tek replica’da p95 14.2 ms, üç replica’da 16.2 ms). Asıl kazanç süreklilikti: sekiz pod crash’i boyunca tek bir intent bile kaybolmadı — ama tekrar gönderilen request’ler bedava değil; naif bir tool intent’lerin %1.37’sini çift faturaladı, bir idempotency key eklenince bu oran %0.05’e indi.