O que é um load balancer: o que ele resolve e o que não resolve

“Vamos colocar um load balancer”#

Quando uma aplicação começa a falhar, ficar lenta ou receber mais tráfego do que o esperado, uma das primeiras respostas costuma ser: “vamos colocar um load balancer”.

A ideia faz sentido até certo ponto. Um load balancer ajuda a distribuir requisições entre vários servidores, evita mandar tráfego para targets que falham nos health checks e permite operar aplicações com mais disponibilidade. Na AWS, o Elastic Load Balancing foi projetado para alta disponibilidade, escalonamento automático e distribuição de tráfego entre diferentes tipos de targets e zonas de disponibilidade.

Mas existe uma diferença importante entre distribuir tráfego e resolver o problema real de uma aplicação.

Um load balancer pode decidir para onde mandar uma requisição. O que ele não pode fazer é otimizar uma query lenta, corrigir um bug, reduzir o consumo excessivo de memória ou fazer um banco de dados saturado responder melhor.

Para se aprofundar: Como fazer deploy de um serviço HTTP em containers na AWS

Documentação: AWS · O que é o Elastic Load Balancing ↗

O que um load balancer faz de fato#

A função principal de um load balancer é atuar como ponto de entrada do tráfego. Em vez de os clientes chamarem diretamente uma instância ou um contêiner, eles chamam um endpoint comum. O load balancer recebe essa requisição e a envia para um dos targets disponíveis.

Isso traz três benefícios importantes.

Primeiro, permite distribuir a carga. Se há várias instâncias saudáveis por trás, o tráfego pode ser dividido entre elas. Isso reduz a dependência de um único servidor e permite escalar horizontalmente.

Segundo, melhora a disponibilidade. Se um target para de responder corretamente, o load balancer pode tirá-lo de rotação e continuar enviando tráfego para os targets que seguem saudáveis. Para isso ele se apoia nos health checks, sinais usados para decidir se um backend deve continuar recebendo requisições.

Terceiro, desacopla os clientes da infraestrutura real. Os usuários não precisam saber quantas instâncias existem por trás, se uma foi substituída ou se o sistema está rodando em várias zonas. O load balancer mantém um ponto de entrada estável enquanto a infraestrutura pode mudar por trás.

Até aqui, o load balancer agrega muito valor. O problema começa quando atribuímos a ele capacidades que, na verdade, pertencem ao design da aplicação e das suas dependências.

O que um load balancer não faz#

O problema aparece quando se espera que o load balancer resolva coisas para as quais ele não foi projetado.

Um load balancer não conserta uma aplicação lenta. Se cada request demora demais porque o código faz trabalho desnecessário, porque há chamadas sequenciais mal projetadas ou porque o banco de dados responde devagar, o load balancer não reduz esse tempo num passe de mágica.

Ele também não corrige uma arquitetura ruim. Se todos os targets dependem do mesmo banco de dados saturado, adicionar mais instâncias atrás do load balancer pode até aumentar a pressão sobre esse gargalo. O tráfego fica mais bem distribuído, sim, mas o problema central continua intacto.

Também é importante entender que um load balancer não garante estabilidade sozinho. Se todos os targets têm o mesmo bug, se todos foram implantados com uma configuração incorreta ou se todos dependem de um serviço externo que está falhando, não existe um backend saudável para onde mandar o tráfego.

Em outras palavras: o load balancer consegue contornar falhas isoladas, mas não consegue salvar um sistema quando a falha é compartilhada por todos os componentes.

Healthy nem sempre significa estável#

Um dos pontos mais delicados é a interpretação dos health checks.

Uma instância passar num health check não significa necessariamente que a aplicação esteja bem para os usuários. A AWS diferencia health checks superficiais e profundos. Os superficiais validam coisas locais, como se os processos críticos estão rodando ou se a instância responde. Os profundos também testam interações com dependências externas, como um banco de dados ou um serviço downstream.

resource "aws_lb_target_group" "app" {
  name     = "app"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  # Automatic Target Weights: reduz o tráfego para targets com erros anômalos.
  load_balancing_algorithm_type     = "weighted_random"
  load_balancing_anomaly_mitigation = "on"

  health_check {
    path                = "/health/ready"
    matcher             = "200"
    interval            = 15
    timeout             = 5
    healthy_threshold   = 3
    unhealthy_threshold = 2
  }
}

As duas abordagens têm vantagens e riscos.

Um health check superficial pode dizer “tudo certo” mesmo que a aplicação não consiga se conectar a uma dependência importante. Do ponto de vista do load balancer, o target está vivo. Do ponto de vista do usuário, a aplicação pode estar falhando.

Um health check profundo detecta melhor problemas reais de ponta a ponta, mas também pode gerar efeitos indesejados. Se uma dependência externa falha temporariamente, muitas instâncias podem parecer não saudáveis mesmo estando bem localmente. A AWS alerta que adicionar checks profundos ao Auto Scaling Group pode provocar substituições desnecessárias de instâncias saudáveis durante falhas transitórias de dependências.

A conclusão é simples: health checks são necessários, mas não são uma definição perfeita de saúde. São um sinal operacional, não uma prova absoluta de que o sistema inteiro funciona bem.

Para se aprofundar: SLIs e SLOs mal definidos: por que geram alertas falsos

Documentação: AWS · Health checks de target groups (ALB) ↗

Falhas cinzentas: quando algo parece saudável, mas não está#

Em produção, nem tudo falha de forma clara. Às vezes um target não está completamente fora do ar, mas se comporta pior que os outros. Pode devolver mais erros, ter mais latência, falhar só em certas rotas ou degradar sob carga.

A AWS chama esse tipo de situação de gray failure: o target passa nos health checks ativos do load balancer, mas mesmo assim devolve erros. Isso pode acontecer por bugs na aplicação, falhas de dependências, perda intermitente de rede, cache frio, sobrecarga de CPU ou outras causas.

Para esses casos, a AWS oferece o Application Load Balancer Automatic Target Weights. Esse recurso detecta targets com uma proporção anômala de erros e reduz o tráfego para eles, enviando mais requisições aos targets que estão respondendo melhor.

Isso é muito útil, mas não muda a mensagem principal: o load balancer está mitigando o impacto, não corrigindo a causa.

Se um target tem um bug, o bug continua lá. Se uma instância está sobrecarregada, a sobrecarga continua lá. Se uma dependência está falhando, a dependência continua sendo o problema.

O load balancer ajuda a reduzir quantos usuários sofrem com o erro, mas o time ainda precisa investigar e corrigir a origem.

Documentação: AWS · Automatic Target Weights (atributos do target group) ↗

Balancear carga não é o mesmo que otimizar desempenho#

Este é o erro mais comum: achar que balancear tráfego equivale automaticamente a melhorar a performance.

Melhora, sim, quando o problema é falta de capacidade nos servidores de aplicação e esses servidores conseguem escalar horizontalmente. Por exemplo, se uma instância atende certa quantidade de tráfego e adicionamos mais instâncias saudáveis atrás do load balancer, o sistema consegue processar mais requisições.

Mas se o gargalo está em outro lugar, o resultado pode ser diferente.

Se o banco de dados está saturado, mais instâncias podem gerar mais conexões e mais consultas contra o mesmo banco. Se um endpoint faz trabalho demais por request, mais targets só dividem esse trabalho caro. Se uma dependência externa está lenta, todos os servidores vão esperar pela mesma dependência.

O load balancer distribui requisições. Ele não reduz automaticamente o custo de processá-las.

Por isso, antes de achar que um load balancer vai resolver um problema de desempenho, vale perguntar: o gargalo está na distribuição do tráfego ou na forma como a aplicação processa cada requisição?

O load balancer como parte da arquitetura, não como solução completa#

Um load balancer agrega mais valor quando faz parte de uma arquitetura bem projetada. Ele funciona melhor quando a aplicação consegue escalar horizontalmente, quando os health checks refletem sinais úteis, quando as dependências têm limites claros e quando existe observabilidade suficiente para entender onde o sistema está falhando.

Também é importante lembrar que o próprio balanceamento de carga pode exigir design. No blog da AWS sobre estratégias de escalonamento para o Elastic Load Balancing, explica-se que, em certos cenários de tráfego alto, pode ser necessário aplicar sharding de ELB, distribuindo a carga entre vários load balancers por meio de DNS e Route 53.

Isso reforça a ideia central: um load balancer não é uma caixa mágica que você coloca na frente e resolve tudo. É uma camada de controle de tráfego dentro de um sistema maior.

Documentação: AWS · O que é o Elastic Load Balancing ↗ · AWS · Estratégias de escalonamento para o Elastic Load Balancing ↗

Verifique antes de adicionar um load balancer#

Um load balancer amplifica o que você já tem. Se a sua aplicação é estável, stateless e escala horizontalmente sem atrito, o Elastic Load Balancing vai deixá-la mais resiliente e distribuída. Mas se ela carrega queries não otimizadas, vazamentos de memória ou sessões presas a uma única instância, o load balancer só vai distribuir esses problemas entre mais nós — e deixá-los mais difíceis de diagnosticar.

Antes de implementar, passe por este checklist. Cada item resolve uma dependência real que o load balancer não cobre sozinho.

O load balancer não conserta a base. Um load balancer distribui tráfego entre targets saudáveis via health checks e melhora a disponibilidade. Ele não corrige queries lentas, não resolve bugs, não reduz consumo de memória nem alivia um banco de dados saturado. Primeiro estabilize a sua aplicação; depois adicione o load balancer para amplificar essa estabilidade.

• Deixe a sua aplicação stateless. Mova sessões e estado para um armazenamento compartilhado (Redis, DynamoDB, S3). Se uma instância guarda estado local, as requisições redistribuídas vão falhar de forma inconsistente.
• Otimize as queries frequentes. Revise planos de execução, crie índices compostos e elimine queries N+1. Uma query lenta continua lenta, não importa qual instância a receba.
• Verifique a concorrência no banco de dados. Garanta que o seu banco suporte conexões simultâneas vindas de várias instâncias. Considere connection pooling (PgBouncer, ProxySQL) ou estratégias como sharding se a carga exigir.
• Confirme que os seus health checks são significativos. Um endpoint que só devolve 200 sem validar dependências reais gera falsos positivos. Configure health checks que verifiquem a conectividade com banco de dados, caches e serviços críticos.
• Meça uma linha de base antes de implementar. Documente latência P50/P95/P99, taxa de erros e tempo de resposta dos endpoints principais. Esses números são a sua referência para avaliar se o load balancer melhora ou mascara problemas existentes.

• 3 — dependências mínimas a validar: banco de dados, sessões e queries frequentes precisam estar estáveis antes de adicionar um load balancer.
• P95 < 200ms — latência-alvo antes da implementação: se os seus endpoints passam desse limite com um único servidor, o load balancer não vai reduzi-la; vai distribuí-la.

Documentação: AWS · O que é o Elastic Load Balancing ↗

O que um load balancer resolve vs o que você precisa resolver antes#

Conclusão#

Load balancers são fundamentais em arquiteturas modernas. Eles ajudam a distribuir tráfego, melhorar a disponibilidade, tirar de rotação targets não saudáveis e reduzir o impacto de certas falhas.

Mas não devem ser confundidos com uma solução automática para problemas de desempenho ou estabilidade.

Um load balancer não otimiza código lento. Não conserta queries pesadas. Não corrige bugs. Não elimina dependências frágeis. Não transforma uma arquitetura fraca em uma arquitetura resiliente.

O papel real dele é outro: permitir que uma aplicação bem projetada receba tráfego de forma mais organizada, disponível e controlada.

“Um load balancer não salva uma aplicação ruim; ele ajuda uma boa arquitetura a lidar melhor com o tráfego”