O que é load balancer (balanceamento de carga)

Todo servidor tem um limite: CPU, memória e conexões simultâneas. Quando o tráfego passa desse limite, as respostas ficam lentas e, no pior caso, o serviço cai. Há dois caminhos: trocar o servidor por um maior (escala vertical) ou colocar vários servidores para dividir o trabalho (escala horizontal). O load balancer é a peça que torna o segundo caminho possível.

O que é um load balancer?#

Um load balancer (balanceador de carga) é um componente que recebe as requisições dos clientes e as encaminha para um grupo de servidores que oferecem o mesmo serviço. Para quem acessa, existe um único endereço, como api.exemplo.com. Por trás dele há vários servidores, e o cliente não sabe qual respondeu.

Ele pode ser um software (nginx, HAProxy, Envoy), um serviço do provedor de nuvem ou um equipamento dedicado. A ideia é a mesma nos três: um ponto de entrada, vários destinos.

Como um load balancer funciona?#

O fluxo de cada requisição tem quatro passos:

1. O cliente resolve o nome do domínio via DNS e abre conexão com o endereço do balanceador.
2. O balanceador consulta a lista de servidores que estão saudáveis.
3. Ele escolhe um deles segundo o algoritmo configurado.
4. Repassa a requisição, recebe a resposta e a devolve ao cliente.

O passo 2 é o que dá resiliência. O balanceador verifica a saúde dos servidores e tira da rotação os que não respondem. Há dois jeitos de checar: o ativo, em que o balanceador faz testes periódicos (por exemplo, uma requisição a /health), e o passivo, em que ele observa as respostas reais e marca como falho o servidor que dá erro. O nginx de código aberto faz só a checagem passiva (a ativa é recurso do NGINX Plus): depois de falhas dentro de uma janela de tempo (max_fails e fail_timeout), ele evita o servidor por um período.

Quais algoritmos de balanceamento existem?#

O algoritmo decide qual servidor recebe a próxima requisição. Os três mais usados:

Existem variações com pesos, que mandam mais tráfego para servidores mais potentes. O IP hash é uma forma de "sessão fixa" (sticky session), mas tem um limite: clientes atrás do mesmo NAT compartilham o IP e caem todos no mesmo servidor.

Qual a diferença entre camada 4 e camada 7?#

O balanceamento de camada 4 trabalha no nível do transporte (TCP/UDP). Ele olha só IP e porta, sem entender o conteúdo. Por isso é rápido e serve para qualquer protocolo, de bancos de dados a servidores de jogos.

O de camada 7 trabalha no nível da aplicação (HTTP). Ele lê o cabeçalho, o caminho e os cookies, e pode decidir com base neles: mandar /api para um grupo de servidores e /static para outro, por exemplo. Em troca, faz mais trabalho por requisição. Esse tipo também costuma encerrar o TLS, o que o aproxima de um proxy reverso.

Como montar um load balancer com nginx?#

O bloco upstream lista os servidores, e o proxy_pass aponta para o grupo. Este exemplo balanceia por menor número de conexões, com checagem passiva:

http {
    upstream app {
        least_conn;
        server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
        server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
        server 10.0.0.13:3000 backup;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://app;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

Sem a linha least_conn;, o nginx usa round-robin. O servidor marcado com backup só recebe tráfego quando os outros estão indisponíveis. Troque os IPs pelos dos seus servidores e recarregue com nginx -s reload.

Que problemas o balanceamento traz?#

Dividir tráfego entre servidores exige que eles sejam intercambiáveis. Os cuidados principais:

• Estado na memória. Se o servidor A guarda a sessão do usuário na própria memória e a próxima requisição cai no B, o usuário perde a sessão autenticada. A saída é guardar a sessão fora do processo, em um banco ou em Redis, ou usar sessão fixa.
• Arquivos locais. Um upload gravado no disco do servidor A não existe no B. Use armazenamento compartilhado, como um object storage.
• Tarefas agendadas. Um cron que roda em todos os servidores executa N vezes. Rode-o em um só.
• O balanceador também falha. Se houver uma única instância dele, ele é um ponto único de falha.

Quando você não precisa de um load balancer?#

Se um servidor atende o tráfego com folga e uma queda curta é aceitável, o balanceador só acrescenta complexidade e custo. A maioria dos bots e dos sites pequenos está nesse caso. Antes de balancear, vale medir CPU, memória e latência e ver se aumentar a RAM do servidor resolve. Uma CDN na frente de conteúdo estático também tira muita carga do servidor de origem sem exigir um segundo servidor.

Como fazer isso na Square Cloud#

Na Square Cloud, o balanceamento é um recurso do domínio, sem nginx para configurar nem balanceador para manter. Suba o mesmo código em duas ou mais aplicações, defina um domínio personalizado na primeira (criando no seu registrador os registros DNS que o painel mostra) e adicione o mesmo domínio nas outras. A partir daí, as requisições se revezam em round-robin entre elas, e uma aplicação que cai sai da rotação por failover passivo, já que não há health check ativo.

O número de aplicações por domínio depende do plano: até 2 no Standard (a partir de R$ 44,99 por mês), até 5 no Pro e até 10 no Enterprise, sem cobrança por requisição. Só domínio personalizado entra no balanceamento, não o subdomínio squareweb.app. E quem decide quantas aplicações ficam atrás do domínio é você: esse número não muda sozinho com o tráfego.

Os cuidados da seção anterior valem aqui. Não há sticky session e cada aplicação tem o próprio disco, então guarde sessões em Redis ou em outro banco, mande os uploads para o Blob e deixe tarefas agendadas numa aplicação só. Se o gargalo for de um único processo, aumentar a RAM da aplicação nas configurações pode bastar. Veja o passo a passo em load balancing e os limites de cada plano em preços.