10.000+ Eşzamanlı Kullanıcı: Kubernetes'te Trafik Dalgalarını Yönetmek

6 yıldır teknik sahibi olduğum multiplayer platform 10.000'in üzerinde eşzamanlı kullanıcıya hizmet veriyor. Bu trafik ne düz bir sinyal, ne de tahmin edilebilir bir grafik: akşam 8-11 arasında zirve, hafta sonları tepki, promosyon günlerinde 2x katlama, yeni özellik lansmanında belirsiz bir dalga.

"Sistem hep ayakta" derken aslında ifade ettiğim şey, "bu dalgaların hiçbirini dünyanın gördüğü kadar hissettirmiyor". Bu yazıda bu rahatlığı sağlayan Kubernetes setup'ının gerçek parçalarını anlatacağım.

CPU-only HPA, oyun backend'i için yeterli değil

Kubernetes'in default autoscaling'i CPU kullanımına bakar. Üzerine "80% CPU'ya gelince ölçekle" kuralı koyarsınız, gerisi tamam. Bu, tipik bir CRUD API için doğru bir model. Multiplayer oyun backend'i için değil.

Sebep: CPU, bizim tarafımızda en son ısınan şey. Bizim bottleneck'lerimiz şöyle sıralanır:

1. Concurrent oyun odası sayısı
2. WebSocket bağlantı sayısı
3. Redis Pub/Sub mesaj dağılımı
4. Veritabanı write throughput
5. ...
6. Nihayet CPU

CPU %80'e ulaştığında oda bekleme süreleri çoktan artmış, oyuncular şikayet etmiş, churn başlamış olur. CPU bize 3 dakika geç sinyal verir.

Çözüm: custom metrics HPA

Prometheus + prometheus-adapter kullanarak HPA'ya özel metrikler bağladık. Şu an:

• game_rooms_active — pod başına aktif oyun odası sayısı
• websocket_connections — aktif bağlantı
• redis_pubsub_queue_depth — Redis kuyruk derinliği (stabilite sinyali)

HPA ayarımız "pod başına 50 aktif oda"yı hedef alıyor. Oda sayısı 60'a çıktığında yeni pod açılıyor, 40'a düştüğünde pod azalıyor. CPU'nun hiçbir yerde olmadığı yerde trafik büyümesine hazırız.

Bu tek değişiklik "yavaşladık" tarzı şikayetleri yaklaşık %70 azalttı.

Pre-warm: reactivetoproactive

HPA sinyali alıp pod açması 30 saniye - 1 dakika sürer. Image pull, initialization, health check, sonra trafik almaya hazır olma. Bu süre büyük bir dalga başlangıcında uzun.

Çözüm: zaman tabanlı pre-scale. Bizim kullanıcı grafiğimiz öngörülebilir — akşam 7.30'da rampa başlıyor. Cronjob ile 7.25'te minimum replica sayısını 3'ten 8'e çekiyoruz. Rampa başladığında pod'lar hazır. HPA bundan sonrasını yönetiyor.

Kulağa "hack" gibi geliyor ama üretim mühendisliğinde işe yarayan her şey iyidir.

Pod priority + eviction davranışı

Bir oyun platformunda tüm pod'lar eşit değildir. Canlı oyun oturumunu tutan pod, arka plan istatistik hesaplayan pod'dan çok daha "kıymetli"dir.

Kubernetes'in PriorityClass özelliğini kullanıyoruz. Oyun pod'ları high priority, arka plan işler low. Node baskı altında kaldığında low priority pod'lar evict edilir, high priority korunur. Basit ama kritik.

Ayrıca: oyun pod'larında graceful shutdown süresi 60 saniye. Pod kapanırken önce yeni bağlantı almayı bırakır, var olan oturumları bitirir, sonra kapanır. Kullanıcı bir maçın ortasında düşmemiş oluyor.

"Soğuk başlangıç" ve JVM

Java/Spring tabanlı game server'lar Kubernetes'te özel bir durum: ilk 30 saniye JIT warm-up yapıyor, ilk trafiği alırken yavaş. HPA yeni pod açsa bile, o pod hemen iş görür hale gelmiyor.

Çözüm: readiness probe sadece port açık olduğunu değil, JVM warm up olduğunu da kontrol ediyor. Warm-up endpoint'i internal bir çağrıdan dönene kadar pod Kubernetes'e "ready" demiyor. Trafik girmiyor, HPA kuyruğu yönetiyor.

Bu, görünmez ama çok değerli bir katman. Olmayınca "pod açıldı, trafik bindi, yavaşladı, otomatik olarak pod artmış gibi geldi ama aslında kötü hizmet verdik" pattern'ine düşersiniz.

Peki bir trafik patlaması nasıl görünüyor?

Geçen ay bir promosyon günü vardı. Beklenen trafik %50, gerçekleşen %150. İlk 10 dakika:

1. Odalar doluyor — game_rooms_active metric yükseliyor
2. HPA tetikleniyor, yeni pod'lar açılıyor
3. Node'lar doluyor, cluster autoscaler yeni node'lar çekiyor
4. Redis Pub/Sub yükü artıyor — ayrı bir HPA bunu da ölçekliyor
5. DB write'ları artıyor — burada biz write-behind pattern kullanıyoruz, sistem anlık yükü absorbe ediyor

Toplam incident: sıfır. Zirve noktasında ekstra ~40 pod çalışıyordu, sonra trafik normalleşince otomatik azaldı. Kimse manuel müdahale etmedi. Bu iyi bir ölçekleme hikayesi.

Sonuç

Kubernetes'in autoscaling özelliklerini kullanmak önemli ama yeterli değil. Gerçek anahtar: sisteminizin neden bottleneck olduğunu bilmek ve ölçekleme kararlarını o sinyale bağlamak. CPU, çoğu production iş yükünün gerçek sinyali değil.

Bir sistem ne kadar uzun süre ayakta kalmışsa, o sistemde tek bir otomasyon kuralı değil, birçok birbirine bağlı otomasyon katmanı çalışıyordur. 10k+ CCU bir gecede kurulan şey değil — beş yılda katmanla katmanla inşa edilen şeydir.