Amazon SNS w Pythonie - fan-out, SQS i koszty

Gdy aplikacja ma poinformować kilka niezależnych systemów o jednym zdarzeniu, bezpośrednie wywoływanie każdego z nich szybko komplikuje backend. Amazon SNS rozwiązuje ten problem, rozsyłając komunikaty do wielu odbiorców z jednego punktu. Wyjaśniam, jak działa ta usługa, czym różni się od SQS, ile kosztuje i jak wykorzystać ją w aplikacji napisanej w Pythonie.

Czym jest Amazon SNS i jak działa

Amazon Simple Notification Service, w skrócie Amazon SNS, to w pełni zarządzana usługa AWS do wysyłania komunikatów i powiadomień. Jej najważniejszy model działania nosi nazwę publish-subscribe. Producent publikuje komunikat do tematu, a usługa przekazuje go wszystkim zainteresowanym odbiorcom.

Temat, czyli topic, jest logicznym kanałem komunikacyjnym. Przykładowo aplikacja e-commerce może mieć temat order-events. Po opublikowaniu zdarzenia o opłaceniu zamówienia ten sam komunikat może trafić do kolejki obsługującej wysyłkę, funkcji Lambda zapisującej statystyki i systemu powiadomień dla klienta.

Publisher, topic i subscriber

W typowym przepływie występują trzy elementy. Publisher publikuje wiadomość, topic pełni rolę punktu rozgłoszeniowego, a subscriber odbiera komunikat przez określony endpoint. Dzięki temu producent nie musi znać szczegółów działania każdego systemu po drugiej stronie.

To właśnie odseparowanie komponentów jest dla mnie największą wartością SNS. Zespół może dodać nowego odbiorcę bez przebudowy kodu publikującego zdarzenia, o ile nowa integracja zostanie podłączona do właściwego tematu i otrzyma odpowiednie uprawnienia IAM.

• SQS odbiera wiadomości do dalszego przetwarzania przez workerów.
• AWS Lambda uruchamia funkcję po dostarczeniu komunikatu.
• HTTP lub HTTPS przekazuje zdarzenie do zewnętrznego API.
• E-mail i SMS pozwalają wysyłać powiadomienia bez budowania własnej infrastruktury komunikacyjnej.
• Mobile push obsługuje powiadomienia dla aplikacji mobilnych.
• Amazon Data Firehose może przekazywać dane do dalszego przetwarzania lub analizy.

Standard czy FIFO

Najczęściej używane są standardowe tematy SNS. Oferują dużą skalowalność, ale dostarczenie odbywa się zasadniczo w modelu „co najmniej raz”. Oznacza to, że odbiorca powinien tolerować duplikaty, a kolejność komunikatów nie zawsze musi być zachowana.

Tematy FIFO są przeznaczone dla scenariuszy wymagających kolejności i deduplikacji. Trzeba jednak zaakceptować bardziej ograniczony model integracji, dlatego nie wybieram FIFO automatycznie. Najpierw sprawdzam, czy odbiorca rzeczywiście potrzebuje uporządkowanych komunikatów, ponieważ zwykły temat jest prostszy i bardziej elastyczny.

Gdzie SNS robi realną różnicę w backendzie i DevOps

SNS najlepiej sprawdza się wtedy, gdy jedno zdarzenie ma uruchomić kilka niezależnych reakcji. Nie jest to tylko narzędzie do wysyłania e-maili. W architekturze backendowej działa raczej jak rozgłośnia zdarzeń, która pozwala rozdzielić odpowiedzialności między usługi.

Wzorzec fan-out

Załóżmy, że klient opłacił zamówienie. Backend publikuje jedno zdarzenie do tematu SNS, a usługa przekazuje je do kilku subskrypcji:

• kolejka SQS dla modułu magazynowego,
• kolejka SQS dla systemu faktur,
• Lambda aktualizująca analitykę,
• endpoint HTTP odpowiedzialny za powiadomienie partnera.

Ten układ nosi nazwę fan-out. Jest istotny, bo każdy konsument może przetwarzać zdarzenie w swoim tempie i niezależnie od pozostałych. Awaria systemu faktur nie musi zatrzymywać aktualizacji magazynu, jeśli każdy z tych modułów ma własną kolejkę.

Alerty operacyjne i automatyzacja

W środowisku DevOps SNS często pojawia się przy alertach z Amazon CloudWatch. Przekroczenie progu zużycia CPU, błąd wdrożenia albo niedostępność instancji może uruchomić publikację do tematu, którego subskrybentami są e-mail, system on-call i funkcja automatycznie zakładająca incydent.

Własne obserwacje z projektowania takich mechanizmów są dość jednoznaczne. Najlepiej działają alerty, które prowadzą do konkretnej akcji, natomiast temat zbierający kilkadziesiąt przypadkowych powiadomień szybko staje się szumem. SNS dostarcza komunikaty, ale nie zastępuje sensownej strategii monitoringu.

Filtrowanie komunikatów

Każda subskrypcja może mieć własną politykę filtrowania. Dzięki niej odbiorca dostaje tylko komunikaty spełniające określone warunki, na przykład zdarzenia z regionu eu-central-1 albo dotyczące typu payment_failed.

Filtry można oprzeć na atrybutach wiadomości lub, w odpowiedniej konfiguracji, na jej strukturze JSON. To ogranicza liczbę niepotrzebnych wywołań i upraszcza kod konsumentów. Trzeba tylko pamiętać, że zmiana polityki filtra może rozchodzić się w systemie z opóźnieniem sięgającym kilkunastu minut.

SNS a SQS i EventBridge

Te usługi często pojawiają się obok siebie, ale rozwiązują różne problemy. Najprościej zapamiętać to tak: SNS rozsyła, SQS przechowuje, a EventBridge routuje zdarzenia według reguł.

Jeżeli komunikat ma trafić do pięciu różnych systemów, zaczynam od SNS. Jeżeli zadanie ma zostać wykonane przez worker dopiero wtedy, gdy będzie miał zasoby, wybieram SQS. Gdy potrzebuję filtrowania po źródle, szczegółowych reguł i integracji z wieloma usługami AWS, rozważam EventBridge.

Najpraktyczniejszy układ to często SNS połączony z kilkoma kolejkami SQS. SNS zapewnia fan-out, a każda kolejka daje własny bufor, retry i tempo przetwarzania. Samo SNS nie powinno być traktowane jak pełnowartościowa kolejka robocza dla długich lub krytycznych zadań.

Jak podłączyć SNS do aplikacji w Pythonie

Do komunikacji z SNS w Pythonie używa się najczęściej biblioteki boto3. Minimalny przepływ obejmuje utworzenie tematu, dodanie subskrypcji, przyznanie uprawnień i publikację wiadomości.

Publikowanie zdarzenia

Poniższy przykład publikuje komunikat JSON. W prawdziwej aplikacji ARN tematu powinien pochodzić z konfiguracji środowiska, a nie być wpisany na stałe w kodzie.

import json
import boto3

sns = boto3.client("sns", region_name="eu-central-1")

event = {
    "event_type": "order_paid",
    "order_id": "A-1042",
    "customer_id": 781
}

response = sns.publish(
    TopicArn="arn:aws:sns:eu-central-1:123456789012:order-events",
    Message=json.dumps(event),
    MessageAttributes={
        "event_type": {
            "DataType": "String",
            "StringValue": "order_paid"
        }
    }
)

print(response["MessageId"])

Atrybut event_type ma praktyczne znaczenie, ponieważ subskrypcje mogą filtrować wiadomości bez uruchamiania logiki biznesowej po stronie odbiorcy. Warto też przechowywać unikalny identyfikator zdarzenia, aby konsument mógł bezpiecznie wykrywać ewentualne duplikaty.

Konfiguracja, którą trzeba sprawdzić

1. Utwórz temat SNS w odpowiednim regionie AWS.
2. Dodaj subskrypcję, na przykład kolejkę SQS lub funkcję Lambda.
3. Skonfiguruj polityki IAM dla publikowania i odbierania komunikatów.
4. Jeśli używasz e-maila lub endpointu HTTP, potwierdź subskrypcję.
5. Dodaj filtr wiadomości, gdy każdy odbiorca ma reagować na inny typ zdarzeń.
6. Przetestuj retry, duplikaty, niedostępność odbiorcy i format payloadu.

W przypadku e-maila lub adresu HTTP sama deklaracja subskrypcji nie zawsze wystarcza. Odbiorca musi ją potwierdzić, dlatego brak wiadomości testowej często wynika nie z błędu Pythona, lecz z niedokończonej konfiguracji.

Koszty, ograniczenia i błędy projektowe

Amazon SNS nie wymaga opłaty startowej ani stałego abonamentu. Według aktualnych stawek AWS standardowe żądania kosztują około 0,50 USD za milion, dostarczenie przez HTTP około 0,06 USD za 100 tysięcy powiadomień, a dostarczenie e-mailowe około 2 USD za 100 tysięcy wiadomości. SMS-y są rozliczane osobno, a ich cena zależy od kraju, operatora i rodzaju trasy.

Dostępny jest także bezpłatny limit obejmujący między innymi 1 milion żądań miesięcznie, 100 tysięcy dostarczeń HTTP i 1000 dostarczeń e-mailowych. Trzeba jednak liczyć także koszty transferu danych oraz usług współpracujących, takich jak Lambda, SQS czy KMS.

Limity techniczne

Standardowa wiadomość SNS może mieć do 256 KB. Przy rozliczeniach każdy blok danych o wielkości 64 KB jest traktowany jako osobne żądanie lub dostarczenie, więc duży payload może zwiększyć rachunek szybciej, niż wynikałoby to z samej liczby publikacji.

W dokumentacji AWS wskazano również domyślne limity rzędu 100 tysięcy tematów na konto i do 10 milionów subskrypcji na temat. To wartości wystarczające dla większości projektów, ale przy większej skali trzeba kontrolować limity usług i ewentualnie wystąpić o ich podniesienie.

Przeczytaj również: CMDB dla Backend i DevOps - Jak uniknąć pułapek?

Co najczęściej psuje wdrożenie

• Brak idempotencji, czyli wielokrotne wykonanie tego samego zdarzenia powoduje podwójny efekt.
• Wysyłanie dużych obiektów zamiast identyfikatora rekordu i danych potrzebnych odbiorcy.
• Traktowanie SNS jak kolejki i oczekiwanie, że usługa będzie przechowywać zadania do późniejszego odczytu.
• Zbyt szerokie uprawnienia IAM, na przykład możliwość publikowania do wszystkich tematów.
• Brak obsługi błędów dostarczenia i monitorowania nieudanych prób.
• Brak wersjonowania schematu, przez co zmiana pola w JSON-ie psuje starszych konsumentów.

W systemach produkcyjnych projektuję komunikaty tak, aby zawierały nazwę zdarzenia, identyfikator, czas wystąpienia i wersję schematu. To kilka dodatkowych pól, które później bardzo ułatwiają debugowanie, migracje i analizę logów.

Jak myśleć o SNS przed wdrożeniem

Amazon SNS jest dobrym wyborem, gdy chcesz odseparować producenta od wielu konsumentów i szybko rozesłać jedno zdarzenie do różnych kanałów. W prostym systemie może obsługiwać alerty e-mailowe, a w większym stać się elementem architektury zdarzeniowej opartej na SNS, SQS i Lambdzie.

Nie traktowałbym go jednak jako uniwersalnego zamiennika kolejki, brokera transakcyjnego ani systemu do przechowywania historii zdarzeń. Najlepszy efekt daje jasny podział ról: SNS odpowiada za dystrybucję, SQS za buforowanie i niezawodne przetwarzanie, a aplikacja za idempotencję, bezpieczeństwo oraz sensowny kontrakt komunikatu.