🥇 Amazon Simple Queue Service (SQS).

Es un servicio de cola de mensajes rapido, 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 esten continuamente disponibles.

Es un buffer entre componentes de una aplicacion 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 multiples 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 mayoria 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 diponible y para gran fiabilidad a la hora de entregar los mensajes asi como gran eficiencia; sin emabrgo 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 retraidos de la cola.

🍿 Ciclo de vida de los mensajes.

  1. El componente 1 envia el mensaje a la cola, y el mensaje es deplicado a traves de los diferentes servidores SQS.

  2. Cuando el componente 2 esta listo para procesar el mensaje, retrae los mensaje de la cola y el mensaje A es leido.

  3. Mientras el mensaje A es procesado se mantiene en la cola y no es enviado a ningun otro request por la duración del visibility timeout.

  4. El componente 2 elimina el mensaje de la cola para prevenir que este mensaje sea recibido y procesado nuevamente despues de que el visibility timeout expire.

🍿 Delay Queues y Visibility Timeouts.

Permiten posponer la entrega de nuevos mensajes en la cola por un numero específico de seguntos. Si se envia, 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). Tambien 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 ocasion a la cola, mientras que visibility timeout oculta el mensaje solo cuando ha sido retraido 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 maximas de visibility timeout.

Desde un solo thread se pueden extraer 50+ peticiones por segunto. Pero es posible escalar horizontalmente, asi 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.

Las operaciones para SQS son

Los mensajes se identifican globalmente mediante una ID unica 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 util 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:

Cuando se crea una nueva cola, hay que proveer un nombre de cola que sea unico dentro del scope de todas las colas. SQS asigna a cada cola un identificar llamado queue url, el cual inlcuye el nombre y otros componentes que Amazon SQS determina. Cuando se desee realizar una accion en una cola, hay que proveer su queue url.

SQS asignar a cada mensaje un identidificador unique que se regresa como resultado de una respuesta a SendMessage. Este identificados es util para identificar mensajes, pero no para borrar un mensaje, es necesario el manejador de recibo (receipt handle) en lugar del ID. El tamaño maximo de un message ID es 100 caracteres.

Cada vez que se recibe un emnsaje 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 or 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.

🍿 Atributos de los mensajes.

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 informacion 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.

🍿 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 periodicas a la cola, este patron es suficiente. Si el cliente de SQS solo repite esas verificaciones periodicas para nuevos mensajes, sin embargo este patron es problematico, 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 drasticamente el tiempo de carga en su cliente.

🍿 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 deat letter queue es la habilidad de alinear y aislar los mensajes procesados insatisfactoriamente que despues se pueden analizar para determinar la razón de su fallo.

🥤 Access Control.

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:

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 frecuentamente inviable.

SQS Access Control permite asignar politicas a las colar que garanticen interacciones especificas a otras cuentas sin que estas cuentas tengan que asumir roles desde la suya. Estas policitas estan 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 durablemente almacenado en SQS. Esto hace que el modelo de programación muy sinmple sin dudas de la seguridad de los mensajes, a diferencia de la situacion con un modelo asíncrono. Si no se necesita un sistema de mensajes durables, se puede habilitar el modo asíncrono, que permite que librerias envien una serie de mensajes enbatch. Tome en cuenta que con esto existe un potencial riesgo de perder mensajes cuando el cliente los proceso o cuando el ost muera por alguna razón.

DynamoDB. Amazon Simple Workflow Service (SWF).
comments powered by Disqus