Automatizando experimentos de caos com o AWS Fault Injection Service e o AWS Lambda

Este post foi escrito por André Stoll, arquiteto de soluções na AWS.

A engenharia do caos é uma prática popular para aumentar a confiança na resiliência de um sistema. No entanto, muitas ferramentas existentes pressupõem a capacidade de alterar configurações de infraestrutura e não são facilmente aplicadas ao paradigma de aplicações Serverless. Devido à natureza stateless, efêmera e distribuída das arquiteturas Serverless, você precisa evoluir a técnica tradicional ao executar experimentos de caos nesses sistemas.

Este post explica uma técnica para executar experimentos de engenharia de caos nas funções do AWS Lambda. A abordagem usa extensões do Lambda para induzir falhas de runtime de forma independente, não exigindo alterações no código da função. Ele mostra como você pode usar o AWS Fault Injection Service (FIS) para automatizar e gerenciar experimentos de caos em diferentes funções do Lambda para fornecer um método de teste reutilizável.

Visão geral

Experimentos de caos são comumente aplicados a aplicações em nuvem para descobrir problemas latentes e evitar interrupções no serviço. As equipes de TI usam experimentos de caos para aumentar a confiança na robustez de seus sistemas. No entanto, os métodos tradicionais usados na engenharia do caos baseada em servidores não se traduzem facilmente no mundo Serverless, pois muitas ferramentas existentes se baseiam na alteração de configurações da infraestrutura subjacente, como nós de cluster ou instâncias de servidor de suas aplicações.

Em aplicações Serverless, a AWS lida com a carga operacional de gerenciar a infraestrutura, para que você possa se concentrar na entrega de valor comercial. Mas isso também significa que as equipes de engenharia têm controle limitado sobre a infraestrutura e precisam confiar em ferramentas em nível de aplicação para realizar experimentos de caos. Duas técnicas comumente usadas na comunidade Serverless para conduzir experimentos de caos em funções Lambda são modificar a configuração da função ou usar bibliotecas específicas de runtime.

Alterar a configuração de uma função Lambda permite que você induza falhas mais simples. Por exemplo, você pode definir a concorrência reservada de uma função Lambda para simular o throttling de invocação. Alternativamente, você pode alterar as permissões da execution role da função ou a política da função para simular uma negação de acesso do IAM. Esses tipos de falhas são fáceis de implementar, mas a variedade de possíveis tipos de fault injection é limitada.

A outra técnica — injetar caos nas funções do Lambda por meio de bibliotecas para runtimes específicas — é mais flexível. Existem várias bibliotecas de código aberto que permitem injetar falhas, como latência adicional, exceções ou esgotamento do disco. Exemplos dessas bibliotecas são chaos_lambda do Python e failure-lambda para Node.js. A desvantagem é que você deve alterar o código da função para cada função na qual deseja executar experimentos de caos. Além disso, essas bibliotecas são para runtimes específicas e cada uma vem com um conjunto de recursos e configurações diferentes. Isso reduz a reutilização de seus experimentos de caos nas funções do Lambda implementadas em diferentes linguagens.

Injetando caos usando extensões Lambda

A implementação de experimentos de caos usando extensões do Lambda permite que você resolva todas as preocupações anteriores. As extensões do Lambda ampliam suas funções adicionando funcionalidades, como capturar informações de diagnóstico ou instrumentar automaticamente seu código. Você pode integrar suas ferramentas preferidas de monitoramento, observabilidade ou segurança ao ambiente Lambda sem precisar de gerenciamento complexo de instalação ou configuração. As extensões do Lambda geralmente são empacotadas como camadas do Lambda (layers) e executadas como um processo separado no ambiente de execução do Lambda. Você pode usar extensões da AWS, usar extensões de parceiros do AWS Lambda ou criar sua própria funcionalidade personalizada.

Com as extensões Lambda, você pode implementar uma extensão de caos para injetar as falhas desejadas em seus ambientes Lambda. Essa extensão de caos usa o padrão proxy da API Runtime, que permite que você se conecte ao ciclo de vida da solicitação de invocação e resposta da função. As runtimes do Lambda usam a API Runtime do Lambda para recuperar o próximo evento de entrada a ser processado pelo manipulador da função e retornar a resposta do manipulador ao serviço Lambda.

O endpoint HTTP da API Runtime está disponível no ambiente de execução do Lambda. As runtimes obtêm o endpoint da API da variável de ambiente AWS_LAMBDA_RUNTIME_API. Durante a inicialização do ambiente de execução, você pode modificar o comportamento de inicialização da runtime. Isso permite que você altere o valor do AWS_LAMBDA_RUNTIME_API para a porta que o processo da extensão de caos está escutando. Agora, todas as solicitações para a API Runtime passam pelo proxy da extensão de caos. Você pode usar esse fluxo de trabalho para bloquear eventos maliciosos, auditar cargas ou injetar falhas.

1. A extensão de caos intercepta eventos de entrada e respostas de saída e injeta falhas de acordo com a configuração do experimento de caos.
2. A extensão acessa variáveis de ambiente para ler a configuração do experimento de caos.
3. Um script wrapper configura o tempo de execução para fazer proxy de solicitações por meio da extensão de caos.

Ao interceptar eventos de entrada e respostas de saída para a API Runtime do Lambda, você pode simular falhas, como introduzir um atraso artificial ou gerar uma resposta de erro para retornar ao serviço Lambda. Esse fluxo de trabalho adiciona latência às suas chamadas de função:

Todas as runtimes do Lambda oferecem suporte a extensões. Como as extensões são executadas como um processo separado, você pode implementá-las em uma linguagem diferente do código da função. A AWS recomenda que você implemente extensões usando uma linguagem de programação que compila em um executável binário, como Golang ou Rust. Isso permite que você use a extensão com qualquer runtime do Lambda.

Alguns dos projetos de código aberto que seguem essa técnica são a chaos-lambda-extension, implementada em Rust, ou a extensão serverless-chaos-extension, implementada em Python.

As extensões fornecem um método flexível e reutilizável para executar seus experimentos de caos nas funções do Lambda. Você pode reutilizar a extensão de caos para todas as runtimes sem precisar alterar o código da função. Adicione a extensão a qualquer função do Lambda em que você queira executar experimentos de caos.

Automatização com modelos de experimentos do AWS FIS

De acordo com os Princípios da Engenharia do Caos, você deve “automatizar seus experimentos para serem executados continuamente”. Para conseguir isso, você pode usar o AWS Fault Injection Service (FIS).

Esse serviço permite gerar modelos de experimentos reutilizáveis. O modelo especifica os alvos e as ações a serem executadas neles durante o experimento, além de uma condição de parada opcional que impede que o experimento ultrapasse limites. Você também pode executar runbooks do AWS Systems Manager Automation que oferecem suporte a tipos de falhas personalizados. Você pode escrever seus próprios documentos do Systems Manager personalizados para definir as etapas individuais envolvidas na automação. Para realizar as ações do experimento, você define scripts no documento para gerenciar sua função Lambda e configurá-la para o experimento de caos.

Para usar a extensão de caos em seus experimentos de caos Serverless:

1. Configure a função Lambda para o experimento. Adicione a extensão de caos como uma camada (layer) e configure o experimento, por exemplo, adicionando variáveis de ambiente especificando o tipo de falha e seu valor correspondente.
2. Pause a automação e conduza o experimento. Para fazer isso, use a ação de automação aws:sleep. Durante esse período, você conduz o experimento, mede e observa o resultado.
3. Limpe o experimento. O script remove a camada (layer) novamente e também redefine as variáveis de ambiente.

Executando seu primeiro experimento de caos Serverless

Esse repositório de exemplo fornece o código necessário para executar seu primeiro experimento de caos Serverless na AWS. O experimento usa a extensão chaos-lambda-extension para injeção de caos.

O exemplo faz o deploy do modelo de experimento do AWS FIS, os runbooks de automação SSM necessários, incluindo a função do IAM usada pelo runbook para configurar as funções do Lambda. O exemplo também provisiona uma função Lambda para testes e um alarme do Amazon CloudWatch usado para reverter o experimento.

Pré-requisitos

• Você tem a extensão de caos já implantada como uma camada (layer) do Lambda em sua conta da AWS.
• Você instalou a CLI do AWS Cloud Development Kit (CDK). Consulte o guia de primeiros passos com o AWS CDK para obter detalhes.
• Clone o repositório de exemplo localmente executando git clone git@github.com:aws-samples/Serverless-chaos-experiments.git
• Certifique-se de ter permissões suficientes para interagir com os alarmes do AWS FIS, Lambda e CloudWatch.

Executando o experimento

Siga as etapas descritas no repositório para realizar seu primeiro experimento. O início do experimento aciona a execução da automação.

Essa automação inclui adicionar a extensão e configurar o experimento, pausar a execução e observar o sistema e reverter todas as alterações para o estado inicial.

Se você invocar a função Lambda de destino durante a segunda etapa, as falhas (nesse caso, latência artificial) serão simuladas.

Práticas recomendadas de segurança

As extensões são executadas no mesmo ambiente de execução da função, portanto, elas têm o mesmo nível de acesso a recursos como sistema de arquivos, rede e variáveis de ambiente. As permissões do IAM atribuídas à função são compartilhadas com extensões. A AWS recomenda que você atribua apenas as permissões necessárias às suas funções.

Sempre instale extensões somente de uma fonte confiável. Use infraestrutura como código (IaC) e ferramentas de automação, como o CloudFormation ou o AWS Systems Manager, para simplificar a associação da mesma configuração de extensão, incluindo permissões do AWS Identity and Access Management (IAM), a várias funções. As ferramentas de IaC e automação permitem que você tenha um registro de auditoria das extensões e versões usadas anteriormente.

Ao criar extensões, não registre dados confidenciais. Limpe as cargas e os metadados antes de registrá-los ou mantê-los para fins de auditoria.

Conclusão

Este post detalha como realizar experimentos de caos para aplicações Serverless criadas usando o Lambda. A abordagem descrita usa extensões do Lambda para injetar falhas no ambiente de execução. Isso permite que você use o mesmo método, independentemente do runtime ou da configuração da função Lambda.

Para automatizar e conduzir o experimento com sucesso, você pode usar o AWS Fault Injection Service. Ao criar um modelo de experimento, você pode especificar as ações a serem executadas nos alvos definidos, como adicionar a extensão durante o experimento. Como a extensão pode ser usada para qualquer runtime, você pode reutilizar o modelo de experimento para injetar falhas em diferentes funções do Lambda.

Visite este repositório para implantar seu primeiro experimento de caos Serverless ou assista a este guia em vídeo para saber mais sobre a criação de extensões. Explore a documentação do AWS FIS para aprender a criar seus próprios experimentos.

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

Esse blog foi traduzido para o Português e o conteúdo original pode ser acessado aqui.

Biografia dos autores

André Stoll é arquiteto de soluções na AWS

Biografia da tradutora

Bianca Mota é arquiteta de soluções para o segmento de Startups e iniciou sua jornada na AWS em 2019 ajudando clientes em suas jornadas na nuvem. Além disso, Bianca é parte da comunidade Serverless na AWS e já apresentou sobre o assunto em diversos eventos, como o AWS Summit São Paulo e o AWS re:Invent. https://www.linkedin.com/in/bianca-smota/

Biografia do revisor

Daniel Abib é arquiteto de soluções sênior 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/