Balanceamento de Carga: como funciona e quando usar

O que é balanceamento de carga?

Balanceamento de carga é a distribuição de tráfego ou trabalho entre dois ou mais recursos capazes de atender uma solicitação. Esses recursos podem ser servidores, máquinas virtuais, containers, zonas de disponibilidade ou até regiões diferentes.

Para o cliente, normalmente existe um único endereço. Por trás dele, o load balancer mantém um conjunto de destinos, verifica quais estão disponíveis e aplica uma regra para selecionar o próximo. Assim, a capacidade não fica restrita a uma única instância.

O mecanismo pode existir como equipamento físico, software instalado pela equipe ou serviço gerenciado de nuvem. NGINX, HAProxy, balanceadores dos provedores de cloud e componentes de plataformas de containers são exemplos de implementações possíveis.

Balancear não significa necessariamente dividir tudo em partes exatamente iguais. Um destino mais potente pode receber mais tráfego, outro pode ser retirado temporariamente, e determinadas requisições podem exigir regras específicas de roteamento.

Como o balanceamento de carga funciona

Em uma aplicação web, o cliente resolve o domínio e estabelece uma conexão com o endereço exposto pelo load balancer. Esse componente recebe a solicitação, seleciona um backend saudável e encaminha o tráfego. A resposta retorna ao cliente diretamente ou passa novamente pelo balanceador, conforme o modelo utilizado.

1. O cliente envia uma conexão ou requisição para o endereço do serviço.
2. O load balancer identifica o conjunto de destinos compatíveis.
3. Destinos indisponíveis são excluídos da seleção.
4. Um algoritmo escolhe o backend que receberá o tráfego.
5. O backend processa a solicitação e devolve a resposta.

A documentação do Elastic Load Balancing da AWS descreve esse fluxo como a recepção do tráfego e seu encaminhamento para alvos registrados e saudáveis, que podem estar distribuídos por zonas de disponibilidade.

Quais são os componentes principais?

• Frontend ou listener: endereço, porta e protocolo usados para receber o tráfego.
• Pool de backends: conjunto de servidores ou serviços disponíveis para atendimento.
• Algoritmo: regra de seleção do próximo destino.
• Health check: verificação que indica se um backend pode receber tráfego.
• Políticas de roteamento: condições baseadas em protocolo, caminho, host, cabeçalhos ou outras características.
• Observabilidade: métricas e registros que mostram conexões, latência, erros e saúde dos destinos.

Em ambientes modernos, a lista de backends pode mudar constantemente. Novas instâncias entram durante a expansão, versões antigas saem em um deploy e containers são recriados. A integração com descoberta de serviços ou plataformas de orquestração evita depender de endereços mantidos manualmente.

Principais algoritmos de balanceamento

Round Robin

Distribui as solicitações sequencialmente entre os destinos. É simples e funciona bem quando os servidores têm capacidade semelhante e as requisições apresentam custos próximos.

Weighted Round Robin

Adiciona pesos ao Round Robin. Um servidor mais potente pode receber uma proporção maior do tráfego, enquanto outro com menos recursos recebe menos solicitações.

Least Connections

Escolhe o destino com menos conexões ativas. Pode ser útil quando a duração das solicitações varia, pois evita continuar enviando trabalho para um servidor que já está ocupado com conexões longas.

Hash

Calcula o destino a partir de um valor, como IP do cliente, cookie ou chave da requisição. Isso pode aumentar a afinidade, mas mudanças no conjunto de backends exigem cuidado para não redistribuir conexões de maneira problemática.

A documentação oficial de balanceamento HTTP do NGINX apresenta métodos como Round Robin, Least Connections e hash. O melhor algoritmo depende do tipo de tráfego; não existe uma regra universal.

Balanceamento na camada 4 e na camada 7

Um load balancer de camada 4 toma decisões principalmente com informações de rede e transporte, como endereço IP, porta, TCP ou UDP. Ele não precisa interpretar o conteúdo completo de uma requisição HTTP.

Na camada 7, o balanceador entende o protocolo de aplicação. Em HTTP e HTTPS, pode encaminhar tráfego conforme domínio, caminho, método ou cabeçalho. Por exemplo, requisições para /imagens podem seguir para um grupo e chamadas para /api para outro.

Aspecto	Camada 4	Camada 7
Base da decisão	IP, porta e protocolo de transporte	Conteúdo e características da requisição
Protocolos comuns	TCP e UDP	HTTP, HTTPS e gRPC
Roteamento	Mais simples e genérico	Mais detalhado por host, caminho ou cabeçalho
Custo de processamento	Normalmente menor	Maior inspeção e mais recursos disponíveis

A visão geral do Cloud Load Balancing diferencia balanceadores de aplicação na camada 7 e balanceadores de rede na camada 4. A escolha começa pelo protocolo e pelo tipo de decisão que o sistema precisa tomar.

Health checks e retirada de servidores

Distribuir tráfego para um servidor indisponível apenas espalha a falha. Por isso, load balancers executam verificações de saúde para decidir quais destinos podem permanecer na rotação.

Um health check pode testar a abertura de uma conexão TCP ou fazer uma requisição HTTP a um endpoint como /health. A resposta deve indicar que a aplicação consegue atender, e não apenas que o processo está em execução.

Intervalo, timeout e quantidade de sucessos ou falhas consecutivas precisam ser equilibrados. Uma regra agressiva pode retirar servidores saudáveis por uma oscilação curta; uma regra lenta mantém tráfego apontando para um destino realmente quebrado.

Segundo a documentação de health checks do Application Load Balancer, cada nó verifica seus alvos e encaminha solicitações somente para os considerados saudáveis nas zonas habilitadas.

Persistência de sessão: quando é necessária?

Se a aplicação guarda a sessão apenas na memória de um servidor, uma requisição encaminhada para outra instância pode não reconhecer o usuário. A persistência de sessão, também chamada de afinidade ou sticky session, tenta manter o cliente no mesmo backend.

Ela pode resolver uma necessidade imediata, mas cria dependência daquele destino e dificulta distribuir tráfego livremente. Quando possível, aplicações escaláveis mantêm sessões em armazenamento compartilhado ou usam dados verificáveis por qualquer instância.

Afinidade é necessária em alguns protocolos e sistemas legados, porém deve ser uma decisão consciente. Se o backend fixado falhar, o cliente ainda precisará ser redirecionado e talvez perca estado não compartilhado.

Benefícios do balanceamento de carga

• Escalabilidade: permite adicionar instâncias para atender mais tráfego.
• Disponibilidade: reduz a dependência de um único servidor de aplicação.
• Manutenção: possibilita retirar uma instância, atualizá-la e recolocá-la sem interromper todo o serviço.
• Uso de recursos: distribui solicitações conforme capacidade e ocupação.
• Roteamento inteligente: separa tráfego por protocolo, domínio, caminho ou região quando necessário.
• Terminação TLS: alguns balanceadores podem centralizar certificados e operações criptográficas.

Esses benefícios são especialmente úteis em arquiteturas de microsserviços, nas quais várias instâncias e serviços mudam de capacidade independentemente. Entretanto, projetos menores podem obter boa disponibilidade com uma arquitetura mais simples.

Limitações e novos pontos de falha

Colocar um load balancer na frente de vários servidores não torna o sistema inteiro altamente disponível. Se o próprio balanceador for uma única instância sem redundância, ele vira o novo ponto único de falha. Serviços gerenciados costumam esconder essa redundância; soluções próprias precisam planejá-la.

Outras dependências continuam relevantes. Dez servidores de aplicação podem compartilhar um único banco saturado, um cache indisponível ou um serviço externo lento. Nesse cenário, distribuir mais requisições aumenta a pressão sobre o verdadeiro gargalo.

Também surgem custos de configuração, certificados, regras, logs, métricas e diagnóstico. O caminho entre cliente e aplicação ganha uma camada a mais, e uma regra incorreta pode afetar todos os backends ao mesmo tempo.

Quando usar balanceamento de carga

• a aplicação já precisa de várias instâncias para atender o volume;
• uma falha de servidor não pode interromper todo o serviço;
• deploys e manutenções precisam acontecer com menos indisponibilidade;
• o tráfego deve ser separado por domínio, caminho, protocolo ou região;
• há necessidade de distribuir conexões longas ou tarefas com custos variados;
• a infraestrutura adiciona e remove instâncias dinamicamente.

Em APIs, o load balancer pode dividir tráfego entre instâncias, enquanto um API Gateway acrescenta responsabilidades como autenticação, limites de uso, transformação e gestão de rotas. Os dois podem coexistir e não devem ser tratados como sinônimos.

Quando evitar ou simplificar

Se a aplicação tem pouco tráfego, tolera uma janela curta de manutenção e funciona confortavelmente em uma instância, adicionar uma solução complexa pode gerar mais trabalho do que valor. Um serviço gerenciado simples ou uma única configuração de proxy pode bastar.

Também não é a primeira resposta para processamento assíncrono. Um load balancer distribui conexões ou requisições que chegam agora; uma fila de mensagens mantém tarefas até que consumidores possam processá-las. O problema define qual mecanismo usar.

Antes de escalar horizontalmente, confirme onde está o gargalo. Consultas lentas, bloqueios no banco, vazamentos de memória e chamadas externas podem exigir correção direta.

Escala vertical e horizontal

Escalar verticalmente significa aumentar CPU, memória ou capacidade de uma máquina. É simples, mas encontra limites físicos e mantém maior dependência daquela instância.

Escalar horizontalmente significa adicionar novas instâncias. O balanceador distribui tráfego entre elas, mas a aplicação precisa estar preparada: estado local, arquivos gravados no disco e tarefas agendadas sem coordenação podem produzir comportamentos inconsistentes.

Na prática, os dois modelos podem ser combinados. A equipe escolhe um tamanho adequado para cada instância e varia a quantidade conforme demanda, custo e limites do sistema.

Como escolher um load balancer

• Protocolo: HTTP, HTTPS, TCP, UDP, gRPC ou combinação.
• Camada: roteamento simples de rede ou decisões detalhadas de aplicação.
• Escopo: tráfego externo, interno, regional ou global.
• Capacidade: conexões por segundo, largura de banda e latência aceitável.
• Saúde: tipos de health check e tempo de reação a falhas.
• Segurança: TLS, políticas de acesso, proteção de rede e registros.
• Operação: serviço gerenciado ou software mantido pela equipe.
• Custo: instâncias, tráfego processado, regras e observabilidade.

Para uma aplicação hospedada em VPS, um proxy reverso com NGINX pode acumular a função de balanceador HTTP. Em ambientes de nuvem, soluções gerenciadas reduzem a manutenção da camada de distribuição e oferecem integração com outros serviços.

Boas práticas de implementação

• Elimine o ponto único de falha do próprio balanceador.
• Crie health checks que representem a capacidade real de atendimento.
• Configure timeouts de conexão e resposta de forma explícita.
• Retire instâncias gradualmente para permitir que conexões em andamento terminem.
• Evite guardar sessão apenas na memória local quando as requisições podem mudar de backend.
• Proteja a comunicação entre load balancer e backends, não apenas a conexão externa.
• Registre o endereço original do cliente com cabeçalhos e confiança bem configurados.
• Monitore latência, erros, conexões, respostas por backend e alterações de saúde.

Ferramentas de observabilidade ajudam a separar tempo gasto no balanceador, na aplicação e em dependências. O guia sobre OpenTelemetry explica como logs, métricas e traces podem ser correlacionados em sistemas distribuídos.

Erros comuns

• Verificar apenas se a porta está aberta: o processo pode responder enquanto suas dependências estão quebradas.
• Usar Round Robin sem observar o tráfego: solicitações muito diferentes podem sobrecarregar uma instância.
• Depender de sessão local: a troca de backend causa perda de estado.
• Ignorar drenagem de conexões: retirar um servidor abruptamente interrompe trabalhos em andamento.
• Deixar o balanceador sem redundância: o ponto único de falha apenas muda de lugar.
• Escalar a camada errada: adicionar servidores de aplicação não resolve um banco saturado.
• Não testar falhas: alta disponibilidade só existe de verdade quando a retirada e recuperação de destinos são verificadas.

Perguntas frequentes

Load balancer e proxy reverso são a mesma coisa?

Não exatamente. O proxy reverso recebe tráfego em nome de servidores internos; o balanceamento distribui esse tráfego entre múltiplos destinos. A mesma ferramenta pode exercer as duas funções.

Qual é a diferença entre load balancer e API Gateway?

O load balancer concentra-se na distribuição e disponibilidade do tráfego. O API Gateway geralmente acrescenta gestão de APIs, autenticação, rate limiting, transformação e políticas específicas.

Balanceamento de carga sempre melhora o desempenho?

Não. Ele distribui tráfego entre recursos, mas não corrige um gargalo compartilhado ou código ineficiente. Também adiciona uma etapa ao caminho da requisição.

Quantos servidores são necessários?

Não existe um número universal. Duas instâncias já permitem distribuição, mas capacidade, redundância, zonas de falha e manutenção determinam o desenho adequado.

O que é sticky session?

Sticky session é a afinidade que tenta encaminhar um cliente repetidamente ao mesmo backend. Pode preservar estado local, mas reduz a liberdade de distribuição e exige estratégia para falhas.

O que é health check?

É uma verificação periódica usada para decidir se um servidor está apto a receber tráfego. Pode testar conexão, endpoint HTTP ou uma condição mais completa da aplicação.

Containers precisam de balanceamento de carga?

Quando existem múltiplas réplicas, algum componente precisa distribuir o tráfego. Plataformas de orquestração normalmente oferecem descoberta e balanceamento internos, além da entrada externa.

Conclusão

O balanceamento de carga coloca uma camada de distribuição entre clientes e servidores. Ela escolhe destinos saudáveis, permite adicionar capacidade e reduz a dependência de uma única instância de aplicação.

O resultado depende de escolhas corretas: camada 4 ou 7, algoritmo, health checks, sessões, timeouts, redundância e observabilidade. Um load balancer bem configurado aumenta resiliência; mal planejado, apenas centraliza novos riscos.

Para colocar esse conceito em prática em uma aplicação web, o próximo passo natural é estudar a configuração de proxy reverso e balanceamento com NGINX, mantendo este guia como base para entender as decisões por trás de cada diretiva.