Como testar latência de rede entre microsserviços no Docker

Por que simular latência de rede em containers Docker?

Quando desenvolvemos arquiteturas baseadas em microsserviços, costumamos testar tudo em ambientes locais onde a comunicação entre os componentes acontece quase instantaneamente. Na prática, isso significa que ignoramos problemas como atrasos na rede ou perda intermitente de dados, que inevitabilizam aplicações em ambientes distribuídos reais. Para resolver essa lacuna sem precisar derrubar cabos de verdade, podemos recorrer a técnicas de injeção de falhas diretamente na camada de rede do sistema operacional.

Em sistemas Linux modernos, a infraestrutura de rede que alimenta o Docker permite manipular pacotes de dados usando recursos nativos do kernel. Assim como diagnosticamos gargalos em hardwares físicos ou ajustamos redes lentas no homelab para rastrear gargalos de pacotes, a injeção controlada de atrasos nos dá a chance de observar o comportamento real de bibliotecas de conexão, filas e sistemas de mensageria sob estresse.

Entendendo o papel do Traffic Control no kernel Linux

O coração de qualquer simulação avançada de rede no Linux é o subsistema conhecido como Traffic Control, frequentemente chamado de tc. Na prática, ele funciona como um guarda de trânsito avançado que fica posicionado nas interfaces de rede virtuais, decidindo quais pacotes devem passar imediatamente, quais devem esperar em uma fila e quais devem ser descartados intencionalmente.

Quando rodamos aplicações em containers Docker, cada instância costuma se conectar a uma ponte de rede virtual usando interfaces do tipo veth. O utilitário tc consegue aplicar regras de disciplina de enfileiramento, conhecidas como qdisc, diretamente nessas portas virtuais. Isso possibilita injetar métricas exatas de atraso temporal, instabilidade na entrega chamada de jitter, e porcentagens reais de pacotes corrompidos ou perdidos no meio do caminho.

Como aplicar atrasos de rede em um container em execução

Para colocar a mão na massa, o primeiro passo é identificar o identificador de processo ou o ID exato do container que desejamos injetar a falha. Com essa informação, podemos descobrir qual é a interface de rede virtual correspondente dentro do espaço de nomes do host. A partir daí, executamos comandos de manipulação de tráfego usando o utilitário iproute2.

Abaixo temos um exemplo prático de comando que adiciona um atraso fixo de cem milissegundos com uma variação de dez milissegundos em uma interface específica:

ip link set dev veth1234 up
tc qdisc add dev veth1234 root netem delay 100ms 10ms loss 1%

Esse comando simples avisa o kernel que qualquer pacote que tentar sair ou entrar por aquela interface específica deve sofrer uma pausa programada. Para quem deseja criar cenários ainda mais complexos, vale a pena estudar como simular quedas de tensão e falhas físicas em fontes com carga ativa, unindo testes de infraestrutura elétrica e resiliência de software.

Automatizando a injeção de falhas em ambientes de integração

Fazer alterações manuais via linha de comando funciona bem para testes pontuais, mas a verdadeira mágica da engenharia moderna acontece quando integramos esses testes de resiliência aos nossos fluxos de trabalho automatizados. Podemos criar scripts de inicialização que aplicam perfis de latência específicos assim que o ambiente de teste sobe via Docker Compose.

Esses perfis ajudam a validar se os mecanismos de circuit breaker, reententativas exponenciais e timeouts configurados nas aplicações estão realmente funcionando conforme o planejado. Se um microsserviço demora mais do que o esperado para responder, a aplicação cliente precisa lidar com essa lentidão de forma graciosa, sem travar threads inteiras ou esgotar o pool de conexões com o banco de dados.

Considerações finais sobre testes de resiliência em containers

Simular problemas de rede no ambiente controlado do Docker deixou de ser um luxo e virou requisito fundamental para garantir a estabilidade de sistemas modernos. Ao expor os microsserviços a cenários adversos de latência e perda de pacotes antes que cheguem à produção, conseguimos antecipar falhas catastróficas e ajustar timeouts com precisão cirúrgica, melhorando drasticamente a experiência final do usuário.

Adotar essa cultura de testes preventivos transforma a maneira como encaramos a infraestrutura, mostrando que a robustez de um sistema distribuído não depende apenas de código limpo, mas principalmente de como ele se comporta quando o pior cenário de rede acontece.