DevOps
Usando Chaos Engineering para melhorar seus sistemas
A Smiles é um dos maiores programas de fidelidade do Brasil, com 16 milhões de participantes em março de 2019. Criado a mais de 25 anos como programa de relacionamento da Varig, foi posteriormente adquirido pela GOL e em 2013 se tornou uma empresa independente, com a captação de R$ 1,1 bilhão com oferta pública inicial (IPO).
O programa de fidelidade é conhecido pela inovação e pioneirismo com o lançamento produtos e serviços lançados desde 2013, como Clube Smiles, Viaje Fácil e Conta Família. A companhia também tem a maior validade de milhas do mercado, que vão de 3 a 10 anos, de acordo com a categoria do cliente.
Desafio
No final de 2021 a Smiles nos procurou para discutir a possibilidade de utilizar as técnicas de Chaos Engineering para melhorar a resiliência e disponibilidade de seus sistemas. Embora esse seja um termo conhecido no mercado, ainda são técnicas pouco utilizadas, principalmente no Brasil, portanto a Smiles buscava um parceiro para ajudá-los nesta jornada.
Além de questões como a seleção de ferramentas, explicação do método e técnicas, o maior desafio foi montar um plano de progressão que trouxesse resultados sem trazer riscos para a operação da Smiles.
Chaos Engineering
Antes de mais nada, é importante entender do que se trata o conceito. Chaos Engineering é a disciplina de realizar experimentos em um sistema para construir confiança na capacidade desse sistema aguentar condições turbulentas em produção.
Na prática, trata-se de um conjunto de técnicas utilizadas para introduzir em um sistema situações adversas, de forma controlada, para que possamos validar o comportamento do sistema e com isso encontrar oportunidades de melhoria. Mais informações podem ser consultadas no site Principles of Chaos.
Frase do Dr. Werner Vogels, extraída da apresentação realizada pela Enkel no AWS Summit São Paulo 2022
Ferramenta
O primeiro passo foi determinar quais ferramentas iriam apoiar o projeto. Como se trata de um universo relativamente novo, a seleção de ferramentas varia bastante em formato de funcionamento, funcionalidades disponíveis, etc, portanto foi necessário organizar uma POC (proof of concept) testando e comparando as principais soluções disponíveis. As soluções testadas neste período foram:
Após este período de testes, foi selecionado o AWS FIS. Os motivos para essa decisão foram principalmente a praticidade de já estar integrado ao ambiente AWS, que é a plataforma utilizada para os serviços da Smiles, bem como a disponibilidade das funcionalidades necessárias.
Histórico do Projeto
Desde 2016 a Smiles vem trabalhando na evolução de DevOps, passando pela infraestrutura, pipelines, arquitetura de aplicações, etc.
Como parte desse processo, sempre existiu a vontade de começar a adotar as técnicas do Chaos Engineering. Finalmente em 2021 foi iniciado um projeto para serem executados alguns testes, ainda em ambientes não-produtivos, para validar se os resultados seriam satisfatórios.
Os resultados foram surpreendentes, fazendo com que o movimento se fortalecesse, dando início a novas fases de projeto e uma transição para maior integração com o on-going. O projeto foi dividido nas seguintes fases:
Levantamento de aplicações
Criação do plano de testes de carga
Criação e medição do steady state
Experimentação em ambiente não-produtivo
Análise dos resultados
Definição de melhorias por aplicação
Apresentação de relatório
Subsequentemente, o time de on-going foi responsável por implementar as melhorias identificadas, trazendo de fato os benefícios para a Smiles.
Testes e Descobertas
Na primeira leva de testes, foram definidas duas aplicações para o piloto, sendo um CMS e um micro- serviço, ambos rodando em containers sendo um em EKS e outro em ECS. Nessas aplicações, foram realizados os seguintes experimentos:
Injeção de 100% de CPU
Injeção de 80% de memória
Aumento de utilização de disco
Matando tasks do ECS
Desligando Instâncias EC2
Aplicando as técnicas do Chaos Engineering aliadas a esses experimentos, foram possíveis algumas descobertas:
Aplicação 1 - Micro Serviço
Há um aumento baixo de tempo de resposta relacionado ao consumo de CPU
Há um aumento muito grande no tempo de resposta relacionado ao consumo de Memória
Nenhum impacto relacionado a consumo de IO em Disco
Queda parcial dos containers: Baixo percentual de erros por menos de um minuto
Queda total dos containers: 100% de erros por pelo menos quatro minutos
Queda de um nó do cluster: Baixo percentual de erros por alguns segundos
Aplicação 2 - CMS
Nenhum impacto relacionado ao consumo de CPU
Há um aumento baixo de tempo de resposta relacionado ao consumo de Memória
Nenhum impacto relacionado a consumo de IO em Disco
Queda parcial dos containers: Baixo percentual de erros por alguns minutos
Queda total dos containers: 100% de erros por pelo menos três minutos
Queda de um nó do cluster: Indisponibilidade total da aplicação, demandando atuação do time técnico
Foi descoberta uma grave falha de disponibilidade na aplicação, causada por uma falha arquitetural. Essa descoberta disparou um plano de melhorias, evoluindo a arquitetura e resolvendo a falha.
Além disso, outras deficiências menos críticas foram identificadas e foram trabalhadas pelo time de on-going, propiciando mais resiliência para as aplicações, o que gera uma melhor experiência de usuário.
Conclusão
Chaos Engineering se mostrou uma excelente técnica para identificar falhas que de outras maneiras não seriam identificadas.
Isso trouxe mais resiliência para as aplicações e também mais confiança para os times de que as aplicações serão capazes de suportar as demandas de negócio, mesmo em situações desfavoráveis.