SQS-meldingsfiltrering og SNS + SQS-integrasjon

I en fan-out-arkitektur uten filtrering mottar hver SQS-abonnent alle SNS-meldinger. Hvis emnet publiserer ordrehendelser for ti ulike produktkategorier, men en abonnent bare behandler elektronikkordrer, mottar den likevel meldinger om mat og klær som den må forkaste. Dette sløser med databehandlingsressurser, øker kostnadene og legger unødvendig belastning på konsumentene. Filterpolicyer for SNS-abonnementer løser dette ved at SNS selv ruter meldinger bare til de riktige abonnentene.

En filterpolicy er et JSON-objekt som brukes på et SQS- eller Lambda-abonnement. SNS evaluerer policyen mot hver meldings meldingsegenskaper før levering. Hvis meldingsegenskapene samsvarer med filterpolicyen, leveres meldingen; hvis ikke, hopper SNS over abonnenten uten å varsle. Filterpolicyer støtter strengsamsvar, numeriske intervaller, prefikssamsvar og operatoren exists for å kontrollere om en egenskap finnes eller mangler.

Som standard samsvarer filterpolicyer med meldingsegenskaper (metadata). Siden 2023 støtter SNS også nyttelastbasert filtrering (meldingstekst) ved at De setter omfanget for filterpolicyen til MessageBody. Dette gjør det mulig å filtrere direkte på meldingsteksten basert på JSON-stier, uten at utgivere må legge til egenskaper. Filtrering av meldingstekst er mer fleksibel, men krever at meldingsteksten er gyldig JSON. Bekreft alltid hvilket omfang som samsvarer med utgiverens utdataformat.

Filterpolicyer støtter flere samsvarsoperatorer utover enkelt strenglikhet:

• Numerisk: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefiks: {"prefix": "order-"} samsvarer med alle strenger som begynner med dette prefikset
• Anything-but: {"anything-but": ["CANCELLED"]} samsvarer med alle verdier unntatt de oppførte
• Exists: {"exists": true} samsvarer hvis egenskapen finnes; false hvis den mangler

For at filtrering skal fungere, må utgiveren inkludere meldingsegenskaper ved publisering til SNS. Egenskaper er nøkkel-verdi-par med en datatype (String, Number, Binary). Utgiveren trenger ikke å vite hvilke filterpolicyer abonnentene har – den beriker bare meldingen med egenskaper som beskriver hendelsen. SNS håndterer rutingen automatisk. Dermed forblir utgiverne fullstendig frikoblet fra abonnentspesifikk logikk.

En avansert fan-out-topologi kan ha SNS som ruter til SQS-køer på flere spesifisitetsnivåer: én kø mottar alle ordrer (uten filter) for revisjon, en annen mottar bare ordrer med høy verdi (beløp >= 1000) for svindelkontroll, og en tredje mottar bare ELEKTRONICS-ordrer for elektronikkvarehuset. Hver SQS-kø har sin egen Lambda-konsument. Dette mønsteret skalerer hvert behandlingstrinn uavhengig og gjør det mulig å legge til nye konsumenter uten å endre eksisterende konsumenter eller utgiveren.

SNS kan levere til SQS-køer i en annen AWS-konto. SQS-køens ressursbaserte policy må tillate at SNS-tjenestens principal kaller sqs:SendMessage fra ARN-en til SNS-emnet i publiseringskontoen. Dette muliggjør sentralisert publisering av hendelser (én konto publiserer, flere kontoteam abonnerer) uten deling av legitimasjon. Fan-out på tvers av kontoer er et vanlig mønster i AWS Organizations-oppsett med flere kontoer.

Når hendelsesvolumet øker kraftig, skalerer direkte SNS-til-Lambda-påkallinger Lambda umiddelbart, noe som potensielt kan overbelaste nedstrøms databaser eller API-er. Ved å legge SQS mellom SNS og Lambda opprettes en buffer: SNS leverer til SQS, og Lambda henter meldinger fra SQS med en kontrollert batchstørrelse. Dermed kan Lambda behandle meldinger i et bærekraftig tempo, mens SQS absorberer trafikktopper. Kødybden fungerer som en mekanisme for å regulere belastningen – De kan overvåke den og varsle når den vokser forbi en terskel som viser at konsumenten ligger etter.

SNS → Lambda (direkte): lavest forsinkelse, ingen buffering, Lambda skalerer umiddelbart. Best egnet for sanntidsvarsler eller viktige varslinger der forsinkelse under ett sekund er avgjørende. SNS → SQS → Lambda: gir støtte for DLQ, kontrollert gjennomstrømming, nye forsøk med synlighetstidsavbrudd og overvåking av kødybde. Best egnet for transaksjonsbehandling, lageroppdateringer og alle scenarier der nedstrøms begrensninger må respekteres. I eksamensoppgaver bør De velge SQS-buffering når varighet og hastighetskontroll nevnes.

Bruk SNS-konsollens redigeringsverktøy for filterpolicyer til å teste om en eksempelmelding samsvarer med filterpolicyen før du distribuerer den. Du kan også bruke SNS Sandbox til å simulere meldingslevering og bekrefte rutingen. I kode kan du validere filterpolicyer ved å publisere testmeldinger med kjente attributter og kontrollere CloudWatch-metrikker for hvert abonnement: Metrikken NumberOfMessagesFiltered viser hvor mange meldinger som ble blokkert av filteret, slik at du kan finjustere policyene uten å vente på hendelser i produksjon.

En komplett SNS + SQS-integrasjon ser slik ut: (1) Applikasjonen publiserer en hendelse til et SNS Standard topic med meldingsattributter; (2) SNS evaluerer hver abonnements filterpolicy og leverer bare samsvarende meldinger til hver SQS-kø; (3) Lambda henter meldinger fra hver SQS-kø med en konfigurert batchstørrelse og behandler dem; (4) Mislykkede meldinger når køens DLQ etter maxReceiveCount; (5) et CloudWatch-alarm for antall meldinger i DLQ varsler teamet. Dette fullstendig frakoblede og robuste mønsteret er en modellarkitektur for SAA-C03.

I denne leksjonen har De lært at SNS-filterpolicyer ruter meldinger basert på meldingsattributter eller innholdet i meldingen på SNS-nivå, slik at unødvendig behandling hos nedstrømsforbrukere unngås; mønsteret SNS→SQS→Lambda tilfører robust buffering og hastighetskontroll mellom kringkasting til flere mottakere og behandling; og SQS-levering på tvers av kontoer muliggjør sentralisert pub/sub i miljøer med flere kontoer ved hjelp av ressursbaserte køpolicyer. Deretter skal vi se nærmere på REST-, HTTP- og WebSocket-API-er i Amazon API Gateway.