Tematy SNS i architektura fan-out

Amazon Simple Notification Service (SNS) to w pełni zarządzana usługa komunikacji pub/sub. Wydawcy wysyłają wiadomości do tematu SNS, a SNS natychmiast dostarcza je wszystkim subskrybentom. W przeciwieństwie do SQS, który działa na zasadzie pobierania, SNS działa na zasadzie wypychania — dostarcza wiadomości subskrybentom zaraz po ich opublikowaniu. Dzięki temu SNS doskonale nadaje się do jednoczesnego rozgłaszania zdarzeń do wielu systemów podrzędnych.

Podobnie jak SQS, SNS ma dwa typy tematów: tematy Standard zapewniają najlepszą możliwą kolejność wiadomości, dostarczanie co najmniej raz i niemal nieograniczoną przepustowość — mogą dostarczać wiadomości do SQS, Lambda, punktów końcowych HTTP, poczty e-mail, SMS-ów i powiadomień push na urządzenia mobilne. Tematy FIFO gwarantują ścisłą kolejność i dostarczenie dokładnie raz, ale wyłącznie do subskrybentów FIFO SQS. Tematy FIFO obsługują do 3000 wiadomości na sekundę z użyciem przetwarzania wsadowego i są używane, gdy kolejność zdarzeń musi zostać zachowana u wielu subskrybentów.

SNS obsługuje wiele typów subskrybentów opartych na protokołach:

• SQS: trwałe kolejkowanie (najczęstszy wybór w przetwarzaniu asynchronicznym)
• Lambda: bezpośrednie wywołanie (z perspektywy SNS synchroniczne)
• HTTP/HTTPS: dostarczanie webhooków do zewnętrznych punktów końcowych
• Email / Email-JSON: powiadomienia dla użytkowników
• SMS: dostarczanie wiadomości tekstowych
• Mobile Push: FCM, APNs za pośrednictwem aplikacji platformowych
• Firehose: przesyłanie strumienia do S3 lub Redshift za pośrednictwem Kinesis Data Firehose

Fan-out to podstawowy wzorzec SNS: jedna wiadomość jest publikowana w temacie, a SNS jednocześnie dostarcza ją wszystkim subskrybentom. Na przykład zdarzenie dotyczące nowego zamówienia może zostać rozgłoszone do: kolejki SQS obsługującej realizację zamówień w magazynie, innej kolejki SQS aktualizującej stan zapasów, funkcji Lambda wykrywającej oszustwa oraz subskrypcji e-mail dla zespołu operacyjnego. Każdy subskrybent przetwarza zdarzenie niezależnie, bez powiązań między nimi. Jest to znacznie bardziej skalowalne niż pojedynczy konsument kierujący komunikaty do wielu systemów.

Zalecany wzorzec łączy SNS i SQS: wiadomości są publikowane w SNS, który rozgłasza je do wielu kolejek SQS. Zapewnia to:

• Trwałość: jeśli konsument jest niedostępny, wiadomości oczekują w SQS
• Niezależne skalowanie: każdy konsument przetwarza wiadomości we własnym tempie
• Rozdzielenie zależności: nowi konsumenci po prostu subskrybują SNS, bez konieczności zmiany wydawcy
• Odporność na ponowienia: SQS zapewnia visibility timeout i DLQ

Bezpośredni subskrybenci Lambda nie mają buforowania zapewnianego przez SQS, dlatego SNS→SQS→Lambda jest bardziej odpornym wzorcem trójwarstwowym.

Gdy SNS nie może dostarczyć wiadomości do subskrybenta (punkt końcowy HTTP zwraca błąd 5xx, Lambda zgłasza wyjątek lub SQS jest niedostępne), ponawia próbę zgodnie ze strategią wykładniczego wycofywania. Zasady ponawiania różnią się zależnie od protokołu: punkty końcowe HTTP otrzymują do 4 natychmiastowych ponowień, a następnie ponowienia z wykładniczym odstępem przez 23 dni; w przypadku Lambda i SQS ponowieniami zarządzają ich własne mechanizmy. Należy skonfigurować DLQ tematu SNS, aby przechwytywać wiadomości, dla których wyczerpano wszystkie próby dostarczenia, i mieć pewność, że żadne zdarzenia nie zostaną utracone bez śladu.

Wiadomości można publikować w SNS za pomocą AWS SDK lub CLI. Każda wiadomość może zawierać Subject (dla poczty e-mail), treść Message (do 256 KB) oraz Message Attributes używane do routingu. W przypadku różnych typów subskrybentów (SQS, poczta e-mail i urządzenia mobilne) można użyć Message Structure, aby wysłać różną treść do każdego protokołu — JSON z kluczami właściwymi dla protokołów pozwala dostosować dane dla danego typu subskrybenta.

Zasady filtrowania subskrypcji pozwalają każdemu subskrybentowi odbierać tylko dotyczące go wiadomości na podstawie atrybutów wiadomości. Bez filtrowania wszyscy subskrybenci otrzymują wszystkie opublikowane wiadomości. Za pomocą zasady filtrowania subskrybent określa, jakie wartości atrybutów go interesują. Na przykład kolejka zamówień „PREMIUM” subskrybuje temat z filtrem {"orderType": ["PREMIUM"]}, a kolejka „STANDARD” filtruje według ["STANDARD"]. Każdy subskrybent obsługuje tylko właściwy dla siebie podzbiór wiadomości, co ogranicza zbędne przetwarzanie.

SNS obsługuje bezpośrednie mobilne powiadomienia push na urządzenia iOS (APNs) i Android (FCM/GCM). Tokeny urządzeń rejestruje się jako ARN-y punktów końcowych platformy, a następnie publikuje bezpośrednio w punkcie końcowym lub w temacie z subskrybentami będącymi aplikacjami platformowymi. W przypadku bezpośrednich powiadomień do urządzeń na dużą skalę (miliony urządzeń) warto połączyć SNS z fan-out SQS: SNS kieruje zdarzenie powiadomienia do SQS, a usługa robocza zajmuje się masowym wyszukiwaniem tokenów i dostarczaniem powiadomień na dużą skalę.

Wiadomości SNS należy chronić za pomocą szyfrowania po stronie serwera z użyciem AWS KMS. Szyfruje ono wiadomości w stanie spoczynku w infrastrukturze SNS. Kontrola dostępu wykorzystuje zarówno zasady oparte na zasobach (określające, kto może publikować w temacie lub go subskrybować), jak i zasady IAM. Aby zezwolić zasobnikowi S3 na publikowanie powiadomień w temacie SNS, należy przyznać uprawnienie sns:Publish podmiotowi usługi S3 w zasadzie zasobów tematu. Należy zawsze ograniczać możliwość publikowania do autoryzowanych źródeł, aby zapobiec wstrzykiwaniu nieautoryzowanych zdarzeń.

SNS i SQS uzupełniają się, a nie stanowią dla siebie alternatywy. SNS (push) służy do natychmiastowego rozgłaszania wiadomości do wielu konsumentów — należy go użyć, gdy wiele systemów musi zareagować na zdarzenie. SQS (pull) służy do niezawodnego i trwałego przetwarzania przez pojedynczego konsumenta, z ponowieniami i DLQ — należy go użyć, gdy jeden konsument ma przetwarzać każdą wiadomość dokładnie raz, we własnym tempie. Wzorzec fan-out SNS→SQS zapewnia oba te rozwiązania: rozgłaszanie przez SNS oraz trwałe przetwarzanie z ponowieniami przez SQS. To połączenie często pojawia się w scenariuszach egzaminacyjnych SAA-C03.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że: tematy SNS zapewniają rozgłaszanie pub/sub oparte na wypychaniu do subskrybentów, w tym jednocześnie do SQS, Lambda, HTTP, SMS-ów i poczty e-mail; architektura fan-out wykorzystuje jeden temat SNS zasilający wiele kolejek SQS, aby zapewnić trwałe, niezależnie skalowalne przetwarzanie zdarzeń przez wielu konsumentów; a zasady filtrowania subskrypcji ograniczają zbędne przetwarzanie, kierując do każdego subskrybenta tylko właściwe zdarzenia na podstawie atrybutów wiadomości. W następnej części szczegółowo omówimy filtrowanie wiadomości SQS oraz integrację SNS + SQS.