Cloud Server com HAProxy sem gargalo de tráfego

Resposta direta

Um Cloud Server para HAProxy deve ser escolhido pelo volume real de conexões, tráfego de rede, tipo de aplicação e tolerância a falhas, não apenas pela quantidade de vCPUs. Para um balanceador HTTP pequeno, 1 a 2 vCPUs, 1 a 2 GB de RAM e rede estável já podem atender bem. Em produção, o ponto de partida mais seguro costuma ser 2 vCPUs, 4 GB de RAM, disco SSD ou NVMe para logs e pelo menos dois servidores de aplicação atrás do HAProxy. Se o HAProxy for terminar TLS, aplicar regras por domínio, expor métricas e lidar com picos, CPU e rede ficam mais relevantes. Para evitar ponto único de falha, use dois balanceadores, health checks, automação de failover e backups da configuração.

Resumo rápido

• HAProxy é indicado para balanceamento HTTP, HTTPS e TCP com alta previsibilidade e baixo consumo de recursos.
• Um ambiente inicial em produção pode começar com 2 vCPUs, 4 GB de RAM, 40 GB de SSD e boa franquia de tráfego.
• Terminação TLS aumenta o uso de CPU, principalmente com muitos handshakes por segundo.
• Health checks bem configurados evitam enviar usuários para aplicações travadas ou em deploy.
• O HAProxy sozinho vira ponto único de falha se não houver par redundante, IP flutuante, DNS planejado ou outro mecanismo de failover.
• Logs, métricas e alertas precisam ser dimensionados desde o início, porque balanceador sem visibilidade vira caixa-preta.
• Datacenter próximo do público reduz latência, especialmente quando o tráfego brasileiro passa por múltiplas camadas de proxy.

Quando faz sentido usar HAProxy em Cloud Server

HAProxy em Cloud Server faz sentido quando você precisa controlar como o tráfego chega às aplicações, mas não quer depender de um balanceador gerenciado fechado. Ele permite rotear por domínio, caminho, porta, header, SNI, IP de origem e status de saúde dos backends. Na prática, isso resolve cenários comuns: distribuir requisições entre três APIs Node.js, separar tráfego de painel administrativo e API pública, publicar um banco via TCP privado, ou fazer blue-green deploy sem trocar DNS a cada release.

O HAProxy costuma aparecer em arquiteturas nas quais Nginx, Caddy ou Traefik também seriam candidatos. A diferença está no foco. Nginx é muito usado como servidor web e reverse proxy. Caddy simplifica TLS automático. Traefik conversa muito bem com Docker e Kubernetes. HAProxy brilha quando a prioridade é balanceamento previsível, observabilidade de conexões, health checks maduros e regras de tráfego bem explícitas. Se você ainda está comparando esses papéis, o guia sobre reverse proxy com Nginx, Caddy e Traefik ajuda a separar proxy reverso, gateway de entrada e balanceador.

O papel do HAProxy na arquitetura

Em uma arquitetura simples, o usuário acessa app.exemplo.com, o DNS aponta para o Cloud Server do HAProxy e o HAProxy distribui as requisições para app-01, app-02 e app-03. Esses backends podem estar em rede privada, com portas internas fechadas para a internet. O balanceador recebe HTTPS na porta 443, valida se cada aplicação responde em /health, escolhe um servidor disponível e registra logs com status, tempo de resposta e backend usado.

Cloud Server, VPS tradicional e load balancer gerenciado

A escolha entre VPS tradicional, Cloud Server e load balancer gerenciado depende do controle desejado. Uma VPS tradicional pode atender projetos pequenos, mas geralmente oferece menos flexibilidade para crescer rede, CPU e recursos de alta disponibilidade. Um Cloud Server costuma entregar provisionamento mais rápido, snapshots, APIs e redes privadas, embora esses recursos variem por provedor e plano. Já o load balancer gerenciado reduz operação, mas limita ajustes finos e pode custar mais em tráfego intenso. Para times que querem aprender, auditar e customizar regras, HAProxy em Cloud Server continua sendo uma solução muito forte.

Como dimensionar CPU, RAM, rede e disco

Dimensionar Cloud Server para HAProxy exige olhar para quatro números: conexões simultâneas, requisições por segundo, volume de tráfego e custo de TLS. Um erro comum é escolher o plano pela RAM, como se o balanceador fosse um banco de dados. Em muitos casos, HAProxy consome pouca memória, mas pode exigir CPU consistente quando termina HTTPS, comprime respostas, registra logs detalhados ou mantém milhares de conexões abertas. Um tráfego de 100 requisições por segundo com respostas pequenas não pesa igual a 100 requisições por segundo entregando arquivos de 5 MB.

Para uma API pequena, 2 vCPUs e 4 GB de RAM dão margem confortável. Se o HAProxy apenas repassa TCP ou HTTP interno, sem TLS pesado, a CPU tende a ficar baixa. Se ele termina TLS para 20 domínios, aplica redirects, inspeciona headers e lida com picos de login, o consumo sobe. Um servidor com 1 vCPU pode funcionar em laboratório, mas em produção deixa pouca folga para spikes, rotação de logs, agentes de monitoramento e atualizações do sistema.

Estimando conexões e throughput

Um cálculo prático ajuda. Imagine uma aplicação SaaS com 300 usuários simultâneos, cada um abrindo 6 conexões HTTP/2 ou mantendo WebSocket. Você pode chegar a 1.800 conexões ativas, mesmo sem tráfego absurdo. Agora some health checks a cada 5 segundos para 6 backends, métricas, painéis internos e requisições automatizadas. O gargalo pode não ser RAM, mas limite de arquivos abertos, backlog TCP, portas efêmeras e rede. Ajustes como ulimit -n 200000, net.core.somaxconn=65535 e net.ipv4.ip_local_port_range="1024 65000" podem ser necessários em ambientes maiores.

Configurações iniciais por porte

Para homologação, 1 vCPU, 1 GB de RAM e 20 GB de SSD bastam para testar regras e deploys. Para produção pequena, use 2 vCPUs, 4 GB de RAM, 40 GB de SSD e rede com boa previsibilidade. Para e-commerce, API pública ou painel B2B com tráfego constante, 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe dão mais folga para TLS, logs e monitoramento. Disco rápido não acelera o balanceamento em si, mas evita travamentos quando logs crescem ou quando o sistema faz rotação e compressão em horário de pico.

Arquitetura prática para balanceamento de carga

A arquitetura mais comum com HAProxy usa uma camada pública, uma rede privada e múltiplos servidores de aplicação. O Cloud Server do HAProxy recebe tráfego nas portas 80 e 443. Os backends ficam em IPs privados, por exemplo 10.10.0.11, 10.10.0.12 e 10.10.0.13, escutando na porta 8080. O firewall libera acesso público apenas ao balanceador. Entre balanceador e aplicação, o tráfego passa pela rede privada do provedor, reduzindo exposição e simplificando regras de segurança.

Essa topologia funciona bem para aplicações web, APIs REST, GraphQL, WebSocket e serviços TCP. Em uma API Laravel com filas, por exemplo, o HAProxy não precisa conhecer Redis, workers ou banco. Ele só precisa saber se o endpoint /health está saudável e quanto peso cada backend deve receber. Durante um deploy, você pode tirar app-02 do pool, atualizar o código, validar a resposta, recolocar o servidor e repetir o processo com app-03. O usuário percebe menos instabilidade, porque o tráfego continua indo para instâncias saudáveis.

HTTP, TCP e TLS

No modo HTTP, o HAProxy entende métodos, paths, hosts e headers. Isso permite regras como enviar /api para um pool e /admin para outro. No modo TCP, ele não interpreta a aplicação, apenas encaminha conexões. Esse modo é útil para PostgreSQL, Redis, MQTT, SMTP ou TLS passthrough. Para HTTPS, há duas estratégias: terminar TLS no HAProxy ou repassar TLS até o backend. Terminar no HAProxy facilita certificados, redirects e headers de segurança. Repassar TLS preserva criptografia ponta a ponta, mas reduz a capacidade de roteamento por path.

Health checks, pesos e persistência

Health check ruim é pior do que não ter balanceamento. Um endpoint /health que só retorna 200 não garante que a aplicação acessa banco, cache ou fila. Em produção, prefira checagens leves, mas reais: banco com timeout curto, cache opcional e versão do build. Use rise 2 e fall 3 para evitar alternância agressiva. Pesos ajudam em migrações graduais, como enviar 80 por cento para app-01 e 20 por cento para app-02. Para sessões legadas sem storage compartilhado, cookies de persistência podem ser usados, mas o ideal é tornar a aplicação stateless.

Configuração base do HAProxy em produção

A configuração do HAProxy deve ser simples o suficiente para qualquer pessoa do time entender às 3 da manhã. Um arquivo grande, cheio de exceções sem comentário, vira risco operacional. O básico envolve blocos global, defaults, frontend e backend. No global, você define logs, usuário de execução, limites e sockets administrativos. No defaults, entram timeouts, modo HTTP ou TCP e opções comuns. O frontend recebe o tráfego público. O backend lista servidores, health checks, algoritmo de balanceamento e regras de persistência.

Um exemplo de configuração HTTP com terminação TLS pode começar assim:

global
    log /dev/log local0
    maxconn 50000
    user haproxy
    group haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin

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

frontend web_https
    bind *:443 ssl crt /etc/haproxy/certs/app.pem alpn h2,http/1.1
    http-request set-header X-Forwarded-Proto https
    acl host_api hdr(host) -i api.exemplo.com
    use_backend api_pool if host_api
    default_backend web_pool

backend api_pool
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server api01 10.10.0.11:8080 check inter 5s fall 3 rise 2
    server api02 10.10.0.12:8080 check inter 5s fall 3 rise 2

Exemplo de haproxy.cfg

O algoritmo roundrobin distribui requisições de forma simples e previsível. Para APIs com tempos de resposta variáveis, leastconn pode funcionar melhor, porque direciona novas conexões para o backend com menos conexões ativas. Em aplicações com servidores de tamanhos diferentes, use peso: server api02 10.10.0.12:8080 check weight 50. Isso faz o servidor receber menos tráfego que outro com weight 100. O ajuste é útil durante migrações, testes canário e substituição gradual de instâncias.

Logs, métricas e validação

Depois de alterar o arquivo, valide antes de recarregar: haproxy -c -f /etc/haproxy/haproxy.cfg. Em seguida, use reload gracioso com systemctl reload haproxy, não restart seco, para reduzir queda de conexões. Exponha métricas com cuidado. A página de stats pode ficar em rede privada ou protegida por autenticação forte. Para Prometheus, use exporter ou recursos compatíveis com sua versão do HAProxy. Logs devem ir para syslog, journald ou agente dedicado, com rotação. Um diretório /var/log lotado pode derrubar mais do que uma regra errada.

Alta disponibilidade, failover e riscos do ponto único

HAProxy melhora a distribuição de tráfego entre aplicações, mas não cria alta disponibilidade sozinho. Se todo o tráfego aponta para um único Cloud Server, esse servidor vira ponto único de falha. Uma atualização mal aplicada, pane no host físico, bloqueio de rede, erro de firewall ou certificado vencido pode deixar todos os backends inacessíveis, mesmo que as aplicações estejam saudáveis. Por isso, o desenho de produção precisa prever dois balanceadores ou uma alternativa gerenciada.

O modelo clássico usa dois Cloud Servers com HAProxy, um ativo e outro passivo. O par compartilha um IP flutuante, quando o provedor oferece esse recurso, ou usa DNS com TTL baixo e automação de troca. Ferramentas como Keepalived podem controlar VRRP em redes compatíveis, mas essa compatibilidade depende do ambiente cloud. Em alguns provedores, VRRP não funciona como em rede física tradicional. Nesses casos, IP flutuante via API ou load balancer gerenciado na frente pode ser mais realista.

Par ativo-passivo

No ativo-passivo, apenas um HAProxy recebe tráfego. O secundário mantém a mesma configuração, certificados, regras e versão do pacote. Um monitor verifica se o primário responde. Se falhar, o IP flutuante muda para o secundário ou o DNS passa a apontar para ele. Parece simples, mas há detalhes: certificados precisam estar sincronizados, o relógio do sistema deve estar correto, o firewall dos dois nós deve ser idêntico e o processo de failover precisa ser testado com tráfego realista. O artigo sobre alta disponibilidade e failover aprofunda essas decisões de arquitetura.

DNS, IP flutuante e automação

DNS com TTL de 30 ou 60 segundos ajuda, mas não garante troca instantânea, porque resolvers podem cachear por mais tempo. IP flutuante tende a ser mais rápido quando suportado pelo provedor e pela região. Uma terceira opção é usar Anycast ou balanceamento global, mas isso já entra em arquitetura mais cara e complexa. Para muitos projetos brasileiros, dois HAProxy em Cloud Servers na mesma região, com backups de configuração e teste mensal de failover, já reduzem bastante o risco. Se o público está no Brasil, também faz sentido analisar latência e rota de rede com cuidado, como explicado no conteúdo sobre baixa latência no Brasil.

Segurança e operação diária do balanceador

O balanceador fica na borda da aplicação. Isso significa que ele recebe tráfego legítimo, bots, scanners, tentativas de exploração e picos inesperados. A primeira camada de segurança é reduzir superfície: liberar apenas 80, 443 e portas administrativas estritamente necessárias, preferencialmente restritas por IP ou VPN. SSH deve usar chave, desabilitar login por senha e ter usuário não root para operação diária. O HAProxy deve rodar com usuário próprio, sem privilégios desnecessários, e o sistema precisa receber atualizações de segurança com janela planejada.

TLS merece atenção especial. Certificados vencidos derrubam vendas, APIs e painéis. Automatize renovação com Certbot, acme.sh ou fluxo equivalente, mas teste reload pós-renovação. Em ambientes com muitos domínios, use um diretório organizado para certificados e monitore validade com alerta 15 e 7 dias antes do vencimento. Headers como Strict-Transport-Security, X-Frame-Options e X-Content-Type-Options podem ser definidos no HAProxy, mas precisam respeitar a aplicação. HSTS mal aplicado pode causar dor em subdomínios antigos.

Firewall, TLS e headers

Um exemplo de regra prática é deixar backends acessíveis apenas pelo IP privado do HAProxy. Em Linux com UFW, o backend poderia liberar ufw allow from 10.10.0.10 to any port 8080 e negar o restante. No balanceador, rate limits simples podem reduzir abuso, como limitar tentativas em /login por IP. HAProxy tem recursos de stick tables para isso, mas use com cuidado para não bloquear usuários atrás de NAT corporativo ou operadoras móveis. Para proteção contra DDoS volumétrico, a solução precisa estar antes do Cloud Server, no provedor ou em rede especializada.

Backups, rollback e testes

A configuração do HAProxy deve estar em Git, com revisão por pull request sempre que possível. Antes de cada mudança, rode validação sintática e teste em homologação. Mantenha cópia dos certificados, scripts de renovação, arquivos de systemd, parâmetros de kernel e regras de firewall. Backups do disco ajudam, mas não substituem infraestrutura como código. Um rollback rápido pode ser tão simples quanto git checkout de uma versão anterior seguido de validação e reload. O segredo é treinar antes da crise, não durante o incidente.

Tabela comparativa de perfis de Cloud Server

A escolha do plano deve seguir o perfil de tráfego e a criticidade, não uma recomendação única. A tabela abaixo usa faixas conservadoras para começar o planejamento. Ela não substitui teste de carga, porque aplicações com WebSocket, uploads, TLS intenso ou respostas grandes podem exigir mais rede e CPU. Também não compara preço, já que valores mudam por região, moeda, promoção e imposto. Antes de contratar, confirme limite de tráfego, velocidade de porta, disponibilidade de IP flutuante, rede privada, snapshots e tipo de armazenamento no site oficial do provedor.

Perfil de uso	Configuração inicial sugerida	Tráfego típico	Pontos de atenção	Exemplo prático
Homologação e testes	1 vCPU, 1 GB RAM, 20 GB SSD	Até 50 req/s em teste controlado	Sem redundância, logs pequenos, TLS simples	Validar regras por host, health check e deploy canário
Produção pequena	2 vCPUs, 4 GB RAM, 40 GB SSD	100 a 500 req/s, respostas leves	CPU para TLS, rotação de logs, monitoramento	API com 2 ou 3 backends em rede privada
Produção média	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	500 a 2.000 req/s, picos previsíveis	Limites de conexão, métricas, alertas e failover	SaaS B2B com WebSocket e múltiplos domínios
Tráfego crítico	2 nós de 4 a 8 vCPUs, 8 a 16 GB RAM	Depende de teste de carga e rede	IP flutuante, automação, DDoS, observabilidade	E-commerce, API pública ou plataforma com SLA interno

Provedores como DigitalOcean, Vultr, Linode Akamai, AWS Lightsail e LetsCloud podem ser avaliados para esse tipo de carga, desde que os recursos sejam confirmados por plano e região. DigitalOcean, Vultr e Akamai costumam ter documentação clara para instâncias e rede cloud. AWS Lightsail é atraente pela simplicidade, mas pode limitar arquiteturas mais customizadas quando comparado a serviços AWS mais avançados. LetsCloud pode fazer sentido quando a prioridade envolve presença regional, pagamento local ou proximidade com usuários brasileiros, mas recursos como NVMe, snapshots, backup automático e localidades específicas precisam ser validados no site oficial antes da publicação ou contratação.

Para benchmarking, use ferramentas como wrk, hey ou k6, sempre com cuidado para não testar contra produção sem autorização. Um teste simples poderia simular 200 conexões por 5 minutos contra /health e depois contra um endpoint real, medindo latência p95, p99, erros 5xx e uso de CPU no balanceador. Se a CPU passa de 70 por cento durante picos curtos, já existe sinal para aumentar plano, otimizar TLS, reduzir logs síncronos ou dividir tráfego entre dois HAProxy.

Recomendações por perfil

Dev solo

Para um desenvolvedor solo, o melhor caminho é começar simples e mensurável. Um Cloud Server com 1 ou 2 vCPUs, 1 a 2 GB de RAM e 20 a 40 GB de SSD é suficiente para aprender HAProxy, publicar uma API pequena e testar balanceamento entre dois backends. Use Ubuntu LTS ou Debian estável, mantenha o haproxy.cfg em Git e configure logs desde o primeiro dia. Não complique com failover automático antes de entender health checks, reload gracioso e certificados TLS. Se o projeto começa a receber clientes pagantes, suba para 2 vCPUs e 4 GB de RAM antes de o servidor virar gargalo.

Time pequeno ou agência

Times pequenos precisam de padronização. A recomendação é usar pelo menos 2 vCPUs, 4 GB de RAM, rede privada e dois ou três backends separados. Crie um template de configuração com blocos por domínio, health checks consistentes e logs centralizados. Para agência que hospeda múltiplos clientes, separe pools por projeto e evite misturar aplicações críticas com sites experimentais no mesmo backend. Um painel de métricas com taxa de erro, latência p95, conexões ativas e status dos servidores reduz muito o tempo de diagnóstico. O time também deve documentar como remover um backend do pool durante deploy ou manutenção.

Produção com tráfego crítico

Em produção crítica, não trate HAProxy como servidor único. Use dois balanceadores, preferencialmente em hosts físicos ou zonas distintas quando o provedor permitir, com IP flutuante, automação testada e cópia sincronizada de certificados. Comece com 4 vCPUs e 8 GB de RAM por nó, ajuste após teste de carga e mantenha margem de CPU para TLS. Monitore saturação de rede, erros 5xx, quedas de backend, fila de conexões e tempo de resposta por rota. Para e-commerce, fintech, healthtech ou SaaS com SLA contratual, inclua plano de rollback, simulado de failover e revisão humana antes de mudanças em regras de produção.