SQS-meddelandefiltrering och SNS + SQS-integration

I en fan-out-arkitektur utan filtrering tar varje SQS-prenumerant emot varje SNS-meddelande. Om ert topic publicerar orderhändelser för tio olika produktkategorier men en prenumerant endast bearbetar elektronikorder, tar den ändå emot och måste kasta mat- och klädmeddelanden. Detta slösar beräkningsresurser, ökar kostnaderna och belastar konsumenterna i onödan. Filterregler för SNS-prenumerationer löser detta genom att låta SNS själv dirigera meddelanden endast till lämpliga prenumeranter.

En filterregel är ett JSON-objekt som tillämpas på en SQS- eller Lambda-prenumeration. SNS utvärderar regeln mot varje meddelandes meddelandeattribut innan leverans. Om meddelandeattributen matchar filterregeln levereras meddelandet. Om de inte gör det hoppar SNS tyst över den prenumeranten. Filterregler stöder strängmatchning, numeriska intervall, prefixmatchning och operatorn exists för att kontrollera om ett attribut finns eller saknas.

Som standard matchar filterregler mot meddelandeattribut (metadata). Sedan 2023 stöder SNS även nyttolastbaserad filtrering (meddelandetext) genom att ange regelns omfattning till MessageBody. Det gör det möjligt att filtrera direkt i meddelandetexten med JSON-sökvägar, utan att producenter behöver lägga till attribut. Filtrering av meddelandetext är mer flexibel, men kräver att meddelandetexten är giltig JSON. Kontrollera alltid vilken omfattning som överensstämmer med producentens utdataformat.

Filterregler stöder flera matchningsoperatorer utöver enkel stränglikhet:

• Numeriskt: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} matchar alla strängar som börjar med det prefixet
• Anything-but: {"anything-but": ["CANCELLED"]} matchar alla värden utom de angivna
• Exists: {"exists": true} matchar om attributet finns, och false om det saknas

För att filtrering ska fungera måste producenten inkludera meddelandeattribut vid publicering till SNS. Attribut är nyckel-värde-par med en datatyp (String, Number, Binary). Producenten behöver inte känna till vilka prenumeranter som har vilka filterregler – den berikar bara meddelandet med attribut som beskriver händelsen. SNS hanterar dirigeringen automatiskt. På så sätt förblir producenterna helt frikopplade från prenumerantspecifik logik.

En avancerad fan-out-topologi kan ha SNS som dirigerar till SQS-köer med olika grad av specificitet: en kö tar emot alla ordrar (inget filter) för granskning, en annan tar endast emot ordrar med högt värde (amount >= 1000) för bedrägerigranskning, och en tredje tar endast emot ELECTRONICS-order för elektroniklagret. Varje SQS-kö har en egen Lambda-konsument. Mönstret gör att varje bearbetningsnivå kan skalas oberoende och att nya konsumenter kan läggas till utan att befintliga konsumenter eller producenten ändras.

SNS kan leverera till SQS-köer i ett annat AWS-konto. SQS-köns resursbaserade policy måste tillåta SNS-tjänsteprincipen att anropa sqs:SendMessage från ARN:en för SNS-topicet i det publicerande kontot. Detta möjliggör centraliserad publicering av händelser (ett konto publicerar och flera kontoteam prenumererar) utan att autentiseringsuppgifter delas. Fan-out mellan konton är ett vanligt mönster i AWS Organizations-miljöer med flera konton.

När händelsevolymen ökar kraftigt skalar direkta SNS-till-Lambda-anrop Lambda omedelbart, vilket kan överbelasta nedströmsdatabaser eller API:er. Genom att lägga till SQS mellan SNS och Lambda skapas en buffert: SNS levererar till SQS och Lambda läser av SQS med en kontrollerad batchstorlek. Det gör att Lambda kan bearbeta meddelanden i en hållbar takt medan SQS absorberar trafiktoppar. Köns djup fungerar som en mekanism för att skapa mottryck – ni kan övervaka det och utlösa en avisering när det växer över ett tröskelvärde som visar att konsumenten släpar efter.

SNS → Lambda (direkt): lägsta fördröjning, ingen buffring och Lambda skalas omedelbart. Bäst för aviseringar i realtid eller brådskande meddelanden där fördröjning under en sekund är viktig. SNS → SQS → Lambda: ger stöd för DLQ, kontrollerad genomströmning, nya försök med visibility timeout och övervakning av köns djup. Bäst för transaktionsbearbetning, lageruppdateringar och alla scenarier där nedströmsbegränsningar måste respekteras. I provfrågor väljer ni SQS-buffring när beständighet och hastighetskontroll nämns.

Använd SNS-konsolens redigerare för filterprinciper för att testa om ett exempelmeddelande skulle matcha filterprincipen innan den distribueras. Ni kan också använda SNS Sandbox för att simulera meddelandeleverans och verifiera routningen. I kod validerar ni filterprinciper genom att publicera testmeddelanden med kända attribut och kontrollera CloudWatch-mått för varje prenumeration: måttet NumberOfMessagesFiltered visar hur många meddelanden som blockerades av filtret, vilket hjälper er att finjustera principerna utan att behöva vänta på händelser i produktionen.

En fullständig SNS + SQS-integration ser ut så här: (1) Applikationen publicerar en händelse till ett SNS Standard topic med meddelandeattribut; (2) SNS utvärderar varje prenumerations filterprincip och levererar endast matchande meddelanden till respektive SQS-kö; (3) Lambda hämtar meddelanden från varje SQS-kö med en konfigurerad batchstorlek och bearbetar dem; (4) Misslyckade meddelanden når köns DLQ efter maxReceiveCount; (5) ett CloudWatch-alarm för DLQ-djupet meddelar teamet. Det här helt frikopplade och motståndskraftiga mönstret är en modellarkitektur för SAA-C03.

I den här lektionen har ni lärt er att SNS-filterprinciper routar meddelanden baserat på meddelandeattribut eller innehåll på meddelandenivå i SNS, vilket eliminerar onödig bearbetning hos nedströmskonsumenter, att mönstret SNS→SQS→Lambda lägger till beständig buffring och hastighetsreglering mellan utsändning till flera mottagare och bearbetning, samt att leverans av SQS-meddelanden mellan konton möjliggör centraliserad pub/sub i miljöer med flera konton genom att använda resursprinciper för köer. Härnäst utforskar vi REST-, HTTP- och WebSocket-API:er i Amazon API Gateway.