Load balancer é o componente que distribui tráfego entre múltiplos servidores, garantindo que nenhum fique sobrecarregado enquanto outros ficam ociosos — e que, quando um servidor falha, o tráfego seja automaticamente redirecionado para os que continuam funcionando.
O problema sem load balancer
Imagine uma aplicação de e-commerce com um único servidor web. Na Black Friday, o tráfego vai de 200 requisições por segundo para 8.000. O servidor não aguenta — CPU no limite, tempo de resposta aumenta, usuários recebem erros, carrinho de compras falha. Você perde venda e reputação ao mesmo tempo.
A solução óbvia é adicionar mais servidores. Mas mais servidores sem load balancer ainda não resolvem: quem vai distribuir o tráfego entre eles? Como os usuários vão saber para qual servidor enviar a requisição? E se um servidor cair no meio da operação?
O load balancer responde todas essas perguntas. Ele fica na frente da sua infraestrutura, recebe todo o tráfego e distribui para o pool de servidores disponíveis conforme as regras configuradas.
Algoritmos de distribuição: como o load balancer decide
A lógica de distribuição do tráfego entre os servidores do pool não é trivial. Diferentes algoritmos se adaptam a diferentes padrões de carga:
Round-Robin é o mais simples: cada nova requisição vai para o próximo servidor na lista, em sequência circular. Servidor 1, servidor 2, servidor 3, servidor 1, servidor 2… Funciona bem quando os servidores têm capacidade equivalente e as requisições têm tempo de processamento semelhante. O problema aparece quando algumas requisições são muito mais pesadas do que outras — um servidor pode ficar com todas as pesadas enquanto outro processa só as leves.
Weighted Round-Robin adiciona pesos: um servidor mais potente pode receber proporcionalmente mais requisições. Servidor A (peso 3) recebe 3 requisições a cada 1 que vai para o Servidor B (peso 1). Útil quando os servidores do pool têm capacidades diferentes.
Least Connections envia cada nova requisição para o servidor com o menor número de conexões ativas no momento. É mais inteligente que round-robin para cargas variáveis — garante que servidores já sobrecarregados não recebam mais tráfego enquanto outros estão com folga.
IP Hash usa o endereço IP do cliente para determinar sempre qual servidor vai atender aquele usuário. Um cliente com o mesmo IP sempre cai no mesmo servidor. Útil para aplicações que mantêm estado na memória do servidor (sessões locais), garantindo que requisições consecutivas do mesmo usuário cheguem ao mesmo lugar.
Layer 4 vs Layer 7: a diferença que muda tudo
Load balancers operam em diferentes camadas do modelo de rede, e isso define o que eles conseguem fazer:
Load balancer Layer 4 (L4) trabalha com TCP e UDP — vê endereço IP e porta, nada mais. Distribui conexões sem inspecionar o conteúdo. É mais rápido e tem overhead menor, mas não entende o protocolo da aplicação. Um L4 LB não sabe a diferença entre uma requisição para /api/usuarios e uma para /api/relatorios — distribui tudo da mesma forma.
Load balancer Layer 7 (L7) entende o protocolo de aplicação — HTTP, HTTPS, WebSocket. Isso permite decisões de roteamento muito mais sofisticadas:
- Rotear requisições para /api para um pool de servidores de API e /static para um pool de servidores de conteúdo estático
- Direcionar usuários autenticados como premium para um pool de servidores com mais recursos
- Terminar SSL/TLS no load balancer (offloading), aliviando os servidores de aplicação
- Inspecionar headers e cookies para tomar decisões de roteamento
- Comprimir respostas e adicionar headers de segurança
Na prática, a maioria das aplicações web modernas usa L7 load balancer. L4 ainda faz sentido para tráfego não-HTTP de alto volume (streaming UDP, protocolos proprietários de banco de dados) onde a inspeção de camada 7 seria overhead desnecessário.
Health checks: como o load balancer detecta falhas
O health check é o mecanismo que faz o load balancer detectar automaticamente quando um servidor do pool está com problema e parar de enviar tráfego para ele.
Na configuração mais simples, o load balancer envia periodicamente uma requisição TCP ou HTTP para cada servidor (por exemplo, GET /health a cada 10 segundos) e espera uma resposta de sucesso (HTTP 200). Se um servidor não responder ou responder com erro por um número configurado de tentativas consecutivas, ele é removido do pool — o tráfego para de ir para ele automaticamente, sem intervenção humana.
Quando o servidor se recupera e volta a responder com sucesso, o load balancer o adiciona de volta ao pool gradualmente.
Isso é o que transforma o load balancer em componente de alta disponibilidade: a aplicação continua funcionando mesmo com um servidor falhando, desde que haja outros saudáveis no pool.
Casos de uso além do óbvio
APIs: load balancer L7 na frente de múltiplos contêineres ou instâncias de API. Permite escalar horizontalmente (adicionar mais instâncias conforme a demanda) e fazer deployments sem downtime — sobe a nova versão em alguns servidores, o load balancer distribui tráfego gradualmente para ela (blue-green ou canary deploy).
Banco de dados com réplicas de leitura: um load balancer pode distribuir queries de leitura (SELECT) entre múltiplas réplicas read-only, aliviando o nó primário de escrita. O código da aplicação aponta para o endereço do load balancer, não para cada réplica individualmente. Quando uma réplica fica para trás em replicação, o health check pode detectar e retirá-la do pool temporariamente.
SSL Offloading: terminar a criptografia TLS no load balancer e passar tráfego decriptografado para os servidores de aplicação. Isso alivia CPU dos servidores de aplicação e centraliza o gerenciamento de certificados num único ponto.
Sticky sessions: algumas aplicações legadas mantêm estado de sessão no servidor (não em banco de dados ou cache distribuído). Com sticky sessions no load balancer (via cookie ou IP hash), o mesmo usuário sempre cai no mesmo servidor durante a sessão. Não é ideal arquiteturalmente, mas resolve o problema sem reescrever a aplicação.
Load balancer como componente de HA
Load balancer só adiciona resiliência se ele mesmo não for ponto único de falha. Em ambientes de produção, o load balancer precisa rodar em alta disponibilidade — pelo menos dois nós em ativo-passivo ou ativo-ativo, com failover automático.
HAProxy, NGINX e Envoy são soluções open source amplamente usadas. No contexto de cloud, AWS ALB/NLB, Azure Load Balancer e soluções equivalentes em cloud privada já são gerenciados com HA nativa pelo provedor.
Os ambientes de cloud privada da Adentro incluem load balancer gerenciado como componente nativo para workloads de alta disponibilidade. Fale com nossa equipe para mais detalhes.