Balanceamento de Carga: O Que É e Quando o seu Site Precisa

Todo servidor tem um teto. Não importa quão potente seja a máquina, existe um número de visitantes simultâneos a partir do qual ela começa a arrastar, e um ponto adiante em que simplesmente para de responder. Além do teto de capacidade, há um problema mais silencioso: se o seu site inteiro roda em um único servidor, esse servidor é um ponto único de falha. Ele reinicia para uma atualização, o disco apresenta defeito, um pico de tráfego o derruba — e, enquanto ele estiver fora, o seu site não existe para ninguém. Balanceamento de carga é a resposta clássica para esses dois problemas ao mesmo tempo.

A ideia é simples de enunciar e cheia de detalhes na prática: em vez de um servidor, você coloca vários por trás de um intermediário que recebe todo o tráfego e o distribui entre eles. Esse intermediário é o balanceador de carga, o load balancer. Ele é ao mesmo tempo um distribuidor de trabalho e um porteiro que percebe quando um servidor adoeceu e para de mandar visitantes para lá. Neste guia você vai entender o que ele faz, como decide para onde mandar cada requisição, o problema do estado que atrapalha lojas e áreas de login, e principalmente como reconhecer se o seu projeto já precisa disso ou se ainda é cedo.

O problema que o balanceador resolve

Imagine uma única fila de supermercado com um caixa só. Enquanto chegam poucos clientes, tudo flui. Quando chega muita gente ao mesmo tempo, a fila cresce, cada pessoa espera mais e algumas desistem. A solução óbvia não é fazer o caixa trabalhar mais rápido — ele tem um limite físico — e sim abrir mais caixas e ter alguém orientando quem vai para qual. O balanceador de carga é essa pessoa que fica na entrada e diz "o senhor, no caixa 3; a senhora, no caixa 1". Ele não atende ninguém; ele só distribui.

Essa distribuição resolve duas coisas de uma vez. Primeiro, capacidade: com vários servidores atendendo em paralelo, o site aguenta muito mais gente simultânea do que qualquer máquina sozinha aguentaria. Segundo, disponibilidade: se um dos servidores cai, o balanceador percebe e manda todo o tráfego para os que continuam de pé. O visitante não vê nada de errado; no bastidor, um terço da sua frota pode ter reiniciado sem que uma única pessoa recebesse página de erro. Essas duas propriedades — escalar horizontalmente e não ter ponto único de falha — são o motivo de o balanceamento existir.

• Capacidade além de uma máquina. Somando vários servidores, você atende picos que derrubariam um servidor único.
• Sem ponto único de falha. A queda de um servidor deixa de ser a queda do site inteiro.
• Manutenção sem downtime. Dá para tirar um servidor do rodízio, atualizar e devolver, enquanto os outros seguem atendendo.
• Base para crescer. Precisou de mais capacidade? Adiciona mais um servidor ao grupo, sem trocar de arquitetura.

Onde o balanceador fica na arquitetura

O balanceador senta na frente dos servidores de aplicação, entre a internet e a sua frota. Para o mundo lá fora, é ele que "é" o seu site: o domínio aponta para o balanceador, e é o endereço dele que o visitante alcança. Por trás, ficam dois, três, dez servidores idênticos — todos rodando a mesma aplicação, todos capazes de responder qualquer requisição. O balanceador recebe cada pedido e escolhe um servidor de destino segundo uma regra, encaminha, recebe a resposta e devolve ao visitante.

Existem duas alturas em que essa distribuição pode acontecer, e vale conhecer a diferença sem se afogar em jargão. Um balanceador de camada 4 (transporte) trabalha no nível da conexão: ele olha endereços e portas e decide para onde mandar o fluxo, sem se importar com o conteúdo. É rápido e simples. Já um balanceador de camada 7 (aplicação) entende o tráfego web: ele lê o pedido HTTP, enxerga o endereço da página, os cabeçalhos, os cookies. Isso permite decisões mais espertas — mandar o tráfego da loja para um grupo de servidores e o do blog para outro, por exemplo — ao custo de um pouco mais de processamento. Na web moderna, o balanceamento de camada 7 é o mais comum justamente porque entende do assunto que está distribuindo.

Como o balanceador decide para onde mandar

Distribuir tráfego parece trivial ("manda um para cada"), mas a regra de escolha muda bastante o resultado. Essas regras são os algoritmos de balanceamento, e cada um serve melhor a um cenário. Nenhum é "o certo" em abstrato; o certo é o que combina com o seu tipo de tráfego.

• Round-robin (rodízio). Distribui em ordem circular: o primeiro pedido vai para o servidor 1, o segundo para o 2, o terceiro para o 3, e recomeça. Simples e justo quando todos os servidores têm a mesma força e as requisições custam mais ou menos o mesmo.
• Menos conexões (least connections). Manda o novo pedido para o servidor que está com menos conexões abertas no momento. Melhor quando as requisições variam muito de duração, porque evita empilhar trabalho num servidor que já está ocupado com tarefas longas.
• Peso (weighted). Você dá pesos diferentes aos servidores. Se um é o dobro mais potente, ele recebe o dobro de tráfego. Útil quando a frota é heterogênea.
• Hash de IP. Usa o endereço do visitante para escolher o servidor, de modo que a mesma pessoa caia sempre no mesmo servidor. Isso ajuda com o problema de estado que veremos adiante, mas distribui de forma menos uniforme.

Health checks: o porteiro que percebe a queda

Distribuir por si só não basta; o balanceador precisa saber quais servidores estão saudáveis. Para isso ele faz verificações de saúde, os health checks: de tempos em tempos, pergunta a cada servidor "você está bem?" — seja abrindo uma conexão, seja pedindo uma página específica de status. Se um servidor para de responder ou responde com erro, o balanceador o marca como indisponível e para de mandar tráfego para lá, sem que ninguém precise intervir. Quando o servidor volta a responder bem, ele é reintegrado ao rodízio.

É esse mecanismo que transforma "vários servidores" em "alta disponibilidade de verdade". Um bom health check não se contenta em checar se a máquina liga; ele testa se a aplicação realmente responde — porque um servidor pode estar ligado e mesmo assim servindo erro, e mandar visitante para lá é tão ruim quanto mandar para uma máquina desligada. Configurar o health check para exercitar um caminho representativo da aplicação é o que separa a redundância que funciona da que só parece funcionar.

O problema do estado: sessão, login e carrinho

Aqui mora a maior armadilha do balanceamento, e é onde muita gente tropeça. Se cada requisição pode cair em um servidor diferente, o que acontece com informações que "moram" em um servidor específico? O caso clássico é a sessão de login e o carrinho de compras. Se o visitante fez login no servidor 1 e o próximo clique dele cai no servidor 2, que não sabe nada daquela sessão, ele é tratado como deslogado. O carrinho some, o login pede senha de novo, a experiência quebra.

Há dois caminhos para resolver, e eles representam filosofias diferentes. O primeiro é a afinidade de sessão, as chamadas sticky sessions: o balanceador amarra cada visitante a um servidor e o mantém lá durante a visita, geralmente por um cookie ou pelo hash de IP. Funciona, mas enfraquece a distribuição e reintroduz um mini ponto de falha — se aquele servidor cai, quem estava preso a ele perde a sessão. O segundo caminho, mais robusto, é tirar o estado dos servidores de aplicação e guardá-lo em um lugar compartilhado: uma sessão armazenada num banco ou num cache rápido que todos os servidores enxergam. Assim, qualquer servidor atende qualquer visitante, e a queda de um não perde nada. Aplicações pensadas para escalar nascem com essa ideia de servidores "sem estado".

Alta disponibilidade e escalabilidade não são a mesma coisa

Vale separar dois conceitos que andam juntos mas não são sinônimos, porque confundi-los leva a decisões erradas. Escalabilidade horizontal é a capacidade de atender mais tráfego adicionando mais servidores ao grupo — é sobre volume. Alta disponibilidade é a capacidade de continuar no ar apesar da falha de um componente — é sobre resiliência. O balanceamento de carga entrega as duas, mas você pode querer uma sem precisar tanto da outra.

Um site com tráfego modesto e constante talvez não precise de mais capacidade, mas não pode se dar ao luxo de cair — nesse caso, dois servidores atrás de um balanceador servem menos para escalar e mais para garantir que a manutenção de um não derrube o serviço. Já um site que dispara em datas específicas precisa sobretudo escalar naqueles dias. Entender qual das duas dores é a sua evita tanto o subdimensionamento (cair no pior momento) quanto o exagero (montar uma frota para tráfego que não existe).

Onde o balanceador ajuda além de distribuir

Como todo o tráfego passa por ele, o balanceador vira um lugar natural para concentrar tarefas que seriam repetitivas em cada servidor. A mais comum é o encerramento de TLS, o SSL offload: o balanceador cuida da criptografia HTTPS com o visitante e conversa com os servidores de trás em conexão interna mais leve, poupando cada servidor de aplicação desse trabalho e centralizando a gestão do certificado num ponto só. Ele também costuma ser o lugar onde se aplicam limites de taxa, regras de bloqueio e compressão, funcionando como uma camada de borda antes da aplicação.

Vale mencionar um primo pobre do balanceador que você talvez já conheça: o round-robin de DNS. Nele, o próprio DNS devolve vários endereços para o mesmo domínio, e os visitantes se espalham entre eles. É barato e simples, mas burro: o DNS não sabe se um dos servidores caiu e continua mandando gente para o endereço morto, além de sofrer com cache de DNS que atrasa qualquer mudança. Serve como distribuição rústica, não como alta disponibilidade de verdade — para isso, você quer um balanceador que faça health check e reaja em segundos.

Quando o seu site realmente precisa disso

Balanceamento de carga é poderoso e, como toda arquitetura distribuída, adiciona complexidade: mais servidores para manter, o problema do estado para resolver, mais peças que podem desalinhar. Montar isso cedo demais é gastar esforço num problema que você ainda não tem. Os sinais de que chegou a hora são concretos.

• Um servidor já não dá conta do pico. Você mede, otimiza o que dá, e mesmo assim a máquina satura nos horários de movimento.
• Indisponibilidade custa caro. Cada minuto fora do ar tem preço — em vendas, em contratos, em reputação — e você não pode depender de uma máquina só.
• Manutenção virou risco. Atualizar o servidor significa derrubar o site, e você precisa de janela para mexer sem tirar o serviço do ar.
• O tráfego é irregular e cresce. Datas de pico exigem capacidade que sobra no resto do mês, e você quer poder adicionar e remover servidores conforme a demanda.

Se nenhum desses sinais aparece, um único servidor bem dimensionado, com bom cache e backups, provavelmente ainda é a escolha certa — mais simples e mais barata. Quando os sinais chegam, as opções vão do software instalado por você (soluções como NGINX e HAProxy fazem esse papel muito bem em um VPS) ao balanceador gerenciado que provedores de cloud oferecem pronto, cobrando pelo uso e cuidando da infraestrutura por baixo. O caminho natural costuma ser começar com um balanceador gerenciado quando o site cresce, porque ele entrega health check, escalonamento e resiliência sem que você precise virar administrador de uma frota. O importante é entender o mecanismo: quando você sabe o que o balanceador faz e qual problema ele resolve, a decisão de adotá-lo deixa de ser moda e vira resposta a uma necessidade que você consegue medir.