{"id":4505,"date":"2020-10-22T17:16:36","date_gmt":"2020-10-22T20:16:36","guid":{"rendered":"https:\/\/blog.fcamara.com.br\/?p=4505"},"modified":"2022-12-05T11:21:20","modified_gmt":"2022-12-05T14:21:20","slug":"a-engenharia-do-caos-na-construcao-da-confiabilidade-de-microsservicos","status":"publish","type":"post","link":"https:\/\/fcamara.com\/blog\/a-engenharia-do-caos-na-construcao-da-confiabilidade-de-microsservicos\/","title":{"rendered":"A Engenharia do Caos na constru\u00e7\u00e3o da confiabilidade de microsservi\u00e7os"},"content":{"rendered":"\n

Por Jo\u00e3o Freitas<\/a>, Arquiteto de Solu\u00e7\u00f5es do Grupo FCamara.<\/em><\/p>\n\n\n\n

Nos \u00faltimos anos todos testemunhamos as r\u00e1pidas mudan\u00e7as das arquiteturas aplicadas em sistemas distribu\u00eddos, especialmente quando as gigantes da ind\u00fastria, ao adotarem arquiteturas de microsservi\u00e7os, passaram a divulgar seus cases de sucesso – que se tornaram modelos de desenvolvimento nos quais muitas aplica\u00e7\u00f5es modernas se baseiam. Embora os conceitos fundamentais por tr\u00e1s disto n\u00e3o sejam novos, a aplica\u00e7\u00e3o do conceito de microsservi\u00e7os tem sido motivada em parte gra\u00e7as aos desafios de escalabilidade, falta de efici\u00eancia, velocidade lenta de desenvolvimento e dificuldades na ado\u00e7\u00e3o de novas tecnologias enfrentadas pelo monolito, tipicamente em produ\u00e7\u00e3o.<\/p>\n\n\n\n

O conceito de microsservi\u00e7o dado por Susan Fowler \u00e9 simples: uma pequena aplica\u00e7\u00e3o que executa uma \u00fanica tarefa e o faz com efici\u00eancia; \u00e9 um pequeno componente que pode ser facilmente substitu\u00eddo e \u00e9 desenvolvido e implantado de forma independente, fazendo parte de um sistema maior, que utiliza diferentes servi\u00e7os para realizar tarefas que seriam tratadas, normalmente, por uma grande aplica\u00e7\u00e3o aut\u00f4noma.<\/p>\n\n\n\n

Apesar de possuir vantagens \u00f3bvias – principalmente no que diz respeito \u00e0 escalabilidade e facilidades de implanta\u00e7\u00e3o – a arquitetura de microsservi\u00e7os traz desafios que lhe s\u00e3o pr\u00f3prios, que v\u00e3o dos desafios organizacionais (e aqui sugiro uma leitura sobre a Lei de Conway Reversa) e desafios de dispers\u00e3o t\u00e9cnica at\u00e9 mesmo ao fato de os servi\u00e7os competirem pelos recursos de infraestrutura, plataformas e equipes. Os maiores problemas enfrentados, no entanto, normalmente dizem respeito \u00e0 padroniza\u00e7\u00e3o da arquitetura frente a seus requisitos, estabilidade, disponibilidade, escalabilidade e desempenho.<\/p>\n\n\n\n

Apesar de toda sua “modernidade” um microsservi\u00e7o vai falhar em algum momento, assim como qualquer outro sistema – e parte da tarefa de garantia da disponibilidade do servi\u00e7o considera a identifica\u00e7\u00e3o e mitiga\u00e7\u00e3o destes riscos; corol\u00e1rio disto \u00e9 a import\u00e2ncia da cria\u00e7\u00e3o de um servi\u00e7o tolerante a falha, uma vez que os componentes, individualmente, fazem parte de uma cadeia complexa de diferentes servi\u00e7os. Desta forma, uma falha em determinado ponto pode ser capaz de derrubar todos os outros pontos da cadeia de forma que a identifica\u00e7\u00e3o e a elimina\u00e7\u00e3o dos pontos \u00fanicos de falha deve ser a maior prioridade aqui, seguidas pela realiza\u00e7\u00e3o dos respectivos testes de resili\u00eancia.<\/p>\n\n\n\n

O teste do caos surge como um teste especial de resili\u00eancia, que for\u00e7a a ocorr\u00eancia de falhas em produ\u00e7\u00e3o<\/em> de forma a avaliar a capacidade de recupera\u00e7\u00e3o do sistema frente a eventos adversos em hardware, software, comunica\u00e7\u00e3o e infraestrutura, em um ambiente monitorado.<\/p>\n\n\n\n

A Engenharia do Caos surge como disciplina capaz de auxiliar no aprendizado do comportamento de determinado sistema distribu\u00eddo em escala atrav\u00e9s da observa\u00e7\u00e3o de experimentos controlados, baseados em um ciclo cont\u00ednuo que compreende os seguintes passos, descritos nos Princ\u00edpios da Engenharia do Caos (https:\/\/principlesofchaos.org\/):<\/p>\n\n\n\n

  1. Constru\u00e7\u00e3o de hip\u00f3teses em torno do comportamento do sistema est\u00e1vel;<\/li>
  2. Altera\u00e7\u00e3o de vari\u00e1veis de eventos reais – por exemplo, a gera\u00e7\u00e3o de falhas em hardware, paradas de servidores ou qualquer outro evento capaz de gerar interrup\u00e7\u00f5es;<\/li>
  3. Execu\u00e7\u00e3o do experimento em produ\u00e7\u00e3o;<\/li>
  4. Automa\u00e7\u00e3o dos experimentos para execu\u00e7\u00e3o cont\u00ednua;<\/li>
  5. Minimiza\u00e7\u00e3o do impacto;<\/li>
  6. Documenta\u00e7\u00e3o do processo e suas observa\u00e7\u00f5es.<\/li><\/ol>\n\n\n\n

    A aplica\u00e7\u00e3o do caos em um projeto exige que a equipe tenha abra\u00e7ado isto como parte de sua cultura, que tem entre seus pilares a proatividade, o desejo comum de mitiga\u00e7\u00e3o dos efeitos adversos e o desejo da cria\u00e7\u00e3o de um ecossistema imune a falhas. O caos deve ser implementado continuamente, sempre que houver mudan\u00e7as de hardware ou de software ou mesmo por altera\u00e7\u00f5es no padr\u00e3o de utiliza\u00e7\u00e3o do servi\u00e7o.<\/p>\n\n\n\n

    Uma equipe preparada para lidar com o caos possui conhecimento multidisciplinar e especializado para a cria\u00e7\u00e3o de cen\u00e1rios catastr\u00f3ficos e capaz de reconhecer os padr\u00f5es de paralisa\u00e7\u00e3o e determina\u00e7\u00f5es de causas-raiz; importante \u00e9 que dentro da constru\u00e7\u00e3o da cultura de uma equipe do caos esteja a no\u00e7\u00e3o de que as falhas e brechas encontradas devam servir como li\u00e7\u00f5es de maturidade, e jamais como forma de encontrar culpados. Os resultados e planos de a\u00e7\u00e3o tra\u00e7ados pelo time devem incluir atividades de mitiga\u00e7\u00e3o em todo o \u00e2mbito do software: infraestrutura, arquitetura e c\u00f3digo.<\/p>\n\n\n\n

    O Chaos Monkey \u00e9 um projeto um projeto open source disponibilizado pela Netflix no Github (https:\/\/github.com\/netflix\/chaosmonkey), que visa exatamente automatizar a ocorr\u00eancia 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 \u00e9 usado para a gera\u00e7\u00e3o de falhas aleat\u00f3rias e cont\u00ednuas no ecossistema de produ\u00e7\u00e3o, sendo capaz n\u00e3o apenas de desligar servidores de aplica\u00e7\u00e3o, como tamb\u00e9m de realizar interrup\u00e7\u00f5es e altera\u00e7\u00f5es em c\u00f3digos legados e c\u00f3digos pouco utilizados, avaliar a conformidade das inst\u00e2ncias dos servi\u00e7os com as pol\u00edticas pr\u00e9-estabelecidas, incluir lat\u00eancia proposital nas comunica\u00e7\u00f5es REST, entre outras coisas. Todo o processo est\u00e1 ligado diretamente em sua esteira de DevOps, o que garante a realiza\u00e7\u00e3o constante deste tipo de testes, portanto, gerando um sistema com alto grau de confiabilidade e resili\u00eancia.<\/p>\n\n\n\n

    Sugiro a todos assistir \u00e0 palestra “Mastering Chaos\u00a0– A Netflix Guide to Microservices” apresentada na QCon Plus em 2017 e dispon\u00edvel no YouTube:<\/p>\n\n\n\n

    \n