Como simular lentidão e caos em redes com o Toxiproxy
Aprenda a injetar falhas de rede, latência severa e perda de pacotes em ambientes de teste usando o Toxiproxy para validar sistemas distribuídos.
Resumo
- Injeção de atrasos artificiais em conexões TCP simula cenários reais de instabilidade na nuvem sem alterar o código da aplicação.
- A separação entre a API de controle e o proxy de dados permite automatizar falhas diretamente dentro de pipelines de testes integrados.
- Sistemas distribuídos modernos precisam falhar graciosamente diante de quedas parciais de rede em vez de travar por completo.
- O uso combinado de ferramentas de simulação de rede e auditorias com Ncat garante maior robustez operacional.
- Validações rigorosas de timeout evitam que conexões pendentes esgotem os recursos computacionais dos servidores backend.
Por que sua aplicação falha quando a rede fica lenta?
Quando desenvolvemos um software em computadores velozes conectados a redes locais ultrarrápidas, tudo parece funcionar perfeitamente. No entanto, o mundo real é implacável: servidores de nuvem sofrem com congestionamentos na internet, cabos submarinos são rompidos e conexões móveis oscilam o tempo todo. Na prática, isso significa que sua aplicação precisa lidar com atrasos e interrupções sem corromper dados ou travar a interface do usuário. Testar esses cenários desfavoráveis de forma controlada costumava ser uma tarefa complexa, exigindo alterações manuais nas configurações de roteadores ou firewalls.
Para resolver esse problema sem dor de cabeça, engenheiros utilizam softwares especializados em engenharia do caos voltados para a camada de rede. É aqui que entra o Toxiproxy, uma ferramenta fantástica desenvolvida pelo Shopify que atua como um intermediário inteligente entre sua aplicação e o banco de dados ou serviços externos. Em vez de mexer na infraestrutura física, você cria um proxy local que intercepta o tráfego de rede e aplica regras artificiais de degradação, permitindo observar exatamente como o seu código se comporta sob forte estresse operacional.
O que é o Toxiproxy e como ele funciona na prática
O Toxiproxy é composto essencialmente por duas partes: uma aplicação leve escrita em Go que gerencia as conexões TCP e uma API HTTP que permite alterar o comportamento dessas conexões em tempo de execução. Quando você inicia o Toxiproxy, ele abre uma porta que finge ser o seu serviço real — por exemplo, um banco de dados PostgreSQL. Sua aplicação passa a se conectar a essa porta do Toxiproxy em vez de ir direto ao banco. Na prática, qualquer pacote de dados que passa por ali pode sofrer atrasos, ser corrompido ou simplesmente desaparecer.
Essa abordagem modular transforma completamente a forma como criamos testes automatizados de integração. Em vez de depender da sorte para flagrar um erro de timeout em produção, você programa o seu ambiente de homologação para injetar intencionalmente duzentos milissegundos de latência durante uma rotina de pagamento. Para garantir que o tráfego permaneça transparente e auditável durante esses testes de estresse, equipes de engenharia frequentemente combinam essas simulações com análises profundas de pacotes, tal como inspecionar tráfego de rede corrompido com eBPF em ambientes Linux de alta performance.
Configurando o Toxiproxy com Docker Compose
A maneira mais limpa e rápida de rodar o Toxiproxy em sua máquina de desenvolvimento ou em um servidor de integração contínua é utilizando o Docker. Podemos criar um arquivo de configuração simples que levanta tanto a ferramenta quanto um serviço fictício para testes. Abaixo, temos um exemplo prático de estrutura para subir o Toxiproxy junto com uma aplicação cliente.
version: '3.8'
services:
toxiproxy-server:
image: shopify/toxiproxy:latest
ports:
- "8474:8474"
- "5433:5433"
command: ["/toxiproxy-server", "--host=0.0.0.0"]
app:
image: my-backend-service:latest
environment:
- DB_HOST=toxiproxy-server
- DB_PORT=5433
depends_on:
- toxiproxy-serverCom esse arquivo rodando, a porta 8474 fica livre para receber comandos de alteração de tráfego, enquanto a porta 5433 redireciona os pacotes para o destino final configurado via API. Essa separação garante que os testes ocorram de forma totalmente isolada, sem interferir em outros serviços do seu cluster ou homelab.
Criando o seu primeiro cenário de caos com toxics
No vocabulário do Toxiproxy, as regras de degradação de rede são chamadas de "toxics". Você pode adicionar toxics usando a interface de linha de comando oficial (cli) ou fazendo requisições HTTP diretas para a API de controle. Para demonstrar como injetar latência e perda de pacotes, vamos utilizar comandos práticos executados no terminal da sua bancada de testes.
Antes de aplicar qualquer regra de caos, precisamos cadastrar a rota que o Toxiproxy vai monitorar, apontando o endereço original do serviço. Siga os passos abaixo para configurar o proxy e injetar instabilidade:
- Cadastre o proxy apontando para o seu banco de dados ou serviço externo real:
curl -X POST http://localhost:8474/proxies -d '{"name": "database", "listen": "0.0.0.0:5433", "upstream": "192.168.1.50:5432"}' - Adicione um atraso artificial de quinhentos milissegundos com variação de cem milissegundos:
curl -X POST http://localhost:8474/proxies/database/toxics -d '{"type": "latency", "attributes": {"latency": 500, "jitter": 100}}' - Simule uma taxa de perda de pacotes de dez por cento para testar a resiliência das retentativas:
curl -X POST http://localhost:8474/proxies/database/toxics -d '{"type": "timeout", "attributes": {"timeout": 1000}}'
Ao executar esses comandos, qualquer requisição feita à porta 5433 sofrerá o impacto configurado instantaneamente. Isso permite que você avalie em tempo real se os seus serviços realizam novas tentativas de conexão de forma segura ou se entram em colapso por esgotamento de threads.
Considerações finais sobre resiliência em sistemas modernos
Simular falhas de rede de maneira intencional deixou de ser um luxo restrito a grandes empresas de tecnologia e passou a ser um requisito fundamental de engenharia. Ferramentas como o Toxiproxy democratizam o acesso a testes de caos, permitindo que qualquer desenvolvedor descubra falhas ocultas em sua arquitetura antes que elas cheguem aos usuários em produção. Saber exatamente como o seu software reage a atrasos severos e pacotes corrompidos garante aplicações muito mais estáveis, seguras e preparadas para qualquer imprevisto na infraestrutura.
Investir tempo na criação de cenários de homologação robustos protege o negócio contra perdas financeiras e diminui drasticamente o estresse da equipe de operações durante incidentes críticos. Combine essas práticas de resiliência de rede com um monitoramento rigoroso de consumo de hardware — como medir o consumo elétrico de servidores com IPMI — e você terá um panorama completo da saúde da sua infraestrutura, tanto no aspecto lógico quanto no físico.