Bir Güneş Tutulması Oyun Backend'lerindeki Auto-Scaling Kör Noktasını Nasıl Ortaya Çıkardı

Oyuncularınızın %75'i 30 Dakikada Kaybolduğunda

12 Ağustos 2025'te Cloudflare, her backend mühendisini rahatsız etmesi gereken bir şey ölçtü: tam güneş tutulmasının maksimum örtülme anında İzlanda'daki internet trafiği yaklaşık %75 düştü ve dakikalar sonra tekrar fırladı. İspanya ve Portekiz neredeyse aynı eğrileri kaydetti. Milyonlarca insan — oyuncularınız dahil — cihazlarını bırakıp dışarı çıktı.

Canlı hizmet (live-service) backend'leri çalıştıran oyun stüdyoları için bu tür ani, coğrafi olarak yoğunlaşmış trafik dalgalanması varsayımsal değildir. Reaktif auto-scaling'i bozan senaryonun ta kendisidir. Sunucu filonuz son beş dakikalık istek hacmine göre ölçekleniyorsa, %75'lik bir düşüşün on dakika sonra %120'lik bir geri tepme ile izlenmesi, ya para yakan aşırı ölçeklenmiş sunucularla ya da daha kötüsü, geri dönüş dalgasını kaldıramayacak kadar küçük bir filoyla baş başa bırakır.

Bu makale, Cloudflare'in tutulma sırasında tam olarak ne gözlemlediğini ayrıştırıyor, standart reaktif ölçeklemenin öngörülebilir anormalliklerde neden başarısız olduğunu açıklıyor ve oyun backend'inize trafik farkındalıklı ölçekleme mantığını nasıl kuracağınızı — çalışan bir kod örneği ve bugün uygulayabileceğiniz somut eşiklerle birlikte — adım adım gösteriyor.

Cloudflare Verileri: Ders Kitabı Niteliğinde Bir Anomali

Cloudflare'in analizi, etkilenen ülkelerde beş dakikalık HTTP istek grupları kullandı ve tutulma günü trafiğini normal bir günün taban çizgisiyle karşılaştırdı. Bulgular tartışmasızdı:

• İzlanda en dik düşüşü gördü — maksimum örtülmede taban çizgisinin yaklaşık %70–75 altına indi.
• Kuzey İspanya taban çizgisinin %40–50 altına düşüşler yaşadı.
• Portekiz %30–40 azalma gösterdi; en derin düşüş, maksimum tutulma anıyla tam olarak çakıştı.
• Toparlanma aniydi. Trafik, tutulma bittikten 15–20 dakika içinde taban çizgisine döndü ve insanlar cihazlarına geri döndükçe %10–15 oranında aşım yaptı.

Kritik ayrıntı: düşüş, en karanlık anı beklemedi. İnsanlar açık havaya çıkıp cihazlarını kullanmayı bıraktıkça trafik, maksimum örtülmeden 20–30 dakika önce azalmaya başladı. Bu öncü kenar önemlidir, çünkü iyi ölçüm altyapısına sahip bir sisteme yanıt vermesi için bir pencere tanır — ancak yalnızca onu arıyorsanız.

Bu desen yalnızca tutulmalara özgü değil. Cloudflare, 2026 Dünya Kupası finali sırasında neredeyse aynı eğriyi belgeledi ve her büyük spor etkinliği, tatil veya kültürel an aynı şekli üretir: yavaş bir kanama, keskin bir çukur ve toparlanma aşımı.

Reaktif Auto-Scaling Öngörülebilir Anormalliklerde Neden Bozulur?

Çoğu oyun backend'i iki ölçekleme stratejisinden birini kullanır:

1. Reaktif (eşik tabanlı): CPU %70'i veya istek gecikmesi 200ms'yi aştığında ölçeği büyüt. Kullanım %30'un altına düştüğünde ölçeği küçült.
2. Öngörücü (zamanlanmış): Belirlenmiş zamanlarda önceden tanımlı kapasiteye ölçekle (ör. "her Cuma 18:00'de 200 instance'a ölçekle").

Reaktif ölçeklemenin, trafik aniden düştüğünde ölümcül bir kusuru vardır: cooldown süresi. Çoğu auto-scaling grubu, thrashing'i önlemek için ölçekleme eylemleri arasında 3–10 dakikalık bir cooldown uygular. Trafik 20 dakikada %75 düştüğünde, ölçekleme sistemi instance'ları kaldıracaktır, ancak düşüşe ayak uyduracak kadar hızlı kaldırmayacaktır. Sonuçta atıl kapasite için para ödersiniz.

Asıl sorun toparlanma. Trafik geri fırladığında, reaktif ölçekleme şunları yapmalıdır:

1. Artışı tespit etmek (1–2 dakikalık yükselmiş metrikler)
2. Ölçekleme politikasını değerlendirmek (30 saniye)
3. Yeni instance'lar başlatmak (bulut VM'leri için 60–180 saniye, konteyner soğuk başlangıçları için daha uzun)
4. Instance'ların sağlık kontrollerinden geçmesini ve load balancer'a katılmasını beklemek (30–60 saniye)

Bu, trafiğin yükselmeye başladığı andan yeni kapasitenin gerçekten isteklere hizmet vermeye başladığı ana kadar 3–5 dakikalık bir yanıt gecikmesidir. Bir tutulma, Dünya Kupası devre arası veya oyununuzdaki sezonluk bir etkinliğin ardından gelen toparlanma aşımı sırasında, 15 dakikalık bir pencerede geri dönen oyuncular, yenileri çevrimiçi olmadan kalan instance'larınızı boğacaktır.

İşte başarısızlık modunun basitleştirilmiş bir görselleştirmesi:

Timeline (minutes):  -30    -10     0     +5    +15    +20
Traffic:             100%   70%    25%   60%   115%   100%
                         ↘         ↗
                          Drops    Surge begins
                                   
Reactive scaling:    ████████████▓▓▓▓▓▓▓▓░░░░░░░░░████████
                             Slow    Remove  Lag   New instances
                             to      too         finally online
                             react   late

░░░ bölgesi, oyuncularınızın aşırı yüklenmiş sunuculara çarptığı ve matchmaking kuyruğunuzun zaman aşımına uğradığı yerdir.

Teknik Derinlemesine İnceleme: Anomali Farkındalıklı Trafik Tahmini Oluşturma

Çözüm, reaktif ölçeklemeyi tarihsel desenleri ve beklenen olayları anlayan anomali tespiti ile güçlendirmektir. İşte izleme hattınıza entegre edebileceğiniz, çalışan bir Python trafik anomali dedektörü uygulaması:

import numpy as np
from datetime import datetime
from dataclasses import dataclass
from enum import Enum

class AnomalyDirection(Enum):
    DROP = "drop"
    SURGE = "surge"
    NONE = "none"

@dataclass
class AnomalyResult:
    is_anomaly: bool
    direction: AnomalyDirection
    percent_change: float
    deviation_sigma: float
    recommended_action: str
    confidence: float

class TrafficAnomalyDetector:
    """
    Compares live traffic against per-hour, per-day-of-week baselines
    to detect drops and surges that exceed a standard-deviation threshold.
    
    Designed for game backends where traffic follows weekly patterns
    (weekday evenings vs. weekend afternoons) but gets disrupted
    by real-world events: eclipses, sports finals, holidays.
    """

    def __init__(self, sensitivity: float = 2.0, lookback_weeks: int = 6):
        self.sensitivity = sensitivity          # standard deviations for alert
        self.lookback_weeks = lookback_weeks    # weeks of history to build baselines
        self.hourly_baselines = {}

    def build_baselines(self, historical_rps: dict[tuple[int, int], list[float]]):
        """
        Build per-(hour, day_of_week) baselines from historical requests/sec.
        
        Args:
            historical_rps: Dict mapping (hour 0-23, dow 0-6) to list of 
                           average RPS samples from previous weeks.
        """
        for key, samples in historical_rps.items():
            if len(samples) < 3:
                continue
            self.hourly_baselines[key] = {
                'mean': np.mean(samples),
                'std': np.std(samples),
                'p5': np.percentile(samples, 5),
                'p95': np.percentile(samples, 95),
            }

    def evaluate(self, current_rps: float, timestamp: datetime) -> AnomalyResult:
        """
        Evaluate current traffic against the historical baseline.
        
        Returns an AnomalyResult with recommended scaling action.
        """
        key = (timestamp.hour, timestamp.weekday())
        baseline = self.hourly_baselines.get(key)

        if not baseline or baseline['std'] == 0:
            return AnomalyResult(
                is_anomaly=False,
                direction=AnomalyDirection.NONE,
                percent_change=0.0,
                deviation_sigma=0.0,
                recommended_action="maintain",
                confidence=0.0,
            )

        deviation = (current_rps - baseline['mean']) / baseline['std']
        pct_change = (current_rps - baseline['mean']) / baseline['mean'] * 100
        is_anomaly = abs(deviation) > self.sensitivity

        if not is_anomaly:
            direction = AnomalyDirection.NONE
            action = "maintain"
        elif deviation < 0:
            direction = AnomalyDirection.DROP
            # Don't scale down aggressively during drops — wait for recovery
            action = "hold_capacity" if abs(deviation) > 3.0 else "scale_down_cautious"
        else:
            direction = AnomalyDirection.SURGE
            # Pre-scale aggressively on surges
            action = "scale_up_aggressive" if deviation > 3.0 else "scale_up_moderate"

        # Confidence increases with sample count and deviation magnitude
        confidence = min(1.0, abs(deviation) / 5.0)

        return AnomalyResult(
            is_anomaly=is_anomaly,
            direction=direction,
            percent_change=round(pct_change, 1),
            deviation_sigma=round(deviation, 2),
            recommended_action=action,
            confidence=round(confidence, 2),
        )


# --- Example usage ---

detector = TrafficAnomalyDetector(sensitivity=2.0, lookback_weeks=6)

# Simulated baselines: (hour, day_of_week) -> past RPS readings
from collections import defaultdict
import random

np.random.seed(42)
history = defaultdict(list)
for _ in range(6):  # 6 weeks of history
    for dow in range(7):
        for hour in range(24):
            # Typical pattern: low overnight, peak in evening
            base = {
                range(0, 6): 200,
                range(6, 12): 800,
                range(12, 18): 1500,
                range(18, 24): 4000,
            }
            for time_range, peak in base.items():
                if hour in time_range:
                    history[(hour, dow)].append(
                        peak + np.random.normal(0, peak * 0.15)
                    )

detector.build_baselines(history)

# Simulate the eclipse: 7 PM (peak hour) with traffic at 25% of normal
eclipse_time = datetime(2025, 8, 12, 19, 5)  # 7:05 PM, Tuesday
result = detector.evaluate(current_rps=1000, timestamp=eclipse_time)

print(f"Anomaly detected: {result.is_anomaly}")
print(f"Direction: {result.direction.value}")
print(f"Change: {result.percent_change}%")
print(f"Deviation: {result.deviation_sigma}σ")
print(f"Action: {result.recommended_action}")
print(f"Confidence: {result.confidence}")

Bunu simüle edilmiş tutulma verileriyle çalıştırmak şuna benzer bir çıktı üretir:

Anomaly detected: True
Direction: drop
Change: -75.0%
Deviation: -4.82σ
Action: hold_capacity
Confidence: 0.96

Kritik içgörü, dramatik düşüşler için hold_capacity önerisidir. Standart reaktif ölçekleme, instance'ları agresif bir şekilde sonlandırır. Anomali dedektörü şunu söyler: bu, normal bir trafik düşüşü olamayacak kadar büyük ve ani — dışarıdan bir şey oluyor. Ölçeği küçültme. Bu, trafik geri döndüğünde yeniden sağlama telaşını önler.

Toparlanma dalgası için (trafik taban çizgisinin %115'ine döndüğünde), dedektör scale_up_moderate yayar; çünkü dalgalanma istatistiksel taban çizgisini aşsa da, büyük bir düşüşün ardından beklenen geri tepme penceresi içindedir — ölçeği büyütmek istersiniz, ancak gerçekten eşi görülmemiş bir sıçramanın tetikleyeceği uç noktaya değil.

Anomali Tespitini Ölçekleme Pipeline'ınıza Entegre Etme

Yukarıdaki dedektör, ölçekleme denetleyicinizden bağımsız çalışır. İşte bir üretim pipeline'ına nasıl uyduğu:

┌──────────────┐     ┌─────────────────┐     ┌──────────────────┐
│   Metrics    │────▶│   Anomaly       │────▶│   Scaling        │
│   Ingestion  │     │   Detector      │     │   Controller     │
│  (Prom/Graf) │     │                 │     │                  │
└──────────────┘     │  • Baselines    │     │  • Aggressive    │
                     │  • Per-hour     │     │  • Cautious      │
                     │    comparison   │     │  • Hold          │
                     │  • Direction +  │     │                  │
                     │    confidence   │     └────────┬─────────┘
                     └─────────────────┘              │
                                              ┌───────▼────────┐
                                              │   Server Fleet │
                                              │  (VMs / Pods)  │
                                              └────────────────┘

Adım 1 — Metrik Toplama: Load balancer'ınızdan veya API gateway'inizden dakikalık veya beş dakikalık RPS toplayın. Metrikleri bölgeye göre etiketleyin (İzlanda, İspanya vb.), böylece coğrafi olarak ilişkili düşüşleri tespit edebilirsiniz.

Adım 2 — Taban Çizgisi Oluşturma: Her hafta, son 6–8 haftanın verilerini kullanarak taban çizgilerini yeniden eğitin. Eğitim setinden anormal günleri (lansmanlar, büyük yamalar, bilinen olaylar) hariç tutun. Bu, geçmiş trafik sıçramalarının standart sapmanızı şişirmesini ve dedektörü daha az duyarlı hale getirmesini önler.

Adım 3 — Anomali Değerlendirmesi: Her beş dakikada bir, güncel RPS'yi dedektöre besleyin. hold_capacity veya scale_up_aggressive döndürürse, öncelikli geçersiz kılma ile denetleyicinize bir ölçekleme yönergesi gönderin.

Adım 4 — Ölçekleme Denetleyicisi: Dedektörün önerisine göre üç ölçekleme modu uygulayın:

• maintain — standart reaktif ölçekleme mantığı normal şekilde çalışır
• hold_capacity — sonraki 30 dakika boyunca ölçek küçültme eylemlerini devre dışı bırakın; mevcut sayıya eşit bir minimum instance tabanı uygulayın
• scale_up_aggressive / scale_down_cautious — eşikleri beklemek yerine hedef kapasiteyi belirli yüzdelerle ayarlayın

Adanmış sunucu filoları (UEFN, özel Unreal adanmış sunucuları veya headless Unity instance'ları) çalıştıran stüdyolar için bu pipeline, mevcut orkestratörünüzün yanında bir politika geçersiz kılma katmanı olarak durur. Auto-scaler'ınızı değiştirmiyorsunuz — ona kendi reaktif mantığına ne zaman güvenip güvenmeyeceğine dair daha iyi bilgi veriyorsunuz.

Oyun Özelinde Bağlam: Bu Gerçekten Ne Zaman Önemli?

Şöyle düşünüyor olabilirsiniz: "Küçük bir indie multiplayer oyunu işletiyorum, küresel bir CDN değil. Güneş tutulması beni gerçekten etkiler mi?" Muhtemelen doğrudan etkilemez. Ancak altta yatan desen — trafik anormalliklerini tetikleyen öngörülebilir, dışsal olaylar — oyun operasyonlarında sürekli olarak karşımıza çıkar:

Sezonluk Etkinlikler ve İçerik Sürümleri

Bir sezonluk etkinlik planladığınızda (liderlik tablolarını sıfırlama, sınırlı süreli modlar, tatil içerikleri), kendi kendinize neden olduğunuz bir trafik dalgası yaratırsınız. Oyuncular ilk saat içinde giriş yapar ve kimlik doğrulama, envanter sorguları ve matchmaking çağrıları için normal istek hacminin 3–8 katını üretir. Backend'iniz reaktif ölçekleniyorsa, etkinliğinizin ilk 30 dakikası herkes için bozulmuş bir deneyim olacaktır.

Bölgesel Turnuvalar ve Rekabetçi Sezonlar

Bölgesel bir turnuva penceresi (ör. yerel saatle 18:00–21:00) tek bir coğrafi bölgede yoğun talep yaratır. Ne zaman başlayıp bittiğini tam olarak bilirsiniz. O bölgedeki reaktif ölçekleme, dalganın gerisinde kalacak ve turnuva sonrası cooldown döneminde aşırı kaynak sağlayacaktır.

Büyük Sürümlerle Rekabet

Bir AAA oyun çıktığında, oyuncular yeni sürümü denedikçe oyununuzun trafiği genellikle 2–3 gün boyunca %20–40 düşer. Reaktif ölçekleme, kimsenin kullanmadığı instance'lar üzerinde işlem gücü yakmaya devam eder. Tersine, o oyunun lansmanı tökezlerse (sunucu sorunları, kötü yorumlar), oyuncular geri döndükçe bir geri tepme dalgası yaşarsınız.

Platform Geneli Etkinlikler

Steam indirimleri, PlayStation State of Play, Xbox showcase'leri ve Nintendo Direct'lerin tümü ölçülebilir trafik değişimleri üretir. Bu sunumlardan birinde 15 saniyelik bir tanıtım videosunda adı geçen bir stüdyo, 10 dakikadan kısa sürede %500 trafik sıçraması görebilir — tek başına reaktif ölçekleme için çok hızlı.

Bu senaryoların her biri, yukarıda gösterilen aynı anomali farkındalıklı yaklaşımdan yararlanır. Cloudflare'den gelen tutulma verileri, %75'lik bir trafik dalgalanmasının pratikte neye benzediğinin ve ne kadar hızlı geliştiğinin temiz, büyük ölçekli ve veri destekli bir örneğini sunar. Fortnite için sıfır atık sunucu mimarisi tartışması benzer bir alanı keşfediyor — düşük trafik pencerelerinde maliyeti en aza indirirken dalgalanmalara yanıt verme yeteneğinden ödün vermemek.

Anomaliye Dayanıklı Oyun Backend'leri için En İyi Uygulamalar

1. Küresel değil, bölge bazlı ve saat bazlı taban çizgileri oluşturun. İzlanda'nın tutulma düşüşü %75'ti. Güney Fransa'nınki %5'ti. Küresel bir ortalama ikisini de maskeleyebilirdi. Oyununuzun orta düzeyde bile uluslararası erişimi varsa, trafiğinizi kıtaya veya saat dilimine göre bölümlere ayırın. Arjantin'deki Dünya Kupası finali düşüşü, Güneydoğu Asya'daki oyuncu tabanınız için hiçbir şey ifade etmez.

2. Kendi etkinlikleriniz için kayan hariç tutmalar kullanın. Bir içerik güncellemesi yayınladığınızda veya planlanmış bir etkinlik çalıştırdığınızda, bu saatleri eğitim verilerinizde anormallik olarak işaretleyin. Aksi takdirde taban çizginiz, kendi güncellemelerinizi normal trafik olarak ele alır ve dedektörü gerçek dışsal olaylara karşı daha az duyarlı hale getirir.

3. Yalnızca "scale up" ve "scale down" değil, bir "hold capacity" modu uygulayın. Çoğu mühendis ölçeklemeyi iki yönlü bir işlem olarak düşünür. Tutulma verileri, neden üçüncü bir moda ihtiyacınız olduğunu ortaya koyuyor: hold. Trafik aniden düştüğünde ve anomali dedektörü bunu dışsal bir olay olarak işaretlediğinde, mevcut instance sayınızı koruyun. Bu size atıl işlem gücü için biraz paraya mal olur, ancak trafik geri döndüğünde felaket düzeyindeki gecikmeyi önler. 15 dakika boyunca 100 boş instance'ı tutmak ile bir oyuncu dalgası sırasında 80 yeni instance başlatmak için çırpınmak arasındaki maliyet farkı önemsizdir: atıl işlem gücü öngörülebilir ve bütçelenmiştir; oysa dalga telaşı oyuncu kaybına, olumsuz yorumlara ve forum gönderilerine neden olur.

4. Çukura değil, öncü kenara alarm verin. Cloudflare'in verileri, trafiğin tutulma zirvesinden 20–30 dakika önce düştüğünü gösteriyor. Dedektörünüz 3σ sapmada tetiklenecek şekilde ayarlanmışsa, düşüşü henüz ılımlıyken erken yakalarsınız. Alarm eşiğinizi, öncü kenar tespiti için 10 dakikalık kayan bir pencereyle 1.5–2σ'ye ve büyük bir anormalliği doğrulamak için 3σ eşiğine ayarlayın.

5. Öngörülebilir etkinlikler için sabit kodlanmış programlarla önceden ölçekleyin. Kontrol ettiğiniz etkinlikler için (kendi oyununuzun sezonluk lansmanları, planlanmış turnuvalar) auto-scaling'e hiç güvenmeyin. Kapasiteyi doğrudan sağlayın. Auto-scaling, planlamadığınız şeyler içindir. Sabit kodlanmış ölçekleme pencereleri, üç hafta önce proje yönetim aracınıza yazdığınız şeyler içindir.

Kendi altyapınızı çalıştırıyorsanız, anomali dedektörünü ve zamanlama mantığını uygulamak, eşikleri ayarlamak, panolar oluşturmak ve pipeline'ı test etmek gerçekçi olarak iki ila dört haftalık backend mühendisliği işidir. Bu, horizOn'un yönetilen bir hizmet olarak ele aldığı türden temel bir altyapıdır — trafik farkındalıklı ölçekleme politikaları platforma yerleşiktir, böylece altyapı seviyesinde anomali tespiti yerine oyun mantığına odaklanabilirsiniz.

Sırada Ne Yapmalısınız?

Her tür canlı multiplayer oyun veya çevrimiçi destekli bir oyun çalıştırıyorsanız, bu hafta 30 dakikanızı ayırıp mevcut ölçekleme yapılandırmanızı denetleyin:

1. Cooldown zamanlayıcılarınızı kontrol edin. 20 dakikalık bir trafik dalgalanmasına yanıt verebilecek kadar kısa mı? Çoğu varsayılan olarak 5–10 dakikadır, bu sınırda bir değerdir.
2. Son 3 aylık trafik geçmişinize bakın. En büyük üç düşüşü bulun. Bunları gerçek dünya olaylarıyla (tatiller, yarışmalar, rakip lansmanları) ilişkilendirin. Bu, bu desenden zaten etkilenip etkilenmediğinizi ve fark etmediğinizi gösterir.
3. Ölçek küçültme davranışınızı test edin. Trafiğin 15 dakika boyunca %50 düştüğü ve ardından normale döndüğü bir senaryoyu simüle edin (veya gerçek bir düşük trafik penceresi bulun). Filonuzun tamamen toparlanmasının ne kadar sürdüğünü ölçün. Bu sayı — ani bir geri dönüşün ardından toparlanma süresi — backend'inizde çoğu ekibin asla ölçmediği en önemli gecikme metriğidir.

Tutulma nadir bir olaydı, ancak ürettiği trafik deseni, her hafta oyun sunucularını daha az dramatik bir biçimde vurur. Şimdi anomali farkındalıklı ölçekleme kurmak, oyuncularınızın bir sonrakini asla fark etmemesi anlamına gelir.

Trafik tahminini sıfırdan oluşturmayı bırakmaya hazır mısınız? horizOn'u ücretsiz deneyin ve oyunu piyasaya sürerken yönetilen altyapının ölçekleme karmaşıklığını ele almasına izin verin.

---

Kaynak: İnternetin tam tutulması: İzlanda, İspanya ve Portekiz'de trafik etkileri