Visibility Timeout, DLQ i long polling

Gdy konsument odbiera komunikat z SQS, komunikat zostaje ukryty przed wszystkimi innymi konsumentami na okres nazywany limitem czasu widoczności. W tym czasie konsument przetwarza komunikat, a następnie go usuwa. Jeśli konsument ulegnie awarii albo nie zakończy przetwarzania na czas, limit czasu widoczności wygaśnie, a komunikat stanie się ponownie widoczny, dzięki czemu będzie mógł go pobrać inny konsument. To podstawowy mechanizm gwarancji dostarczania co najmniej raz w SQS.

Domyślny limit czasu widoczności wynosi 30 sekund. Można go ustawić w zakresie od 0 sekund do 12 godzin. Należy ustawić go tak, aby z bezpiecznym zapasem przekraczał maksymalny przewidywany czas przetwarzania — jeśli przetwarzanie trwa do 2 minut, limit należy ustawić na co najmniej 3–4 minuty. Limit można również zmienić dla konkretnego uchwytu odbioru za pomocą change-message-visibility, co jest przydatne, gdy konsument wykryje, że potrzebuje więcej czasu na przetworzenie określonego komunikatu.

Ustawienie limitu czasu zbyt krótko powoduje ponowne pojawienie się komunikatów, zanim konsument zakończy przetwarzanie, co prowadzi do wielokrotnego przetwarzania. Ustawienie go zbyt długo opóźnia przejęcie komunikatu przez innego konsumenta, jeśli pierwotny konsument ulegnie cichej awarii (np. w wyniku awarii instancji EC2 bez prawidłowego sprzątania). Optymalny limit czasu powinien być nieco dłuższy niż czas przetwarzania dla 99. percentyla, ale jednocześnie na tyle krótki, aby umożliwić szybkie odzyskanie po awarii konsumenta. Należy monitorować metrykę CloudWatch ApproximateNumberOfMessagesNotVisible, aby wykrywać problemy z limitami czasu.

Dead-Letter Queue (DLQ) to osobna kolejka SQS, do której komunikaty są wysyłane po nieudanym przetworzeniu konfigurowalną liczbę razy (maxReceiveCount). Gdy liczba odebrań komunikatu przekroczy maxReceiveCount, SQS automatycznie przenosi go do DLQ. Kolejki DLQ zapobiegają blokowaniu kolejki w nieskończoność przez komunikaty zatruwające (komunikaty, których przetwarzanie zawsze kończy się niepowodzeniem). Komunikaty w DLQ można sprawdzać, debugować i ponownie odtwarzać po naprawieniu błędu przetwarzania.

DLQ jest po prostu zwykłą kolejką SQS (Standard dla źródła Standard, FIFO dla źródła FIFO). W kolejce źródłowej należy skonfigurować zasadę ponownego kierowania (Redrive Policy), określając kolejkę DLQ oraz próg maxReceiveCount. Należy upewnić się, że okres przechowywania w DLQ jest dłuższy niż okres przechowywania w kolejce źródłowej — komunikaty trafiają do DLQ z opóźnieniem i potrzebny jest czas na ich zbadanie, zanim wygasną.

Należy ustawić alarm CloudWatch dla metryki ApproximateNumberOfMessagesVisible kolejki DLQ. Każdy komunikat trafiający do DLQ wskazuje na błąd przetwarzania wymagający uwagi. Alarm należy skonfigurować tak, aby wywoływał powiadomienie SNS i natychmiast powiadamiał inżyniera dyżurnego. Każdy komunikat w DLQ należy traktować jak błąd wymagający zbadania — komunikaty DLQ nie powinny gromadzić się niezauważone. Po naprawieniu błędu należy użyć funkcji DLQ Redrive, aby wysłać komunikaty z powrotem do kolejki źródłowej w celu ponownego przetworzenia.

Po naprawieniu błędu powodującego niepowodzenia przetwarzania należy użyć funkcji SQS DLQ Redrive, aby przenieść komunikaty z DLQ z powrotem do kolejki źródłowej w celu ponownego przetworzenia. Konsola udostępnia wbudowaną funkcję redrive. Można filtrować komunikaty według ich atrybutów, aby ponownie odtworzyć tylko wybrane komunikaty. Alternatywnie można napisać funkcję Lambda, która będzie odpytywać DLQ i przekazywać komunikaty z powrotem do kolejki źródłowej, jeśli potrzebna jest niestandardowa logika filtrowania.

Domyślnie SQS używa krótkiego odpytywania: wywołanie receive-message sprawdza losowy podzbiór serwerów i natychmiast zwraca wynik — nawet jeśli nie ma dostępnych komunikatów. Skutkuje to dużą liczbą pustych odpowiedzi i marnowaniem wywołań API. Długie odpytywanie czeka do 20 sekund na pojawienie się komunikatu, zanim zwróci pustą odpowiedź. Długie odpytywanie znacznie obniża koszty (mniej wywołań API) i zmniejsza opóźnienia (komunikat jest odbierany natychmiast po pojawieniu się, nawet do 20 sekund wcześniej niż w następnym cyklu odpytywania).

Długie odpytywanie można włączyć na poziomie kolejki (dotyczy wszystkich wywołań odbierania) albo dla pojedynczego żądania. Konfiguracja na poziomie kolejki z wartością ReceiveMessageWaitTimeSeconds równą 20 jest zalecanym ustawieniem dla większości aplikacji. Gdy Lambda używa SQS jako źródła zdarzeń, automatycznie korzysta z długiego odpytywania. W przypadku konsumentów opartych na EC2 należy ustawić WaitTimeSeconds w wywołaniu receive-message.

Komunikaty SQS mogą zawierać atrybuty komunikatów — metadane w postaci par klucz-wartość, niezależne od treści komunikatu. Atrybuty mają typ (String, Number, Binary) i wartość. Gdy SQS jest subskrybentem tematu SNS, można używać zasad filtrowania subskrypcji SNS stosowanych do atrybutów komunikatów, aby kierować do każdej kolejki tylko odpowiednie komunikaty. Bez filtrowania każdy subskrybent SQS otrzymuje każdą publikację SNS, niezależnie od jej treści.

Kolejka opóźnień sprawia, że każdy nowy komunikat staje się niewidoczny na określony czas (od 0 do 15 minut) po wysłaniu. Jest to przydatne w przepływach pracy, w których konsument nie powinien przetwarzać komunikatu natychmiast — na przykład gdy najpierw trzeba zaczekać na zakończenie zależnego procesu. Można również ustawić opóźnienie dla pojedynczego komunikatu za pomocą parametru DelaySeconds w wywołaniu wysyłania, co zastępuje opóźnienie ustawione na poziomie kolejki. Uwaga: kolejki opóźnień nie są dostępne dla kolejek FIFO.

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

W tej lekcji nauczyli się Państwo, że: Visibility Timeout ukrywa wiadomość przed innymi konsumentami na czas przetwarzania, umożliwiając dostarczanie co najmniej raz i automatyczne ponowne dostarczenie, jeśli konsument ulegnie awarii; Dead-Letter Queues przechowują wielokrotnie kończące się niepowodzeniem wiadomości, aby można je było debugować i ponownie odtworzyć po naprawieniu błędu; a Long Polling (czas oczekiwania do 20 sekund) zmniejsza koszty API i opóźnienia w porównaniu z krótkim odpytywaniem. W następnej części omówimy tematy SNS i architekturę fan-out.