Tiempo de espera de visibilidad, DLQ y long polling

Cuando un consumidor recibe un mensaje de SQS, el mensaje se oculta para todos los demás consumidores durante un período llamado tiempo de espera de visibilidad. Durante este intervalo, el consumidor procesa el mensaje y después lo elimina. Si el consumidor se bloquea o no termina a tiempo, el tiempo de espera de visibilidad expira y el mensaje vuelve a estar visible, lo que permite que otro consumidor lo procese. Este es el mecanismo principal que sustenta la garantía de entrega al menos una vez de SQS.

El tiempo de espera de visibilidad predeterminado es de 30 segundos. Puede configurarse entre 0 segundos y 12 horas. Establézcalo con un margen suficiente por encima del tiempo máximo de procesamiento previsto: si el procesamiento tarda hasta 2 minutos, establezca el tiempo de espera en al menos 3 o 4 minutos. También puede cambiar el tiempo de espera por recepción mediante change-message-visibility, lo que resulta útil cuando un consumidor detecta que necesita más tiempo para terminar de procesar un mensaje específico.

Establecer el tiempo de espera demasiado corto hace que los mensajes reaparezcan antes de que el consumidor termine, lo que provoca un procesamiento duplicado. Establecerlo demasiado largo retrasa que otro consumidor recoja un mensaje si el consumidor original falla silenciosamente (por ejemplo, si se bloquea una instancia de EC2 sin realizar una limpieza correcta). El tiempo de espera óptimo es ligeramente superior al tiempo de procesamiento del percentil 99, pero lo bastante corto para recuperarse rápidamente de los fallos de los consumidores. Supervise la métrica de CloudWatch ApproximateNumberOfMessagesNotVisible para detectar problemas relacionados con el tiempo de espera.

Una cola de mensajes no entregados (DLQ) es una cola de SQS independiente a la que se envían los mensajes después de que fallen al procesarse un número configurable de veces (el maxReceiveCount). Cuando el número de recepciones de un mensaje supera maxReceiveCount, SQS lo mueve automáticamente a la DLQ. Las DLQ evitan que los mensajes problemáticos (mensajes que siempre fallan) bloqueen la cola indefinidamente. Los mensajes de la DLQ pueden inspeccionarse, depurarse y reproducirse después de corregir el error de procesamiento.

Una DLQ no es más que una cola de SQS normal (Standard para un origen Standard y FIFO para un origen FIFO). Configure la política de redirección en la cola de origen para especificar qué cola es la DLQ y cuál es el umbral de maxReceiveCount. Asegúrese de que el período de retención de la DLQ sea más largo que el de la cola de origen: los mensajes llegan tarde a la DLQ y necesita tiempo para investigarlos antes de que caduquen.

Configure una alarma de CloudWatch sobre la métrica ApproximateNumberOfMessagesVisible de la DLQ. Cualquier mensaje que llegue a la DLQ indica un fallo de procesamiento que requiere atención. Configure la alarma para activar una notificación de SNS que avise inmediatamente al ingeniero de guardia. Trate cada mensaje de la DLQ como un error que debe investigarse: los mensajes de la DLQ no deben acumularse silenciosamente. Después de corregir el error, use DLQ Redrive para devolver los mensajes a la cola de origen y reprocesarlos.

Una vez corregido el error que provocó los fallos de procesamiento, use SQS DLQ Redrive para mover los mensajes de la DLQ a la cola de origen y reprocesarlos. La consola proporciona una función de redirección integrada. Puede filtrar por atributos de mensaje para reproducir únicamente mensajes específicos. Como alternativa, escriba una función de Lambda que sondee la DLQ y reenvíe los mensajes a la cola de origen si necesita una lógica de filtrado personalizada.

De forma predeterminada, SQS utiliza el sondeo corto: una llamada a receive-message consulta un subconjunto aleatorio de servidores y devuelve la respuesta inmediatamente, incluso si no hay mensajes disponibles. Esto genera muchas respuestas vacías y desperdicia llamadas a la API. El sondeo largo espera hasta 20 segundos a que llegue un mensaje antes de devolver una respuesta vacía. El sondeo largo reduce significativamente los costes (menos llamadas a la API) y disminuye la latencia (el mensaje se recibe en cuanto llega, hasta 20 segundos antes que en el siguiente ciclo de sondeo).

Active el sondeo largo en el nivel de la cola (se aplica a todas las llamadas de recepción) o por solicitud. La configuración a nivel de cola con ReceiveMessageWaitTimeSeconds establecido en 20 es la recomendada para la mayoría de las aplicaciones. Cuando Lambda utiliza SQS como origen de eventos, usa automáticamente el sondeo largo. Para consumidores basados en EC2, establezca WaitTimeSeconds en la llamada a receive-message.

Los mensajes de SQS pueden incluir atributos de mensaje: pares de clave-valor de metadatos independientes del cuerpo del mensaje. Los atributos tienen un tipo (String, Number, Binary) y un valor. Cuando SQS está suscrito a un tema de SNS, puede usar políticas de filtro de suscripción de SNS aplicadas a los atributos de mensaje para enrutar únicamente los mensajes relevantes a cada cola. Sin filtrado, cada suscriptor de SQS recibe todas las publicaciones de SNS, independientemente de su contenido.

Una cola de retardo hace que cada mensaje nuevo permanezca invisible durante un período de retardo (de 0 a 15 minutos) después de enviarse. Esto resulta útil en flujos de trabajo en los que un consumidor no debe procesar un mensaje inmediatamente, por ejemplo, mientras espera a que termine primero un proceso del que depende. También puede establecer un retardo por mensaje mediante DelaySeconds en la llamada de envío, lo que anula el retardo configurado a nivel de cola. Nota: las colas de retardo no están disponibles para las colas FIFO.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido lo siguiente: Visibility Timeout oculta un mensaje a otros consumidores durante su procesamiento, lo que permite una entrega al menos una vez con reenvío automático si el consumidor falla; las Dead-Letter Queues capturan los mensajes que fallan repetidamente para depurarlos y reproducirlos después de corregir el error; y el Long Polling (un tiempo de espera de hasta 20 segundos) reduce los costes de la API y la latencia en comparación con el sondeo corto. A continuación, exploraremos los temas de SNS y la arquitectura fan-out.