Solución:
Los reintentos y los reintentos “tiempo de espera” se pueden configurar directamente en la cola de SQS.
Cuando cree una cola, configure los siguientes atributos:
los Tiempo de espera de visibilidad predeterminado será el momento en que el mensaje será oculto una vez que su solicitud la haya recibido. Si el mensaje falla durante la ejecución de lambda y se lanza una excepción, lambda no eliminará cualquiera de los mensajes en el lote y todos ellos eventualmente volverán a aparecer en la cola.
Si solo desea intentarlo 3 veces, debe configurar la política de reinicio de SQS (también conocida como Cola de mensajes fallidos)
La política de reenvío permitirá que su cola redirija los mensajes a una Cola de mensajes fallidos (DLQ) después de que el mensaje haya reaparecido en la cola. N número de veces, donde N es un número entre 1 y 1000.
Es esencial comprender que lambda continuará procesando un mensaje fallido (un mensaje que genera una excepción en el código) hasta que:
- Se procesa sin errores (lambda elimina el mensaje)
- los
Message Retention Periodexpira (SQS elimina el mensaje) - Se envía al conjunto de DLQ en la política de re-conducción de la cola de SQS (SQS “mueve” el mensaje al DLQ)
- Elimina el mensaje de la cola directamente en su código (el usuario elimina el mensaje)
Lambda no eliminará este mensaje incorrecto de otro modo.
Observaciones importantes
Lambda no se ocupará de los mensajes fallidos
Según varios experimentos que realicé para comprender el comportamiento de la integración de SQS (la documentación sobre los reintentos es ambigua ATM), lambda no eliminará los mensajes fallidos y continuará volviéndolos a intentar. Incluso si tiene una Lambda DLQ configurada, los mensajes no se enviarán a la DLQ, depende completamente de la configuración de la cola SQS para este propósito, como se indica en la documentación de lambda DLQ.
Recomendación:
- Utilice siempre una política de reinicio en su cola de SQS.
Las excepciones fallarán en un lote completo de mensajes
Como dije anteriormente, si hay una excepción en su código mientras se procesa un mensaje, se vuelve a intentar todo el lote de mensajes, no importa si algunos de los mensajes se procesaron correctamente. Si por alguna razón falla un servicio de bajada, puede terminar con mensajes que fueron procesados en la DLQ.
Recomendación:
- Eliminar manualmente los mensajes que se han procesado correctamente
- Asegúrese de que su función lambda pueda procesar el mismo mensaje más de una vez
Límites de concurrencia de Lambda y efectos secundarios de SQS
La publicación del blog “Los límites de simultaneidad de Lambda y los activadores de SQS no se mezclan bien (a veces)” describe cómo, si su límite de simultaneidad se establece demasiado bajo, lambda puede hacer que los lotes de mensajes se aceleren y el intento recibido para ser incrementado sin nunca ser procesado.
Recomendación:
La publicación y las recomendaciones de Amazon son:
- Establezca el tiempo de espera de visibilidad de la cola en al menos 6 veces el tiempo de espera que configura en su función.
- El tiempo adicional permite que Lambda vuelva a intentarlo si la ejecución de su función se limita mientras su función está procesando un lote anterior.
- Establezca maxReceiveCount en la política de reenvío de la cola en al menos 5. Esto ayudará a evitar el envío de mensajes a la cola de mensajes no entregados debido a la limitación.
- Configure la letra muerta para retener los mensajes fallidos el tiempo suficiente para poder moverlos más tarde para ser reprocesados
Así es como lo hice.
- Crear colas normales (entrega inmediata), primer trimestre
- Crear colas de retraso (retraso de 5 minutos), segundo trimestre
- Crear DLQ (después de reintentos), DLQ1
(Q1 / Q2) Disparador SQS -> Lambda L1 (si falla, elimínelo en (Q1 / Q2), suéltelo en Q2) -> En caso de falla DLQ
Cuando llegan mensajes en Q1, activa Lambda L1 si el éxito va desde allí. Si falla, déjelo caer a Q2 (que es una cola retrasada). Cada mensaje que llegue el segundo trimestre tendrá un retraso de 5 minutos.
Si su mensaje inicial puede tener una demora de 5 minutos, es posible que no necesite dos colas. Una cola debería ser buena. Si el retraso inicial no es aceptable, necesita dos colas. Otra razón más para tener dos colas, siempre tendrá un camino para los mensajes nuevos que se presenten en el camino.
Si tiene un error de código en el manejo de Q1 / Q2, la infraestructura de AWS lo reintentará inmediatamente 3 veces antes de enviarlo a DLQ1. Si maneja el error en el código, entonces puede hacer que la canalización funcione con los tiempos que mencionó.
Colas de retraso SQS:
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html
Arquitectura SQS Lambda:
https://nordcloud.com/amazon-sqs-as-a-lambda-event-source/
Espero eso ayude.
Bastante simple (si ejecuta Lambda de forma asincrónica) y sin la necesidad de realizar ninguna codificación. En primer lugar: si su código arrojará un error, AWS Lambda volverá a intentar 3 veces más para ejecutar su código. En este caso, si no se pudo acceder a la API externa, hay un gran cambio en el que AWS vuelve a intentarlo por tercera vez: la API funcionará. Además, el retraso entre los reintentos es aleatorio, lo que significa que hay un retraso entre los reintentos.
Si ocurre lo peor y la API externa aún no está activa, puede aprovechar la función de cola de mensajes no entregados (DLQ) que tiene cada lambda. Lo que enviará a SQS un mensaje que indica qué salió mal, para que pueda tomar acciones adicionales. En este caso, vuelva a intentarlo hasta que lo logre.
Puede leer más aquí: https://docs.aws.amazon.com/lambda/latest/dg/dlq.html