SQS-viestien suodatus ja SNS–SQS-integraatio

Fan-out-arkkitehtuurissa ilman suodatusta jokainen SQS-tilaaja vastaanottaa jokaisen SNS-viestin. Jos aihe julkaisee tilaustapahtumia kymmenestä eri tuoteryhmästä mutta tilaaja käsittelee vain elektroniikkatilauksia, se vastaanottaa silti ruoka- ja vaatetilausten viestit ja joutuu hylkäämään ne. Tämä tuhlaa laskentaresursseja, kasvattaa kustannuksia ja lisää kuluttajien tarpeetonta kuormaa. SNS subscription filter policies -suodatuskäytännöt ratkaisevat ongelman antamalla SNS:n reitittää viestit vain sopiville tilaajille.

Suodatuskäytäntö on SQS- tai Lambda-tilaukseen sovellettava JSON-objekti. SNS vertaa käytäntöä kunkin viestin message attributes -määritteisiin ennen toimitusta. Jos viestimääritteet vastaavat suodatuskäytäntöä, viesti toimitetaan; muussa tapauksessa SNS ohittaa kyseisen tilaajan hiljaisesti. Suodatuskäytännöt tukevat merkkijonojen vertailua, numeerisia alueita, etuliitteiden vertailua sekä exists-operaattoria, jolla tarkistetaan määritteen olemassaolo tai puuttuminen.

Oletusarvoisesti suodatuskäytännöt kohdistuvat message attributes -määritteisiin eli metatietoihin. Vuodesta 2023 lähtien SNS on tukenut myös hyötykuormaan perustuvaa (rungon) suodatusta asettamalla suodatuskäytännön laajuudeksi MessageBody. Näin JSON-polkuun perustuva suodatus voidaan tehdä suoraan viestin rungosta ilman, että julkaisijoiden tarvitsee lisätä määritteitä. Rungon suodatus on joustavampaa, mutta se edellyttää, että viestin runko on kelvollista JSON-muotoa. Varmistakaa aina, kumpi laajuus vastaa julkaisijan tuottamaa muotoa.

Suodatuskäytännöt tukevat yksinkertaisen merkkijonojen yhtäsuuruuden lisäksi useita vertailuoperaattoreita:

• Numeric: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} vastaa kaikkia merkkijonoja, jotka alkavat kyseisellä etuliitteellä
• Anything-but: {"anything-but": ["CANCELLED"]} vastaa kaikkia arvoja lueteltuja arvoja lukuun ottamatta
• Exists: {"exists": true} vastaa, jos määrite on olemassa; false, jos se puuttuu

Jotta suodatus toimisi, julkaisijan on sisällytettävä viestimääritteet julkaistessaan viestin SNS:ään. Määritteet ovat avain–arvo-pareja, joilla on tietotyyppi (String, Number, Binary). Julkaisijan ei tarvitse tietää, millaisia suodatuskäytäntöjä tilaajilla on – sen tarvitsee vain rikastaa viestiä tapahtumaa kuvaavilla määritteillä. SNS huolehtii reitityksestä automaattisesti. Näin julkaisijat pysyvät täysin irrotettuina tilaajakohtaisesta logiikasta.

Edistyneessä fan-out-topologiassa SNS voi reitittää viestejä SQS-jonoihin useilla tarkkuustasoilla: yksi jono vastaanottaa kaikki tilaukset (ei suodatinta) auditointia varten, toinen vastaanottaa vain HIGH_VALUE-tilaukset (amount >= 1000) petosten tarkastelua varten ja kolmas vain ELECTRONICS-tilaukset elektroniikkavarastoa varten. Jokaisella SQS-jonolla on oma Lambda-kuluttajansa. Tämä malli mahdollistaa kunkin käsittelytason itsenäisen skaalauksen ja uusien kuluttajien lisäämisen koskematta olemassa oleviin kuluttajiin tai julkaisijaan.

SNS voi toimittaa viestejä eri AWS-tilillä sijaitseviin SQS-jonoihin. SQS-jonon resurssipohjaisen käytännön on sallittava SNS-palvelun principalin kutsua sqs:SendMessage-toimintoa julkaisevan tilin SNS-aiheen ARN:stä. Näin keskitetty tapahtumien julkaiseminen on mahdollista (yksi tili julkaisee ja useiden tilien tiimit tilaavat) ilman tunnistetietojen jakamista. Tilien välinen fan-out on yleinen malli usean tilin AWS Organizations -ympäristöissä.

Kun tapahtumamäärä kasvaa äkillisesti, suorat SNS–Lambda-kutsut skaalaavat Lambdan välittömästi ja voivat mahdollisesti kuormittaa liikaa taustalla olevia tietokantoja tai rajapintoja. Kun SNS:n ja Lambdan väliin lisätään SQS, syntyy puskuri: SNS toimittaa viestit SQS:ään, ja Lambda noutaa niitä hallitun eräkoon mukaisesti. Näin Lambda voi käsitellä viestejä kestävällä nopeudella SQS:n tasatessa liikenteen piikkejä. Jonon syvyys toimii vastapaineen mekanismina – sitä voidaan valvoa ja siitä voidaan ilmoittaa, kun se kasvaa raja-arvon yli ja ilmaisee kuluttajan jäävän jälkeen.

SNS → Lambda (suora): pienin viive, ei puskurointia, Lambda skaalautuu välittömästi. Sopii parhaiten reaaliaikaiseen hälytykseen tai kiireellisiin ilmoituksiin, joissa alle sekunnin viive on tärkeä. SNS → SQS → Lambda: lisää DLQ-tuen, hallitun läpimenon, Visibility Timeoutiin perustuvat uudelleenyritykset ja jonon syvyyden valvonnan. Sopii parhaiten tapahtumien käsittelyyn, varastosaldojen päivityksiin ja tilanteisiin, joissa taustajärjestelmien rajoja on noudatettava. Koetehtävissä valitkaa SQS-puskurointi aina, kun mainitaan kestävyys ja nopeuden hallinta.

Testatkaa SNS-konsolin suodatuskäytäntöeditorilla, vastaisiko esimerkkiviesti suodatuskäytäntöänne, ennen kuin otatte sen käyttöön. Voitte myös käyttää SNS Sandboxia viestien toimituksen simulointiin ja reitityksen varmistamiseen. Koodissa voitte validoida suodatuskäytännöt julkaisemalla testiviestejä, joiden attribuutit ovat tiedossa, ja tarkistamalla kunkin tilauksen CloudWatch-mittarit: NumberOfMessagesFiltered-mittari näyttää, kuinka monta viestiä suodatin esti, joten voitte hienosäätää käytäntöjä odottamatta tuotantotapahtumia.

Täydellinen SNS + SQS -integraatio toimii näin: (1) sovellus julkaisee tapahtuman SNS Standard -aiheeseen viestiattribuutteineen; (2) SNS arvioi kunkin tilauksen suodatuskäytännön ja toimittaa kuhunkin SQS-jonoon vain täsmäävät viestit; (3) Lambda lukee jokaisesta SQS-jonosta määritetyn eräkoon mukaisesti ja käsittelee viestit; (4) epäonnistuneet viestit siirtyvät jonon DLQ:hun maxReceiveCount-arvon täytyttyä; (5) DLQ:n syvyyttä valvova CloudWatch-hälytys ilmoittaa tiimille. Tämä täysin hajautettu ja vikasietoinen malli on esimerkki SAA-C03-arkkitehtuurista.

Tässä oppitunnissa opitte, että SNS-suodatuskäytännöt reitittävät viestejä viestiattribuuttien tai viestin sisällön perusteella SNS-tasolla, mikä poistaa tarpeettoman käsittelyn kuluttajilta, SNS→SQS→Lambda -malli lisää kestävän puskurin ja nopeudensäätelyn fan-out-lähetyksen ja käsittelyn välille ja tilien välinen SQS-toimitus mahdollistaa keskitetyn pub/sub-arkkitehtuurin usean tilin ympäristöissä jonoresurssien käytäntöjen avulla. Seuraavaksi tutustumme Amazon API Gatewayn REST-, HTTP- ja WebSocket-rajapintoihin.