Como um Eclipse Solar Revelou o Ponto Cego do Auto-Scaling em Backends de Jogos
Em resumo
Descubra como o eclipse solar expôs o ponto cego do auto-scaling em backends de jogos e como criar um detector de anomalias para evitar quedas.
Quando 75% dos Seus Jogadores Somem em 30 Minutos
Em 12 de agosto de 2025, a Cloudflare mediu algo que deveria deixar todo engenheiro de backend desconfortável: o tráfego de internet na Islândia caiu cerca de 75% durante a máxima obscuração do eclipse solar total e voltou a subir minutos depois. Espanha e Portugal registraram curvas quase idênticas. Milhões de pessoas — incluindo seus jogadores — largaram seus dispositivos e saíram para a rua.
Para estúdios que operam backends live-service, esse tipo de oscilação repentina e geograficamente concentrada não é hipotética. É exatamente o cenário que quebra auto-scaling reativo. Se a sua frota de servidores escala com base nos últimos cinco minutos de volume de requisições, uma queda de 75% seguida, dez minutos depois, por um repique de 120% vai deixar você com servidores super provisionados queimando dinheiro ou, pior, uma frota subdimensionada que não consegue absorver o pico de retorno.
Este artigo mostra exatamente o que a Cloudflare observou durante o eclipse, explica por que o scaling reativo padrão falha em anomalias previsíveis e mostra como construir lógica de scaling ciente de tráfego no seu backend de jogo — com um exemplo de código funcional e limites concretos que você pode aplicar hoje.
Os Dados da Cloudflare: Uma Anomalia de Livro Didático
A análise da Cloudflare usou buckets de requisições HTTP de cinco minutos nos países afetados, comparando o tráfego do dia do eclipse com uma baseline de dia normal. Os resultados foram inequívocos:
- Islândia teve o declínio mais acentuado — aproximadamente 70–75% abaixo da baseline na máxima obscuração.
- Norte da Espanha apresentou quedas de 40–50% abaixo da baseline.
- Portugal mostrou reduções de 30–40%, com o ponto mais profundo coincidindo exatamente com o momento do eclipse máximo.
- A recuperação foi repentina. O tráfego voltou à baseline em 15–20 minutos após o fim do eclipse e depois excedeu em 10–15% quando as pessoas voltaram aos seus dispositivos.
O detalhe crítico: a queda não esperou o momento de pico da escuridão. O tráfego começou a diminuir 20–30 minutos antes da máxima obscuração, conforme as pessoas saíam de casa e paravam de usar seus dispositivos. Essa borda de queda é importante porque dá a um sistema bem instrumentado uma janela para responder — mas somente se você estiver observando.
Esse padrão não é exclusivo de eclipses. A Cloudflare documentou uma curva quase idêntica durante a final da Copa do Mundo de 2026, e todo grande evento esportivo, feriado ou momento cultural produz o mesmo formato: uma queda lenta, um vale acentuado e um excesso de recuperação.
Por Que o Auto-Scaling Reativo Quebra em Anomalias Previsíveis
A maioria dos backends de jogos usa uma de duas estratégias de scaling:
- Reativo (baseado em limites): Escala para cima quando a CPU excede 70% ou a latência de requisição excede 200ms. Escala para baixo quando a utilização cai abaixo de 30%.
- Preditivo (agendado): Escala para capacidade predefinida em horários agendados (ex.: "escalar para 200 instâncias às 18h de toda sexta-feira").
O scaling reativo tem uma falha fatal quando o tráfego cai subitamente: o período de cooldown. A maioria dos grupos de auto-scaling impõe um cooldown de 3–10 minutos entre ações de scaling para evitar thrashing. Quando o tráfego cai 75% em 20 minutos, o sistema de scaling vai remover instâncias, mas não rápido o suficiente para acompanhar o declínio. Você acaba pagando por capacidade ociosa.
O problema real é a recuperação. Quando o tráfego volta a disparar, o scaling reativo precisa:
- Detectar o aumento (1–2 minutos de métricas elevadas)
- Avaliar a política de scaling (30 segundos)
- Iniciar novas instâncias (60–180 segundos para VMs em nuvem, mais para cold starts em contêineres)
- Aguardar as instâncias passarem pelos health checks e entrarem no load balancer (30–60 segundos)
Isso é uma latência de resposta de 3–5 minutos desde o momento em que o tráfego começa a subir até o momento em que a nova capacidade está realmente servindo requisições. Durante um excesso de recuperação após um eclipse, um intervalo da Copa do Mundo ou um evento sazonal no seu jogo, os jogadores que voltam em uma janela de 15 minutos sobrecarregam suas instâncias restantes antes que as novas entrem online.
Aqui está uma visualização simplificada do modo de falha:
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
A zona ░░░ é onde seus jogadores estão atingindo servidores sobrecarregados e sua fila de matchmaking está estourando o tempo limite.
Mergulho Técnico: Construindo Predição de Tráfego Ciente de Anomalias
A solução é aumentar o scaling reativo com detecção de anomalias que entende padrões históricos e eventos previstos. Aqui está uma implementação Python funcional de um detector de anomalias de tráfego que você pode integrar ao seu pipeline de monitoramento:
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}")
Executar isso contra os dados simulados do eclipse produz uma saída como:
Anomaly detected: True
Direction: drop
Change: -75.0%
Deviation: -4.82σ
Action: hold_capacity
Confidence: 0.96
O insight principal é a recomendação hold_capacity para quedas drásticas. O scaling reativo padrão encerraria instâncias agressivamente. O detector de anomalias diz: isso é grande e repentino demais para ser um declínio normal de tráfego — algo externo está acontecendo. Não reduza o scaling. Isso evita a correria dolorosa para reprovisionar quando o tráfego voltar.
Para o pico de recuperação (quando o tráfego retorna a 115% da baseline), o detector emite scale_up_moderate porque, embora o pico exceda a baseline estatística, ele está dentro da janela de repique esperada após uma grande queda — você quer escalar para cima, mas não ao extremo que um pico verdadeiramente sem precedentes provocaria.
Integrando a Detecção de Anomalias ao Seu Pipeline de Scaling
O detector acima roda de forma independente do seu controlador de scaling. Veja como ele se encaixa em um pipeline de produção:
┌──────────────┐ ┌─────────────────┐ ┌──────────────────┐
│ Metrics │────▶│ Anomaly │────▶│ Scaling │
│ Ingestion │ │ Detector │ │ Controller │
│ (Prom/Graf) │ │ │ │ │
└──────────────┘ │ • Baselines │ │ • Aggressive │
│ • Per-hour │ │ • Cautious │
│ comparison │ │ • Hold │
│ • Direction + │ │ │
│ confidence │ └────────┬─────────┘
└─────────────────┘ │
┌───────▼────────┐
│ Server Fleet │
│ (VMs / Pods) │
└────────────────┘
Passo 1 — Ingestão de Métricas: Colete RPS por minuto ou a cada cinco minutos do seu load balancer ou API gateway. Marque as métricas por região (Islândia, Espanha, etc.) para detectar quedas correlacionadas geograficamente.
Passo 2 — Construção de Baselines: Toda semana, retreine as baselines usando os últimos 6–8 semanas de dados. Exclua dias anômalos (lançamentos, grandes patches, incidentes conhecidos) do conjunto de treinamento. Isso evita que picos de tráfego passados inflacionem o desvio padrão e tornem o detector menos sensível.
Passo 3 — Avaliação de Anomalias: A cada cinco minutos, alimente o detector com o RPS atual. Se ele retornar hold_capacity ou scale_up_aggressive, envie uma diretiva de scaling ao seu controlador com override de prioridade.
Passo 4 — Controlador de Scaling: Implemente três modos de scaling com base na recomendação do detector:
maintain— a lógica padrão de scaling reativo executa normalmentehold_capacity— desativa ações de scale-down pelos próximos 30 minutos; aplica um piso mínimo de instâncias igual à contagem atualscale_up_aggressive/scale_down_cautious— ajusta a capacidade alvo por percentuais específicos em vez de esperar por limites
Para estúdios que operam frotas de servidores dedicados (UEFN, servidores dedicados personalizados de Unreal ou instâncias headless de Unity), esse pipeline fica ao lado do seu orquestrador existente como uma camada de override de políticas. Você não está substituindo seu auto-scaler — está dando a ele informações melhores sobre quando confiar ou desconfiar da própria lógica reativa.
Contexto Específico para Jogos: Quando Isso Realmente Importa?
Você deve estar pensando: "Eu rodo um jogo multiplayer indie pequeno, não uma CDN global. Um eclipse solar realmente me afeta?" Provavelmente não diretamente. Mas o padrão subjacente — eventos externos previsíveis causando anomalias de tráfego — aparece constantemente nas operações de jogos:
Eventos Sazonais e Lançamentos de Conteúdo
Quando você agenda um evento sazonal (reset de leaderboards, modos por tempo limitado, conteúdo de feriado), você cria um pico de tráfego autoinfligido. Os jogadores fazem login na primeira hora, gerando de 3 a 8 vezes o volume normal de requisições para autenticação, consultas de inventário e chamadas de matchmaking. Se o seu backend escala reativamente, os primeiros 30 minutos do seu evento serão uma experiência degradada para todos.
Torneios Regionais e Temporadas Competitivas
Uma janela de torneio regional (ex.: 18h–21h no horário local) cria demanda concentrada em uma zona geográfica. Você sabe exatamente quando ela começa e termina. O scaling reativo nessa região vai ficar atrasado em relação ao pico e depois super provisionar durante o cooldown pós-torneio.
Competindo com Grandes Lançamentos
Quando um título AAA é lançado, o tráfego do seu jogo frequentemente cai 20–40% por 2–3 dias enquanto os jogadores experimentam o novo lançamento. O scaling reativo vai continuar queimando compute em instâncias que ninguém está usando. Por outro lado, quando o lançamento daquele jogo tropeça (problemas de servidor, reviews negativas), você recebe um pico de retorno conforme os jogadores voltam.
Eventos de Plataforma
Promoções da Steam, PlayStation State of Play, showcases da Xbox e Nintendo Directs produzem mudanças mensuráveis de tráfego. Um estúdio mencionado em um sizzle reel de 15 segundos durante uma dessas apresentações pode ver um pico de 500% em menos de 10 minutos — rápido demais para o scaling reativo sozinho.
Cada um desses cenários se beneficia da mesma abordagem ciente de anomalias demonstrada acima. Os dados do eclipse da Cloudflare fornecem simplesmente uma ilustração limpa, em larga escala e baseada em dados do que uma oscilação de 75% no tráfego parece na prática e com que rapidez ela se desenvolve. A discussão sobre arquitetura de servidores com desperdício zero para Fortnite explora território semelhante — minimizando custos durante janelas de baixo tráfego sem sacrificar a capacidade de responder a picos.
Melhores Práticas para Backends de Jogos Resilientes a Anomalias
1. Construa baselines por região e por hora — não globais. A queda do eclipse na Islândia foi de 75%. No sul da França, 5%. Uma média global teria mascarado ambos. Se o seu jogo tem alcance internacional mesmo que moderado, segmente seu tráfego por continente ou fuso horário. Uma queda na final da Copa do Mundo na Argentina não significa nada para a sua base de jogadores no Sudeste Asiático.
2. Use exclusões rolantes para seus próprios eventos. Quando você lança uma atualização de conteúdo ou executa um evento agendado, marque essas horas como anomalias nos seus dados de treinamento. Caso contrário, sua baseline vai tratar seus próprios updates como tráfego normal, tornando o detector menos sensível a eventos externos genuínos.
3. Implemente um modo "hold capacity", não apenas "scale up" e "scale down". A maioria dos engenheiros pensa em scaling como uma operação bidirecional. Os dados do eclipse revelam por que você precisa de um terceiro modo: hold. Quando o tráfego cai subitamente e o detector de anomalias sinaliza como um evento externo, mantenha a contagem atual de instâncias. Isso custa algum dinheiro em compute ocioso, mas evita o lag catastrófico quando o tráfego retorna. A diferença de custo entre manter 100 instâncias ociosas por 15 minutos e correr para lançar 80 novas instâncias durante um pico de jogadores é trivial: o compute ocioso é previsível e orçado, enquanto a correria do pico causa churn de jogadores, reviews negativas e posts no fórum.
4. Alerte na borda de queda, não no vale. Os dados da Cloudflare mostram o tráfego declinando 20–30 minutos antes do pico do eclipse. Se o seu detector estiver ajustado para disparar em 3σ de desvio, você vai pegar a queda cedo, enquanto o declínio ainda é moderado. Defina seu limite de alerta para 1,5–2σ com uma janela móvel de 10 minutos para detecção na borda, e um limite de 3σ para confirmar uma anomalia grave.
5. Pré-escala para eventos previsíveis com agendamentos fixos. Para eventos que você controla (lançamentos sazonais do seu jogo, torneios agendados), não dependa de auto-scaling. Faça o provisionamento de capacidade diretamente. Auto-scaling é para as coisas que você não planejou. Janelas de scaling fixas são para as coisas que você escreveu na sua ferramenta de gerenciamento de projetos há três semanas.
Se você está rodando sua própria infraestrutura, implementar o detector de anomalias e a lógica de agendamento, ajustar limites, construir dashboards e testar o pipeline é realisticamente de duas a quatro semanas de trabalho de engenharia de backend. Esse é o tipo de infraestrutura fundamental que a horizOn trata como serviço gerenciado — políticas de scaling cientes de tráfego estão integradas à plataforma, para que você possa focar na lógica do jogo em vez de detecção de anomalias em nível de infra.
O Que Fazer a Seguir
Se você roda qualquer tipo de jogo multiplayer ao vivo ou título habilitado para online, reserve 30 minutos esta semana para auditar sua configuração de scaling atual:
- Verifique seus timers de cooldown. Eles são curtos o suficiente para responder a uma oscilação de tráfego de 20 minutos? A maioria usa o padrão de 5–10 minutos, o que é borderline.
- Observe seu histórico de tráfego dos últimos 3 meses. Encontre as três maiores quedas. Correlacione-as com eventos do mundo real (feriados, competições, lançamentos de concorrentes). Isso mostra se você já foi afetado por esse padrão sem perceber.
- Teste seu comportamento de scale-down. Simule (ou encontre uma janela real de baixo tráfego) onde o tráfego cai 50% por 15 minutos e depois volta ao normal. Meça quanto tempo leva para sua frota se recuperar totalmente. Esse número — o tempo de recuperação após um retorno repentino — é a métrica de latência mais importante do seu backend que a maioria dos times nunca mede.
O eclipse foi um evento raro, mas o padrão de tráfego que ele produziu atinge servidores de jogos toda semana de forma menos dramática. Construir scaling ciente de anomalias agora significa que seus jogadores nunca perceberão o próximo.
Pronto para parar de construir predição de tráfego do zero? Experimente a horizOn gratuitamente e deixe a infraestrutura gerenciada cuidar da complexidade do scaling enquanto você lança o jogo.
Fonte: Eclipse total da Internet: impactos no tráfego na Islândia, Espanha e Portugal