O blog da AWS

Criação de aplicativos resilientes Serverless usando engenharia de caos

Por Suranjan Choudhury (gerente de TME e ITes SA), Anil Sharma (Sr. PSA, Migração)  

A engenharia do caos é o processo de estressar um aplicativo em ambientes de teste ou produção criando eventos disruptivos, como interrupções, observando como o sistema responde e implementando melhorias. A engenharia do caos ajuda você a criar as condições reais necessárias para descobrir problemas ocultos e gargalos de desempenho que são difíceis de encontrar em aplicativos distribuídos.

Você pode criar aplicativos resilientes distribuídos Serverless usando o AWS Lambda e testar funções do Lambda em condições operacionais do mundo real usando a engenharia do caos. Este blog mostra uma abordagem para injetar caos nas funções do Lambda, sem fazer alterações no código da função do Lambda. Este blog usa o serviço AWS Fault Injection Simulator (FIS) para criar experimentos que injetam interrupções em aplicativos Serverless baseados em Lambda.

O AWS FIS é um serviço gerenciado que realiza experimentos de injeção de falhas em suas cargas de trabalho da AWS. O AWS FIS é usado para configurar e executar experimentos de falhas que simulam condições do mundo real para descobrir problemas de aplicativos que, de outra forma, seriam difíceis de encontrar. Você pode melhorar a resiliência e o desempenho do aplicativo usando os resultados dos experimentos do FIS.

O código de exemplo neste blog apresenta falhas aleatórias nas funções existentes do Lambda, como um aumento nos tempos de resposta (latência) ou falhas aleatórias. Você pode observar o comportamento do aplicativo sob o caos introduzido e fazer melhorias no aplicativo.

Abordagens para injetar caos nas funções do Lambda

Atualmente, o AWS FIS não oferece suporte à injeção de falhas nas funções do Lambda. No entanto, existem duas abordagens principais para injetar caos nas funções do Lambda: usar bibliotecas externas ou usar camadas (layer) do Lambda.

Os desenvolvedores criaram bibliotecas para introduzir condições de falha nas funções do Lambda, como chaos_lambda e Failure-lambda. Essas bibliotecas permitem que os desenvolvedores injetem elementos do caos nas funções Lambda do Python e do Node.js. Para injetar o caos usando essas bibliotecas, os desenvolvedores devem decorar o código da função Lambda existente. As funções envolvem a função Lambda existente, adicionando caos em tempo de execução. Essa abordagem exige que os desenvolvedores alterem as funções existentes do Lambda.

Você também pode usar camadas (layer) do Lambda para injetar caos, sem exigir alterações no código da função, pois a injeção de falhas é separada. Como a camada (layer) Lambda é implantada separadamente, você pode alterar de forma independente o elemento do caos, como latência na resposta ou falha da função Lambda. Esta postagem do blog discute essa abordagem.

Injetando caos nas funções do Lambda usando camadas (layer) do Lambda

Uma camada (layer) Lambda é um arquivo de arquivos.zip que contém código ou dados suplementares. As camadas geralmente contêm dependências de biblioteca, um tempo de execução personalizado ou arquivos de configuração. Este blog cria um experimento FIS que usa camadas do Lambda para injetar interrupções nas funções existentes do Lambda para runtimesde Java, Node.js e Python.

A camada Lambda contém o código de injeção de falhas. Ele é invocado antes da invocação da função Lambda e injeta latência ou erros aleatórios. A injeção de latência aleatória simula condições imprevisíveis do mundo real. As camadas de injeção de caos em Java, Node.js e Python fornecidas são genéricas e reutilizáveis. Você pode usá-los para injetar caos em suas funções do Lambda.

As camadas (layer) Lambda da Chaos Injection

Camada (layer) Java Lambda para injeção de caos

Java Lambda Layer for Chaos Injection

A camada (layer) de injeção de caos para funções Java Lambda usa a variável de ambiente JAVA_TOOL_OPTIONS. Essa variável de ambiente permite especificar a inicialização das ferramentas, especificamente o lançamento de agentes nativos ou da linguagem de programação Java. O JAVA_TOOL_OPTIONS tem um parâmetro javaagent que aponta para a camada (layer) de injeção de caos. Essa camada (layer) usa o método premain do Java e a biblioteca Byte Buddy para modificar a classe Java da função Lambda durante o tempo de execução.

Quando a função Lambda é invocada, a JVM usa a classe especificada com o parâmetro javaagent e invoca seu método premain antes da invocação do manipulador (handler) da função Lambda. O método Java premain injeta o caos antes da execução do Lambda.

O experimento FIS adiciona a associação de camadas (layer) e a variável de ambiente JAVA_TOOL_OPTIONS à função Lambda.

Camada (layer) Lambda Python e Node.js para injeção de caos

 

Python and Node.js Lambda Layer for Chaos Injection

Ao injetar caos nas funções do Python e do Node.js, o manipulador (handler) da função Lambda é substituído por uma função nas respectivas camadas (layer) pela ação FIS aws:ssm:start-automation-execution. A automação, que é um documento SSM, salva o manipulador (handler) da função Lambda original no AWS Systems Manager Parameter Store, para que as alterações possam ser revertidas quando o experimento for concluído.

A função de camada (layer) contém a lógica para injetar o caos. Em tempo de execução, a função de camada (layer) é invocada, injetando caos na função Lambda. A função de camada, por sua vez, invoca o manipulador (handler) original da função Lambda, para que a funcionalidade seja cumprida.

O resultado em todos os runtimes(Java, Python ou Node.js) é a invocação da função Lambda original com latência ou falha injetada. As alterações observadas são latência aleatória ou falha injetada pela camada.

Depois que o experimento for concluído, um documento SSM é fornecido. Isso reverte a associação da camada (layer) à função Lambda e remove a variável de ambiente, no caso do Java Runtime.

Experimente experimentos FIS usando camadas (layer) SSM e Lambda

No código de exemplo fornecido, as camadas (layer) do Lambda são fornecidas para os runtimesde Python, Node.js e Java, juntamente com exemplos de funções do Lambda para cada tempo de execução.

A exemplo implanta as camadas (layer) do Lambda e as funções do Lambda, o template de experimento do FIS, as funções do AWS Identity and Access Management (IAM) necessárias para executar o experimento e os documentos do AWS Systems Manager (SSM). O template do AWS CloudFormation é fornecido para implantação.

Etapa 1: Concluir os pré-requisitos

  • Para implantar o código de exemplo, clone o repositório localmente:
    git clone https://github.com/aws-samples/chaosinjection-lambda-samples.git
  • Preencha os pré-requisitos documentados aqui.

Etapa 2: Implantar usando o AWS CloudFormation

O template do CloudFormation fornecido junto com este blog implanta um código de exemplo. Execute o runCfn.sh.

Quando isso for concluído, ele retornará o StackID que o CloudFormation criou:

Etapa 3: execute o experimento de injeção de caos

Por padrão, o experimento é configurado para injetar caos na função Lambda de exemplo Java. Para alterá-lo para as funções Lambda do Python ou do Node.js, edite o template do experimento e configure-o para injetar caos usando as etapas a seguir.

Etapa 4: iniciar o experimento

No console FIS, escolha Iniciar experimento.

 Start experiment

Espere até que o estado do experimento mude para “Concluído”.

Etapa 5: execute seu teste

Nesse estágio, você pode injetar caos em sua função Lambda. Execute as funções do Lambda e observe seu comportamento.

1. Invoque a função Lambda usando o comando abaixo:

aws lambda invoke --function-name NodeChaosInjectionExampleFn out --log-type Tail --query 'LogResult' --output text | base64 -d
Bash

2. A saída dos comandos da CLI exibe os registros criados pelas camadas (layer) do Lambda mostrando a latência introduzida nessa invocação.

Neste exemplo, a saída mostra que a camada (layer) Lambda injetou 1799 ms de latência aleatória na função.

O experimento injeta latência ou falha aleatória na função Lambda. Executar a função Lambda novamente resulta em uma latência ou falha diferente. Nesse estágio, você pode testar o aplicativo e observar seu comportamento sob condições que podem ocorrer no mundo real, como um aumento na latência ou falha da função Lambda.

Etapa 6: reverter o experimento

Para reverter o experimento, execute o documento SSM para reversão. Isso reverte a função Lambda para o estado anterior à injeção de caos. Execute este comando:

aws ssm start-automation-execution \
--document-name “InjectLambdaChaos-Rollback” \
--document-version “\$DEFAULT\
--parameters \{“FunctionName”:[“FunctionName”],”LayerArn”:[“LayerArn”],”assumeRole”:[“RoleARN
”]}\
--region eu-west-2
Bash

Limpando / Apagando recursos

Para evitar cobranças futuras, apague os recursos criados pelo template do CloudFormation executando o seguinte comando da CLI. Atualize o nome da pilha para o que você forneceu ao criar a pilha.

aws cloudformation delete-stack --stack-name myChaosStack
Bash

Usando os resultados dos experimentos FIS

Você pode usar os resultados do experimento FIS para validar o comportamento esperado do sistema. Um exemplo do comportamento esperado é: “Se a latência do aplicativo aumentar em 10%, haverá um aumento de menos de 1% nas falhas de login”. Depois que o experimento for concluído, avalie se a resiliência do aplicativo está alinhada às suas expectativas comerciais e técnicas.

Conclusão

Este blog explica uma abordagem para testar a confiabilidade e a resiliência em funções do Lambda usando a engenharia do caos. Essa abordagem permite que você injete o caos nas funções do Lambda sem alterar o código da função do Lambda, com uma clara segregação da injeção de caos e da lógica de negócios. Ele fornece uma maneira de os desenvolvedores se concentrarem na criação de funcionalidades comerciais usando as funções do Lambda.

As camadas (layer) Lambda que injetam o caos podem ser desenvolvidas e gerenciadas separadamente. Essa abordagem usa o AWS FIS para executar experimentos que injetam caos usando camadas (layer) Lambda e testam o desempenho e a resiliência de aplicativos Serverless. Usando os insights do experimento FIS, você pode encontrar, corrigir ou documentar os riscos que surgem no aplicativo durante o teste.

Para obter mais recursos de aprendizado Serverless, visite Serverless Land.

 

Este artigo foi traduzido do Blog da AWS em Inglês.

 


Sobre o autor

Suranjan Choudhury é gerente de TME e ITes SA

 

 

 

 

Anil Sharma é Sr. PSA, Migração

 

 

 

 

Tradutor

Daniel Abib é Enterprise Solution Architect na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/