Creo que esta presentación de re:Invent 2018 sobre los servicios de mensajería merece mucho la pena invertir nuestro preciado tiempo en verla. En ella se explican los servicios de mensajería que ofrece la nube, las características que lo diferencian y los casos de uso donde encaja uno u otro.

La charla empieza con una sentencia demoledora: “Si tu aplicación es cloud-native, o altamente escalable o distribuida, y no incluye un componente de mensajería, esto es probablemente un error”.

La mensajería es muy importante en AWS, de hecho el primer servicio que ofreció fue el Simple Queue Messaging (SQS para los amigos), allá por el año 2004. Los servicios de AWS se suelen dividir en cuatro grandes bloques: computación, almacenamiento, bases de datos y la mencionada mensajería. Los cuatro pilares de las aplicaciones modernas, como dicen en la presentación.

AWS ofrece tres servicios de mensajería dirigidos a la implementación de de aplicaciones en la nube, y un cuarto servicio dirigido a la migración de aplicaciones ya existentes en el entorno de on-premise.

A continuación mi particular resumen sobre esta charla con lo más importante:

Amazon SQS Estándar

  • Cuando se envía un mensaje con el API de SQS y se recibe un OK, puedes estar seguro que el mensaje se va a entregar.
  • Si hay algún problema al recibir el OK del mensaje en la cola, y el cliente vuelve a enviarlo, es posible que el mensaje se guarde en la cola de manera duplicada. SQS no detecta los mensajes duplicados
  • Cuando se consume el mensaje únicamente hay que usar el método receiveMessage y la url de la cola. Es responsabilidad de SQS seleccionar el mejor mensaje para dárselo a consumidor.
  • Cuando el mensaje se entrega al consumidor, no se destruye de la cola, si no que permanece como “invisible”. Cuando el consumidor procesa el mensaje, llama a “delete message” para destruir el mensaje de la cola. Si no se llama a borrar mensaje, el timeout expira y el mensaje deja de ser invisible y esta disponible de nuevo para los consumidores.
  • Cada mensaje es independiente y auto contenido.
  • El orden no está garantizado
  • Para destinar los mensajes que pueden estar duplicados, con el mismo ID de mensaje, se suele tener en consideración también el timestamp del mensaje para saber con qué mensaje quedarse y cual ignorar por parte del consumidor.

Amazon SQS FIFO

  • Los mensajes se guardan en grupos. Cada grupo mantiene un orden FIFO (First In First Out)
  • En este caso SQS es capaz de detectar mensajes duplicados evitando tenerlos en la cola como en el caso anterior.
  • Cuando un consumidor saca un mensaje de un grupo, como en el caso anterior este se mantienen en la cola de manera invisible. Sin embargo, ningún otro consumidor puede sacar un mensaje del mismo grupo (así se preserva el orden en la entrega de los mensajes).
  • Todos los consumidores pueden recibir mensajes de cualquier grupo disponible

Amazon SNS

  • SNS envía mensajes a múltiples destinatarios
  • Se pueden publicar mensajes en el topic para que lo reciban los consumidores que están suscritos
  • Se pueden configurar filtros para cada destinatario
  • Cuando el productor publica un mensaje, éste se guarda inmediatamente en la cola
  • Para cada destinatario se envía una copia del mensaje
  • Los destinatarios pueden ser varios
    • SQS
    • Lambda
    • HTTP/S
    • Mobile App
    • SMS
    • email
  • Cuando no se puede entregar el mensaje a un destinatario, por ejemplo en el tipo HTTP cuando el endpoint de destino está caído, se reintenta. Cuando el destinatario es SQS o una lambda se reintenta para siempre.

Amazon Kinesis

  • Los shards (agrupaciones de mensajes) tienen que crearse previamente, no se puede crear dinámicamente
  • Los mensajes se mandan a un shard en concreto, dependiendo de un hash del id del mensaje (registro)
  • Los mensajes pueden estar duplicados
  • El cliente tiene que decir de que shard va a leer. Puede preguntar a Kinesis cuáles son los shards disponibles.
  • Cuando se consumen los mensajes no se destruyen
  • Se recomienda usar la librería KCL para facilitar la implementación de los consumidores
  • Los consumidores de una aplicación se adueñan de un shard en concreto y sólo un consumidor puede leer de un shard. Sin embargo, una segunda aplicación puede leer de los mismos shards.