Eu tenho SQS - Lambda - SNS (minhas mensagens acabam na fila de mensagens mortas)

Question

Eu tenho uma função Lambda que tem uma simultaneidade fixa de 1 que tem um gatilho SQS configurado com batchSize de 10. Essa função Lambda publica apenas o que encontrar em um tópico do SNS (o código é apenas algumas linhas ). Estou usando isso para controlar uma quantidade enorme de mensagens que recebo para que meu backend possa processá-las sem engasgar.

Teoricamente, este Lambda nunca deve enviar nada para a fila de cartas mortas do SQS, mas 80% das mensagens acabam lá! Eu não entendo porque os logs do Lambda mostram que nenhuma execução falha. Não há exceções lançadas e apenas execuções bem-sucedidas estão sendo mostradas nos logs.

Em que ponto o Lambda decide que uma mensagem em particular deve ir para a fila de cartas mortas? (minha política de redirecionamento tem um máximo de 3).

    

Answer 1

Não responde diretamente à sua pergunta, mas porque o seu back-end não pesquisa o SQS e processa uma mensagem de cada vez ao seu próprio ritmo? Esse seria um padrão mais comum.

Você também poderia dimensionar o processamento de backend (se aplicável) adicionando mais nós com base na profundidade da fila do SQS. Se as suas mensagens chegarem com mais frequência, por exemplo, durante o horário comercial e com menos frequência à noite, o seu back-end deverá ser capaz de acompanhar o fluxo durante os períodos mais silenciosos.

Como alternativa, se você estiver interessado apenas nas mensagens mais recentes, poderá definir o tempo de expiração para algo como 1 minuto, após o qual a mensagem desaparecerá da fila e seu back-end recuperará a mais recente.

Acho que é uma arquitetura melhor do que tentar limitar as mensagens do Lambda ao SNS e esperar que o back-end continue.

Se não for possível fazer o polling SQS no backend , avise-nos e nós revisitaremos seu problema com o Lambda / DLQ;)

Espero que ajude:)

    

Answer 2

Parece que você não está as mensagens recuperadas na sua função do Lambda após o processamento.

Suponho que isso é o que acontece:

1. mensagem M1 chega ao SQS,
2. seu Lambda o pega, envia para o SNS, não o exclui do SQS e sai.
3. após algum tempo (após Tempo limite de visibilidade padrão = 30s), a mesma mensagem M1 é reinserida na fila, porque foi recuperada, mas não foi excluída após o processamento.
4. que acontece 3 vezes (devido à sua Política de Redrive) e, em seguida, é enviado para Fila de Devoluções .

Por fim, todas as mensagens acabam no DLQ por causa disso.

Estou certo? :)

    

Answer 3

Outra ideia - como a validade das mensagens no SQS é de até 4 dias, você pode ter um processo pesquisando o SQS em alguma taxa sustentável (conforme determinado pelo seu rendimento de RDS) e reenviar para o SNS. Esse processo implementará a limitação necessária - mantendo um contador de mensagens processadas no último minuto e atrasando a próxima pesquisa SQS até que a taxa de transferência esteja abaixo do limite. Algoritmo de janela simples deslizante deve fazer o truque. Você pode obter inspiração de limite de taxa de rede que tem o mesmo objetivo - limitar o throughput ao destinatário.

Isso será muito mais fácil de implementar do que ter o Lambda acionado pelo SQS e tentar estrangulá-lo por meio de simultaneidade e limites de tamanho de lote - esse método pode ter um perfil de rendimento bastante imprevisível. / p>

Você pode fazer o polling em um Lambda de longa duração (até 10 minutos por corrida, acredito) ou talvez melhor como um serviço em um contêiner rodando no Fargate ou no ECS. O que for mais barato.

Isso poderia ser uma resposta?