Como configurar um Load Balancer para o seu servidor de MU Online

Conforme um servidor de MU Online cresce, a primeira dor de escala costuma aparecer no login: filas de conexão, timeout no ConnectServer ou o site caindo justamente no horário de pico, quando mais jogadores tentam entrar ao mesmo tempo. Um load balancer distribui essa carga entre múltiplas instâncias de um mesmo serviço, evitando que um único processo ou máquina vire gargalo. Este tutorial mostra como aplicar balanceamento de carga na camada de ConnectServer, site e APIs auxiliares de um servidor de MU, incluindo configuração prática com Nginx, health checks e testes de carga.

O que pode (e o que não pode) ser balanceado em um servidor de MU

A arquitetura típica de um servidor de MU Online tem componentes com características de escala muito diferentes:

Entender essa tabela evita o erro de tentar "jogar um load balancer na frente do GameServer" esperando resolver lag de mapa — isso não funciona da mesma forma, porque o estado do jogo vive dentro de um processo específico.

Cenários que justificam um load balancer

Antes de investir tempo em configuração, confirme que o sintoma bate com o problema certo:

• Fila ou timeout de conexão no ConnectServer em horário de pico, mesmo com CPU/RAM normais.
• Site ou loja fora do ar justamente quando o servidor está mais cheio (evento, reset de season).
• Painel administrativo lento para a staff durante os mesmos picos.

Se o sintoma é lag dentro dos mapas do jogo, o problema provavelmente está em outro lugar (otimização de script, quantidade de monstros, banco de dados do próprio GameServer) — vale investigar isso separadamente antes de assumir que falta balanceamento.

Arquitetura de referência com Nginx

Uma arquitetura simples e eficaz para começar usa o Nginx como balanceador de carga na frente de múltiplas instâncias do site/API e, quando aplicável, do ConnectServer:

                    ┌──────────────┐
   Jogadores  ──►   │  Nginx (LB)  │
                    └──────┬───────┘
              ┌────────────┼────────────┐
              ▼            ▼            ▼
        Instância 1   Instância 2   Instância 3
        (site/API)    (site/API)    (site/API)

Configurando balanceamento do site com Nginx

Um bloco básico de upstream no nginx.conf distribui requisições HTTP entre múltiplas instâncias da aplicação do site:

upstream mu_site_backend {
    least_conn;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
}

server {
    listen 80;
    server_name seusite.com.br;

    location / {
        proxy_pass http://mu_site_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

A diretiva least_conn direciona cada nova requisição para a instância com menos conexões ativas no momento, evitando que uma instância fique sobrecarregada enquanto outra fica ociosa — geralmente mais eficaz que o round-robin padrão para tráfego irregular como o de um servidor de MU.

Health checks: removendo instâncias com falha automaticamente

Um load balancer sem verificação de saúde continua enviando tráfego para uma instância travada, piorando a experiência em vez de melhorá-la. Configure um endpoint simples de health check na aplicação (ex.: /health, retornando 200 se estiver saudável) e, no Nginx (ou usando o módulo nginx_upstream_check_module / soluções como HAProxy para checagem ativa mais robusta), monitore esse endpoint periodicamente:

upstream mu_site_backend {
    server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;
}

Com max_fails e fail_timeout, o Nginx para de enviar tráfego para uma instância após 3 falhas consecutivas, dando 30 segundos antes de tentar novamente — reduzindo o impacto de uma instância travada sobre os jogadores.

Balanceando o ConnectServer

O ConnectServer é responsável por autenticar a conexão inicial e direcionar o cliente ao GameServer correto — ele não mantém o estado da sessão de jogo em si, o que o torna mais fácil de replicar em múltiplas instâncias. A abordagem mais comum é rodar 2 ou mais instâncias do ConnectServer em portas diferentes (ou máquinas diferentes) e usar um balanceador de camada 4 (TCP), já que o protocolo do ConnectServer não é HTTP:

frontend mu_connect
    bind *:44405
    mode tcp
    default_backend mu_connect_pool

backend mu_connect_pool
    mode tcp
    balance leastconn
    server connect1 127.0.0.1:44406 check
    server connect2 127.0.0.1:44407 check

Esse exemplo usa sintaxe no estilo HAProxy, mais adequado que o Nginx puro para balanceamento TCP de baixo nível como o do ConnectServer — o Nginx também suporta stream para isso, mas HAProxy costuma ser a escolha mais madura nesse cenário específico.

Sessão e afinidade (sticky sessions)

Para o site e o painel administrativo, se a aplicação guarda sessão de login em memória local (não em banco/Redis compartilhado), é necessário configurar "sticky sessions" — garantir que o mesmo jogador/admin sempre caia na mesma instância durante a sessão, evitando logout inesperado ao ser redirecionado para outra instância. A solução mais robusta, no entanto, é migrar a sessão para um armazenamento compartilhado (Redis, banco), tornando qualquer instância intercambiável e o balanceamento mais simples e resiliente.

Testando o balanceamento sob carga

Antes de confiar a configuração em produção, simule tráfego concorrente com uma ferramenta de teste de carga (ab, wrk, ou k6):

wrk -t4 -c200 -d30s http://seusite.com.br/

Esse comando simula 200 conexões simultâneas por 30 segundos usando 4 threads. Observe, durante o teste, se a carga é distribuída de forma equilibrada entre as instâncias (via logs ou métricas do Nginx/HAProxy) e se o tempo de resposta se mantém estável mesmo sob esse volume.

Monitorando o balanceador em produção

Depois de ativo, monitore continuamente:

Escalando gradualmente conforme a base cresce

Não é necessário começar com uma arquitetura elaborada de múltiplas máquinas físicas. Um caminho de evolução comum:

1. Uma única instância do site/ConnectServer, sem balanceador (fase inicial).
2. Múltiplas instâncias na mesma VPS, balanceadas localmente por Nginx (fase de crescimento).
3. Múltiplas instâncias em VPS diferentes, com balanceador dedicado e sessão compartilhada em Redis (fase de escala).
4. Balanceamento geográfico (múltiplos data centers/regiões), reservado a servidores de grande porte com base internacional.

Avançar de fase antes de precisar apenas adiciona complexidade operacional sem benefício real — dimensione conforme os sintomas de sobrecarga realmente aparecerem.

Erros comuns e soluções

Checklist de configuração de load balancer

• Componentes identificados corretamente (o que pode e o que não pode ser balanceado).
• Múltiplas instâncias do site/API configuradas e testadas individualmente.
• Balanceador (Nginx/HAProxy) configurado com algoritmo adequado (least_conn).
• Health checks configurados para remoção automática de instâncias com falha.
• Sessão compartilhada (Redis/banco) configurada, se aplicável.
• Balanceamento TCP dedicado para ConnectServer, se necessário.
• Teste de carga realizado antes de liberar em produção.
• Monitoramento contínuo de requisições, tempo de resposta e falhas por instância.

Com a camada de conexão e serviços auxiliares preparada para picos de acesso, vale revisar a configuração de base de todo o ambiente — consulte o tutorial de criação de servidor de MU Online para confirmar que GameServer e banco de dados também estão dimensionados para o crescimento da comunidade.

Perguntas frequentes