Cześć!

Czy wiesz co to jest awizo? Czy zdarzało Ci się negocjować z kurierem, który stał pod Twoim mieszkaniem, a Ciebie nie było? No właśnie, to wiesz co to Dead Letter - to do przeczytania za tydzień!

W dzisiejszych czasach większość z nas jest w stanie instynktownie powiedzieć, że kolejki warto używać gdy chcemy mieć pewność, że nasza wiadomość zostanie dostarczona. Używając z nich mamy zwykle do czynienia z “eventual consistency”. Niektórzy mówią z “opóźnieniem” - co jest jak mówią politycy - “minięciem się z prawdą”. Eventual consistency nie oznacza wcale, że wiadomość będzie dostarczona później - oznacza, że nie mamy pewności kiedy będzie dostarczone. Słowo klucz - asynchroniczność. Zwykle jest to niewolniej niż synchronicznie - często szybciej. No ale nie o tym dzisiaj.

Tak jak już wspomniałem, wiemy że użycie kolejek - oznacza większą odporność na błędy. Serwis padł, nie ważne - wstanie i odbierze sobie wiadomość. Kolejki mają mechanizm ponowienia. Tak jak kurier, zwykle idzie się z nim dogadać. Jak akurat wyszliśmy, nas nie było to dostarczy nam później, albo jutro. No chyba, że nie. Zdarza się tak, że nie idzie się z kurierem spotkać. Albo nam za każdym razem coś wypada, albo kurier leci w kulki.

Co się wtedy dzieje? Wtedy nasza paczuszka trafia do magazynu. Ciągle możemy ją jeszcze jakiś czas odebrać. Co prawda trochę nas to kosztuje, bo musimy jechać na jakieś zadupie, gdzie zlokalizowany jest taki magazyn. Jest to dosyć kłopotliwe - ale się udaje.

No chyba, że nie.

Jeśli grzebiemy się dalej, to paczka po jakimś czasie znika z magazynu i już jej odebrać nie możemy (no chyba, że nadawca nam ją ponownie wyśle).

Tak samo działają kolejki. To nie jest tak, że one magicznie zawsze nam wysłaną wiadomość dostarczą. Mają zwykle mechanizmy ponowienia - spróbują wiadomość kilka razy dostarczyć, ale jak się nie uda to w końcu przestaną próbować. Co się wtedy stanie? Zwykle można to porównać do kuriera, który nie mogąc się z nami dogadać, mówi “no i ch, to wywalam do śmietnika!“. Tak właśnie robią kolejki, zwykle wtedy taka wiadomość zostaje po prostu wyrzucona. Nawet te z pamięcią jak Kafka, Kinesis i podobne. Jak sobie u nich ta wiadomość poleży ale nie uda jej się dostarczyć to w zależności od konfiguracji “retention policy” w końcu ją usuną.

Co wtedy? Zwykle kolejki nie są tak miłe jak listonosz z poczty. Nie zostawiają nam śladu po tym, że wiadomość została usunięta - nie ma awizo.

Sporo systemów messagingowych wspiera jednak taki “czyściec” - magazyn ze wcześniejszego przykładu. Jeśli wiadomość nie uda się dostarczyć maksymalną liczbą powtórzeń to wiadomość wpada właśnie na “Dead Letter Queue”. Jest to po prostu inna kolejka, postawiona z boku gdzie wpadają wiadomości, które nie udało się dostarczyć.

Po co mielibyśmy to robić? Po to, żeby mieć ślad, że jakieś wiadomości zostaną “zgubione”. Mając taką wiedzę jesteśmy w stanie coś z nimi zrobić. Co np.?

1. Monitorować i oceniać skuteczność dostarczenia i wyciągać wnioski - np. poprzez metryki oceniać SLA.
2. Otrzymać powiadomienie- np. na slacka, maila, itd.
3. Odnajdywać dzięki temu wąskie gardła i problematyczne miejsca w systemie.
4. Przepuścić te wiadomości jeszcze raz - bo np. wiemy, że nasz serwis odbiorca miał błąd, wdrożyliśmy nową wersję i chcemy spróbować jeszcze raz.
5. Podjąć akcję korekcyjną - np. anulować proces biznesowy. Możemy przyjąć, że np. jeśli nie udało się wykonać operację kilka razy to znaczy, że już się więcej nie uda.

“No to pięknie, to idę używać!”

Śmiało, ale najpierw jeszcze proszę doczytaj do końca. Jakie można popełnić błędy:

1. Definiowanie DLQ dla zasady i nic więcej - wiele razy spotkałem się z sytuacją gdy widziałem, że ktoś definiował DLQ i gdy pytałem się “no ale co z tymi wiadomościami zrobisz? Jaka jest Twoja strategia na jej obsługę”. Odbpowiedź bardzo często brzmiała “No nie wiem, może się potem przyda. Będziemy mogli do niej patrzeć.”. No więc nie będziecie. Jeśli nie mamy strategii co z tym zrobić to zapewniam, że nikt sam z siebie tam nie wejdzie i nic z tym nie zrobi. Będzie to tylko marnowanie zasobów.
2. Brak definicji metryk i powiadomień - tak jak napisałem powyżej, nikt nie będzie sam z siebie monitorował DLQ. Jeśli chcemy wiedzieć, że coś się złego dzieje to musimy zdefiniować metryki, a na ich podstawie powiadomienia. Jeśli już to robimy to przemyślmy to dobrze. Nie ma nic bardziej demotywującego niż kanał na slacku gdzie wpada co chwile informacja o błędzie, że coś nie działa. To jak z testami i buildami w systemie CI. Jeśli są ciągle czerwone to w końcu każdy zaczyna je olewać.
3. Zakładanie, że jak dostanę powiadomienie to ktoś wejdzie i przepuści te zdarzenia ręcznie - DLQ zwykle są średnio wygodne w użyciu, wcale nie jest łatwo wrzucić wiadomości czasem z powrotem do procesowania. Jeśli dobrze nie przemyślimy automatyzacji to będzie ciężko. Pamiętajmy, że jeśli co chwilę będziemy musieli diagnozować DLQ to zamiast programować będziemy tylko to robić. Spróbujmy zrobić np. akcje korekcyjne - np. anulowanie procesu. Zróbmy dobre alerty - np. ustalmy jaka ilość “zgubionych wiadomości” jest dla nas akceptowalna, bo ilu znaczy, że nasz system leży i musimy wejść zainterweniować.

Tak, nawet jeśli użyjemy systemy streamingowe jak Kafka, jak mamy DLQ musimy pamiętać, że wiadomość może nie zostać dostarczona. Wbrew marketingowi - dostarczenie wiadomości “dokładnie raz” jest praktycznie niemożliwe, “co najmniej raz” niełatwe. Pisałem o tym już we wcześniejszym mailu “Jak nie zgubić zdarzenia, czyli wzorce Outbox i Inbox” - https://oskar-dudycz.netlify.app/pl/jak_nie_zgubic_zdarzenia_czyli_outbox_i_inbox_w_praktyce/ (tak jak pisałem tydzień temu - przedpremierowo udostępniam Ci już częściowe archiwum newslettera).

Zobacz również:

• Gregor Hohpe - Starbucks Does Not Use Two-Phase Commit - https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html,
• Marc de Graauw - Nobody Needs Reliable Messaging - https://www.infoq.com/articles/no-reliable-messaging/.

Także podstawa taka jak zawsze: pragmatyzm. Analiza scenariusza biznesowego. Myślenie o tym co może pójść nie tak i ocena tego ryzyka. Znając to możemy ocenić czy i jak na to reagujemy. DLQ dają dużo nowych opcji. W najgorszym razie będą dla nas takim awizo, czyli powiedzą nam, że wiadomości do nas nie doszły. Możemy wtedy zareagować, albo chociaż świadomie je zignorować.

Co o tym sądzisz? Używasz w swojej pracy Dead Letter Queue? Jak je obsługujesz?

Dziękuję za przeczytanie!

Oskar