Wie eine Sonnenfinsternis den blinden Fleck beim Auto-Scaling in Game-Backends aufdeckte
Kurz und knapp
Erfahre, wie eine Sonnenfinsternis den Auto-Scaling-Blindflug in Game-Backends aufdeckt und wie du mit Anomalieerkennung skalierst.
Wenn 75 % deiner Spieler in 30 Minuten verschwinden
Am 12. August 2025 maß Cloudflare etwas, das jeden Backend-Entwickler unruhig werden lässt: Der Internet-Traffic in Island brach während der maximalen Verdunkelung der totalen Sonnenfinsternis um rund 75 % ein, um wenige Minuten später wieder anzusteigen. Spanien und Portugal verzeichneten nahezu identische Kurven. Millionen von Menschen – darunter auch deine Spieler – legten ihre Geräte beiseite und gingen nach draußen.
Für Spielestudios, die Live-Service-Backends betreiben, ist diese Art von plötzlichem, geografisch konzentriertem Traffic-Ausschlag keine hypothetische Bedrohung. Es ist genau das Szenario, das reaktives Auto-Scaling zum Scheitern bringt. Wenn dein Server-Fleet auf Basis der letzten fünf Minuten Request-Volumen skaliert, lässt dich ein 75-prozentiger Einbruch, gefolgt von einem 120-prozentigen Anstieg zehn Minuten später, entweder mit überdimensionierten Servern zurück, die Geld verbrennen, oder – schlimmer – mit einem zu kleinen Fleet, das den Rückkehr-Ansturm nicht verkraftet.
Dieser Artikel schlüsselt genau auf, was Cloudflare während der Sonnenfinsternis beobachtet hat, erklärt, warum reaktives Skalieren bei vorhersehbaren Anomalien versagt, und zeigt, wie du verkehrsbewusste Skalierungslogik in dein Game-Backend einbaust – mit einem funktionierenden Codebeispiel und konkreten Schwellenwerten, die du sofort anwenden kannst.
Die Cloudflare-Daten: Eine Muster-Anomalie
Cloudflares Analyse verwendete Fünf-Minuten-Intervalle der HTTP-Requests in den betroffenen Ländern und verglich den Verkehr am Tag der Finsternis mit einer Tagesbaseline. Die Ergebnisse waren eindeutig:
- Island verzeichnete den steilsten Rückgang – etwa 70–75 % unter der Baseline bei maximaler Verdunkelung.
- Nordspanien erlebte Einbrüche von 40–50 % unter der Baseline.
- Portugal zeigte Reduktionen von 30–40 %, wobei der tiefste Punkt exakt mit dem Moment der maximalen Sonnenfinsternis zusammenfiel.
- Die Erholung kam plötzlich. Der Verkehr normalisierte sich innerhalb von 15–20 Minuten nach Ende der Finsternis und übertraf das Niveau dann um 10–15 %, als die Menschen zu ihren Geräten zurückkehrten.
Das entscheidende Detail: Der Einbruch wartete nicht auf den Moment der größten Dunkelheit. Der Verkehr begann bereits 20–30 Minuten vor der maximalen Verdunkelung zu sinken, als die Menschen ins Freie gingen und ihre Geräte nicht mehr nutzten. Diese Vorderflanke ist wichtig, denn sie gibt einem gut instrumentierten System ein Zeitfenster zum Reagieren – aber nur, wenn man danach sucht.
Dieses Muster ist nicht nur bei Sonnenfinsternissen zu beobachten. Cloudflare dokumentierte eine nahezu identische Kurve während des WM-Finales 2026, und jedes große Sportereignis, jeder Feiertag oder kulturelle Moment erzeugt dieselbe Form: ein langsames Ausbluten, ein scharfes Tal und ein Überschwingen bei der Erholung.
Warum reaktives Auto-Scaling bei vorhersehbaren Anomalien versagt
Die meisten Game-Backends verwenden eine von zwei Skalierungsstrategien:
- Reaktiv (schwellenbasiert): Hochskalieren, wenn die CPU-Auslastung 70 % oder die Request-Latenz 200 ms überschreitet. Herunterskalieren, wenn die Auslastung unter 30 % fällt.
- Prädiktiv (zeitplangesteuert): Skalierung auf vordefinierte Kapazität zu geplanten Zeiten (z. B. „Skaliere jeden Freitag um 18 Uhr auf 200 Instanzen“).
Reaktives Skalieren hat einen fatalen Fehler, wenn der Traffic plötzlich einbricht: die Abkühlphase. Die meisten Auto-Scaling-Gruppen erzwingen eine Abkühlzeit von 3–10 Minuten zwischen Skalierungsaktionen, um ein Flattern zu vermeiden. Wenn der Traffic in 20 Minuten um 75 % einbricht, entfernt das Skalierungssystem zwar Instanzen, aber nicht schnell genug, um dem Rückgang zu entsprechen. Am Ende zahlst du für ungenutzte Kapazität.
Das eigentliche Problem ist die Erholung. Wenn der Traffic zurückschwappt, muss das reaktive Skalieren:
- Den Anstieg erkennen (1–2 Minuten erhöhter Metriken)
- Die Skalierungsrichtlinie auswerten (30 Sekunden)
- Neue Instanzen starten (60–180 Sekunden für Cloud-VMs, länger bei Container-Kaltstarts)
- Darauf warten, dass die Instanzen die Health Checks bestehen und sich dem Load Balancer anschließen (30–60 Sekunden)
Das ergibt eine Reaktionsverzögerung von 3–5 Minuten vom Moment des Traffic-Anstiegs bis zu dem Moment, in dem neue Kapazität tatsächlich Requests bedient. Bei einem Erholungs-Überschwinger nach einer Sonnenfinsternis, einer WM-Halbzeit oder einem saisonalen Event in deinem Spiel werden die zurückkehrenden Spieler in einem 15-Minuten-Fenster deine verbleibenden Instanzen überlasten, bevor neue online kommen.
Hier ist eine vereinfachte Visualisierung des Fehlermodus:
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
Die ░░░-Zone ist der Bereich, in dem deine Spieler auf überlastete Server treffen und deine Matchmaking-Warteschlange eine Zeitüberschreitung erleidet.
Technischer Deep-Dive: Anomalie-bewusste Verkehrsprognose aufbauen
Die Lösung besteht darin, das reaktive Skalieren um eine Anomalieerkennung zu erweitern, die historische Muster und erwartete Ereignisse versteht. Hier ist eine funktionierende Python-Implementierung eines Verkehrs-Anomalie-Detektors, den du in deine Monitoring-Pipeline integrieren kannst:
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}")
Wenn du das mit den simulierten Sonnenfinsternis-Daten ausführst, erhältst du eine Ausgabe wie:
Anomaly detected: True
Direction: drop
Change: -75.0%
Deviation: -4.82σ
Action: hold_capacity
Confidence: 0.96
Die wichtigste Erkenntnis ist die hold_capacity-Empfehlung bei drastischen Einbrüchen. Reaktives Skalieren würde aggressiv Instanzen beenden. Der Anomalie-Detektor sagt: Das ist zu groß und zu plötzlich für einen normalen Traffic-Rückgang – hier passiert etwas Externes. Nicht herunterskalieren. Das verhindert das schmerzhafte Nachziehen, wenn der Verkehr zurückkommt.
Für den Erholungsanstieg (wenn der Verkehr auf 115 % der Baseline steigt) gibt der Detektor scale_up_moderate aus, weil der Anstieg zwar die statistische Baseline überschreitet, aber im erwarteten Erholungsfenster nach einem großen Einbruch liegt – du willst hochskalieren, aber nicht so extrem wie bei einem wirklich beispiellosen Spike.
Anomalieerkennung in deine Skalierungspipeline integrieren
Der obige Detektor läuft unabhängig von deinem Skalierungs-Controller. So fügt er sich in eine Produktionspipeline ein:
┌──────────────┐ ┌─────────────────┐ ┌──────────────────┐
│ Metrics │────▶│ Anomaly │────▶│ Scaling │
│ Ingestion │ │ Detector │ │ Controller │
│ (Prom/Graf) │ │ │ │ │
└──────────────┘ │ • Baselines │ │ • Aggressive │
│ • Per-hour │ │ • Cautious │
│ comparison │ │ • Hold │
│ • Direction + │ │ │
│ confidence │ └────────┬─────────┘
└─────────────────┘ │
┌───────▼────────┐
│ Server Fleet │
│ (VMs / Pods) │
└────────────────┘
Schritt 1 – Metrik-Erfassung: Sammle die Requests pro Minute oder pro fünf Minuten von deinem Load Balancer oder API-Gateway. Tagge die Metriken nach Region (Island, Spanien usw.), um geografisch korrelierte Einbrüche zu erkennen.
Schritt 2 – Baselines aufbauen: Trainiere die Baselines wöchentlich mit den letzten 6–8 Wochen Daten. Schließe anomale Tage (Launches, große Patches, bekannte Vorfälle) aus dem Trainingssatz aus. Das verhindert, dass vergangene Traffic-Spitzen die Standardabweichung aufblähen und den Detektor unempfindlicher machen.
Schritt 3 – Anomaliebewertung: Speise die aktuellen RPS alle fünf Minuten in den Detektor ein. Wenn er hold_capacity oder scale_up_aggressive zurückgibt, sende eine Skalierungsanweisung mit Prioritätsüberschreibung an deinen Controller.
Schritt 4 – Skalierungs-Controller: Implementiere drei Skalierungsmodi basierend auf der Empfehlung des Detektors:
maintain– die normale reaktive Skalierungslogik wird ausgeführthold_capacity– deaktiviere Herunterskalierungen für die nächsten 30 Minuten; wende ein Mindestinstanzlimit in Höhe der aktuellen Anzahl anscale_up_aggressive/scale_down_cautious– passe die Zielkapazität um bestimmte Prozentsätze an, anstatt auf Schwellenwerte zu warten
Für Studios, die dedizierte Server-Fleets betreiben (UEFN, benutzerdefinierte Unreal-Dedicated-Server oder Headless-Unity-Instanzen), liegt diese Pipeline als Policy-Override-Ebene neben deinem bestehenden Orchestrator. Du ersetzt deinen Auto-Scaler nicht – du gibst ihm bessere Informationen darüber, wann er seiner eigenen reaktiven Logik vertrauen oder misstrauen soll.
Spielespezifischer Kontext: Wann ist das wirklich relevant?
Du denkst vielleicht: „Ich betreibe ein kleines Indie-Multiplayer-Spiel, kein globales CDN. Betrifft mich eine Sonnenfinsternis wirklich?“ Wahrscheinlich nicht direkt. Aber das zugrunde liegende Muster – vorhersehbare, externe Ereignisse, die Verkehrsanomalien verursachen – taucht im Spielbetrieb ständig auf:
Saisonale Events und Content-Drops
Wenn du ein saisonales Event planst (Leaderboards zurücksetzen, zeitlich begrenzte Modi, Feiertagsinhalte), erzeugst du eine selbstverschuldete Verkehrsspitze. Spieler melden sich in der ersten Stunde an und erzeugen das 3- bis 8-fache an Requests für Authentifizierung, Inventarabfragen und Matchmaking-Aufrufe. Wenn dein Backend reaktiv skaliert, wird die erste halbe Stunde deines Events für alle eine verschlechterte Erfahrung sein.
Regionale Turniere und Wettkampfsaisons
Ein regionales Turnierfenster (z. B. 18–21 Uhr Ortszeit) erzeugt konzentrierte Nachfrage in einer geografischen Zone. Du weißt genau, wann es beginnt und endet. Reaktives Skalieren in dieser Region hinkt der Spitze hinterher und überprovisioniert dann während der Abkühlphase nach dem Turnier.
Konkurrenz mit großen Veröffentlichungen
Wenn ein AAA-Titel erscheint, sinkt der Traffic deines Spiels oft für 2–3 Tage um 20–40 %, während die Spieler sich den neuen Release ansehen. Reaktives Skalieren verbrennt weiterhin Rechenleistung für Instanzen, die niemand nutzt. Wenn der Start dieses Spiels dann ins Straucheln gerät (Serverprobleme, schlechte Bewertungen), bekommst du einen Erholungsschub, wenn die Spieler zurückkehren.
Plattformweite Ereignisse
Steam-Sales, PlayStation State of Play, Xbox Showcases und Nintendo Directs erzeugen alle messbare Verkehrsverschiebungen. Ein Studio, das während einer dieser Präsentationen in einem 15-sekündigen Zusammenschnitt erwähnt wird, kann in weniger als 10 Minuten eine Traffic-Spitze von 500 % erleben – viel zu schnell für reaktives Skalieren allein.
Jedes dieser Szenarien profitiert von demselben anomaliebewussten Ansatz wie oben gezeigt. Die Cloudflare-Daten zur Sonnenfinsternis sind lediglich eine saubere, groß angelegte, datengestützte Veranschaulichung dafür, wie ein 75-prozentiger Traffic-Ausschlag in der Praxis aussieht und wie schnell er entsteht. Die Diskussion zur Serverarchitektur ohne Verschwendung für Fortnite erkundet ein ähnliches Terrain – Kosten während Schwachlastzeiten minimieren, ohne die Fähigkeit zu verlieren, auf Spitzen zu reagieren.
Best Practices für anomaliensichere Game-Backends
1. Baue regionale, stündliche Baselines auf – keine globalen. Islands Sonnenfinsternis-Einbruch betrug 75 %. Der von Südfrankreichs 5 %. Ein globaler Durchschnitt hätte beide verschleiert. Wenn dein Spiel auch nur eine moderate internationale Reichweite hat, segmentiere deinen Traffic nach Kontinent oder Zeitzone. Ein WM-Final-Einbruch in Argentinien bedeutet nichts für deine südostasiatische Spielerbasis.
2. Verwende rollierende Ausschlüsse für deine eigenen Events. Wenn du ein Inhaltsupdate veröffentlichst oder ein geplantes Event durchführst, markiere diese Stunden als Anomalien in deinen Trainingsdaten. Andernfalls behandelt deine Baseline deine eigenen Updates als normalen Verkehr, was den Detektor für echte externe Ereignisse unempfindlicher macht.
3. Implementiere einen „Hold-Capacity“-Modus, nicht nur „Hochskalieren“ und „Herunterskalieren“. Die meisten Entwickler denken beim Skalieren an eine Zwei-Richtungs-Operation. Die Sonnenfinsternis-Daten zeigen, warum du einen dritten Modus brauchst: Halten. Wenn der Traffic plötzlich einbricht und der Anomalie-Detektor dies als externes Ereignis kennzeichnet, halte deine aktuelle Instanzanzahl. Das kostet etwas Geld für ungenutzte Rechenleistung, verhindert aber die katastrophale Verzögerung, wenn der Verkehr zurückkommt. Der Kostenunterschied zwischen dem Halten von 100 ungenutzten Instanzen für 15 Minuten und dem hektischen Starten von 80 neuen Instanzen während einer Spielerspitze ist vernachlässigbar: Die ungenutzte Rechenleistung ist vorhersehbar und budgetiert, während das hektische Hochfahren zu Spielerabwanderung, negativen Bewertungen und Forenbeiträgen führt.
4. Alarme an der Vorderflanke, nicht an der Talsohle. Cloudflares Daten zeigen, dass der Verkehr 20–30 Minuten vor dem Höhepunkt der Sonnenfinsternis zurückgeht. Wenn dein Detektor so eingestellt ist, dass er bei einer Abweichung von 3σ auslöst, erwischst du den Rückgang früh, solange er noch moderat ist. Setze deine Alarmschwelle auf 1,5–2σ mit einem rollierenden 10-Minuten-Fenster für die Erkennung der Vorderflanke und eine 3σ-Schwelle zur Bestätigung einer größeren Anomalie.
5. Skaliere für vorhersehbare Ereignisse mit fest einprogrammierten Zeitplänen vor. Für Ereignisse, die du kontrollierst (eigene saisonale Launches, geplante Turniere), verlasse dich nicht auf Auto-Scaling. Stelle die Kapazität direkt bereit. Auto-Scaling ist für die Dinge da, die du nicht geplant hast. Fest programmierte Skalierungsfenster sind für die Dinge, die du vor drei Wochen in dein Projektmanagement-Tool geschrieben hast.
Wenn du deine eigene Infrastruktur betreibst, sind die Implementierung des Anomalie-Detektors und der Planungslogik, das Abstimmen der Schwellenwerte, das Erstellen von Dashboards und das Testen der Pipeline realistischerweise zwei bis vier Wochen Backend-Engineering-Arbeit. Das ist die Art von grundlegender Infrastruktur, die horizOn als verwalteten Dienst anbietet – verkehrsbewusste Skalierungsrichtlinien sind in der Plattform integriert, sodass du dich auf die Spiellogik konzentrieren kannst, anstatt auf Infrastruktur-Anomalieerkennung.
Was du als Nächstes tun solltest
Wenn du irgendein Live-Multiplayer-Spiel oder einen Online-Titel betreibst, nimm dir diese Woche 30 Minuten Zeit, um deine aktuelle Skalierungskonfiguration zu überprüfen:
- Überprüfe deine Abkühlzeiten. Sind sie kurz genug, um auf einen 20-minütigen Verkehrsausschlag zu reagieren? Die meisten Standardwerte liegen bei 5–10 Minuten, was grenzwertig ist.
- Sieh dir deine Verkehrshistorie der letzten 3 Monate an. Finde die drei größten Einbrüche. Bringe sie mit realen Ereignissen in Verbindung (Feiertage, Wettbewerbe, Konkurrenzstarts). So erkennst du, ob du bereits von diesem Muster betroffen warst, ohne es zu merken.
- Teste dein Herunterskalierungsverhalten. Simuliere (oder finde ein echtes Schwachlastfenster), in dem der Verkehr 15 Minuten lang um 50 % einbricht und dann wieder normal wird. Miss, wie lange dein Fleet braucht, um sich vollständig zu erholen. Diese Zahl – die Erholungszeit nach einer plötzlichen Rückkehr – ist die wichtigste Latenzmetrik in deinem Backend, die die meisten Teams nie messen.
Die Sonnenfinsternis war ein seltenes Ereignis, aber das Verkehrsmuster, das sie erzeugt hat, trifft Spiele-Server jede Woche in weniger dramatischer Form. Wenn du jetzt anomaliebewusstes Skalieren aufbaust, werden deine Spieler die nächste Sonnenfinsternis gar nicht erst bemerken.
Bereit, die Verkehrsprognose nicht mehr von Grund auf neu zu bauen? Teste horizOn kostenlos und lass die verwaltete Infrastruktur die Skalierungskomplexität übernehmen, während du das Spiel veröffentlichst.
Quelle: Total eclipse of the Internet: traffic impacts in Iceland, Spain, and Portugal