O que é balanceamento de carga: como funciona e benefícios para HA
Balanceamento de carga (load balancing) é a distribuição de requisições entre múltiplos servidores para evitar sobrecarga de um único servidor e garantir disponibilidade quando um servidor falha. Load balancers L4 (camada de transporte) distribuem tráfego TCP/UDP por IP/porta; load balancers L7 (camada de aplicação) entendem o protocolo HTTP/HTTPS e podem rotear por URL, headers ou cookies. Para Alta Disponibilidade, o load balancer atua como health check ativo, desviando tráfego de servidores falhos automaticamente.
Aplicações web e APIs que têm picos de carga (Black Friday, fechamento de pedidos, campanha de marketing) podem saturar um único servidor. Load balancer distribui a carga entre múltiplos servidores e permite escalar horizontalmente adicionando nós.
Sem load balancer, a falha do servidor de aplicação causa downtime imediato. Com load balancer na frente de dois servidores, a falha de um é detectada via health check e o tráfego é desviado para o outro, failover transparente.
Com load balancer, é possível fazer manutenção (patching, atualização) em um servidor de cada vez, retirando-o do pool enquanto os outros absorvem o tráfego, zero downtime para o usuário.
L4 load balancer (HAProxy em modo TCP, AWS NLB) é simples e de alta performance, distribui conexões TCP por IP de destino sem inspecionar o conteúdo. Ideal para banco de dados, SMTP e protocolos não-HTTP com latência mínima.
L7 load balancer (NGINX, HAProxy em modo HTTP, AWS ALB) entende HTTP e pode rotear /api para servidores de API e /static para CDN, fazer SSL termination, e aplicar regras de roteamento baseadas em headers. Ideal para aplicações web e microserviços.
Configure health checks HTTP (GET /health) a cada 10 a 30 segundos. Após 2 a 3 falhas consecutivas, o servidor é removido do pool e o tráfego é redistribuído. Após recuperação, o servidor é readicionado automaticamente.
O load balancer em si pode ser um SPOF. Em produção, use dois load balancers em cluster ativo-passivo (keepalived/VRRP) ou ativo-ativo. A falha de um load balancer não causa downtime.
A Boreal Tecnologias provisiona load balancers L4 e L7 em cloud privada no Brasil para aplicações que precisam de HA e escalabilidade. Diagnóstico gratuito avalia a arquitetura atual e identifica onde load balancing melhora disponibilidade e performance.
ERPs tradicionais (SAP B1, Protheus, Sankhya) geralmente não são projetados para clustering horizontal via load balancer, têm estado de sessão que complica o balanceamento. Para ERPs, HA é implementado no banco de dados (Always On, RMAN) e no servidor de aplicação via failover ativo-passivo, não load balancing horizontal.
Round-robin distribui requisições em rotação entre os servidores, simples mas ignora diferenças de carga. Least connections envia a próxima requisição para o servidor com menos conexões ativas, mais inteligente para requisições de duração variável. Para APIs com tempos de resposta homogêneos, round-robin é adequado; para processamento de duração variável, least connections é melhor.
Sim, NGINX é um dos load balancers mais usados em produção para tráfego HTTP/HTTPS. Suporta upstream com health checks, SSL termination, caching e roteamento por URL. Para tráfego TCP/UDP L4, use HAProxy ou NGINX Stream. Para volumes muito altos, considere load balancers dedicados de hardware ou serviços gerenciados.
Sticky sessions vinculam um usuário sempre ao mesmo servidor, necessário para aplicações com estado de sessão em memória local. O problema é que um servidor sobrecarregado continua recebendo o tráfego dos seus usuários 'stickados' mesmo que outros servidores estejam ociosos. A solução é externalizar o estado de sessão (Redis, banco de dados), permitindo balanceamento sem stickiness.
Receba um diagnóstico estratégico gratuito e descubra o que está limitando performance, estabilidade e escala hoje.
Sem compromisso. Resposta em até 15 minutos em horário comercial.