Tempo limite de visibilidade, DLQ e sondagem longa

Quando um consumidor recebe uma mensagem do SQS, ela fica oculta para todos os outros consumidores durante um período chamado tempo limite de visibilidade. Durante essa janela, o consumidor processa a mensagem e depois a exclui. Se o consumidor falhar ou não terminar a tempo, o tempo limite de visibilidade expirará e a mensagem ficará visível novamente, permitindo que outro consumidor a obtenha. Esse é o mecanismo central por trás da garantia de entrega pelo menos uma vez do SQS.

O tempo limite de visibilidade padrão é de 30 segundos. Ele pode ser definido de 0 segundos a 12 horas. Defina-o para exceder confortavelmente o tempo máximo esperado de processamento — se o processamento levar até 2 minutos, defina o tempo limite como pelo menos 3 a 4 minutos. Também é possível alterar o tempo limite por recibo usando change-message-visibility, o que é útil quando um consumidor detecta que precisa de mais tempo para terminar o processamento de uma mensagem específica.

Definir o tempo limite como curto demais faz as mensagens reaparecerem antes que o consumidor termine, levando ao processamento duplicado. Defini-lo como longo demais impede que outro consumidor obtenha uma mensagem se o consumidor original falhar silenciosamente (por exemplo, uma falha da instância do EC2 sem uma limpeza adequada). O tempo limite ideal é: um pouco maior que o tempo de processamento no percentil 99, mas curto o suficiente para permitir uma recuperação rápida de falhas dos consumidores. Monitore a métrica do CloudWatch ApproximateNumberOfMessagesNotVisible para identificar problemas com o tempo limite.

Uma fila de mensagens não entregues (DLQ) é uma fila separada do SQS para a qual as mensagens são enviadas depois de falharem no processamento um número configurável de vezes (o maxReceiveCount). Quando a contagem de recebimentos de uma mensagem excede maxReceiveCount, o SQS a move automaticamente para a DLQ. As DLQs impedem que mensagens problemáticas (mensagens que sempre falham) bloqueiem a fila indefinidamente. As mensagens na DLQ podem ser inspecionadas, depuradas e reproduzidas depois que o erro de processamento for corrigido.

Uma DLQ é simplesmente uma fila comum do SQS (Standard para uma origem Standard, FIFO para uma origem FIFO). Você configura a política de redirecionamento na fila de origem para especificar qual fila é a DLQ e definir o limite de maxReceiveCount. Certifique-se de que o período de retenção da DLQ seja maior que o período de retenção da fila de origem — as mensagens chegam à DLQ tarde, e você precisa de tempo para investigá-las antes que expirem.

Configure um alarme do CloudWatch para a métrica ApproximateNumberOfMessagesVisible da DLQ. Qualquer mensagem que chegue à DLQ indica uma falha de processamento que requer atenção. Configure o alarme para disparar uma notificação do SNS que envie imediatamente um alerta ao engenheiro de plantão. Trate cada mensagem da DLQ como um erro que precisa ser investigado — as mensagens da DLQ não devem se acumular silenciosamente. Depois de corrigir o erro, use o redirecionamento da DLQ para enviar as mensagens de volta à fila de origem para reprocessamento.

Depois de corrigir o erro que causou as falhas de processamento, use o redirecionamento da DLQ do SQS para mover as mensagens da DLQ de volta à fila de origem para reprocessamento. O console oferece um recurso integrado de redirecionamento. Você pode filtrar por atributos da mensagem para reproduzir somente mensagens específicas. Como alternativa, escreva uma função do Lambda para consultar a DLQ e encaminhar as mensagens de volta à fila de origem caso precise de uma lógica de filtragem personalizada.

Por padrão, o SQS usa consulta curta: uma chamada receive-message consulta um subconjunto aleatório de servidores e retorna imediatamente, mesmo quando não há mensagens disponíveis. Isso resulta em muitas respostas vazias e desperdiça chamadas de API. A consulta prolongada espera até 20 segundos pela chegada de uma mensagem antes de retornar uma resposta vazia. A consulta prolongada reduz significativamente os custos (menos chamadas de API) e diminui a latência (a mensagem é recebida assim que chega, até 20 segundos antes do próximo ciclo de consulta).

Ative a consulta prolongada no nível da fila (aplicável a todas as chamadas de recebimento) ou por solicitação. A configuração no nível da fila com ReceiveMessageWaitTimeSeconds definido como 20 é a recomendação para a maioria das aplicações. Quando o Lambda usa o SQS como origem de eventos, ele usa automaticamente a consulta prolongada. Para consumidores baseados em EC2, defina WaitTimeSeconds na chamada receive-message.

As mensagens do SQS podem conter atributos de mensagem — pares de metadados de chave e valor separados do corpo da mensagem. Os atributos têm um tipo (String, Number, Binary) e um valor. Quando o SQS está inscrito em um tópico do SNS, você pode usar políticas de filtro de assinatura do SNS aplicadas aos atributos das mensagens para encaminhar somente as mensagens relevantes para cada fila. Sem filtragem, cada assinante do SQS recebe cada publicação do SNS, independentemente do conteúdo.

Uma fila de atraso torna cada mensagem nova invisível durante um período de atraso (de 0 a 15 minutos) depois que ela é enviada. Isso é útil para fluxos de trabalho nos quais um consumidor não deve processar uma mensagem imediatamente — por exemplo, quando é necessário aguardar primeiro a conclusão de um processo dependente. Também é possível definir um atraso por mensagem usando DelaySeconds na chamada de envio, o que substitui o atraso definido no nível da fila. Observação: as filas de atraso não estão disponíveis para filas FIFO.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu: o tempo limite de visibilidade oculta uma mensagem de outros consumidores durante o processamento, permitindo a entrega pelo menos uma vez, com reentrega automática se o consumidor falhar; as filas de mensagens não entregues capturam mensagens que falham repetidamente para depuração e reprodução depois que o erro é corrigido; e a sondagem longa (com espera de até 20 segundos) reduz os custos de API e a latência em comparação com a sondagem curta. A seguir, exploraremos os tópicos do SNS e a arquitetura de distribuição.