[kontra]

Siema! Mam rozkmine - mam aplikacje dzialajaca glownie na lambdach, SQS i SNS, calosc jest event based i stateless. Nie mam bazy danych ani nic, tylko przekladanie eventow z jednego miejsca w drugie.

Mam podstawowe mechanizmy do retry i failure handling (DLQ itd.) ale okazuje sie, ze musze dodac exponential backoff - w przypadku bledu chce miec mozliwosc ponownego przetworzenia eventu z opoznieniem np. 6h albo 24h. Niestety delivery delay wbudowane w SQS ma tylko max 15 minut opoznienia i wyglada na to, ze nie ma oczywistego mechanizmu na cos takiego.

Moge to zrobic przy uzyciu Dynamo, S3+Cron itd. ale bardzo chce tego uniknac, bo - tak jak pisalem - calosc nie ma zadnego stanu, zadnej bazy i chcialbym zeby tak zostalo, dlatego szukam rozwiazania czysto z uzyciem SQS albo czegos innego, co pozwoli zachowac stateless, event-based nature.

Ma ktos jakies pomysly jak do tego podejsc? Z gory dzieki.

#programowanie #aws

[mmichal]

przetworzenia eventu z opoznieniem np. 6h albo 24h.

zachowac stateless,

@kontra: zdecyduj się :) chcesz przechowywać czy chcesz stateless?

[K.....a]

@kontra: ile masz tych eventów dziennie? Proponuję by failure wysyłać do State Machine, i ona będzie się męczyła z tą wiadomością.
Czyli SQS dead letter, i ten dead letter będzie triggerować StateMachine.

[kontra]

@mmichal: wiesz o co chodzi ;) Nie chce zarzadzac stanem - tzn. wprowadzac do stacku bazy danych lub S3 gdzie odkladalbym eventy, a pozniej odzyskiwal.

[kontra]

ile masz tych eventów dziennie?

@Klopsztanga: ogolnie, czy tych konkretnych przypadkow?

Zreszta, problem w tym, ze nie wiem. Generalnie potrzebuje tego, zeby obsluzyc specificzny edge case, o ktorym wiem ze bedzie mial miejsce, ale nie wiem jak czesto, i nie dowiem sie, dopoki aplikacja nie bedzie na produkcji. A musimy to wprowadzic zanim wypuscimy to na produkcje ;) Powiedzmy, ze kilkaset dziennie.

[mmichal]

@kontra: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html

[K.....a]

@kontra: to w sumie statemachine wyjdzie niedrogo , bo 0.025$ za zmianę statusu maszyny.
Pokombinuj z statemachine zatem :) Tam możesz bawić się w dni

[kontra]

@mmichal: @Klopsztanga: dzieki. Dotychczas ze step functions nie bylo mi zbyt po drodze, moze raz albo dwa mialem do czynienia z bliska, wiec sie przyjrze ;)

[K.....a]

@kontra: i jak, zabawiłeś się z state machine?

[kontra]

@Klopsztanga: a jeszcze nie mialem czasu, dzisiaj koniec sprintu w firmie i duzo spotkan na glowie (z ktorych polowa moglaby byc emailami ( ͡° ͜ʖ ͡°) ). Dzisiaj albo jutro do tego siade. Ale najpierw mam inny, prostszy pomysl, ktory chce przetestowac, bez angazowania zadnych dodatkowych narzedzi.

[K.....a]

@kontra: jaki?

[kontra]

@Klopsztanga: Yh, ale wlasnie doczytalem ze raczej nie zadziala xD

Poprzez "reczne" zwiekszanie visibility timeout danej wiadomosci na SQS, czyli dodatkowych pare linijek kodu w lambdzie przed zwroceniem bledu. Tzn:
1. Lambda konsumuje wiadomosc z SQS
2. Mam blad, chce wiadomosc przetworzyc ponownie za godzine
3. W lambdzie zmieniam visibility timeout tej wiadomosci przy uzyciue ChangeMessageVisibility na 3600 (sekund)
4. Zwracam error w lambdzie
5. Wiadomosc ma visibility timeout godzine, wiec

[kontra]

@Klopsztanga: @mmichal: Podsumowanie - obeszlo sie bez step functions ;) Wystarczy zmienic message visibility timeout.

Ale dokumentacja mowi, ze max visibility timeout moze byc 12 godzin od momentu pojawienia sie wiadomosci na SQS.

Okazalo sie, ze zle przeczytalem dokumentacje - maksymalny visibility timeout moze byc 12 godzin od momentu otrzymania wiadomosci przez konsumenta (w moim przypadku - przez lambde). Oznacza to, ze za kazdym dostarczeniem (ie. za kazdym retry) moge