Como configurar balanceamento de carga no HAProxy para alta concorrência

Por que o HAProxy é indispensável em arquiteturas de alta concorrência

Quando um sistema cresce e o tráfego de usuários explode, um único servidor web deixa de dar conta do recado. É aí que entra o balanceamento de carga, um mecanismo que atua como um maestro invisível, distribuindo as requisições de rede entre vários computadores de retaguarda, conhecidos como backends. Entre as ferramentas open source mais respeitadas para esse trabalho está o HAProxy, um software extremamente rápido e estável projetado para lidar com milhões de conexões simultâneas consumindo pouca memória.

Na prática, o HAProxy intercepta tudo o que vem da internet e decide para qual servidor interno aquela requisição deve ir. Para garantir que o sistema continue funcionando mesmo se uma máquina pifar, a ferramenta realiza verificações de integridade constantes, tirando de cena os nós problemáticos. Além disso, assim como lidamos com a resiliência em redes usando ferramentas como failover automático de rede no systemd-networkd, precisamos garantir que o tráfego web também seja redirecionado sem intervenção humana quando um nó falha.

Escolhendo o algoritmo correto de distribuição de tráfego

A forma como o HAProxy decide qual servidor vai atender o próximo cliente depende do algoritmo configurado no arquivo de configuração principal. O método padrão é o roundrobin, que faz um revezamento simples e sequencial entre os servidores disponíveis. Embora funcione bem quando todas as máquinas têm exatamente a mesma potência e processam tarefas de durabilidade semelhante, ele pode gerar desbalanceamento se algumas requisições demorarem muito mais que outras.

Para cenários onde o tempo de resposta varia bastante, o algoritmo leastconn costuma ser a escolha mais inteligente. Ele direciona a nova requisição sempre para o servidor que possui o menor número de conexões ativas naquele exato momento. Isso evita que um servidor já sobrecarregado receba mais trabalho enquanto outro ocioso fica esperando. Se você precisar que o mesmo usuário seja sempre direcionado para o mesmo servidor por causa de sessões ativas, a estratégia baseada em hash de IP garante essa persistência de forma limpa.

Estruturando o arquivo de configuração e as seções globais

Toda a mágica do HAProxy acontece dentro do arquivo haproxy.cfg, geralmente localizado no diretório /etc/haproxy/. O arquivo é dividido em blocos lógicos bem definidos, começando pela seção global, onde definimos parâmetros de baixo nível do sistema operacional, como o número máximo de processos simultâneos e o usuário que executará o serviço.

Logo abaixo, encontramos a seção defaults, que estabelece regras padrão de tempo limite e comportamento para os blocos seguintes. É fundamental configurar corretamente os limites de tempo, conhecidos como timeouts. Por exemplo, definir um limite para o tempo que o HAProxy espera por uma resposta do servidor evita que conexões travadas mantenham portas de rede ocupadas indefinidamente, esgotando os recursos da máquina.

global
    log /dev/log local0
    maxconn 50000
    user haproxy
    group haproxy

defaults
    log     global
    mode    http
    option  httplog
    timeout connect 5s
    timeout client  50s
    timeout server  50s

Configurando frontends e backends para alta disponibilidade

O coração operacional do HAProxy reside na dupla frontend e backend. O frontend define como o balanceador aceita as conexões dos clientes, escutando em portas específicas e endereços IP públicos. É nele que aplicamos regras de segurança, certificados SSL para criptografia e inspeção inicial de pacotes, algo semelhante ao cuidado que tomamos ao analisar pacotes TCP em tempo real com tcpdump para entender gargalos de rede.

Já o backend agrupa os servidores reais que vão processar o trabalho pesado. Abaixo temos um exemplo prático de como declarar esses blocos, habilitando o algoritmo de menor número de conexões e configurando verificações automáticas de saúde para garantir que o tráfego nunca caia em um servidor morto.

frontend web_cluster_front
    bind *:80
    default_backend web_cluster_back

backend web_cluster_back
    balance leastconn
    option httpchk GET /healthz
    server web1 192.168.1.10:8080 check inter 3s rise 2 fall 3
    server web2 192.168.1.11:8080 check inter 3s rise 2 fall 3

Monitorando falhas e mantendo a resiliência operacional

Configurar o balanceamento de carga é apenas o primeiro passo; garantir que o sistema continue operando sem surpresas exige monitoramento ativo. O parâmetro check no arquivo de configuração instrui o HAProxy a enviar requisições periódicas — como um simples teste HTTP na rota /healthz — para confirmar se o aplicativo está vivo e respondendo corretamente.

Se um servidor falhar em três tentativas consecutivas (definido pelo parâmetro fall 3), o HAProxy o remove imediatamente da rota de distribuição, redirecionando os novos clientes para os servidores restantes. Quando o problema é resolvido e o servidor responde com sucesso duas vezes seguidas (rise 2), ele é reintegrado automaticamente. Esse ciclo autônomo de autocura reduz drasticamente a necessidade de intervenção humana durante a madrugada quando incidentes ocorrem. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como testar a bateria CMOS da placa-mãe com multímetro.

Considerações finais sobre performance e escalabilidade

Dominar a configuração do HAProxy permite transformar uma infraestrutura frágil em um ambiente capaz de absorver picos massivos de acesso sem perder a estabilidade. O segredo está em alinhar a escolha do algoritmo de distribuição com o perfil real da aplicação, ajustar com precisão os parâmetros de timeout e manter verificações de saúde rigorosas em todos os nós de backend. Com essas práticas implementadas, sua arquitetura ganha a robustez necessária para crescer de forma sustentável e segura.