Implementando padrões de tratamento de erros do AWS Lambda

Este post foi escrito por Jeff Chen, arquiteto principal de aplicações em nuvem, e Jeff Li, arquiteto sênior de aplicações em nuvem

As arquiteturas orientadas por eventos são um estilo de arquitetura que pode ajudá-lo a aumentar a agilidade e criar aplicações confiáveis e escaláveis. Dividir uma aplicação em serviços pouco acoplados pode ajudar a escalar cada serviço de forma independente. Uma aplicação distribuída e pouco acoplada depende de eventos para comunicar os estados de alteração da aplicação. Cada serviço consome eventos de outros serviços e emite eventos para notificar outros serviços sobre mudanças de estado.

O tratamento de erros se torna ainda mais importante ao projetar aplicações distribuídas. Um serviço pode falhar se não conseguir lidar com uma carga de dados inválida, os recursos ou aplicações dependentes podem estar indisponíveis ou o serviço pode expirar. Pode haver erros de permissão que possam causar falhas. Os serviços da AWS fornecem muitos recursos para lidar com condições de erro, que você pode usar para melhorar a resiliência de suas aplicações.

Este post explora três casos de uso e padrões de design para lidar com falhas.

Visão geral

O AWS Lambda, o Amazon Simple Queue Service (Amazon SQS), o Amazon Simple Notification Service (Amazon SNS) e o Amazon EventBridge são os principais componentes para a criação de aplicações orientadas a eventos serverless.

O post Entendendo as diferentes maneiras de invocar funções Lambda lista as três maneiras diferentes de invocar uma função Lambda: invocação síncrona, assíncrona e baseada em polling. Para obter uma lista dos serviços e qual método de invocação eles usam, consulte a documentação.

A integração do Lambda com o Amazon API Gateway é um exemplo de invocação síncrona. Um cliente faz uma solicitação ao API Gateway, que envia a solicitação ao Lambda. O API Gateway aguarda a resposta da função e retorna a resposta ao cliente. Não há novas tentativas ou tratamento de erros incorporados. Se a solicitação falhar, o cliente tentará fazer a solicitação novamente.

A integração do Lambda com o SNS e o EventBridge são exemplos de invocações assíncronas. O SNS, por exemplo, envia um evento ao Lambda para processamento. Quando o Lambda recebe o evento, ele o coloca em uma fila de eventos interna e retorna uma confirmação ao SNS de que recebeu a mensagem. Outro processo do Lambda lê eventos da fila interna e invoca sua função do Lambda. Se o SNS não conseguir entregar um evento à sua função do Lambda, o serviço tentará realizar automaticamente a mesma operação com base em uma política de repetição (retry).

A integração do Lambda com o SQS usa invocações baseadas em polling. O Lambda executa uma frota de pollers que pesquisam mensagens em sua fila do SQS. Os pollers leem as mensagens em lotes e invocam sua função Lambda uma vez por lote.

Você pode aplicar esse padrão em vários cenários. Por exemplo, sua aplicação operacional pode adicionar pedidos de venda a um armazenamento de dados operacional. Em seguida, talvez você queira carregar os pedidos de venda em seu data warehouse periodicamente para que as informações estejam disponíveis para previsão e análise. A aplicação operacional pode agrupar as vendas concluídas como eventos e colocá-las em uma fila do SQS. Uma função Lambda pode então processar os eventos e carregar os registros de venda preenchidos em seu data warehouse.

Se sua função processar o lote com êxito, os pollers excluirão as mensagens da fila do SQS. Se o lote não for processado com êxito, os pollers não excluirão as mensagens da fila. Quando o tempo limite de visibilidade expirar, as mensagens estarão disponíveis novamente para serem reprocessadas. Se o período de retenção da mensagem expirar, o SQS excluirá a mensagem da fila.

A tabela a seguir mostra os tipos de invocação e o comportamento de repetição (retry) dos serviços da AWS mencionados.

Há vários padrões de design a serem usados para tipos de invocação assíncrona e baseada em polling para reter mensagens com falha para processamento adicional. Esses padrões podem ajudar você a se recuperar de falhas de entrega ou processamento.

Você pode explorar os padrões e testar os cenários implantando o código desse repositório que usa o AWS Cloud Development Kit (AWS CDK) com Python.

Padrão de invocação baseado em polling no Lambda

Ao usar o Lambda com o SQS, se o Lambda não conseguir processar a mensagem e o período de retenção da mensagem expirar, o SQS descartará a mensagem. A falha no processamento da mensagem pode ocorrer devido a falhas no processamento da função, incluindo timeout ou cargas inválidas. Falhas de processamento também podem ocorrer quando a função de destino não existe ou tem permissões incorretas.

Você pode configurar uma dead-letter queue (DLQ) separada na fila de origem para que o SQS retenha a mensagem descartada. Uma DLQ preserva a mensagem original e é útil para analisar as causas-raiz, tratar condições de erro adequadamente ou enviar notificações que exijam intervenções manuais. No cenário de invocação baseada em polling, a função Lambda em si não mantém uma DLQ. Ela depende da DLQ externa configurada no SQS. Para obter mais informações, consulte Usando o Lambda com o Amazon SQS.

A seguinte imagem mostra o padrão de design quando você configura o Lambda para pesquisar eventos de uma fila do SQS e invocar uma função Lambda.

O Lambda faz a pesquisa síncrona em lotes de mensagens do SQS

Para explorar esse padrão, faça o deploy do código desse repositório. Depois de implantado, você pode usar essas instruções para testar o padrão com os caminhos que resultem sucesso e falha.

Padrão de invocação assíncrona no Lambda

Com invocações assíncronas, há dois aspectos de falha a serem considerados ao usar o Lambda. A fonte do evento não poder entregar a mensagem para o Lambda e a função Lambda cometer erros ao processar o evento.

As fontes de eventos variam na forma como lidam com falhas na entrega de mensagens para o Lambda. Se o SNS ou o EventBridge não conseguirem enviar o evento para o Lambda após esgotarem todas as tentativas, o serviço cancelará o evento. Você pode configurar uma DLQ em um tópico do SNS ou no barramento de eventos do EventBridge para recuperar o evento descartado. Isso funciona da mesma forma que o padrão de invocação baseado em polling com SQS.

As funções Lambda podem então apresentar erros devido a erros de sintaxe do input payload, timeouts de duração ou a função gerar uma exceção, como um recurso de dados não disponível.

Para invocações assíncronas, você pode configurar por quanto tempo o Lambda retém um evento em sua fila interna, em até 6 horas. Você também pode configurar quantas vezes o Lambda tenta novamente quando a função dá erro, entre 0 e 2. O Lambda descarta o evento quando o tempo máximo passa ou todas as tentativas de repetição falham. Para reter uma cópia dos eventos descartados, você pode configurar uma DLQ ou, de preferência, um Lambda destination (destino) de evento com falha como parte da configuração da função Lambda.

Um destination no Lambda permite que você especifique o que fazer em seguida se uma invocação assíncrona for bem sucedida ou falhar. Você pode configurar um destination para enviar registros de invocação para SQS, SNS, EventBridge ou outra função do Lambda. Destinations são preferíveis para o processamento de falhas, pois oferecem suporte a targets adicionais e incluem informações adicionais. Uma DLQ contém o evento original que falhou. Com um destination, o Lambda também passa detalhes da resposta da função no registro de invocação. Isso inclui rastreamento da stack, que pode ser útil para analisar a causa raiz.

Usando DLQ e Lambda destinations

Você pode aplicar esse padrão em vários cenários. Por exemplo, muitas de suas aplicações podem conter registros de clientes. Para cumprir a Lei de Privacidade do Consumidor da Califórnia (CCPA) ou a Lei Geral de Proteção de Dados Pessoais (LGPD), diferentes organizações podem precisar excluir registros de um determinado cliente. Você pode configurar um tópico de exclusão do SNS para consumidores. Cada organização cria uma função Lambda, que processa os eventos publicados pelo tópico do SNS e exclui registros de clientes em suas aplicações gerenciadas.

O exemplo a seguir mostra o padrão de design quando você configura um tópico do SNS como fonte de eventos para uma função Lambda, que usa filas como um destination para processos de sucesso e falha.

Tópico do SNS como fonte de eventos para Lambda

Você configura uma DLQ no tópico SNS para capturar mensagens que o SNS não pôde entregar ao Lambda. Quando o Lambda invoca a função, ele envia detalhes das mensagens processadas com sucesso para um “on-success” destination no SQS. Você pode usar esse padrão para rotear um evento para diferentes serviços em casos de uso mais simples. Para orquestrar vários serviços, o AWS Step Functions é a melhor opção de design.

O Lambda também pode enviar detalhes de mensagens processadas sem sucesso para um “on-failure” destination no SQS.

Uma variante desse padrão é substituir um destination no SQS por um destination no EventBridge para que vários consumidores possam processar um evento com base no destination.

Para explorar como usar ums DLQ no SQS e Lambda destinations, faça deploy do código desse repositório. Depois de implantado, você pode usar essas instruções para testar o padrão com os caminhos que resultem sucesso e falha.

Usando uma DLQ

Embora usar o destinations seja o método preferido para lidar com falhas de função, você pode explorar o uso de DLQs.

O exemplo a seguir mostra o padrão de design quando você configura um tópico do SNS como a fonte do evento para uma função Lambda, que usa filas SQS para o processo de falha.

Função Lambda invocada de forma assíncrona

Você configura uma DLQ no tópico SNS para capturar as mensagens que o SNS não pôde entregar à função Lambda. Você também configura uma DLQ separada para a função Lambda. O Lambda salva um evento mal sucedido nessa DLQ depois que o Lambda não consegue processar o evento após o máximo de tentativas.

Para explorar como usar uma DLQ no Lambda, faça o deploy do código desse repositório. Depois de implantado, você pode usar essas instruções para testar o padrão com caminhos que resultem sucesso e falha.

Conclusão

Este post explica três padrões que você pode usar para criar aplicações resilientes e orientadas por eventos. O tratamento de erros durante o processamento de eventos é uma parte importante da criação de aplicações serverless em nuvem.

Você pode fazer deploy do código dos repositórios para explorar como usar invocações assíncronas e baseadas em polling. Ver como as invocações baseadas em polling podem enviar mensagens com falha para uma DLQ. Ver como usar DLQs e Lambda destinations para rotear e lidar com eventos malsucedidos.

Saiba mais sobre arquiteturas orientadas a eventos no Serverless Land.

Esse blog foi traduzido para o Português e o conteúdo original pode ser acessado em: https://aws.amazon.com/blogs/compute/implementing-aws-lambda-error-handling-patterns/

Biografia dos autores 

	Jeff Chen é arquiteto principal de aplicações em nuvem.
	Jeff Li é arquiteto sênior de aplicações em nuvem.

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/