Editor Top
|
Hoy lanzamos un nuevo conjunto de API para Amazon Simple Queue Service (Amazon SQS). Estas nuevas API le permiten administrar la redirección de la cola de mensajes fallidos (DLQ) mediante programación. Ahora puede utilizar los SDK de AWS o la interfaz de línea de comandos de AWS (AWS CLI) para mover mediante programación los mensajes de la DLQ a su cola original, o a un destino de cola personalizado, para intentar procesarlos nuevamente. Una DLQ es una cola en la que Amazon SQS mueve automáticamente los mensajes que su aplicación de consumidor no procesa correctamente.
Para apreciar completamente cómo esta nueva API podría ayudarlo, echemos un vistazo rápido al historial.
Colas de mensajes son una parte integral de las arquitecturas de aplicaciones modernas. Permiten a los desarrolladores desacoplar servicios al permitir comunicaciones asincrónicas y basadas en mensajes entre productores y consumidores de mensajes. En la mayoría de los sistemas, los mensajes se mantienen en el almacenamiento compartido (la cola) hasta que el consumidor los procesa. Las colas de mensajes permiten a los desarrolladores crear aplicaciones resistentes a fallas temporales del servicio. Ayudan a priorizar el procesamiento de mensajes y escalan su flota de nodos trabajadores que procesan los mensajes. Las colas de mensajes también son populares en las arquitecturas basadas en eventos.
El intercambio de mensajes asincrónicos no es nuevo en las arquitecturas de aplicaciones. El concepto de intercambiar mensajes de forma asíncrona entre aplicaciones apareció en la década de 1960 y se hizo popular por primera vez cuando IBM lanzó TCAM para OS/360 en 1972. La adopción general llegó 20 años después con Serie IBM MQ en 1993 (ahora IBM MQ) y cuándo Sun Microsystems lanzó Java Messaging Service (JMS) en 1998una API estándar para que las aplicaciones Java interactúen con las colas de mensajes.
AWS lanzó Amazon SQS el 12 de julio de 2006. Amazon SQS es un servicio de gestión de colas altamente escalable, confiable y elástico que «simplemente funciona». Como Werner escribió en ese momento: “Hemos elegido un modelo de concurrencia en el que el proceso que trabaja en un mensaje adquiere automáticamente un bloqueo arrendado en ese mensaje; si el mensaje no se elimina antes de que expire la concesión, vuelve a estar disponible para su procesamiento. Hace que el manejo de fallas sea muy simple.”
El 29 de enero de 2014, presentamos las colas de mensajes fallidos (DLQ). Los DLQ lo ayudan a evitar que un mensaje que no se pudo procesar permanezca para siempre en la parte superior de la cola, lo que posiblemente impida que se procesen otros mensajes en la cola. Con DLQ, cada cola tiene una propiedad asociada que indica a Amazon SQS cuántas veces se puede presentar un mensaje para su procesamiento (maxReceiveCount). Cada mensaje también tiene un contador de recepción asociado (ReceiveCount). Cada vez que una aplicación de consumidor selecciona un mensaje para procesarlo, el conteo de mensajes recibidos se incrementa en 1. Cuando ReceiveCount > maxReceiveCount, Amazon SQS mueve el mensaje a su DLQ designado para el análisis humano y la depuración. Por lo general, asocia alarmas con el DLQ para enviar notificaciones cuando ocurren tales eventos. Las razones típicas para mover un mensaje a la DLQ son porque tienen un formato incorrecto, hay errores en la aplicación del consumidor o lleva demasiado tiempo procesar el mensaje.
En AWS re:Invent 2021, AWS anunció el redireccionamiento de la cola de mensajes fallidos en la consola de Amazon SQS. El redireccionamiento aborda la segunda parte del ciclo de vida del mensaje fallido. Le permite reinyectar el mensaje en su cola original para intentar procesarlo nuevamente. Una vez que la aplicación del consumidor está reparada y lista para consumir los mensajes fallidos, puede redireccionar los mensajes del DLQ a la cola de origen o a una cola de destino personalizada. Solo requiere un par de clics en la consola.
Hoy, estamos agregando API que le permiten escribir aplicaciones y scripts que manejan la redirección mediante programación. Ya no es necesario que un humano haga clic en la consola. El uso de la API aumenta la escalabilidad de sus procesos y reduce el riesgo de error humano.
Veámoslo en acción
Para probar esta nueva API, abro una terminal para una demostración solo desde la línea de comandos. Antes de comenzar, me aseguro de tener la última versión de AWS CLI. En macOS entro brew upgrade awscli.
Primero creo dos colas. Una es la cola de mensajes fallidos y la otra es la cola de mi aplicación:
# First, I create the dead-letter queue (notice the -dlq I choose to add at the end of the queue name)
➜ ~ aws sqs create-queue \
--queue-name awsnewsblog-dlq
{
"QueueUrl": "https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog-dlq"
}
# second, I retrieve the Arn of the queue I just created
➜ ~ aws sqs get-queue-attributes \
--queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog-dlq \
--attribute-names QueueArn
{
"Attributes": {
"QueueArn": "arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq"
}
}
# Third, I create the application queue. I enter a redrive policy: post messages in the DLQ after three delivery attempts
➜ ~ aws sqs create-queue \
--queue-name awsnewsblog \
--attributes '{"RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq\",\"maxReceiveCount\":\"3\"}"}'
{
"QueueUrl": "https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog"
}Ahora que las dos colas están listas, publico un mensaje en la cola de la aplicación:
➜ ~ aws sqs send-message \
--queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog \
--message-body "Hello World"
{
"MD5OfMessageBody": "b10a8db164e0754105b7a99be72e3fe5",
"MessageId": "fdc26778-ce9a-4782-9e33-ae73877cfcb2"
}A continuación, consumo el mensaje, pero no lo elimino de la cola. Esto simula un bloqueo en la aplicación consumidora de mensajes. Se supone que los consumidores de mensajes deben eliminar el mensaje después de un procesamiento exitoso. puse el maxReceivedCount propiedad a 3 cuando entré en el redrivePolicy. Por lo tanto, repito esta operación tres veces para obligar a Amazon SQS a mover el mensaje a la cola de mensajes fallidos después de tres intentos de entrega. El tiempo de espera de visibilidad predeterminado es de 30 segundos, por lo que tengo que esperar 30 segundos o más entre los reintentos.
➜ ~ aws sqs receive-message \
--queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
{
"Messages": [
{
"MessageId": "fdc26778-ce9a-4782-9e33-ae73877cfcb2",
"ReceiptHandle": "AQEBP8yOfgBlnjlkGXjyeLROiY7xg7cZ6Znq8Aoa0d3Ar4uvTLPrHZptNotNfKRK25xm+IU8ebD3kDwZ9lja6JYs/t1kBlwiNO6TBACN5srAb/WggQiAAkYl045Tx3CvsOypbJA3y8U+MyEOQRwIz6G85i7MnR8RgKTlhOzOZOVACXC4W8J9GADaQquFaS1wVeM9VDsOxds1hDZLL0j33PIAkIrG016LOQ4sAntH0DOlEKIWZjvZIQGdlRJS65PJu+I/Ka1UPHGiFt9f8m3SR+Y34/ttRWpQANlXQi5ByA47N8UfcpFXXB5L30cUmoDtKucPewsJNG2zRCteR0bQczMMAmOPujsKq70UGOT8X2gEv2LfhlY7+5n8z3yew8sdBjWhVSegrgj6Yzwoc4kXiMddMg==",
"MD5OfBody": "b10a8db164e0754105b7a99be72e3fe5",
"Body": "Hello World"
}
]
}
# wait 30 seconds,
# then repeat two times (for a total of three receive-message API calls)Después de tres intentos de procesamiento, el mensaje ya no está en la cola:
➜ ~ aws sqs receive-message \
--queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
{
"Messages": []
}El mensaje se ha movido a la cola de mensajes fallidos. Compruebo el DLQ para confirmar (observe que la URL de la cola termina con -dlq):
➜ ~ aws sqs receive-message \
--queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog-dlq
{
"Messages": [
{
"MessageId": "fdc26778-ce9a-4782-9e33-ae73877cfcb2",
"ReceiptHandle": "AQEBCLtBMoZYVMMq7fUGNHeCliqE3mFXnkuJ+nOXLK1++uoXWBG31nDejCpxElmiBZWfbcfGJrEdKj4P9HJdrQMYDbeSqB+u1ZlB7CYzQBiQps4SEG0biEoubwqjQbmDZlPrmkFsnYgLD98D1XYWk/Ik6Z2n/wxDo9ko9rbZ15izK5RFnbwveNy8dfc6ireqVB1EGbeGkHcweHGuoeKWXEab1ynZWhNqZsQgCR6pWRkgtn59lJcLv4cJ4UMewNzvt7tMHH69GvVjXdYDYvJJI2vj+6RHvcvSHWWhTNT+CuPEXguVNuNrSya8gho1fCnKpVwQre6HhMlLPjY4wvn/tXY7+5rmte9eXagCqLQXaENB2R7qWNVPiWRIJy8/cTf37NLYVzBom030DNJlH9EeceRhCQ==",
"MD5OfBody": "b10a8db164e0754105b7a99be72e3fe5",
"Body": "Hello World"
}
]
}Ahora que la configuración está lista, redirigimos mediante programación el mensaje a su cola original. Supongamos que entiendo por qué el consumidor no procesó correctamente el mensaje y que arreglé el código de la aplicación del consumidor. yo suelo start-message-move-task en el DLQ para iniciar el redireccionamiento asíncrono. Hay un atributo opcional (MaxNumberOfMessagesPerSecond) para controlar la velocidad del redrive:
➜ ~ aws sqs start-message-move-task \
--source-arn arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq
{
"TaskHandle": "eyJ0YXNrSWQiOiI4ZGJmNjBiMy00MmUwLTQzYTYtYjg4Zi1iMTZjYWRjY2FkNmEiLCJzb3VyY2VBcm4iOiJhcm46YXdzOnNxczp1cy1lYXN0LTI6NDg2NjUyMDY2NjkzOmF3c25ld3NibG9nLWRscSJ9"
}
Puedo enumerar y verificar el estado de las tareas de movimiento que inicié con list-message-move-tasks o cancelar una tarea en ejecución llamando al cancel-message-move-task API:
➜ ~ aws sqs list-message-move-tasks \
--source-arn arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq
{
"Results": [
{
"Status": "COMPLETED",
"SourceArn": "arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq",
"ApproximateNumberOfMessagesMoved": 1,
"ApproximateNumberOfMessagesToMove": 1,
"StartedTimestamp": 1684135792239
}
]
}Ahora mi aplicación puede consumir el mensaje nuevamente desde la cola de la aplicación:
➜ ~ aws sqs receive-message \
--queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
{
"Messages": [
{
"MessageId": "a7ae83ca-cde4-48bf-b822-3d4bc1f4dcae",
"ReceiptHandle": "AQEB9a+Dm2nvb3VUn9+46j9UsDidU/W6qFwJtXtNWTyfoSDOKT7h73e6ctT9RVZysEw3qqzJOx1cxblTTOSrYwwwoBA2qoJMGsqsrsRGGYojBvf9X8hqi8B8MHn9rTm8diJ2wT2b7WC+TDrx3zIvUeiSEkP+EhqyYOvOs7Q9aETR+Uz02kQxZ/cUJWsN4MMSXBejwW+c5ivv5uQtpfUrfZuCWa9B9O67Kj/q52clriPHpcqCCfJwFBSZkGTXYwTpnjxD4QM7DPS+xVeVfTyM7DsKCAOtpvFBmX5m4UNKT6TROgCnGxTRglUSMWQp8ufVxXiaUyM1dwqxYekM9uX/RCb01gEyCZHas4jeNRV5nUJlhBkkqPlw3i6w9Uuc2y9nH0Df8nH3g7KTXo4lv5Bl3ayh9w==",
"MD5OfBody": "b10a8db164e0754105b7a99be72e3fe5",
"Body": "Hello World"
}
]
}Disponibilidad
Las API de redireccionamiento de DLQ están disponibles hoy en todas las regiones comerciales donde está disponible Amazon SQS.
Redirigir los mensajes de la cola de mensajes fallidos a la cola de origen o a una cola de destino personalizada genera llamadas de API adicionales que se facturan según los precios existentes (a partir de $0,40 por millón de llamadas de API, después del primer millón, que es gratis todos los meses). Amazon SQS procesa por lotes los mensajes mientras los redirige de una cola a otra. Esto hace que mover mensajes de una cola a otra sea una opción simple y de bajo costo.
Para obtener más información sobre DLQ y DLQ redrive, consulte nuestra documentación.
Recuerda que vivimos en un mundo asincrónico—también deberían hacerlo sus aplicaciones. Comience hoy y escriba su primera aplicación de redrive.
