Load Balancer: distribuindo tráfego sem sobrecarregar servidores

O que é um load balancer e por que ele é necessário

Distribuindo carga para escalabilidade e alta disponibilidade

Um load balancer é um componente de infraestrutura que distribui requisições de entrada entre múltiplas instâncias de servidores backend, evitando que qualquer servidor individual se torne gargalo. Sem load balancing, escalar horizontalmente adicionando servidores seria inútil pois todo o tráfego continuaria indo para uma única instância. Além de distribuir carga, o load balancer é responsável por remover instâncias não saudáveis do pool de destinos, garantindo que requisições sejam enviadas apenas para servidores operacionais. Em arquiteturas cloud-native, load balancers são componentes fundamentais que permitem zero downtime deployments através de rolling updates.

L4 vs L7 load balancing — camada de transporte vs aplicação

Entendendo onde na pilha de rede o balanceamento ocorre

Load balancers L4 operam na camada de transporte, roteando conexões TCP ou UDP baseados em IP de origem e destino e número de porta, sem inspecionar o conteúdo das requisições. L4 load balancers são extremamente rápidos pois não precisam terminar a conexão TCP — apenas encaminham o fluxo de bytes para o backend escolhido. Load balancers L7 operam na camada de aplicação, podendo inspecionar headers HTTP, cookies, URL paths e corpo da requisição para tomar decisões de roteamento mais sofisticadas. A capacidade de fazer SSL termination, routing baseado em path e header-based routing torna L7 load balancers essenciais para arquiteturas de microsserviços e APIs complexas.

Algoritmos — round robin, least connections, IP hash

Como o load balancer decide para qual backend enviar cada requisição

Round robin é o algoritmo mais simples, distribuindo requisições sequencialmente entre os backends em ordem circular — ideal quando os servidores têm capacidade equivalente e as requisições têm custo similar. Least connections envia cada nova requisição para o backend com menor número de conexões ativas, sendo mais justo em cenários onde algumas requisições demoram mais que outras. IP hash usa o IP do cliente para determinar deterministicamente qual backend receberá a requisição, garantindo que o mesmo cliente sempre chegue ao mesmo servidor — essencial para aplicações com estado no servidor. Weighted variants de cada algoritmo permitem enviar proporcionalmente mais tráfego para servidores mais poderosos.

Health checks — não enviar tráfego para instâncias doentes

Monitoramento contínuo da saúde dos backends

Health checks são verificações periódicas que o load balancer faz em cada backend para determinar se ele está apto a receber tráfego. Checks passivos observam respostas de requisições reais, marcando backends como unhealthy após um número configurável de falhas consecutivas. Checks ativos enviam requisições sintéticas para endpoints de saúde específicos como /health ou /ready, independentemente do tráfego real, detectando falhas mais rapidamente. A configuração de thresholds — quantas falhas para marcar como unhealthy e quantos sucessos para restaurar — é crítica para evitar tanto remoção prematura de instâncias transitoriamente lentas quanto manter instâncias genuinamente falhas no pool.

Sticky sessions — manter o usuário na mesma instância

Quando e como manter afinidade entre cliente e servidor

Sticky sessions (ou session affinity) garantem que requisições de um mesmo cliente sejam sempre roteadas para o mesmo servidor backend, necessário quando estado de sessão é armazenado localmente na memória da aplicação. A implementação mais comum usa um cookie inserido pelo load balancer na primeira resposta, que é enviado de volta em requisições subsequentes para identificar o backend preferido. O problema fundamental de sticky sessions é que elas reduzem a efetividade do balanceamento — se um servidor fica sobrecarregado com sessões ativas, o load balancer não pode redistribuí-las facilmente. A alternativa preferida em sistemas modernos é armazenar estado de sessão externamente em Redis ou banco de dados, tornando os servidores stateless e eliminando a necessidade de sticky sessions.

SSL termination no load balancer

Centralizando gerenciamento de certificados e criptografia

SSL termination no load balancer significa que as conexões TLS são decriptadas nele, e a comunicação com os backends ocorre em HTTP simples dentro da rede privada. Essa abordagem centraliza o gerenciamento de certificados SSL em um único ponto, simplificando renovação e evitando que cada servidor backend precise lidar com criptografia. A comunicação interna em HTTP reduz overhead de CPU nos servidores de aplicação, mas exige que a rede interna seja confiável. Para ambientes com requisitos de segurança mais rigorosos, SSL passthrough repassa a conexão TLS intacta para o backend, ou re-encryption cria uma nova conexão TLS do load balancer para o backend, mantendo criptografia end-to-end.

Load balancer interno vs externo

Balanceamento na borda e dentro do cluster

Load balancers externos recebem tráfego da Internet e distribuem para instâncias em redes privadas, sendo o ponto de entrada público da aplicação com IP público e DNS configurado. Load balancers internos distribuem tráfego entre serviços dentro de uma VPC ou cluster Kubernetes, sem exposição à Internet, essenciais para comunicação entre microsserviços. Em Kubernetes, o Service type LoadBalancer cria um cloud load balancer externo, enquanto Services internos usam ClusterIP com o kube-proxy distribuindo conexões. Service meshes como Istio adicionam uma camada de load balancing L7 interno com capabilities avançadas como circuit breaking e traffic splitting para canary deployments.

HAProxy, NGINX e AWS ALB/NLB

Comparando as principais soluções de load balancing disponíveis

HAProxy é considerado o load balancer de alta performance mais confiável do mercado open-source, especializado em TCP e HTTP com configuração detalhada de algoritmos, health checks e ACLs para roteamento sofisticado. NGINX funciona como load balancer L7 além de servidor web e reverse proxy, sendo a escolha mais comum para quem já usa NGINX como proxy e quer adicionar balanceamento sem nova infraestrutura. O AWS ALB (Application Load Balancer) é um serviço gerenciado L7 com routing por path, host-based routing e suporte nativo a ECS e EKS, enquanto o NLB (Network Load Balancer) opera em L4 com latência ultra-baixa e suporte a IPs estáticos para whitelist de firewall.

Load balancing de banco de dados — ProxySQL e pgBouncer

Distribuindo conexões de banco de dados em ambientes de alta carga

ProxySQL é um proxy de alto desempenho para MySQL e MariaDB que faz load balancing entre réplicas de leitura, connection pooling, query routing e failover automático transparente para a aplicação. pgBouncer é um connection pooler leve para PostgreSQL que reutiliza conexões de banco de dados entre múltiplas aplicações, resolvendo o problema de custo alto de abertura de conexões no PostgreSQL. A separação de reads e writes via proxy é uma das otimizações mais impactantes em sistemas de banco de dados sob alta carga, direcionando escritas para o primary e leituras para réplicas. Ferramentas como Vitess para MySQL em Kubernetes levam esse conceito ainda mais longe com sharding automático e topologia flexível.

Conclusão — load balancer como pilar da disponibilidade

Escalabilidade horizontal e resiliência dependem de um bom balanceamento

Um load balancer bem configurado é o que separa um sistema que escala horizontalmente de um que apenas adiciona servidores sem benefício real. Entender os algoritmos, os tipos de health checks e as implicações de sticky sessions permite tomar decisões arquiteturais que impactam diretamente a disponibilidade e o custo de operação. Continue em: Fundamentos obrigatórios antes de produção.