Topic SNS e architettura fan-out

Amazon Simple Notification Service (SNS) è un servizio di messaggistica pub/sub completamente gestito. I publisher inviano messaggi a un topic SNS e SNS li distribuisce immediatamente a tutti i subscriber. A differenza di SQS, basato sul pull, SNS è basato sul push: distribuisce i messaggi ai subscriber non appena vengono pubblicati. Questo rende SNS ideale per trasmettere eventi simultaneamente a più sistemi downstream.

Come SQS, SNS offre due tipi di topic: i topic Standard garantiscono l'ordinamento dei messaggi secondo il criterio best effort, la consegna almeno una volta e un throughput quasi illimitato; possono distribuire messaggi a SQS, Lambda, endpoint HTTP, email, SMS e notifiche push mobili. I topic FIFO garantiscono un ordinamento rigoroso e la consegna esattamente una volta, ma solo ai subscriber SQS FIFO. I topic FIFO supportano fino a 3.000 messaggi al secondo con il batching e vengono utilizzati quando è necessario preservare l'ordine degli eventi tra più subscriber.

SNS supporta diversi tipi di subscriber basati su protocollo:

• SQS: accodamento persistente (il più comune per l'elaborazione asincrona)
• Lambda: invocazione diretta (sincrona dal punto di vista di SNS)
• HTTP/HTTPS: consegna tramite webhook a endpoint esterni
• Email / Email-JSON: notifiche per gli utenti
• SMS: consegna di messaggi di testo
• Mobile Push: FCM, APNs tramite applicazioni della piattaforma
• Firehose: streaming verso S3 o Redshift tramite Kinesis Data Firehose

Fan-out è il pattern fondamentale di SNS: si pubblica un messaggio in un topic e SNS lo distribuisce simultaneamente a tutti i subscriber. Ad esempio, un evento relativo a un nuovo ordine può essere distribuito a: una coda SQS per l'evasione in magazzino, un'altra coda SQS per l'aggiornamento dell'inventario, una funzione Lambda per il rilevamento delle frodi e una sottoscrizione email per il team operativo. Ogni subscriber elabora l'evento in modo indipendente, senza accoppiamento tra i vari componenti. Questa soluzione è molto più scalabile rispetto a un singolo consumer che instrada i messaggi verso più sistemi.

Il pattern consigliato combina SNS e SQS: si pubblica su SNS, che distribuisce i messaggi a più code SQS. Questo offre:

• Persistenza: se un consumer è inattivo, i messaggi rimangono in coda in SQS
• Scalabilità indipendente: ogni consumer elabora i messaggi al proprio ritmo
• Disaccoppiamento: i nuovi consumer devono solo sottoscriversi a SNS, senza modificare il publisher
• Resilienza ai retry: SQS fornisce il visibility timeout e la DLQ

I subscriber Lambda diretti non dispongono del buffering offerto da SQS; per questo SNS→SQS→Lambda è il pattern a tre livelli più resiliente.

Quando SNS non riesce a consegnare un messaggio a un subscriber (l'endpoint HTTP restituisce 5xx, Lambda genera un'eccezione o SQS non è disponibile), effettua nuovi tentativi utilizzando una strategia di exponential backoff. Le policy di retry variano in base al protocollo: gli endpoint HTTP ricevono fino a 4 retry immediati, seguiti da un exponential backoff nell'arco di 23 giorni; per Lambda e SQS, i retry sono gestiti dai rispettivi meccanismi. Configuri una SNS Topic DLQ per raccogliere i messaggi per i quali sono esauriti tutti i tentativi di consegna, assicurandosi che nessun evento vada perso senza che ve ne accorgiate.

Pubbblichi su SNS utilizzando AWS SDK o CLI. Ogni messaggio può includere un Subject (per le email), un corpo Message (fino a 256 KB) e Message Attributes per l'instradamento. Per diversi tipi di subscriber (SQS, email o dispositivi mobili), può utilizzare Message Structure per inviare contenuti differenti a ciascun protocollo: un JSON con chiavi specifiche per protocollo consente di adattare il payload al tipo di subscriber.

Le policy di filtro delle sottoscrizioni consentono a ogni subscriber di ricevere solo i messaggi pertinenti, in base agli attributi del messaggio. Senza filtraggio, tutti i subscriber ricevono tutti i messaggi pubblicati. Con una filter policy, un subscriber specifica i valori degli attributi di suo interesse. Ad esempio, una coda per gli ordini 'PREMIUM' si sottoscrive con il filtro {"orderType": ["PREMIUM"]}; una coda 'STANDARD' filtra per ["STANDARD"]. Ogni subscriber gestisce solo il sottoinsieme pertinente, riducendo l'elaborazione non necessaria.

SNS supporta notifiche push mobili dirette verso dispositivi iOS (APNs) e Android (FCM/GCM). Si registrano i token dei dispositivi come ARN di endpoint della piattaforma, quindi si pubblica direttamente su un endpoint oppure su un topic con subscriber costituiti da applicazioni della piattaforma. Per notifiche dirette ai dispositivi su larga scala (milioni di dispositivi), combini SNS con il fan-out SQS: SNS instrada l'evento di notifica verso SQS e un servizio worker gestisce la risoluzione in blocco dei token e la consegna su larga scala.

Protegga i messaggi SNS con la crittografia lato server utilizzando AWS KMS. In questo modo i messaggi vengono crittografati quando sono inattivi all'interno dell'infrastruttura SNS. Il controllo degli accessi utilizza sia le policy basate sulle risorse (chi può pubblicare nel topic o sottoscriversi a esso) sia le policy IAM. Per consentire a un bucket S3 di pubblicare notifiche in un topic SNS, conceda sns:Publish al principale di servizio S3 nella policy basata sulle risorse del topic. Limiti sempre la pubblicazione alle fonti autorizzate, per impedire l'iniezione di eventi non autorizzati.

SNS e SQS sono servizi complementari, non alternativi. SNS (push) serve per trasmettere immediatamente i messaggi a più consumer: lo utilizzi quando più sistemi devono reagire a un evento. SQS (pull) serve per un'elaborazione affidabile e persistente da parte di un singolo consumer, con retry e DLQ: lo utilizzi quando un consumer deve elaborare ogni messaggio esattamente una volta, al proprio ritmo. Il pattern fan-out SNS→SQS offre entrambi i vantaggi: la distribuzione broadcast di SNS e l'elaborazione persistente e ripetibile di SQS. Questa combinazione ricorre frequentemente negli scenari d'esame SAA-C03.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha appreso che: i topic SNS forniscono una distribuzione pub/sub basata sul push verso subscriber tra cui SQS, Lambda, HTTP, SMS ed email simultaneamente; l'architettura fan-out utilizza un singolo topic SNS che alimenta più code SQS, per ottenere un'elaborazione degli eventi da parte di più consumer persistente e scalabile in modo indipendente; le policy di filtro delle sottoscrizioni riducono l'elaborazione non necessaria instradando a ogni subscriber solo gli eventi pertinenti, in base agli attributi dei messaggi. Ora analizzeremo in dettaglio il filtraggio dei messaggi SQS e l'integrazione SNS + SQS.