A Engenharia do Caos na construção da confiabilidade de microsserviços

Por João Freitas, Arquiteto de Soluções do Grupo FCamara.

Nos últimos anos todos testemunhamos as rápidas mudanças das arquiteturas aplicadas em sistemas distribuídos, especialmente quando as gigantes da indústria, ao adotarem arquiteturas de microsserviços, passaram a divulgar seus cases de sucesso – que se tornaram modelos de desenvolvimento nos quais muitas aplicações modernas se baseiam. Embora os conceitos fundamentais por trás disto não sejam novos, a aplicação do conceito de microsserviços tem sido motivada em parte graças aos desafios de escalabilidade, falta de eficiência, velocidade lenta de desenvolvimento e dificuldades na adoção de novas tecnologias enfrentadas pelo monolito, tipicamente em produção.

O conceito de microsserviço dado por Susan Fowler é simples: uma pequena aplicação que executa uma única tarefa e o faz com eficiência; é um pequeno componente que pode ser facilmente substituído e é desenvolvido e implantado de forma independente, fazendo parte de um sistema maior, que utiliza diferentes serviços para realizar tarefas que seriam tratadas, normalmente, por uma grande aplicação autônoma.

Apesar de possuir vantagens óbvias – principalmente no que diz respeito à escalabilidade e facilidades de implantação – a arquitetura de microsserviços traz desafios que lhe são próprios, que vão dos desafios organizacionais (e aqui sugiro uma leitura sobre a Lei de Conway Reversa) e desafios de dispersão técnica até mesmo ao fato de os serviços competirem pelos recursos de infraestrutura, plataformas e equipes. Os maiores problemas enfrentados, no entanto, normalmente dizem respeito à padronização da arquitetura frente a seus requisitos, estabilidade, disponibilidade, escalabilidade e desempenho.

Apesar de toda sua “modernidade” um microsserviço vai falhar em algum momento, assim como qualquer outro sistema – e parte da tarefa de garantia da disponibilidade do serviço considera a identificação e mitigação destes riscos; corolário disto é a importância da criação de um serviço tolerante a falha, uma vez que os componentes, individualmente, fazem parte de uma cadeia complexa de diferentes serviços. Desta forma, uma falha em determinado ponto pode ser capaz de derrubar todos os outros pontos da cadeia de forma que a identificação e a eliminação dos pontos únicos de falha deve ser a maior prioridade aqui, seguidas pela realização dos respectivos testes de resiliência.

O teste do caos surge como um teste especial de resiliência, que força a ocorrência de falhas em produção de forma a avaliar a capacidade de recuperação do sistema frente a eventos adversos em hardware, software, comunicação e infraestrutura, em um ambiente monitorado.

A Engenharia do Caos surge como disciplina capaz de auxiliar no aprendizado do comportamento de determinado sistema distribuído em escala através da observação de experimentos controlados, baseados em um ciclo contínuo que compreende os seguintes passos, descritos nos Princípios da Engenharia do Caos (https://principlesofchaos.org/):

1. Construção de hipóteses em torno do comportamento do sistema estável;
2. Alteração de variáveis de eventos reais – por exemplo, a geração de falhas em hardware, paradas de servidores ou qualquer outro evento capaz de gerar interrupções;
3. Execução do experimento em produção;
4. Automação dos experimentos para execução contínua;
5. Minimização do impacto;
6. Documentação do processo e suas observações.

A aplicação do caos em um projeto exige que a equipe tenha abraçado isto como parte de sua cultura, que tem entre seus pilares a proatividade, o desejo comum de mitigação dos efeitos adversos e o desejo da criação de um ecossistema imune a falhas. O caos deve ser implementado continuamente, sempre que houver mudanças de hardware ou de software ou mesmo por alterações no padrão de utilização do serviço.

Uma equipe preparada para lidar com o caos possui conhecimento multidisciplinar e especializado para a criação de cenários catastróficos e capaz de reconhecer os padrões de paralisação e determinações de causas-raiz; importante é que dentro da construção da cultura de uma equipe do caos esteja a noção de que as falhas e brechas encontradas devam servir como lições de maturidade, e jamais como forma de encontrar culpados. Os resultados e planos de ação traçados pelo time devem incluir atividades de mitigação em todo o âmbito do software: infraestrutura, arquitetura e código.

O Chaos Monkey é um projeto um projeto open source disponibilizado pela Netflix no Github (https://github.com/netflix/chaosmonkey), que visa exatamente automatizar a ocorrência do caos (existe um artigo bastante interessante do Alex Lattaro sobre o projeto disponibilizado no IMasters ainda em 2016; deixo o link ao final deste post). Ele é usado para a geração de falhas aleatórias e contínuas no ecossistema de produção, sendo capaz não apenas de desligar servidores de aplicação, como também de realizar interrupções e alterações em códigos legados e códigos pouco utilizados, avaliar a conformidade das instâncias dos serviços com as políticas pré-estabelecidas, incluir latência proposital nas comunicações REST, entre outras coisas. Todo o processo está ligado diretamente em sua esteira de DevOps, o que garante a realização constante deste tipo de testes, portanto, gerando um sistema com alto grau de confiabilidade e resiliência.

Sugiro a todos assistir à palestra “Mastering Chaos – A Netflix Guide to Microservices” apresentada na QCon Plus em 2017 e disponível no YouTube:

Além do Chaos Monkey, outras alternativas estão disponíveis para serem usadas livremente. Meus companheiros de .NET, por exemplo, contam com o Simmy, que está pronto para ser utilizado com o Polly (uma biblioteca com foco em trazer resiliência para as aplicações, bastante conhecida). Mais do que uma lista tecnologias, no entanto, a Engenharia do Caos deve ser abraçada como cultura na formação de equipes maduras e times de grande performance. Quer conversar mais a respeito?

Materiais recomendados:

Artigo do Alex Lattaro
https://imasters.com.br/cloud/chaos-monkey-da-netflix-e-atualizado-veja-o-que-muda

Documentação da Microsoft sobre a Engenharia do Caos
https://docs.microsoft.com/pt-pt/azure/architecture/framework/resiliency/chaos-engineering