Como simular perda de pacotes em microsserviços

Por que simular falhas de rede na homologação

Quando construímos sistemas baseados em microsserviços, assumimos inconscientemente que a rede entre eles é sempre rápida e confiável. Na prática do mundo real, cabos se rompem, roteadores reiniciam e pacotes simplesmente desaparecem no meio do caminho. Para garantir que sua aplicação não trave quando o pior acontecer, precisamos testar a resiliência ativamente antes de lançar código novo. Assim como explicamos nos conceitos de como projetar filas de mensagens tolerantes a falhas, antecipar o caos é o único caminho para a estabilidade.

A injeção de falhas consiste em corromper, atrasar ou descartar intencionalmente o tráfego de rede em um ambiente controlado de homologação. Isso nos permite observar como os serviços reagem à perda repentina de conexão ou a uma lentidão extrema. Em vez de torcer para que a infraestrutura nunca falhe, forçamos o sistema a provar que sabe se recuperar sozinho. Na prática, isso significa que sua aplicação deve lidar com timeouts, retransmissões e circuit breakers sem gerar erros em cascata para o usuário final.

Ferramentas modernas para injeção de latência e perda

Existem diferentes abordagens para manipular o tráfego de rede durante os testes automatizados ou manuais. No nível do sistema operacional Linux, o utilitário Netem (Network Emulator), que opera junto ao comando iproute2, consegue modificar pacotes diretamente nas placas de rede virtuais ou físicas. Ele é excelente para testes em nível de infraestrutura, simulando conexões via satélite ou redes móveis instáveis. Se você já passou pela frustração de investigar por que a placa reinicia sozinha e como testar trilhas, sabe que entender o comportamento físico e de enlace economiza horas de depuração.

Outra alternativa muito popular entre desenvolvedores de microsserviços é o Toxiproxy, criado pelo Shopify. Ele funciona como um proxy TCP que se posiciona entre a sua aplicação e o banco de dados ou API externa. Com ele, podemos criar regras via API HTTP para injetar exatamente dez porcento de perda de pacotes ou atrasar respostas em quinhentos milissegundos apenas em uma rota específica. Essa granularidade é perfeita para rodar baterias de testes automatizados de integração que precisam validar o comportamento do sistema sob estresse severo.

Implementando cenários de teste com Toxiproxy

Para colocar a mão na massa e criar um ambiente de homologação realista, vamos configurar o Toxiproxy em um arquivo de infraestrutura com Docker Compose. O primeiro passo consiste em definir o container do proxy apontando para o serviço dependente, como um banco de dados PostgreSQL. Dessa forma, toda chamada que seu microsserviço fizer para o banco passará primeiro pelo proxy, permitindo a manipulação cirúrgica dos pacotes de rede sem alterar uma única linha do código da aplicação.

version: '3.8'&#nservices:&#n  toxiproxy:&#n    image: shopify/toxiproxy&#n    ports:&#n      - "8474:8474"&#n      - "5433:5433"&#n    environment:&#n      - TOXIPROXY_HOST=0.0.0.0&#n  database:&#n    image: postgres:15-alpine&#n    environment:&#n      - POSTGRES_PASSWORD=secret&#n

Com o container rodando, o segundo passo é cadastrar a rota que desejamos monitorar e manipular através da API de controle do Toxiproxy. Você pode enviar uma requisição HTTP simples usando a ferramenta curl a partir da sua máquina de testes para registrar o serviço de banco de dados na porta configurada. Essa automação pode ser integrada facilmente ao seu pipeline de CI/CD para rodar testes de resiliência antes de qualquer promoção de ambiente.

curl -X POST http://localhost:8474/proxies -d '{&#n  "name": "postgresql_db",&#n  "listen": "0.0.0.0:5433",&#n  "upstream": "database:5432"&#n}'&#n

O terceiro e último passo prático é injetar a falha propriamente dita logo antes da execução do teste de integração automatizado. No exemplo abaixo, adicionamos uma regra de toxicidade chamada loss que descarta vinte porcento dos pacotes de rede de forma aleatória, simulando uma conexão degradada. Assim que o teste termina, podemos remover a regra instantaneamente pela API para normalizar o ambiente.

curl -X POST http://localhost:8474/proxies/postgresql_db/toxics -d '{&#n  "type": "timeout",&#n  "attributes": {&#n    "timeout": 1000&#n  },&#n  "toxicity": 20&#n}&#nConforme monitoramos os logs, ferramentas de observabilidade como o Prometheus ajudam a rastrear anomalias, corroborando práticas discutidas em como criar alertas eficientes no Prometheus e Grafana sem fadiga.&#n'

Validando o comportamento dos microsserviços

Depois de injetar a perda de pacotes, o verdadeiro trabalho de engenharia começa na análise das métricas coletadas. Se a sua aplicação utiliza padrões como Circuit Breaker, ela deve parar de enviar requisições para o serviço instável após uma taxa limite de falhas, retornando um erro amigável ou um valor em cache. Caso contrário, o microsserviço continuará tentando se conectar, esgotando as conexões disponíveis e derrubando toda a cadeia de dependências por efeito dominó.

Outro ponto crítico é a observação do tempo de resposta e do uso de memória durante a degradação da rede. Sem uma ferramenta de injeção de latência, problemas de concorrência causados por esperas infinitas só aparecem em produção, quando milhares de usuários reais estão conectados. Simular essas condições em homologação transforma incertezas operacionais em dados previsíveis, permitindo que a equipe ajuste timeouts e políticas de retry com total segurança.

Considerações Finais

A engenharia de resiliência vai muito além de escrever código limpo; ela exige que estejamos preparados para o colapso inevitável da infraestrutura de rede. O uso de ferramentas como Toxiproxy e Netem em ambientes de homologação desmistifica o comportamento de sistemas distribuídos sob pressão. Ao adotar testes de injeção de falhas como parte rotineira do desenvolvimento, sua equipe ganha a confiança necessária para operar arquiteturas complexas sem medo do imprevisível.