SNS-emner og fan-out-arkitektur

Amazon Simple Notification Service (SNS) er en fullstendig administrert pub/sub-meldingstjeneste. Utgivere sender meldinger til et SNS-emne, og SNS leverer umiddelbart disse meldingene til alle abonnenter. I motsetning til SQS (pull-basert) er SNS push-basert – meldingene leveres til abonnentene så snart de publiseres. Dette gjør SNS ideelt for samtidig kringkasting av hendelser til flere nedstrøms systemer.

I likhet med SQS har SNS to emnetyper: Standard-emner tilbyr best mulig sortering av meldinger, levering minst én gang og nesten ubegrenset gjennomstrømming – de kan levere til SQS, Lambda, HTTP-endepunkter, e-post, SMS og mobil-push. FIFO-emner garanterer streng sortering og levering nøyaktig én gang, men bare til FIFO-SQS-abonnenter. FIFO-emner støtter opptil 3 000 meldinger per sekund med batching og brukes når hendelsesrekkefølgen må bevares på tvers av flere abonnenter.

SNS støtter flere protokollbaserte abonnenttyper:

• SQS: varig købehandling (mest vanlig for asynkron behandling)
• Lambda: direkte påkalling (synkront fra SNS' perspektiv)
• HTTP/HTTPS: webhook-levering til eksterne endepunkter
• Email / Email-JSON: varsling av personer
• SMS: levering av tekstmeldinger
• Mobile Push: FCM, APNs via plattformapplikasjoner
• Firehose: strømming til S3 eller Redshift via Kinesis Data Firehose

Fan-out er det sentrale SNS-mønsteret: publiser én melding til et emne, så leverer SNS den samtidig til alle abonnentene. For eksempel kan en hendelse for en ny ordre videresendes til: en SQS-kø for lagerbehandling, en annen SQS-kø for lageroppdatering, en Lambda-funksjon for svindeloppdagelse og et e-postabonnement for driftsteamet. Hver abonnent behandler hendelsen uavhengig, uten kobling mellom dem. Dette er langt mer skalerbart enn én konsument som ruter til flere systemer.

Det anbefalte mønsteret kombinerer SNS og SQS: publiser til SNS, som videresender meldingen til flere SQS-køer. Dette gir:

• Varighet: Hvis en konsument er nede, legges meldingene i kø i SQS
• Uavhengig skalering: Hver konsument behandler meldinger i sitt eget tempo
• Frikobling: Nye konsumenter kan abonnere på SNS uten at utgiveren må endres
• Robusthet ved nye forsøk: SQS tilbyr synlighetstidsavbrudd og DLQ

Direkte Lambda-abonnenter mangler bufferen som SQS tilbyr, noe som gjør SNS→SQS→Lambda til det mer robuste trelagsmønsteret.

Når SNS ikke klarer å levere til en abonnent (HTTP-endepunktet returnerer 5xx, Lambda kaster et unntak eller SQS er utilgjengelig), prøver tjenesten på nytt med en strategi for eksponentiell tilbakeforsinkelse. Strategiene for nye forsøk varierer etter protokoll: HTTP-endepunkter får opptil fire umiddelbare nye forsøk, etterfulgt av eksponentiell tilbakeforsinkelse over 23 dager; Lambda og SQS får nye forsøk som håndteres av deres egne mekanismer. Konfigurer en SNS Topic DLQ for å fange opp meldinger som har brukt opp alle leveringsforsøkene, slik at ingen hendelser går tapt uten varsel.

Publiser til SNS ved hjelp av AWS SDK eller CLI. Hver melding kan inneholde et Subject (for e-post), en Message-tekst (på opptil 256 KB) og Message Attributes for ruting. For ulike abonnenttyper (SQS, e-post eller mobil) kan De bruke Message Structure til å sende forskjellig innhold til hver protokoll – JSON med protokollspesifikke nøkler lar Dem tilpasse nyttelasten for hver abonnenttype.

Filterpolicyer for abonnementer lar hver abonnent bare motta meldingene som er relevante for den, basert på meldingsegenskaper. Uten filtrering mottar alle abonnenter alle publiserte meldinger. Med en filterpolicy angir en abonnent hvilke egenskapsverdier den er interessert i. En kø for «PREMIUM»-ordrer kan for eksempel abonnere med filteret {"orderType": ["PREMIUM"]}, mens en «STANDARD»-kø filtrerer etter ["STANDARD"]. Hver abonnent håndterer bare sitt relevante utvalg, noe som reduserer unødvendig behandling.

SNS støtter direkte mobile push-varsler til iOS-enheter (APNs) og Android-enheter (FCM/GCM). De registrerer enhetstokener som plattformendepunkt-ARN-er og publiserer deretter direkte til et endepunkt eller til et emne med abonnenter fra plattformapplikasjoner. For varsler direkte til enheter i stor skala (millioner av enheter) kan De kombinere SNS med SQS fan-out: SNS ruter varslingen til SQS, og en arbeidertjeneste håndterer oppslag av tokener og levering i stort omfang.

Beskytt SNS-meldinger med server-side-kryptering ved hjelp av AWS KMS. Dette krypterer meldinger når de er lagret i SNS-infrastrukturen. Tilgangskontroll bruker både ressursbaserte policyer (hvem som kan publisere til eller abonnere på emnet) og IAM-policyer. For å tillate at en S3-bøtte publiserer varsler til et SNS-emne må De gi S3-tjenestens principal tillatelsen sns:Publish i emnets ressursbaserte policy. Begrens alltid publisering til autoriserte kilder for å forhindre uautorisert injisering av hendelser.

SNS og SQS utfyller hverandre og er ikke alternativer. SNS (push) brukes til å kringkaste meldinger til flere konsumenter umiddelbart – bruk det når flere systemer må reagere på en hendelse. SQS (pull) brukes til pålitelig og varig behandling av én konsument, med nye forsøk og DLQ – bruk det når én konsument skal behandle hver melding nøyaktig én gang i sitt eget tempo. SNS→SQS fan-out-mønsteret gir Dem begge deler: kringkastingslevering fra SNS og varig behandling med mulighet for nye forsøk fra SQS. Denne kombinasjonen forekommer ofte i eksamensscenarier for SAA-C03.

I denne leksjonen lærte De at SNS-emner tilbyr push-basert pub/sub-kringkasting til abonnenter, inkludert SQS, Lambda, HTTP, SMS og e-post samtidig, at fan-out-arkitektur bruker ett SNS-emne som mater flere SQS-køer for å oppnå varig og uavhengig skalerbar hendelsesbehandling med flere konsumenter, og at filterpolicyer for abonnementer reduserer unødvendig behandling ved å rute bare relevante hendelser til hver abonnent basert på meldingsegenskaper. Deretter skal vi se nærmere på filtrering av SQS-meldinger og integrasjon mellom SNS og SQS.