¿Cómo funciona Amazon Simple Queue Service (SQS)?
Amazon Simple Queue Service es un servicio de cola de mensajes rápido, confiable, escalable y manejado. Hace sencillo desacoplar componentes de una aplicación en la nube. Se puede utilizar para transferir cualquier volumen de datos, a cualquier nivel sin perder mensajes o requerir que otros servicios estén continuamente disponibles.
Es un buffer entre componentes de una aplicación que reciben datos y que los procesan en el sistema. Si por alguna razón como un monto masivo de transacciones no puede ser procesada, el trabajo es agregado a la cola de forma que el procesamiento pueda realizarse cuando se este listo para hacerlo. Es decir que el trabajo no se pierde debido a recursos insuficientes.
SQS se asegura de entrar los mensajes al menos una vez y soporta múltiples lectores y escritores interactuando con la misma cola. Esta cola puede ser utilizada al mismo tiempo por muchas aplicaciones, sin necesidad de que los componentes se coordinen unos con otros. Aunque la mayoría de las veces los mensajes se entregaran una sola ocasión, es necesario realizar una aplicación que no sea afectada si el proceso se realiza en dos ocasiones.
SQS esta diseñado para ser altamente disponible y para gran fiabilidad a la hora de entregar los mensajes así como gran eficiencia; sin embargo el servicio no garantiza entrega FIFO. Si un orden es requerido, este se puede indicar la secuencia como parte del mensaje para reordenarlos cuando sean retraídos de la cola.
¿Cuál es el ciclo de vida de los mensajes en SQS?
- El componente 1 envía el mensaje a la cola, y el mensaje es duplicado a traves de los diferentes servidores SQS.
- Cuando el componente 2 esta listo para procesar el mensaje, retrae los mensaje de la cola y el mensaje A es leído.
- Mientras el mensaje A es procesado se mantiene en la cola y no es enviado a ningún otro request por la duración del visibility timeout.
- El componente 2 elimina el mensaje de la cola para prevenir que este mensaje sea recibido y procesado nuevamente después de que el visibility timeout expire.
¿Para qué se utilizan los delay queues y visibility timeouts?
Permiten posponer la entrega de nuevos mensajes en la cola por un número específico de segundos. Si se envía, este mensaje estará invisible para el usuario durante un periodo delay. Para crear un delay queue, utilice CreateQueue y defina el atributo DelaySeconds a cualquier valor entre 0 y 900 (15 minutos). También es posible convertir una cola existente en una cola delay utilizando SetQueueAttributes para cambiar el atributo DelaySeconds. El valor por default, es 0.
Las colas delayed son similares a los timeouts en el sentido de que ambos convierten los mensajes en no disponibles por un periodo de tiempo, sin embargo la diferencia es que un delay queue oculta el mensaje cuando es añadido por primera ocasión a la cola, mientras que visibility timeout oculta el mensaje solo cuando ha sido retraído de la cola.
Cuando un mensaje esta en la cola no se encuentra delayed o en visibility timeout, es considerado in flight (en vuelo). Se pueden tener hasta 120,000 mensajes (in flight) en cualquier punto del tiempo. SQS soporta hasta 12 horas máximas de visibility timeout.
Desde un solo thread se pueden extraer 50+ peticiones por segundo. Pero es posible escalar horizontalmente, así que entre mas threads y hosts se añadan, mayor es el rendimiento. Utilizando este modelo de escalamiento, algunos clientes de AWS tienen colas que procesan miles de mensajes cada segundo.
Operaciones de cola, IDs únicos y Metadata
¿Cuáles son las operaciones para SQS?
- CreateQueue
- ListQueues
- DeleteQueue
- SendMessage
- SendMessageBatch
- ReceiveMessage
- DeleteMessage
- DeleteMessageBatch
- PurgeQueue
- ChangeMessageVisibility
- ChangeMessageVisibilityBatch
- SetQueueAttributes
- GetQueueAttributes
- GetQueueUrl
- ListDeadLetterSourceQueues
- AddPermission
- RemovePermission
Los mensajes se identifican globalmente mediante una ID única que SQS retorna cuando el mensaje es entregado en la cola. El ID no es requerido para realizar ninguna acción mas en el mensaje, pero es útil para monitorear si un mensaje en particular en la cola ha sido recibido. Cuando se recibe un mensaje desde la cola, la respuesta incluye un recibo de control, que se debe proveer cuando se borre el mensaje.
Colas y mensajes identificadores
SQS utiliza tres tipos de identificadores con los que hay que familiarizarse:
- URLs
- IDs de los mensajes (message IDs)
- Manejadores de recibo (Receipt handles)
Cuando se crea una nueva cola, hay que proveer un nombre de cola que sea único dentro del scope de todas las colas. SQS asigna a cada cola un identificar llamado queue url, el cual incluye el nombre y otros componentes que Amazon SQS determina. Cuando se desee realizar una acción en una cola, hay que proveer su queue url.
SQS asignar a cada mensaje un identificador unique que se regresa como resultado de una respuesta a SendMessage. Este identificador es útil para identificar mensajes, pero no para borrar un mensaje, es necesario el manejador de recibo (receipt handle) en lugar del ID. El tamaño máximo de un message ID es 100 caracteres.
Cada vez que se recibe un mensaje desde una cola, se recibe un receipt handle para tal mensaje. El manejador es asociado con el acto de recibir el mensaje, no con el mensaje mismo. Para borrar dicho mensaje o cambiar la visibilidad del mensaje, es necesario proveer dicho receipt handle y no el ID del mensaje. Esto significa que usted debe de recibir siempre un mensaje antes de que lo pueda borrar. El tamaño máximo del receipt handle es de 2014 caracteres.
¿Cuáles son los atributos de los mensajes SQS?
SQS provee soporte para atributos en los mensajes. Los atributos proveen medatadata estructurada (timestamps, datos geoespaciales, firmas e identificadores) acerca del mensaje. Los atributos del mensaje son opciones y separados de este, pero enviados junto con el cuerpo del mensaje. El receptor del mensaje puede utilizar esta información para decidir como manejar el mensaje sin tener que procesar el cuerpo del mensaje primero. Cada mensaje puede tener hasta 10 atributos. Para especificar los atributos del mensaje se puede echar mano de la consola, SDK o la API.
¿Qué es el long polling?
Cuando la aplicación consulta la cola de mensajes de SQS, llama a la funciona ReceiveMessage, la cual verifica la existencia de un mensaje en la cola y regresa inmediatamente, ya sea con o sin mensaje. Si el código hace consultas periódicas a la cola, este patrón es suficiente. Si el cliente de SQS solo repite esas verificaciones periódicas para nuevos mensajes, sin embargo este patrón es problemático, debido a que los constantes llamadas utilizan ciclos del CPU y se atan a un thread.
En este sentido es mejor utilizar long polling, con este se puede enviar el argumento WaitTimeSeconds a ReceiveMessage de hasta 20 segundos. Si no existe un mensaje en la cola, esperará el tiempo definido para que aparezca un mensaje antes de regresar valores. Si un mensaje aparece antes de que el tiempo expire, la llamada regresará el mensaje. Long polling reduce drásticamente el tiempo de carga en su cliente.
¿Qué son las dead letter queues?
SQS provee soporte para dead letter queues. Estas son colas que otros colas origen pueden utilizar para enviar mensajes los cuales por alguna razón en la cual no fueron procesadas satisfactoriamente. Un beneficio primario de utilizar dead letter queue es la habilidad de alinear y aislar los mensajes procesados insatisfactoriamente que después se pueden analizar para determinar la razón de su fallo.
Access Control (Control de acceso)
Mientras IAM puede ser utilizado para controlar las interacciones con diferentes entidades de AWS mediante colas, a menudo hay ocasiones que se desea exponer las colas a otras cuentas:
- Se quiere garantizar acceso particular a ciertas cuentas AWS, por ejemplo SendMessage.
- Se quiere garantizar otro acceso a la cola a cuentas AWS por un tiempo específico.
- Se quiere garantizar acceso a otra cuenta AWS a la cola solo si el request viene de sus instancia EC2.
- Se quiere denegar acceso a la cola a otras cuentas AWS.
Mientras la coordinación cercana entre cuentas puede permitir este tipo de acciones a través del uso de roles IAM, el nivel de coordinación es frecuentemente inviable.
SQS Access Control permite asignar políticas a las colar que garanticen interacciones específicas a otras cuentas sin que estas cuentas tengan que asumir roles desde la suya. Estas políticas están escritas en JSON como en IAM.
Compensación de Durabilidad y Latencia
SQS no retorna success a una llamada SendMessage a la API hasta que el mensaje es duráblemente almacenado en SQS. Esto hace que el modelo de programación muy simple sin dudas de la seguridad de los mensajes, a diferencia de la situación con un modelo asíncrono. Si no se necesita un sistema de mensajes durables, se puede habilitar el modo asíncrono, que permite que librerías envíen una serie de mensajes en bloque. Tome en cuenta que con esto existe un potencial riesgo de perder mensajes cuando el cliente los proceso o cuando el host muera por alguna razón.
