Filtrowanie wiadomości SQS i integracja SNS + SQS

W architekturze fan-out bez filtrowania każdy subskrybent SQS otrzymuje każdą wiadomość SNS. Jeśli temat publikuje zdarzenia dotyczące zamówień z 10 różnych kategorii produktów, a dany subskrybent obsługuje tylko zamówienia elektroniki, nadal otrzymuje wiadomości dotyczące żywności i odzieży, które musi odrzucić. Powoduje to marnowanie zasobów obliczeniowych, wzrost kosztów i niepotrzebne obciążenie konsumentów. Zasady filtrowania subskrypcji SNS rozwiązują ten problem, ponieważ to samo SNS kieruje wiadomości wyłącznie do odpowiednich subskrybentów.

Zasada filtrowania to obiekt JSON stosowany do subskrypcji SQS lub Lambda. SNS ocenia tę zasadę względem atrybutów wiadomości przed jej dostarczeniem. Jeśli atrybuty wiadomości pasują do zasady filtrowania, wiadomość zostaje dostarczona; w przeciwnym razie SNS po cichu pomija danego subskrybenta. Zasady filtrowania obsługują dopasowanie ciągów znaków, zakresy liczbowe, dopasowanie prefiksów oraz operator exists sprawdzający obecność lub brak atrybutu.

Domyślnie zasady filtrowania dopasowują wartości na podstawie atrybutów wiadomości (metadanych). Od 2023 roku SNS obsługuje również filtrowanie na podstawie danych (treści) przez ustawienie zakresu zasady filtrowania na MessageBody. Umożliwia to filtrowanie bezpośrednio w treści wiadomości za pomocą ścieżki JSON, bez konieczności dodawania atrybutów przez wydawców. Filtrowanie treści jest bardziej elastyczne, ale wymaga, aby treść wiadomości była prawidłowym kodem JSON. Należy zawsze potwierdzić, który zakres odpowiada formatowi danych generowanych przez wydawcę.

Zasady filtrowania obsługują wiele operatorów dopasowania wykraczających poza proste porównanie ciągów znaków:

• Numeric: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} dopasowuje każdy ciąg znaków zaczynający się od tego prefiksu
• Anything-but: {"anything-but": ["CANCELLED"]} dopasowuje każdą wartość poza wymienionymi
• Exists: {"exists": true} dopasowuje, jeśli atrybut jest obecny; wartość false oznacza jego brak

Aby filtrowanie działało, wydawca musi dołączyć atrybuty wiadomości podczas publikowania w SNS. Atrybuty to pary klucz-wartość z określonym typem danych (String, Number, Binary). Wydawca nie musi wiedzieć, którzy subskrybenci mają poszczególne zasady filtrowania — wystarczy, że wzbogaci wiadomość o atrybuty opisujące zdarzenie. SNS automatycznie zajmie się routingiem. Dzięki temu wydawcy pozostają całkowicie niezależni od logiki właściwej dla poszczególnych subskrybentów.

Zaawansowana topologia fan-out może obejmować kierowanie przez SNS wiadomości do kolejek SQS o różnym poziomie szczegółowości: jedna kolejka otrzymuje wszystkie zamówienia (bez filtra) na potrzeby audytu, druga otrzymuje tylko zamówienia HIGH_VALUE (kwota >= 1000) na potrzeby analizy oszustw, a trzecia otrzymuje wyłącznie zamówienia ELECTRONICS dla magazynu elektroniki. Każda kolejka SQS ma własnego konsumenta Lambda. Ten wzorzec umożliwia niezależne skalowanie poszczególnych poziomów przetwarzania oraz dodawanie nowych konsumentów bez modyfikowania istniejących elementów ani wydawcy.

SNS może dostarczać wiadomości do kolejek SQS znajdujących się na innym koncie AWS. Zasada oparta na zasobach kolejki SQS musi zezwalać podmiotowi usługi SNS na wywołanie sqs:SendMessage z ARN-em tematu SNS z konta wydawcy. Umożliwia to centralne publikowanie zdarzeń (jedno konto publikuje, a zespoły z wielu kont subskrybują temat) bez udostępniania poświadczeń. Fan-out między kontami jest często stosowany w konfiguracjach AWS Organizations obejmujących wiele kont.

Gdy natężenie zdarzeń gwałtownie rośnie, bezpośrednie wywołania SNS-to-Lambda natychmiast skalują Lambda, co może przeciążyć podrzędne bazy danych lub interfejsy API. Dodanie SQS między SNS i Lambda tworzy bufor: SNS dostarcza wiadomości do SQS, a Lambda odpytuje SQS z kontrolowanym rozmiarem partii. Pozwala to funkcji Lambda przetwarzać wiadomości w tempie możliwym do utrzymania, podczas gdy SQS absorbuje skoki ruchu. Głębokość kolejki działa jako mechanizm kontroli przeciążenia — można ją monitorować i generować alerty, gdy przekroczy próg wskazujący na opóźnienia konsumenta.

SNS → Lambda (bezpośrednio): najniższe opóźnienie, brak buforowania, natychmiastowe skalowanie Lambda. Najlepsze rozwiązanie w przypadku alertów w czasie rzeczywistym lub pilnych powiadomień, gdy istotne jest opóźnienie poniżej sekundy. SNS → SQS → Lambda: zapewnia obsługę DLQ, kontrolowaną przepustowość, ponowienia z visibility timeout oraz monitorowanie głębokości kolejki. Najlepsze rozwiązanie w przypadku przetwarzania transakcji, aktualizacji zapasów i wszelkich scenariuszy, w których należy respektować ograniczenia systemów podrzędnych. W pytaniach egzaminacyjnych należy wybrać buforowanie SQS, gdy wspomniano o trwałości i kontroli tempa.

Użyj edytora zasad filtrowania w konsoli SNS, aby przed wdrożeniem sprawdzić, czy przykładowa wiadomość pasowałaby do zasady filtrowania. Możesz także użyć SNSSandbox, aby symulować dostarczanie wiadomości i zweryfikować routing. W kodzie sprawdzaj zasady filtrowania, publikując testowe wiadomości ze znanymi atrybutami i monitorując metryki CloudWatch dla każdej subskrypcji: metryka NumberOfMessagesFiltered pokazuje, ile wiadomości zostało zablokowanych przez filtr, co pomaga dostrajać zasady bez czekania na zdarzenia produkcyjne.

Kompletna integracja SNS + SQS wygląda następująco: (1) aplikacja publikuje zdarzenie w standardowym temacie SNS wraz z atrybutami wiadomości; (2) SNS ocenia zasadę filtrowania każdej subskrypcji i dostarcza do każdej kolejki SQS tylko pasujące wiadomości; (3) Lambda odpytuje każdą kolejkę SQS ze skonfigurowanym rozmiarem partii i przetwarza wiadomości; (4) wiadomości, których nie udało się przetworzyć, trafiają do DLQ kolejki po osiągnięciu wartości maxReceiveCount; (5) alarm CloudWatch monitorujący liczbę wiadomości w DLQ powiadamia zespół. Ten w pełni rozdzielony i odporny na błędy wzorzec stanowi modelową architekturę SAA-C03.

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

W tej lekcji poznali Państwo następujące zagadnienia: zasady filtrowania SNS kierują wiadomości na poziomie SNS na podstawie atrybutów wiadomości lub jej treści, eliminując zbędne przetwarzanie po stronie konsumentów; wzorzec SNS→SQS→Lambda dodaje trwałe buforowanie i kontrolę tempa między rozgłaszaniem do wielu odbiorców a przetwarzaniem; natomiast dostarczanie SQS między kontami umożliwia scentralizowany model pub/sub w środowiskach obejmujących wiele kont dzięki zasadom zasobów kolejek. W następnej części omówimy interfejsy REST, HTTP i WebSocket usługi Amazon API Gateway.