Implementação de padrões de tratamento de erros do AWS Lambda

As arquiteturas orientadas por eventos são um estilo de arquitetura que pode ajudar você a aumentar a agilidade e criar aplicativos confiáveis e escaláveis. Dividir um aplicativo em serviços pouco acoplados pode ajudar cada serviço a crescer de forma independente. Um aplicativo distribuído e fracamente acoplado depende de eventos para comunicar os estados de alteração do aplicativo. 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 aplicativos distribuídos. Um serviço pode falhar se não conseguir lidar com uma carga inválida, se os recursos dependentes estiverem indisponíveis ou se o serviço atingir o tempo limite. Podendo ainda haver erros de permissão que causam 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 seus aplicativos.

Esta postagem 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 elementos básicos para a criação de aplicativos orientados por eventos sem servidor.

O post Entendendo as diferentes maneiras de invocar funções do AWS Lambda lista as três maneiras diferentes de invocar uma função do AWS Lambda: invocação síncrona, assíncrona e baseada em fontes de eventos (“event source mapping”). Para obter uma lista de 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 Amazon API Gateway, que envia a solicitação para o AWS Lambda. O Amazon API Gateway aguarda a resposta da função e retorna a resposta ao cliente. Não há novas tentativas embutidas ou tratamento de erros. Se a solicitação falhar, o cliente tentará a solicitação novamente.

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

A integração do Lambda com o Amazon SQS usa invocações baseadas em buscas (“poll-based invocations”). O Lambda administra uma frota de pooling que pesquisam mensagens na fila do Amazon SQS. Os pesquisadores (“poolers”) 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, seu aplicativo pode adicionar pedidos de vendas a um armazenamento de dados. Em seguida, talvez você queira carregar as ordens de venda em seu data warehouse periodicamente para que as informações estejam disponíveis para previsão e análise. O aplicativo pode agrupar as vendas concluídas como eventos e colocá-las em uma fila do Amazon SQS. Uma função Lambda pode então processar os eventos e carregar os registros de vendas concluídos em seu data warehouse.

Se sua função de processar o lote for realizada com êxito, os pesquisadores (“poolers”)  excluirão as mensagens da fila Amazon SQS. Se o lote não for processado com sucesso, os pesquisadores (“poolers”) 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 Amazon SQS excluirá a mensagem da fila.

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

Há vários padrões de design a serem usados para tipos de invocação assíncrona e baseados em pooling 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) usando Python.

Padrão de invocação baseado em pesquisa (“poll-based”) no Lambda

Ao usar o AWS Lambda com o Amazon SQS, se o AWS Lambda não conseguir processar a mensagem e o período de retenção da mensagem expirar, o Amazon SQS descartará a mensagem. A falha no processamento da mensagem pode ocorrer devido a falhas no processamento da função Lambda, incluindo tempos limite ou cargas (payloads) 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 fila de mensagens (DLQ) separada na fila de origem para que o Amazon SQS retenha a mensagem descartada. Uma DLQ preserva a mensagem original e é útil para analisar as causas principais, lidar adequadamente com as condições de erro ou enviar notificações que exigem intervenções manuais. No cenário de invocação baseada em pooling, a função Lambda em si não mantém uma DLQ. Ele se baseia na DLQ externa configurada no Amazon SQS. Para obter mais informações, consulte Como usar o Lambda com o Amazon SQS.

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

Para explorar esse padrão, implante o código nesse repositório. Depois de implantado, você pode usar essa instrução para testar o padrão com os caminhos felizes e infelizes.

Padrão de invocação assíncrona do AWS Lambda

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

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

As funções do AWS Lambda podem, então, apresentar erros devido a erros de sintaxe da carga útil (payloads) de entrada, limites 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, até 6 horas. Você também pode configurar quantas vezes o Lambda tenta novamente quando a função comete erros, entre 0 e 2. O Lambda descarta o evento quando a idade máxima passa ou todas as tentativas de nova tentativa falham. Para reter uma cópia dos eventos descartados, você pode configurar uma DLQ ou, de preferência, um destino de evento com falha como parte da configuração da função do Lambda.

Um destino do AWS Lambda permite que você especifique o que fazer a seguir se uma invocação assíncrona for bem-sucedida ou falhar. Você pode configurar um destino para enviar registros de invocação para Amazon SQS, Amazon SNS, Amazon EventBridge ou outra função do AWS Lambda. Os destinos são preferidos para o processamento de falhas, pois oferecem suporte a metadados adicionais e incluem informações adicionais. Um DLQ contém o evento original que falhou. Com um destino, o AWS Lambda também passa detalhes da resposta da função no registro de invocação. Isso inclui rastreamentos de pilha, que podem ser úteis para analisar a causa raiz.

Usando destinos DLQ e AWS Lambda

Você pode aplicar esse padrão em vários cenários. Por exemplo, muitos de seus aplicativos podem conter registros de clientes. Para cumprir a Lei de Privacidade do Consumidor da Califórnia (CCPA), diferentes organizações podem precisar excluir registros de um determinado cliente. Você pode configurar um tópico Amazon SNS de exclusão do consumidor. Cada organização cria uma função AWS Lambda, que processa os eventos publicados pelo tópico do Amazon SNS e exclui registros de clientes em seus aplicativos gerenciados.

O seguinte mostra o padrão de design quando você configura um tópico do Amazon SNS como a origem do evento para uma função do AWS Lambda, que usa filas de destino para processos de sucesso e falha.

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

O AWS Lambda também pode enviar detalhes de mensagens processadas sem sucesso para um destino Amazon SQS em caso de falha.

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

Para explorar como usar um Amazon SQS DLQ e destinos Lambda, implante o código nesse repositório. Depois de implantado, você pode usar essa instrução para testar o padrão com os caminhos felizes e infelizes.

Usando um DLQ

Embora os destinos sejam o método preferido para lidar com falhas de função, você pode explorar o uso de DLQs.

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

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

Para explorar como usar uma DLQ do AWS Lambda, implante o código nesse repositório. Depois de implantado, você pode usar essa instrução para testar o padrão com caminhos felizes e infelizes.

Conclusão

Esta postagem explica três padrões que você pode usar para projetar aplicativos resilientes e sem servidor orientados por eventos. O tratamento de erros durante o processamento de eventos é uma parte importante do design de aplicativos em nuvem sem servidor.

Você pode fazer o deploy do código do repositório para explorar como usar invocações assíncronas e baseadas em pooling. Veja como as invocações baseadas em pooling podem enviar mensagens com falha para uma DLQ. Veja como usar DLQs e destinos AWS Lambda para rotear e lidar com eventos malsucedidos.

Saiba mais sobre a arquitetura orientada por eventos no Serverless Land.

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