Amazon SQS
Amazon Simple Queue Service
W pełni zarządzane kolejki wiadomości. Odsprzęgaj komponenty aplikacji, buforuj obciążenie i buduj niezawodne systemy rozproszone.
Amazon SQS (Simple Queue Service) to w pełni zarządzany serwis kolejek wiadomości, który pozwala odsprzęgać (decouple) komponenty aplikacji. Zamiast bezpośredniej komunikacji między serwisami (co tworzy ścisłe zależności), jeden serwis wysyła wiadomość do kolejki, a drugi pobiera ją i przetwarza we własnym tempie.
SQS był pierwszym serwisem AWS - uruchomionym w 2004 roku, jeszcze przed EC2 i S3. Dziś obsługuje biliony wiadomości rocznie. Kolejki SQS skalują się automatycznie od jednej wiadomości do milionów na sekundę, bez provisionowania. To fundamentalny element architektury event-driven i mikrousług na AWS.
SQS oferuje dwa typy kolejek: Standard (nieograniczona przepustowość, kolejność best-effort) i FIFO (gwarantowana kolejność, exactly-once delivery, do 3000 msg/s z batching). Wybór zależy od tego, czy Twoja aplikacja wymaga ścisłej kolejności przetwarzania.
Amazon SQS był pierwszym publicznie dostępnym serwisem AWS - uruchomionym w lipcu 2004 roku, ponad 2 lata przed S3 i EC2. Pojedyncza kolejka SQS Standard może obsłużyć praktycznie nieograniczoną liczbę wiadomości na sekundę bez żadnej konfiguracji.
Zawsze konfiguruj Dead Letter Queue (DLQ) dla swoich kolejek. Jeśli wiadomość nie zostanie przetworzona po N próbach (maxReceiveCount), trafia do DLQ zamiast być przetwarzana w nieskończoność. Monitoruj DLQ alarmem CloudWatch - jeśli rosną, masz problem w konsumencie.
Standard SQS gwarantuje at-least-once delivery, wiec Twoj consumer MUSI byc idempotentny (ten sam message moze przyjsc 2+ razy). FIFO queues maja limit 3000 msg/s (z batching) lub 300 msg/s bez. Maksymalny rozmiar wiadomosci to 256 KB. Dla wiekszych payloadow uzyj wzorca SQS Extended Client (dane w S3, referencja w SQS). Visibility timeout musi byc dluzszy niz czas przetwarzania, inaczej message wroci do kolejki.
Amazon SQS to w pelni zarzadzana kolejka wiadomosci, ktora oddziela producentow od konsumentow. Wiadomosci czekaja w kolejce az konsument je pobierze i przetworzy - dzieki temu systemy moga dzialac niezaleznie i w roznym tempie. SQS gwarantuje dostarczenie kazdej wiadomosci co najmniej raz (Standard) lub dokladnie raz (FIFO).
Producent wysyla wiadomosc do kolejki
Aplikacja (Lambda, EC2, ECS lub dowolny klient SDK) wywoluje SendMessage z trescia do 256 KB. Mozesz dodac atrybuty wiadomosci (metadane), ustawic opoznienie dostarczenia (delay, 0-900 sekund) oraz grupowac wiadomosci w FIFO za pomoca MessageGroupId. Dla wiekszych payloadow uzyj Extended Client Library, ktora automatycznie przechowuje tresc w S3.
SQS przechowuje wiadomosc
Wiadomosc jest replikowana na wiele serwerow w regionie - nie zgubisz jej nawet przy awarii infrastruktury. Domyslny czas retencji to 4 dni (konfigurowalne od 1 minuty do 14 dni). W kolejce Standard wiadomosci moga byc dostarczone w innej kolejnosci niz wyslane. W FIFO zachowuja scisla kolejnosc w ramach MessageGroupId.
Konsument polluje kolejke
Konsumer wywoluje ReceiveMessage - moze pobrac do 10 wiadomosci naraz (batch). Long polling (WaitTimeSeconds do 20s) redukuje puste odpowiedzi i koszty o nawet 90%. Kazda pobrana wiadomosc staje sie niewidoczna dla innych konsumentow na czas Visibility Timeout (domyslnie 30s, max 12h).
Przetwarzanie wiadomosci
Konsument przetwarza wiadomosc - zapisuje do bazy, wywoluje API, generuje raport. Jesli przetwarzanie trwa dluzej niz Visibility Timeout, wiadomosc wraca do kolejki i moze zostac pobrana ponownie. Dlatego konsumenty powinny byc idempotentne - wielokrotne przetworzenie tej samej wiadomosci musi dawac ten sam efekt.
Usuwanie przetworzonej wiadomosci
Po udanym przetworzeniu konsument wywoluje DeleteMessage z ReceiptHandle. Jesli nie usunie wiadomosci w czasie Visibility Timeout, SQS uznaje, ze przetwarzanie sie nie powiodlo i ponownie udostepnia wiadomosc. DeleteMessageBatch pozwala usunac do 10 wiadomosci naraz, co zmniejsza liczbe wywolan API.
Obsluga bledow - Dead Letter Queue
Jesli wiadomosc nie zostanie pomyslnie przetworzona po okreslonej liczbie prob (maxReceiveCount, np. 3), SQS automatycznie przenosi ja do Dead Letter Queue (DLQ). DLQ to osobna kolejka, gdzie mozesz analizowac problematyczne wiadomosci, naprawic blad i ponownie wyslac je do glownej kolejki za pomoca DLQ redrive.
SQS to jeden z najprostszych serwiswow AWS, ale kilka decyzji architektonicznych moze dramatycznie wplynac na koszty i niezawodnosc. Ponizej kluczowe wskazowki z produkcyjnych wdrozen.
Standard vs FIFO - swiadomy wybor
Standard obsluguje praktycznie nieograniczona przepustowosc i kosztuje okolo 0.40 USD za milion requestow. FIFO gwarantuje kolejnosc i dokladnie jednokrotne dostarczenie, ale limit to 3000 wiadomosci/s z batchingiem (300 bez). FIFO kosztuje okolo 0.50 USD za milion. Wybieraj FIFO tylko gdy kolejnosc jest krytyczna (np. transakcje finansowe, kolejnosc zdarzen). Nazwa kolejki FIFO musi konczyc sie na .fifo.
PoczatkujacyVisibility Timeout - dostosuj do czasu przetwarzania
Domyslny Visibility Timeout to 30 sekund. Jesli Lambda przetwarza wiadomosc 2 minuty, a timeout to 30s - wiadomosc wroci do kolejki i zostanie przetworzona podwojnie. Ustaw timeout na 6x sredni czas przetwarzania. Dla Lambdy z SQS triggerem AWS zaleca ustawic VT na co najmniej 6x timeout funkcji - nie dzieje sie to automatycznie. Mozesz tez dynamicznie przedluzac VT za pomoca ChangeMessageVisibility.
PoczatkujacyDead Letter Queue - nie ignoruj bledow
Zawsze konfiguruj DLQ z maxReceiveCount 3-5. Bez DLQ problematyczna wiadomosc bedzie przetwarzana w kolko, marnujac zasoby. Podlacz CloudWatch Alarm na metryce ApproximateNumberOfMessagesVisible w DLQ - powiadomisz sie o problemach zanim eskaluja. Regularnie przegladaj DLQ i uzywaj redrive do ponownego przetworzenia naprawionych wiadomosci.
PoczatkujacyLong polling - oszczednosc na pustych odpowiedziach
Short polling (domyslny) natychmiast zwraca odpowiedz, nawet pusta - generuje mnodstwo zbednych wywolan API. Ustaw WaitTimeSeconds na 20 (maksimum) przy tworzeniu kolejki lub w ReceiveMessage. Long polling czeka do 20 sekund na wiadomosc, redukujac liczbr pustych odpowiedzi i koszty. Jedyny minus - odpowiedz moze przyjsc z opoznieniem do 20s.
PoczatkujacyBatch operations - do 10 wiadomosci naraz
SendMessageBatch, ReceiveMessage (MaxNumberOfMessages=10) i DeleteMessageBatch zmniejszaja liczbe wywolan API nawet 10-krotnie. Przy SQS trigger dla Lambdy ustaw BatchSize na 10 i MaximumBatchingWindowInSeconds na 5 - Lambda zbierze wiecej wiadomosci przed wywolaniem. To drastycznie redukuje liczbe invocations i koszty Lambda.
ZaawansowanyDeduplikacja w FIFO - ContentBasedDeduplication
FIFO automatycznie odrzuca duplikaty w oknie 5 minut. Mozesz uzyc ContentBasedDeduplication (hash z body) lub jawnego MessageDeduplicationId. W Standard Queue nie ma wbudowanej deduplikacji - musisz ja zaimplementowac po stronie konsumenta (np. sprawdzanie messageId w DynamoDB). To szczegolnie wazne przy retry po bledach sieciowych.
ZaawansowanyScreenshoty z AWS Console
Wkrotce pojawia sie tu zrzuty ekranu pokazujace jak korzystac z Amazon SQS bezposrednio w konsoli AWS.
Do czego sluzy Amazon SQS?
Buforowanie obciążenia (load leveling)
Gdy ruch na stronie wzrasta nagle (np. Black Friday), wiadomości czekają w kolejce zamiast przeciążać backend. Konsumenci przetwarzają je we własnym tempie.
Mikrousługi i event-driven architecture
Serwis A wrzuca event do SQS, serwis B reaguje. Jeśli B padnie, wiadomości czekają bezpiecznie w kolejce. Zerowa utrata danych.
Przetwarzanie w tle (background jobs)
Generowanie PDF, wysyłanie e-maili, przetwarzanie zdjęć - zamiast robić to synchronicznie, wrzuć zadanie do kolejki. Lambda lub ECS przetworzy je asynchronicznie.
Fan-out z SNS + SQS
SNS publikuje event do wielu kolejek SQS jednocześnie. Każda kolejka przetwarza event niezależnie - np. kolejka do e-maili, kolejka do logowania, kolejka do analityki.
Co musisz wiedziec?
Kolejka (Queue)
Bufor przechowujący wiadomości. Producent wysyła (SendMessage), konsument odbiera (ReceiveMessage) i kasuje (DeleteMessage). Dwa typy: Standard i FIFO.
Wiadomość (Message)
Jednostka danych w kolejce. Max rozmiar: 256 KB. Może zawierać JSON, XML, tekst. Dla większych danych - zapisz w S3 i wyślij referencję.
Visibility Timeout
Czas, przez który wiadomość jest niewidoczna dla innych konsumentów po pobraniu. Domyślnie 30s, max 12h. Jeśli konsument nie usunie wiadomości przed timeout, wraca do kolejki.
Dead Letter Queue (DLQ)
Kolejka na wiadomości, które nie mogły być przetworzone po określonej liczbie prób (maxReceiveCount). Pozwala debugować problemy bez blokowania głównej kolejki.
Long Polling
Technika odbierania wiadomości, gdzie ReceiveMessage czeka do 20s na nowe wiadomości zamiast natychmiast zwracać pustą odpowiedź. Redukuje liczbę pustych żądań i koszty.
Architektura asynchronicznego przetwarzania z SQS
Typowy wzorzec producer-consumer z kolejka SQS. Producenci wysylaja wiadomosci niezaleznie od konsumentow, a DLQ lapie problematyczne wiadomosci.
Porównanie Standard vs FIFO Queue
| Cecha | Standard Queue | FIFO Queue |
|---|---|---|
| Przepustowość | Praktycznie nieograniczona | Do 3000 msg/s (z batching) |
| Kolejność | Best-effort (może się zmienić) | Gwarantowana (FIFO) |
| Duplikaty | Możliwe (at-least-once) | Exactly-once delivery |
| Koszt | $0.40/mln żądań | $0.50/mln żądań |
| Nazwa kolejki | Dowolna | Musi kończyć się .fifo |
| Najlepszy dla | Wysoka przepustowość, tolerancja duplikatów | Transakcje, zamówienia, płatności |
Ile kosztuje Amazon SQS?
Standard Queue
Płacisz za liczbę żądań API (SendMessage, ReceiveMessage, DeleteMessage). Każde żądanie = 1 request.
$0.40 za milion żądań (po Free Tier)
FIFO Queue
Droższa, ale gwarantuje kolejność i exactly-once delivery. Rozliczanie per żądanie API.
$0.50 za milion żądań FIFO
Transfer danych
Transfer między SQS a serwisami AWS w tym samym regionie jest DARMOWY. Płacisz tylko za transfer między regionami.
$0.00 w obrębie regionu
Free Tier
1 milion żądań SQS miesięcznie - za darmo, permanentnie (nie wygasa po 12 miesiącach).
Wystarczy na mniejsze aplikacje produkcyjne
Przyklady AWS CLI
Utwórz kolejkę
Tworzy nową kolejkę Standard z 60s visibility timeout
aws sqs create-queue \
--queue-name moja-kolejka \
--attributes VisibilityTimeout=60Wyślij wiadomość
Wysyła wiadomość JSON do kolejki
aws sqs send-message \
--queue-url https://sqs.eu-central-1.amazonaws.com/123456789012/moja-kolejka \
--message-body '{"order_id": "12345", "action": "process"}'Odbierz wiadomości
Pobiera do 10 wiadomości z long polling (20s)
aws sqs receive-message \
--queue-url https://sqs.eu-central-1.amazonaws.com/123456789012/moja-kolejka \
--max-number-of-messages 10 \
--wait-time-seconds 20Quiz: Amazon SQS
Sprawdz czy dobrze rozumiesz podstawy. Kliknij odpowiedz — feedback pojawi sie od razu.
1. Jaki jest maksymalny rozmiar wiadomości w SQS?
2. Czym się różni Standard Queue od FIFO Queue?
3. Co to jest Dead Letter Queue?
Czesto uzywane razem z Amazon SQS
Czytaj więcej o Amazon SQS
Chcesz poznac Amazon SQS w praktyce?
Darmowy kurs "AWS od podstaw" pokazuje jak uzywac Amazon SQS krok po kroku. Teoria + praktyka od zera.