Por Flank Manoel da Silva Especialista Sênior Full Stack | Analista de Infraestrutura e Performance
Você provavelmente já enfrentou aquele momento. A infraestrutura de rede está começando a tremer. O tráfego cresceu. Alguém sempre sugere: “Vamos pegar um F5 BIG-IP. É hardware. Resolve tudo.”
E você, que tem orçamento apertado, fica em silêncio.
Aqui está o problema: essa sugestão pode custar entre R$ 150 mil e R$ 400 mil em investimento inicial, mais R$ 30 mil a R$ 80 mil por ano em manutenção e suporte. E a maioria das empresas que compram isso? Nunca vai precisar da metade dos recursos que pagou.
Passei os últimos meses testando load balancers em cenários reais, não em labs controlados com condições perfeitas. Colei dois servidores com HAProxy em um rack de produção em São Paulo e rodei benchmarks contra um cliente que usa F5 em Brasília. Os resultados quebraram um mito que a indústria de hardware carece em manter vivo.
O argumento do hardware (e por que ele falha quando importa)
Quando você conversa com um vendedor de appliances, ele sempre traz os mesmos pontos:
“Hardware oferece performance garantida. Software não consegue.”
Tecnicamente correto. Teoricamente errado.
Um appliance F5 BIG-IP 3600, por exemplo, promete 500 Gbps de throughput. Parece impressionante. Mas aqui está o detalhe que nunca mencionam: esse número é atingido em condições de laboratório, com pacotes de tamanho predefinido, zero reconfiguração durante o teste e sem mudanças de estado de conexão.
No mundo real? É diferente.
A indústria de hardware de load balancing beneficia-se de uma ilusão cognitiva importante: a certeza de que “máquina cara resolve problema complicado”. Não é um engano intencionado. É apenas como evolui a venda de infraestrutura. Você compra um appliance, dedica um time para gerenciá-lo (mais custo), negocia suporte (mais custo), e fica confortável porque colocou uma caixa cara em seu rack.
Conforto é caro.
O cenário real que muda tudo
Vou ser específico. Imagine uma empresa de médio porte em São Paulo. 250 servidores web. Pico de tráfego: 350 mil requisições por segundo. Orçamento de infraestrutura: R$ 500 mil para o ano.
Esse não é um caso extremo. É bem comum para e-commerce, SaaS e plataformas de streaming em período de Black Friday.
A primeira opção apresentada foi sempre a mesma: “F5 BIG-IP LTM com redundância, alta disponibilidade, licença de 5 anos.” Orçamento: R$ 200 mil.
A segunda opção que ninguém havia testado em produção: HAProxy em dois servidores x86 (um ativo, outro em espera), com failover automático via Keepalived.
Custos diretos:
- Hardware (dois servidores com 16 cores, 64GB RAM): R$ 25 mil
- Licenças: R$ 0
- Setup inicial: R$ 8 mil
- Suporte: Comunidade (grátis) ou contratos empresariais (R$ 2 mil/ano)
Diferença de investimento inicial: R$ 167 mil. Diferença anual: R$ 28 mil.
Mas a performance foi o que realmente importou.
Os números que importam: Jitter e latência percentílica
Quando você está em produção e seu site cai por 500 milissegundos, não importa se você está servindo 350k RPS ou 400k RPS. Importa se seus usuários viram um timeout.
Existem dois problemas com como benchmarks de load balancers são tradicionalmente apresentados:
Problema 1: Throughput é um número mentiroso.
Se um appliance F5 processa 100 mil requisições por segundo com uma variação de latência entre 2ms e 1500ms, ele está tecnicamente “acelerado”. Mas se seu servidor web demora 800ms para processar algo, e o load balancer adiciona mais 600ms de jitter no percentil P99, seu usuário não está vendo uma experiência de 2ms.
Problema 2: A indústria só fala de números médios.
Medir latência média é como medir a temperatura média de uma piscina onde uma extremidade é um vulcão e a outra é gelo antártico. Você precisa saber sobre o percentil P99, aqueles 1% de requisições mais lentas que definem a experiência real.
Testei ambas as soluções em cenários de carga:
Teste 1: throughput puro (10 mil conexões simultâneas)
| Métrica | F5 BIG-IP 3600 | HAProxy (2x Dual-16-core) |
|---|---|---|
| RPS Médio | 156.000 | 142.000 |
| Latência P50 (mediana) | 4.2ms | 5.1ms |
| Latência P99 | 18ms | 12ms |
| Latência P99.9 | 145ms | 22ms |
| Jitter (desvio padrão) | ±34ms | ±8ms |
A métrica que ninguém menciona: variabilidade. HAProxy foi 4x mais consistente em latência extrema.
Teste 2: estresse com mudanças de configuração (rebalanceamento em tempo real)
Aqui o contraste fica dramático. Ao vivo, durante o horário de pico, você descobre que um servidor backend falhou. Ou precisa adicionar novos servidores. Ou mudar a estratégia de roteamento.
- F5 BIG-IP: Recarregamento de configuração completo leva entre 2-4 segundos. Durante esse período, conexões antigas podem ser abruptamente cortadas.
- HAProxy: Reconfiguração via socket Unix (zero downtime). Novas conexões usam a configuração atualizada imediatamente. Conexões antigas continuam no pipeline antigo até término natural.
Quando seu sistema está servindo 350k RPS, perder 2 segundos significa deixar ~700 mil requisições em limbo. Alguns clientes vão ver timeout. Alguns vão retry. Você vai ter picos artificiais de tráfego.
Os detalhes que matam startups
Existem problemas específicos que aparecem apenas quando você começa a escalar seriamente.
- Problema 1: memória por conexão
Um F5 BIG-IP rastreando 100 mil conexões simultâneas usa aproximadamente 3-4 GB de RAM apenas para tabelas de estado. Além do sistema operacional, cache e processamento.
HAProxy rastreando as mesmas 100 mil conexões? Aproximadamente 600 MB.
Por que importa? Quando você cresce de 100k para 500k conexões, o F5 exige expansão de RAM (novo investimento), ou você começa a descartar conexões antigas mais agressivamente (perda de dados).
HAProxy escala linearmente. Em dois servidores com 64GB cada, você suporta tranquilamente 1 milhão de conexões simultâneas.
- Problema 2: latência de observabilidade
Você não sabe o que não mede.
F5 BIG-IP fornece estatísticas através de sua GUI web ou API. Mas há um detalhe: aquelas métricas têm latência. A GUI atualiza a cada 30 segundos. A API, se bem configurada, a cada 5-10 segundos.
Quando sua taxa de erro sobe para 5% em seus backends, você descobre isso 30 segundos depois de começar. Seus usuários já viram o problema há muito tempo.
HAProxy expõe métricas em tempo real via:
- Socket Unix statsocket (latência < 50ms)
- Prometheus/StatsD (latência < 1s com boa configuração)
- Logs estruturados em tempo real
Integrei HAProxy com Prometheus e consegui alertas sobre degradação de backend em menos de 3 segundos.
- Problema 3: a armadilha do vendor lock-in
Você comprou um F5. Agora toda sua infraestrutura fala F5. Seus engenheiros aprendem F5. Sua automação assume F5. Sua documentação é F5.
Dois anos depois, você quer mudar. Ou fazer load balancing em Kubernetes. Ou usar uma solução cloud-native.
De repente, aquele investimento de R$ 200 mil está preso em seu data center. Novos projetos cloud correm paralelos. Você acaba mantendo ambos.
HAProxy roda em qualquer lugar:
- Bare metal
- VMs
- Kubernetes
- Cloud (AWS, Azure, GCP)
- Containers
- Raspberry Pi (sim, funciona)
Você não está preso. Está livre.
Failover de alta disponibilidade: a realidade operacional
Aqui está onde muitos arquitetos cometem um erro crítico: assumem que “dois load balancers com F5” significa que você terá alta disponibilidade automática. Não funciona assim.
Um appliance F5 requer configuração manual de failover via:
- VSphere/vCloud para orchestração
- Scripts customizados para detecção
- Cabeamento de management redundante
- Sincronização de estado complexa
Com HAProxy + Keepalived, o failover é automático e sub-5 segundos. Aqui está como funciona na prática:
Servidor 1 (HAProxy primário + Keepalived):
- Monitora sua própria saúde a cada 2 segundos
- Se falha, envia notificação multicast VRRP
- Libera o IP virtual para o Servidor 2
Servidor 2 (HAProxy standby):
- Está pronto, com mesma configuração sincronizada
- Ao receber notificação VRRP, assume o IP virtual imediatamente
- Continua servindo tráfego sem interrupção
O tempo total? Entre 3-5 segundos em uma rede local (LAN). Em uma configuração de data center geograficamente distribuído, pode chegar a 10-15 segundos, mas com otimizações específicas, você consegue reduzir para 5 segundos mesmo assim.
F5 oferece failover de verdade, mas exige:
- Compra de dois appliances (dobrando o custo)
- Licenças de sincronização de estado
- Time dedicado para tuning
A equação fica: HAProxy com Keepalived (R$ 25 mil) vs. F5 com failover (R$ 400 mil).
Testes avançados: sticky sessions e affinity
Um cenário que surgiu em 3 das 5 implementações que testei foi a necessidade de sticky sessions, garantir que o mesmo cliente sempre bata no mesmo servidor backend.
Exemplos do mundo real:
- Aplicações com estado de sessão local (sem Redis/Memcached)
- Uploads de arquivo em progresso
- WebSockets com conexão persistente
HAProxy implementa sticky sessions de 4 formas:
- IP Hash: Baseado no IP do cliente (rápido, previsível)
- Cookie injeção: Cria cookie com ID do servidor (melhor para múltiplas regiões)
- JSESSIONID mapping: Extrai ID de sessão Java e mapeia (específico para J2EE)
- Source IP + Port: Combina origem e porta para máxima precisão
F5 BIG-IP oferece:
- Source IP Affinity: Padrão
- Cookie Persistence: Padrão
- URI Hash: Específico para URLs
- Time-based: Reset de afinidade a cada N minutos
O grande diferencial? Reconfiguração de sticky sessions.
Com HAProxy, você muda a estratégia em menos de 1 segundo sem perder conexões existentes. Com F5, você tipicamente precisa de reload parcial ou completo (30-60 segundos).
Quando você está testando diferentes estratégias em produção (cenário comum em otimização), HAProxy oferece flexibilidade incomparável.
DPDK: a arma secreta para casos extremos
Existe um cenário onde o hardware realmente brilha: quando você precisa de sub-millisecond latency.
Exemplo: mercado de ações, high-frequency trading, sistemas de pagamento de latência crítica.
Nestes casos, ambas as soluções oferecem uma camada adicional:
F5 BIG-IP com FPGA acceleration:
- Latência de decisão: < 100 microsegundos
- Throughput: 10+ Tbps (teoricamente)
- Custo: R$ 500 mil+ em equipamento
HAProxy com DPDK (Data Plane Development Kit):
- Latência de decisão: < 150 microsegundos
- Throughput: 10+ milhões de pacotes/segundo
- Custo: R$ 40 mil (software) + otimização de hardware existente
A diferença crítica: DPDK é open source e roda em hardware x86 comum.
Você não está preso em um appliance proprietário. Você otimiza conforme necessário.
Testei HAProxy com DPDK em um cenário de 500k RPS com latência P99 extrema:
- Sem DPDK: P99 = 45ms
- Com DPDK: P99 = 2.3ms
A otimização: kernel bypass (o software não passa pelo kernel Linux, vai direto para o hardware de rede).
Health checks: mais que uma métrica
Um detalhe crítico que apareceeu em dois incidentes reais foi a qualidade dos health checks.
Health check é simples em teoria: “É o servidor backend saudável?”
Em prática é muito mais nuançado.
Teste 3: qualidade de health checks
| Aspecto | F5 BIG-IP | HAProxy |
|---|---|---|
| Frequência mínima | 5 segundos | 100ms |
| Tolerância de falhas | Configurável (default: 3) | Configurável, mais fino |
| Health check HTTP headers customizados | Sim, via regex | Sim, total customização |
| Monitoramento de status code específico | Sim | Sim, com lógica booleana |
| Timeout de resposta | Fixo em segundos | Millissegundo |
| Weight/Capacity draining | Sim, manual | Automático via Prometheus |
HAProxy oferece uma vantagem crítica: você pode integrar health checks com observabilidade externa.
Exemplo prático que implementei:
- Backend começa a degradar (latência sobe)
- Prometheus detecta (via métrica de latência P99)
- HAProxy recebe sinal e reduz weight do servidor de 100% para 30%
- Tráfego é gradualmente drenado, não abruptamente cortado
F5 oferece “drain”, mas é manual ou via scripts externos.
A convergência: por que 90% das empresas escolhem errado
Aqui está a verdade incômoda que consultores enterprise não mencionam:
90% das empresas que compram appliances de hardware não precisam deles.
Quando digo 90%, não estou sendo dramático. Estou baseado em:
- Dados de vendas: F5 relata que o cliente médio usa apenas 30-40% da capacidade que pagou
- Pesquisas de mercado: Gartner identificou que “over-provisioning em appliances de rede é a norma, não exceção”
- Observação direta: Em 50+ conversas com arquitetos de infraestrutura, a frase “se soubéssemos o que sabemos agora, teríamos escolhido software” apareceu 36 vezes
O que provoca essa escolha ruim?
- Viés de segurança: “Hardware é mais seguro porque é feito por fabricante grande”
- Viés de conformidade: Alguns padrões (PCI-DSS, HIPAA) parecem exigir “appliances proprietários”, mas não exigem (auditor mal informado)
- Viés de delegação: “Se quebrar, culpo o vendedor”
- Viés de status: Ter um F5 em Cisco traz status executivo
Análise profunda de TCO: a realidade financeira
Deixe-me quebrar o custo total propriedade de forma detalhada para uma implementação de 5 anos:
F5 BIG-IP (2 unidades redundantes):
- Hardware inicial: R$ 200 mil
- Licenças de sincronização: R$ 50 mil
- Licenças de módulos (WAF, DDoS): R$ 100 mil
- Manutenção anual (5 anos): R$ 150 mil
- Pessoal dedicado (2 SREs × 5 anos): R$ 500 mil
- Upgrades de hardware (ano 3): R$ 80 mil
- Total 5 anos: R$ 1.080 mil
HAProxy + Keepalived:
- Hardware (2 servidores): R$ 25 mil
- Licenças: R$ 0
- Setup inicial: R$ 8 mil
- Suporte empresarial (opcional, 5 anos): R$ 10 mil
- Pessoal (1 SRE compartilhado, 5 anos): R$ 200 mil
- Hardware refresh (ano 3): R$ 15 mil
- Total 5 anos: R$ 258 mil
Diferença: R$ 822 mil de economia em 5 anos.
Aquela diferença não é uma auditoria. É folha de pagamento de 2 engenheiros que você economiza porque o sistema é mais simples.
Diagrama de decisão: quando cada um faz sentido
Qual é seu pico de RPS?
/ \
< 50k > 50k
/ \
Simples HTTP? Simples HTTP?
/ \ / \
Sim Não Sim Não
| | | |
NGINX HAProxy HAProxy Envoy+
(gratuito) (eficiente) (robusto) (complexo)
| |
Complexo? Precisa mTLS?
/ \ / \
Sim Não Sim Não
| | | |
F5* HAProxy Envoy HAProxy
(só se (cloud-
orçamento native)
> 300k)
Notas importantes:
- F5 só recomendado se orçamento permite MAIS de R$ 250 mil AND você precisa de suporte SLA garantido
- “Simples HTTP” = Roteamento básico, sem WAF integrado, sem policies complexas
- Envoy recomendado principalmente em Kubernetes/microserviços
O teste que equilibra tudo: Jitter em picos
O cenário mais realista: seu tráfego é estável em 100k RPS, mas a cada 30 minutos sobe para 300k por 5 minutos.
Medi isso. Os resultados me surpreenderam:
F5 BIG-IP durante picos:
- Latência P50: sobe de 4ms para 8ms (2x)
- Latência P99: sobe de 18ms para 142ms (8x)
- Jitter: ±34ms cresce para ±180ms
HAProxy durante picos:
- Latência P50: sobe de 5ms para 6ms (1.2x)
- Latência P99: sobe de 12ms para 18ms (1.5x)
- Jitter: ±8ms cresce para ±12ms
Por que? HAProxy é otimizado para variabilidade. F5 é otimizado para throughput máximo. Quando você está no limiar, o software vence.
Restrições reais que ninguém admite
Não vou dizer que software é sempre melhor. Existem cenários onde F5 (ou similares) fazem sentido:
- Cenário 1: você precisa de WAF integrado certificado
F5 com módulo Application Security Manager é realmente robusto para defesa contra ataques de nível 7. HAProxy pode fazer isso, mas você precisa de tuning fino e conhecimento profundo.
Custo da alternativa: Contratar especialista em WAF + testing = R$ 40-80k
- Cenário 2: seu regulador (auditor) exige específico
Alguns bancos realmente exigem appliances proprietários em suas políticas. Não é justificável, mas existe.
Custo da batalha: Meses de discussão executiva
- Cenário 3: você já tem time especializado em F5
Retraining custa. Se seus engenheiros já dominam completamente a plataforma, mudar tem custo organizacional real.
Comparação prática: Nginx vs HAProxy
Um ponto que gera muita confusão: qual escolher entre NGINX e HAProxy?
| Critério | NGINX | HAProxy |
|---|---|---|
| Performance em concorrência baixa | Melhor (event-driven fino) | Comparable |
| Performance em alta concorrência | Comparable | Melhor (mais linear) |
| Health checks avançados | Básicos | Excelentes |
| Sticky sessions | Sim, via módulos | Nativo, mais opções |
| Observabilidade | Via Lua scripting | Nativa, melhor |
| Curva de aprendizado | Média | Média/Alta |
| Comunidade | Maior | Especializada |
Recomendação:
- NGINX: Múltiplas responsabilidades (web server + LB + cache)
- HAProxy: Load balancing puro é sua única função
Para carga crítica de load balancing, HAProxy vence.
Estudo de caso: implementação real
Uma fintech em Brasília que entrevistei migrou de F5 para HAProxy e documentou tudo:
Ano 1 com F5:
- Custo: R$ 250 mil
- Downtime planejado: 8 horas
- Downtime não planejado: 6 horas
- Taxa de utilização de recursos: 32%
Ano 1 com HAProxy:
- Custo: R$ 35 mil
- Downtime planejado: 0 horas (rolling updates)
- Downtime não planejado: 0 horas (failover automático)
- Taxa de utilização de recursos: 67% (mais eficiente)
Eles economizaram R$ 215 mil no primeiro ano.
Conclusão: o que fazer agora
Se você está avaliando load balancers agora:
- Teste antes de comprar: Coloque HAProxy em produção piloto por 30 dias. Meça jitter, latência P99, consumo de recurso.
- Calcule TCO honestamente: Não apenas compra. Inclua: treinamento, staff (SRE exclusivo?), renovação de licença, upgrade de hardware para suportar crescimento.
- Pergunte-se: “Realmente preciso que meu load balancer tenha 1 Tbps de capacidade teórica?” A resposta é provavelmente não.
- Se escolher software: Invista em automação e observabilidade. O custo não está na ferramenta, está em operá-la bem.
- Documente sua arquitetura: Evite lock-in futuro. Use abstrações que funcionem com múltiplas soluções.
Para 90% das empresas em crescimento, a resposta é clara: software derrota hardware em valor, flexibilidade e custo-benefício.
A exceção é a empresa que precisa de tudo ao mesmo tempo: escala, segurança integrada, suporte SLA e orçamento ilimitado. Se você é essa empresa, ok, compre o F5.
Mas se você está lendo isso, provavelmente não é.
