Integrando o Amazon SQS com o AWS Lambda - Entendendo os principais aspectos dessa integração

Neste artigo, a ideia é explorar todos os aspectos que envolvem essa que é uma das principais integrações no mundo serverless: uma Lambda consumindo mensagens do serviço SQS. Apesar de simples de criar, essa integração possui aspectos importantes (alguns desconhecidos pelos desenvolvedores) que impactam diretamente na confiabilidade da sua solução. Conceitos Fundamentais O Amazon SQS (Simple Queue Service) integrado ao AWS Lambda implementa um modelo de processamento baseado em polling, através de um mecanismo chamado event source mapping para criar um fluxo de processamento. O event source mapping é responsável por realizar uma chamada GET na API do SQS, agrupar os resultados em lotes e invocar de forma síncrona a Lambda. Conforme podemos ver na imagem abaixo: Mecanismo de Processamento A Lambda implementa o seguinte fluxo de processamento: Polling das Mensagens Como vimos, a Lambda realiza consultas periódicas à fila SQS e as mensagens são recuperadas em lotes. Cada lote gera uma única invocação da função Lambda. Ciclo de Visibilidade A partir daqui entra um aspecto importante da integração, o ciclo de visibilidade das mensagens. As mensagens permanecem na fila durante o processamento da Lambda, porém de forma oculta de acordo com o visibility timeout configurado na fila. Quando definimos um visibility timeout de 30 segundos, por exemplo, as mensagens que estão sendo processadas pela Lambda permanecerão invisíveis por este período, evitando assim que outros consumidores tentem processá-las simultaneamente. Gerenciamento de Conclusão Se o processamento for bem sucedido, a Lambda remove automaticamente as mensagens da fila. Caso a Lambda tenha uma falha no processamento, as mensagens retornam à fila após a expiração do visibility timeout. Configurações de Processamento em Lote O trigger SQS para a Lambda oferece configurações específicas para otimização do processamento: Tamanho do Lote: Por padrão, agrupa 10 mensagens em uma única execução, mas pode ser aumentado até 10 mil mensagens para filas standard e 10 para filas FIFO. Janela de Lote (Batch Window): Permite acumular mensagens por até 5 minutos antes de invocar o processamento da Lambda. Quando um desses dois critérios é alcançado, dispara a execução da Lambda. Garantias de Processamento O mecanismo de event source mapping garante processamento "at least once", que significa que uma mensagem será processada pelo menos uma vez, podendo ocorrer processamentos duplicados. Para gerenciar esta característica, é importante a Lambda possuir mecanismo de idempotência. Mecanismos de Tratamento de Erros A Lambda implementa automaticamente um mecanismo de tratamento de erros que reduz gradualmente a escalabilidade (Lambdas executando em paralelo) durante o consumo de mensagens da fila SQS, prevenindo assim que erros ocorram em larga escala na sua aplicação. Em casos de throttling (quando a Lambda retorna erro 429 too many requests), a Lambda tenta reprocessar a mesma mensagem até que o visibility timeout na fila expire. Após esse período, caso o processamento não tenha sido bem sucedido, a mensagem é descartada.

Feb 18, 2025 - 19:06

Integrando o Amazon SQS com o AWS Lambda - Entendendo os principais aspectos dessa integração

Neste artigo, a ideia é explorar todos os aspectos que envolvem essa que é uma das principais integrações no mundo serverless: uma Lambda consumindo mensagens do serviço SQS. Apesar de simples de criar, essa integração possui aspectos importantes (alguns desconhecidos pelos desenvolvedores) que impactam diretamente na confiabilidade da sua solução.

Conceitos Fundamentais

O Amazon SQS (Simple Queue Service) integrado ao AWS Lambda implementa um modelo de processamento baseado em polling, através de um mecanismo chamado event source mapping para criar um fluxo de processamento. O event source mapping é responsável por realizar uma chamada GET na API do SQS, agrupar os resultados em lotes e invocar de forma síncrona a Lambda. Conforme podemos ver na imagem abaixo:

Mecanismo de Processamento

A Lambda implementa o seguinte fluxo de processamento:

Polling das Mensagens
Como vimos, a Lambda realiza consultas periódicas à fila SQS e as mensagens são recuperadas em lotes. Cada lote gera uma única invocação da função Lambda.
Ciclo de Visibilidade
A partir daqui entra um aspecto importante da integração, o ciclo de visibilidade das mensagens. As mensagens permanecem na fila durante o processamento da Lambda, porém de forma oculta de acordo com o visibility timeout configurado na fila. Quando definimos um visibility timeout de 30 segundos, por exemplo, as mensagens que estão sendo processadas pela Lambda permanecerão invisíveis por este período, evitando assim que outros consumidores tentem processá-las simultaneamente.
Gerenciamento de Conclusão
Se o processamento for bem sucedido, a Lambda remove automaticamente as mensagens da fila. Caso a Lambda tenha uma falha no processamento, as mensagens retornam à fila após a expiração do visibility timeout.

Configurações de Processamento em Lote

O trigger SQS para a Lambda oferece configurações específicas para otimização do processamento:

Tamanho do Lote: Por padrão, agrupa 10 mensagens em uma única execução, mas pode ser aumentado até 10 mil mensagens para filas standard e 10 para filas FIFO.
Janela de Lote (Batch Window): Permite acumular mensagens por até 5 minutos antes de invocar o processamento da Lambda.

Quando um desses dois critérios é alcançado, dispara a execução da Lambda.

Garantias de Processamento

O mecanismo de event source mapping garante processamento "at least once", que significa que uma mensagem será processada pelo menos uma vez, podendo ocorrer processamentos duplicados. Para gerenciar esta característica, é importante a Lambda possuir mecanismo de idempotência.

Mecanismos de Tratamento de Erros

A Lambda implementa automaticamente um mecanismo de tratamento de erros que reduz gradualmente a escalabilidade (Lambdas executando em paralelo) durante o consumo de mensagens da fila SQS, prevenindo assim que erros ocorram em larga escala na sua aplicação.

Em casos de throttling (quando a Lambda retorna erro 429 too many requests), a Lambda tenta reprocessar a mesma mensagem até que o visibility timeout na fila expire. Após esse período, caso o processamento não tenha sido bem sucedido, a mensagem é descartada.