Temas de SNS y arquitectura fan-out

Amazon Simple Notification Service (SNS) es un servicio de mensajería pub/sub completamente administrado. Los publicadores envían mensajes a un topic de SNS, y SNS entrega inmediatamente esos mensajes a todos los suscriptores. A diferencia de SQS, que se basa en extracción, SNS se basa en notificaciones push: entrega los mensajes a los suscriptores en cuanto se publican. Esto hace que SNS sea ideal para difundir eventos simultáneamente a varios sistemas posteriores.

Al igual que SQS, SNS tiene dos tipos de topics: los Standard topics ofrecen ordenación de mensajes con el mejor esfuerzo, entrega al menos una vez y un rendimiento prácticamente ilimitado; pueden entregar mensajes a SQS, Lambda, endpoints HTTP, correo electrónico, SMS y notificaciones push móviles. Los FIFO topics garantizan un orden estricto y una entrega exactamente una vez, pero únicamente a suscriptores de FIFO SQS. Los FIFO topics admiten hasta 3.000 mensajes por segundo con procesamiento por lotes y se utilizan cuando es necesario conservar el orden de los eventos entre varios suscriptores.

SNS admite varios tipos de suscriptores basados en protocolos:

• SQS: colas duraderas (la opción más habitual para el procesamiento asíncrono)
• Lambda: invocación directa (síncrona desde la perspectiva de SNS)
• HTTP/HTTPS: entrega mediante webhook a endpoints externos
• Email / Email-JSON: notificaciones para personas
• SMS: entrega de mensajes de texto
• Mobile Push: FCM y APNs mediante aplicaciones de plataforma
• Firehose: transmisión a S3 o Redshift mediante Kinesis Data Firehose

Fan-out es el patrón principal de SNS: se publica un mensaje en un topic y SNS lo entrega simultáneamente a todos los suscriptores. Por ejemplo, un evento de nuevo pedido se distribuye a: una cola de SQS para el cumplimiento en el almacén, otra cola de SQS para actualizar el inventario, una función de Lambda para detectar fraudes y una suscripción de correo electrónico para el equipo de operaciones. Cada suscriptor procesa el evento de forma independiente, sin acoplamiento entre ellos. Esto es mucho más escalable que un único consumidor que enruta los mensajes a varios sistemas.

El patrón recomendado combina SNS y SQS: se publica en SNS, que distribuye los mensajes a varias colas de SQS. Esto proporciona:

• Durabilidad: si un consumidor no está disponible, los mensajes se acumulan en SQS
• Escalado independiente: cada consumidor procesa los mensajes a su propio ritmo
• Desacoplamiento: los nuevos consumidores solo tienen que suscribirse a SNS, sin cambiar el publicador
• Resiliencia ante reintentos: SQS proporciona un tiempo de espera de visibilidad y una DLQ

Los suscriptores directos de Lambda no disponen del almacenamiento temporal que proporciona SQS, por lo que SNS→SQS→Lambda es el patrón de tres niveles más resiliente.

Cuando SNS no puede entregar un mensaje a un suscriptor (el endpoint HTTP devuelve un error 5xx, Lambda genera una excepción o SQS no está disponible), vuelve a intentarlo mediante una estrategia de retroceso exponencial. Las políticas de reintento varían según el protocolo: los endpoints HTTP reciben hasta 4 reintentos inmediatos y después reintentos con retroceso exponencial durante 23 días; Lambda y SQS gestionan los reintentos mediante sus propios mecanismos. Configure una SNS Topic DLQ para capturar los mensajes que agoten todos los reintentos de entrega y garantizar que no se pierda ningún evento silenciosamente.

Publique mensajes en SNS mediante el AWS SDK o la CLI. Cada mensaje puede incluir un Subject (para correo electrónico), un cuerpo Message (de hasta 256 KB) y Message Attributes para el enrutamiento. Para distintos tipos de suscriptores (SQS, correo electrónico o dispositivos móviles), puede utilizar Message Structure para enviar contenido diferente a cada protocolo; un JSON con claves específicas del protocolo permite adaptar la carga útil a cada tipo de suscriptor.

Las políticas de filtrado de suscripciones permiten que cada suscriptor reciba únicamente los mensajes relevantes para él, según los atributos del mensaje. Sin filtrado, todos los suscriptores reciben todos los mensajes publicados. Con una política de filtrado, un suscriptor especifica los valores de atributos que le interesan. Por ejemplo, una cola de pedidos 'PREMIUM' se suscribe con el filtro {"orderType": ["PREMIUM"]}; una cola 'STANDARD' filtra por ["STANDARD"]. Cada suscriptor procesa únicamente el subconjunto que le corresponde, lo que reduce el procesamiento innecesario.

SNS admite notificaciones push móviles directas a dispositivos iOS (APNs) y Android (FCM/GCM). Se registran los tokens de los dispositivos como ARN de endpoints de plataforma y, a continuación, se publica directamente en un endpoint o en un topic con suscriptores de aplicaciones de plataforma. Para notificaciones directas a dispositivos a gran escala (millones de dispositivos), combine SNS con SQS fan-out: SNS enruta el evento de notificación a SQS y un servicio de trabajo se encarga de resolver los tokens y realizar la entrega masiva a escala.

Proteja los mensajes de SNS mediante cifrado del lado del servidor con AWS KMS. Esto cifra los mensajes en reposo dentro de la infraestructura de SNS. El control de acceso utiliza tanto políticas basadas en recursos (quién puede publicar en el topic o suscribirse a él) como políticas de IAM. Para permitir que un bucket de S3 publique notificaciones en un topic de SNS, conceda sns:Publish a la entidad principal de servicio de S3 en la política basada en recursos del topic. Restrinja siempre la publicación a fuentes autorizadas para evitar la inyección de eventos no autorizados.

SNS y SQS son servicios complementarios, no alternativas. SNS (push) sirve para difundir mensajes inmediatamente a varios consumidores; utilícelo cuando varios sistemas deban reaccionar ante un evento. SQS (pull) sirve para un procesamiento fiable y duradero por parte de un único consumidor, con reintentos y DLQ; utilícelo cuando un consumidor deba procesar cada mensaje exactamente una vez y a su propio ritmo. El patrón fan-out SNS→SQS le ofrece ambas capacidades: entrega de difusión mediante SNS y procesamiento duradero con reintentos mediante SQS. Esta combinación aparece con frecuencia en los escenarios del examen SAA-C03.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido lo siguiente: los topics de SNS proporcionan difusión pub/sub basada en push a suscriptores como SQS, Lambda, HTTP, SMS y correo electrónico simultáneamente; la arquitectura fan-out utiliza un topic de SNS que alimenta varias colas de SQS para lograr un procesamiento de eventos duradero y escalable de forma independiente entre varios consumidores; y las políticas de filtrado de suscripciones reducen el procesamiento innecesario al enrutar a cada suscriptor únicamente los eventos relevantes según los atributos del mensaje. A continuación, exploraremos en profundidad el filtrado de mensajes de SQS y la integración de SNS + SQS.