17 pontos por GN⁺ 2025-05-23 | 1 comentários | Compartilhar no WhatsApp
  • Em ambientes de microsserviços e nuvem, falhas são inevitáveis, por isso é necessário fortalecer previamente a resiliência do sistema por meio de Chaos Engineering
  • Chaos Toolkit e Chaos Monkey são ferramentas poderosas de teste de falhas, destacando-se respectivamente pela versatilidade e pela especialização em ambientes Java (Spring Boot)
  • Por meio de experimentos baseados em Kubernetes e Istio, é possível simular vários cenários realistas de falha, como latência de rede, indisponibilidade de serviços e falhas de região
  • Ao integrar Chaos Engineering ao pipeline de CI/CD, é possível validar automaticamente a capacidade de resposta a falhas antes da produção
  • O ponto central não é a ‘destruição’, mas sim a ‘construção de confiança’, e recomenda-se uma estratégia de começar pequeno e aumentar gradualmente o nível de caos

Chaos Engineering para microsserviços

O que é Chaos Engineering?

  • Chaos Engineering é uma metodologia que simula falhas reais para descobrir previamente vulnerabilidades do sistema e melhorá-las
  • Principais exemplos de simulação:
    • falha de região ou de data center
    • latência de rede entre serviços
    • sobrecarga de CPU e falhas de I/O
    • indisponibilidade de serviços dependentes
    • erros no sistema de arquivos
  • Objetivo: antes que a falha aconteça, reduzir o tempo de recuperação, aumentar a disponibilidade e minimizar o impacto para o usuário

Ciclo de vida dos experimentos de Chaos Engineering

  • Por meio de um processo estruturado de experimentação, aplica-se um fluxo cíclico de planejar → executar → observar → melhorar
  • Operação contínua baseada em experimentos para aumentar sistematicamente a confiabilidade

Chaos Toolkit vs. Chaos Monkey

  • Finalidade

    • Chaos Toolkit : framework genérico de experimentos de chaos que pode ser usado em diversas plataformas e ambientes
    • Chaos Monkey (exclusivo para Spring Boot) : ferramenta de simulação de falhas voltada a aplicações Java Spring Boot
  • Forma de configuração

    • Chaos Toolkit : define experimentos usando uma configuração declarativa baseada em JSON/YAML
    • Chaos Monkey : configurado por meio do arquivo application.yml e da integração com o Spring Boot Actuator
  • Linguagens e ambientes suportados

    • Chaos Toolkit : suporte a ambientes multilíngues e multiplataforma (Node.js, Java, Kubernetes etc.)
    • Chaos Monkey : especializado em aplicações baseadas em Java (Spring Boot)
  • Tipos de falha suportados

    • Chaos Toolkit : suporte a uma ampla gama de experimentos de falha, incluindo falhas de rede, encerramento de Pod, estresse de CPU/memória e falhas personalizadas
    • Chaos Monkey : injeção de falhas focada na camada de aplicação, como latência (Latency), exceções (Exceptions) e interrupção de serviço (KillApp)
  • Sistemas com os quais pode se integrar

    • Chaos Toolkit : pode integrar-se com Kubernetes, Istio, Azure, Prometheus e outros
    • Chaos Monkey : integra-se diretamente com a API do Spring Boot Actuator para atuar sobre componentes internos do Spring

Situações em que o uso é recomendado

  • Chaos Toolkit
    • ambientes de deploy baseados em Kubernetes
    • serviços multicloud ou multilíngues
    • composição de cenários complexos de falha
  • Chaos Monkey
    • apps Spring Boot baseados em Java
    • testes de exceção/latência em nível de método
    • quando se prefere uma abordagem simples e embutida

Exemplos práticos com Chaos Toolkit (Java/Node.js/Kubernetes)

Experimentos em ambiente Kubernetes

  • Experimento de encerramento de Pod: validação de resiliência com pod-kill
  • Experimento de latência regional: injeção de latência de rede em um serviço virtual do Istio
  • Experimento de exaustão de recursos: consumo forçado de CPU/memória
  • Simulação de interrupção de banco de dados: teste de resposta a falhas de serviços dependentes
  • Particionamento de rede: experimento de interrupção da comunicação entre serviços
  • Falhas baseadas em tempo: injeção de falhas em horários de pico de tráfego

Injeção de latência com base em Istio

  • Injeção de latência de rede na camada de service mesh
  • Controle de latência/taxa de erro por meio da configuração do Istio

Geração e análise de relatórios

  • Resumo dos resultados dos experimentos com o comando chaos report
  • Interpretação dos resultados:
    • estado normal mantido → resiliência garantida
    • anomalia detectada → necessidade de análise de logs e monitoramento
    • falha em cascata → considerar adoção de circuit breaker e refatoração

Chaos Monkey no Spring Boot

  • Alvos monitorados: @Controller, @Service, @Repository, @RestController
  • Falhas que podem ser injetadas:
    • Latency Assault: latência artificial
    • Exception Assault: geração de exceções
    • KillApp Assault: interrupção da aplicação inteira

Forma de execução

  • Ativar o profile chaos-monkey em application.yml
  • Controle dinâmico por meio da API do Spring Boot Actuator

Chaos Engineering em Node.js

Uso de Chaos Monkey para Node.js

  • Instalação de uma biblioteca Chaos Monkey de terceiros
  • Funcionalidades:
    • injeção de latência
    • geração de exceções
    • simulação de falhas de rede

Exemplo de uso do Chaos Toolkit

  • Configuração do experimento em formato JSON
  • Ex.: injeção de 200ms de latência em uma API específica de Node.js

Integração de chaos ao pipeline de CI/CD

Objetivos da integração

  • validação automática da resiliência antes do deploy
  • identificação de gargalos de desempenho
  • melhoria do MTTR (Mean Time to Recovery)
  • automação de rollback sem intervenção manual

Exemplo de integração com GitHub Actions

  • execução automática de experimentos ao fazer commit de código
  • execução dos experimentos após a instalação do Chaos Toolkit
  • interrupção do deploy em caso de falha no health check

Boas práticas em experimentos de Chaos Engineering

  • 1. Estabelecer uma hipótese de estado normal: definir claramente o que caracteriza o funcionamento normal do sistema
  • 2. Começar com experimentos de baixa intensidade: 100ms de latência → reforço gradual
  • 3. Integração com monitoramento é obrigatória: observação em tempo real com Prometheus, Grafana etc.
  • 4. Configurar rollback automático: criar um mecanismo de recuperação rápida em caso de falha
  • 5. Expandir o escopo gradualmente: do nível de serviço → para o nível de cluster

Conclusão

  • Chaos Engineering não serve para quebrar o sistema, mas sim é uma estratégia para construir confiança
  • Em Java, Node.js, Kubernetes ou Istio, é possível começar com pequenos experimentos e expandi-los gradualmente
  • Usando ferramentas como Chaos Toolkit e Chaos Monkey, é possível simular com segurança situações reais de falha
  • Ao integrar e automatizar os experimentos no CI/CD, é possível garantir previamente uma operação estável

Materiais de referência

1 comentários

 
aer0700 2025-05-24

Quando ouvi a expressão engenharia do caos, por um instante achei que estavam falando do backend da nossa empresa que eu mesmo escrevi;