Trabajando con Amazon SNS y SQS

¿Cómo desacoplar componentes en arquitecturas con Amazon SNS y SQS?

Introducción a la charla

• El presentador da la bienvenida a los espectadores y solicita confirmación sobre la calidad del audio antes de comenzar.

• Se menciona que el tema del día es sobre dos servicios de AWS: Amazon SNS (Simple Notification Service) y Amazon SQS (Simple Queue Service).

• Se destaca que se está en el cuarto día de un reto de 100 días hablando sobre AWS, enfocándose en compartir conocimientos prácticos.

Importancia del desacoplamiento

• Se enfatiza la importancia de evitar el acoplamiento fuerte entre componentes en una arquitectura para mejorar su resiliencia.

• El presentador planea compartir lecciones aprendidas y errores comunes al implementar estos servicios.

Ejemplo de arquitectura acoplada

• Se presenta un ejemplo donde dos componentes A y B están altamente acoplados; si uno falla, el otro también lo hace.

• La dependencia entre múltiples componentes puede llevar a fallos en cadena, afectando toda la arquitectura.

Uso de colas para desacoplar componentes

• Se introduce el concepto de utilizar colas (SQS) para permitir que los mensajes sean enviados desde un componente A a un componente B sin necesidad de estar directamente conectados.

• Si el componente A falla, los mensajes permanecen en la cola, permitiendo que el componente B continúe procesando cuando esté disponible.

Proceso de manejo de mensajes

• Los mensajes son colocados por varios productores en una cola y luego extraídos por consumidores para ser procesados.

• Una vez que un mensaje es procesado por el componente B, se elimina de la cola. Esto permite manejar cargas variables sin afectar otros procesos.

Introducción a la arquitectura desacoplada con Amazon SQS

Conceptos básicos de productores y consumidores

• Se está evitando que las arquitecturas estén altamente acopladas, utilizando colas como Amazon SQS para gestionar la comunicación entre componentes.

• Varios productores pueden enviar mensajes a una sola cola, permitiendo que diferentes componentes se comuniquen sin estar directamente conectados.

• Los consumidores son responsables de procesar los mensajes en la cola, realizando tareas como generar facturas o almacenar datos en Amazon S3.

• Es posible escalar de manera independiente el número de productores y consumidores; por ejemplo, tener tres productores y diez consumidores para manejar cargas variables.

• La escalabilidad se puede lograr mediante grupos de escalado automático (Auto Scaling Groups), basándose en métricas como la cantidad de mensajes en la cola.

Mantenimiento del flujo de trabajo

• Si todos los productores fallan, los mensajes permanecen en la cola hasta que los consumidores puedan procesarlos nuevamente. Esto asegura continuidad operativa.

• La infraestructura desacoplada permite que si un componente falla (productor o consumidor), el sistema siga funcionando al mantener los mensajes en espera.

• Los recursos computacionales pueden variar; cualquier script o función puede actuar como productor o consumidor, lo que proporciona flexibilidad en el diseño del sistema.

Ejemplo práctico con Amazon SQS

• Se demuestra cómo crear una cola en Amazon SQS y cómo funciona el envío y recepción de mensajes a través de una interfaz web simulada.

• Al crear una nueva cola llamada "my sqs", se utilizan configuraciones predeterminadas para simplificar el proceso inicial.

• El proceso incluye enviar un mensaje desde un productor simulado y luego realizar polling para verificar su recepción por parte del consumidor.

Interacción entre productores y consumidores

• A medida que se envían más mensajes (por ejemplo, "mensaje 2" o "mensaje 10"), se observa cómo los consumidores procesan estos mensajes uno tras otro desde la cola.

¿Cómo funcionan las colas en el procesamiento de mensajes?

Proceso de extracción y eliminación de mensajes

• Se explica cómo un consumidor puede extraer mensajes de una cola mediante la función "poll". Al realizar esta acción, se obtienen los mensajes disponibles.

• Es ideal que, tras procesar un mensaje, este sea eliminado para mantener la cola limpia. El proceso implica leer el mensaje y luego eliminarlo.

• Si todos los mensajes han sido procesados y eliminados, al hacer "poll" nuevamente no habrá mensajes disponibles. Esto permite verificar rápidamente el estado del servicio.

Tipos de colas: estándar vs FIFO

• Al crear una cola, se puede optar por una configuración estándar o FIFO (First In First Out). La opción estándar garantiza que cada mensaje será entregado al menos una vez.

• Las colas FIFO mantienen el orden en que llegan los mensajes. Esto significa que si se envía un mensaje primero, será el primero en ser consumido.

Políticas de acceso y manejo de errores

• La política de acceso define qué recursos pueden acceder a la cola SQS. Por ejemplo, se deben especificar permisos para funciones Lambda que necesiten extraer mensajes.

• La política "redrive" y "Dead Letter Queue" (DLQ) son cruciales para manejar errores en el procesamiento. Permiten redirigir mensajes fallidos a otra cola después de varios intentos fallidos.

Manejo de errores con Dead Letter Queue

• Un escenario típico involucra un productor enviando múltiples mensajes a la cola mientras un consumidor intenta procesarlos.

• Si un mensaje presenta errores repetidamente y no puede ser procesado, esto podría causar que el consumidor quede atascado intentando procesarlo sin éxito.

• Para evitar este comportamiento indeseado, se utiliza una DLQ donde los mensajes fallidos son enviados después de varios intentos fallidos. Esto permite revisar manualmente los problemas asociados con esos mensajes.

Conclusión sobre las colas y su gestión

• La implementación adecuada de políticas como DLQ es esencial para asegurar que los sistemas no queden bloqueados por errores persistentes en ciertos mensajes. Esto facilita la depuración y mejora la eficiencia del sistema general.

¿Cómo configurar colas y Dead Letter en Amazon SQS?

Creación de Colas y Configuración de Dead Letter

• Se menciona la necesidad de habilitar la cola de "Dead Letter" (DLQ) al crear una nueva cola, donde se debe definir el ARN (Amazon Resource Name) de esta cola y la cantidad máxima de intentos para recibir un mensaje antes de enviarlo a la DLQ.

• Luis Antonio explica que al establecer una política de redrive, se puede permitir que otras colas actúen como DLQ. Si se configura correctamente, esto ayuda a gestionar los mensajes fallidos.

• En este contexto, se define qué colas serán las DLQ para otra cola específica. Es crucial otorgar permisos adecuados para que estas colas puedan interactuar entre sí.

• Se ejemplifica creando dos colas: Cola Uno y Cola Dos. La Cola Dos será designada como DLQ para la Cola Uno, estableciendo así un flujo claro en el manejo de errores.

• La correcta configuración entre ambas colas es esencial para evitar reintentos innecesarios en el procesamiento de mensajes fallidos, lo cual optimiza el rendimiento del sistema.

Beneficios del Uso de Amazon SQS

• Amazon SQS permite desacoplar componentes arquitectónicos, mejorando la tolerancia a fallos. Los mensajes permanecen en la cola si un componente falla, permitiendo que otros continúen procesando sin interrupciones.

• Se mencionan alternativas como RabbitMQ, destacando que existen múltiples opciones disponibles en el mercado para manejar sistemas basados en colas.

¿Qué es Amazon SNS y cómo funciona?

Introducción a Amazon Simple Notification Service (SNS)

• Luis Antonio introduce Amazon SNS como un servicio diseñado para enviar notificaciones. Se crea un tópico llamado "Max topic" con nombre visible similar.

• Al crear un tópico estándar (no FIFO), se establece una base sobre la cual se pueden realizar suscripciones a diferentes servicios o endpoints.

Creación y Gestión de Suscripciones

• Se discute cómo agregar suscripciones al tópico creado. Las opciones incluyen servicios como Kinesis Data Firehose o SQS, además del envío directo a correos electrónicos o SMS.

• Para simplificar el proceso, Luis Antonio opta por enviar notificaciones vía SMS utilizando su número personal como ejemplo práctico durante la demostración.

Mecanismos Recurrentes en Servicios AWS

• Se destaca que también es posible establecer una DLQ para las suscripciones creadas; si no se recibe un mensaje correctamente en el endpoint especificado, este puede ser redirigido automáticamente a una DLQ correspondiente.

Demostración Práctica: Envío de Mensajes

Publicación y Recepción de Mensajes

• Luis Antonio realiza una demostración enviándose un mensaje desde el tópico creado. El contenido del mensaje incluye saludos al canal junto con información temporal relevante.

• Finalmente, confirma que ha recibido exitosamente el mensaje en su dispositivo móvil, mostrando así la efectividad del sistema implementado mediante SNS.

¿Cómo funciona Amazon SNS y SQS?

Introducción a los mensajes en SNS

• Se muestra un ejemplo de envío de mensajes utilizando Amazon SNS, donde se envía un mensaje con el asunto "Hola" y se confirma su recepción en el celular.

• Se explica que SNS permite enviar mensajes a diferentes suscriptores, incluyendo colas SQS y correos electrónicos.

Proceso de suscripción y confirmación

• Se detalla el proceso de confirmar la suscripción para recibir correos electrónicos desde un tópico de SNS.

• Se menciona que es sencillo trabajar con ambos servicios (SNS y SQS), destacando la facilidad del proceso.

Arquitectura de mensajería: Fan Out

• Se introduce el concepto de crear múltiples colas SQS suscritas a un único tópico SNS, permitiendo que cada mensaje enviado sea distribuido a todas las colas.

• Ejemplo práctico sobre cómo se envían los mismos mensajes a varias colas simultáneamente.

Consumo de mensajes desde las colas

• Los consumidores extraen los mensajes directamente desde las colas SQS, lo cual es fundamental para entender la arquitectura del sistema.

• Se presenta el patrón arquitectónico conocido como "fan out", donde los mensajes son distribuidos eficientemente entre varios consumidores.

Diferencias entre modelos Pull y Push

• Explicación sobre cómo los consumidores utilizan un modelo Pull para solicitar mensajes desde las colas SQS, contrastándolo con el modelo Push utilizado por SNS.

• Enfatiza que mientras SQS jala (Pull) los mensajes bajo demanda, SNS empuja (Push) automáticamente los mensajes a todos los suscriptores al llegar al tópico.

Conclusiones finales

• Resumen sobre la clase del día enfocada en cómo trabajar con Amazon SNS y SQS, invitando a realizar preguntas si hay dudas.

• Anuncio sobre futuras sesiones educativas relacionadas con otros temas como bases de datos y programación.

Almacenamiento y Manejo de Mensajes en SQS y SNS

Capacidad de Almacenamiento en SQS

• El servicio SQS puede almacenar hasta 1,200,000 mensajes, con un límite máximo de 120,000 mensajes por cola.

• Los mensajes se almacenan en la cola de SQS. Si un suscriptor no está disponible, es crucial manejar los errores para asegurar que el evento sea procesado cuando el suscriptor esté listo.

Manejo de Errores y Suscripciones

• En caso de que un mensaje no llegue a su destinatario (por ejemplo, un suscriptor HTTP), se puede configurar una "dead letter queue" para almacenar esos mensajes fallidos.

• La configuración de una "dead letter queue" permite revisar posteriormente por qué ciertos mensajes no fueron entregados a los suscriptores.

Diferencias entre SNS y SQS

• En SNS (Simple Notification Service), cada vez que llega un mensaje, se realiza un "push" a todos los suscriptores disponibles.

• A diferencia de SNS, en SQS (Simple Queue Service), los consumidores realizan un "pull" para recibir los mensajes desde la cola.

Proceso de Consumo de Mensajes

• Los consumidores envían peticiones HTTP a la cola SQS para obtener los mensajes disponibles. Este proceso implica hacer polling o "pull".

• Es importante entender que mientras SNS utiliza el modelo push para notificaciones, SQS opera bajo el modelo pull donde los consumidores solicitan activamente los mensajes.

Conclusiones Finales

• Se espera que las diferencias entre ambos servicios queden más claras tras esta explicación. Se agradece la participación del público y se invita a continuar con futuras sesiones.