AWS oferuje zbiór niezwykle przydatnych narzędzi i rozwiązań. Potrafi też jednak zaskoczyć. W trakcie swojej prezentacji, Karol przedstawi kilka problemów na które natknął się w projektach, a które wzięły jego zespół z zaskoczenia. Skupi się też na tym, jak skutecznie sobie z nimi poradzić.
3. Iteracja 1
Projekt
● API Gateway uruchamiające Lambdę
● Lambda wywołująca i oczekująca synchronicznie
na wynik wywołania Step Function
● Step Function EXPRESS flow
○ 5 minut maksymalny czas trwania
○ do wywołań synchronicznych
● Dane pomiędzy krokami przechowywane w
DynamoDB
Problemy?
● Zimny start na krokach flow
● Maksymalny czas trwania połączenia na API
Gateway - 30 sekund
API Gateway + Step functions
C
o
m
o
g
ł
o
p
ó
j
ś
ć
n
i
e
t
a
k
?
5. Iteracja 3
Zmiana flow:
API Gateway + Step functions
Proponowane rozwiązanie:
Przerobienie projektu ;)
● Zrównoleglenie części kroków
● Usunięcie oczekiwania na odpowiedź platformy
AML (niepotrzebna nadgorliwość)
● Usunięcie kroku pobierania nazwy banku
6. Iteracja 3
Et Voilà! :)
API Gateway + Step functions
Proponowane rozwiązanie:
Przerobienie projektu ;)
Zmiana flow:
● Zrównoleglenie części kroków
● Usunięcie oczekiwania na odpowiedź platformy
AML (niepotrzebna nadgorliwość)
● Usunięcie kroku pobierania nazwy banku
8. Dane:
● AWS przechowuje kod lambd na S3
● Limit to 75GB / konto / region
● Każde opublikowanie lambdy to nowa wersja
● Liczba lambd x liczba bibliotek x liczba wersji =
Lambdy, wersjonowanie i przechowywanie kodu
Możliwości:
● Osobne konta AWS per środowisko (generalnie dobra praktyka)
● Brak wersjonowania lambd na środowiskach nie-produkcyjnych
● Korzystanie z warstw
● Okresowe czyszczenie starych wersji lambd (np. przy użyciu pluginu serverless-prune-plugin)
10. Case study
● Manager transakcji
● Początek transakcji -> kilka operacji wymagających atomowości ->
Zakończenie transakcji
● ZONK! Transakcji nie ma w DDB
DynamoDB i eventual consistency
Gdzie się podziała ta transakcja?
● Domyślnie odczyty są eventually consistent
● ConsistentRead: true Waszym przyjacielem
11. Co to TTL?
● Time To Live
● Oznaczenie elementu DDB do usunięcia
● DDB po przekroczeniu TTL usuwa rekord bez zużywania WCU
● Brak dodatkowych kosztów
DynamoDB i TTL
Where’s the catch?
● Elementy mogą być usunięte nawet do 48h po przekroczeniu TTL
● Do tego czasu nadal są widoczne w kwerendach
● Do momentu usunięcia mogą być edytowane (nawet samo TTL!)
12. Co z tym fantem zrobić?
● Świadome wykorzystanie
○ Usuwanie rekordów, które utraciły ważność
○ Porządkowanie tabel
● Używanie FilterExpression w Query/Scanach
DynamoDB i TTL
14. Przykład
● Zmiana wysokości oprocentowania na kontach
● Brak możliwości batchowej edycji kont w Mambu
● Ograniczona moc obliczeniowa / ilość obsługiwanych requestów po stronie
Mambu (429)
● Max concurrency nie działa dla Lambd triggerowanych przez SQS (bounce
back)
Lambdy triggerowane przez wiadomości na SQS
16. ● Jeśli lambda zakończyła błędem to wiadomość wraca na kolejkę
● To może prowadzić do nieskończonego przetwarzania wiadomości
● W skrajnych przypadkach poison-pill message
Lambdy triggerowane przez wiadomości na SQS
Jak do tego podejść?
● Dodanie DLQ z odpowiednim czasem życia
● Odpięcie triggera, zdrenowanie kolejki, podpięcie na nowo z DLQ
Błędy przetwarzania wiadomości przez lambdę
17. SQS pozwala publikować wiadomości o maksymalnej wielkości 256KB
Co wtedy?
Wrzucamy payload na S3 (max 2MB)
Lambdy triggerowane przez wiadomości na SQS
Ciekawostka
19. ● Sposób na zrównoleglenia przetwarzania kolekcji danych
● Podobne do Parallel, tylko różny input
Map w Step Functions
Na co uważać?
● Limit równoległych wywołań (domyślnie MaxConcurrency: 0)
● Dla MaxConcurrency > 40 mogą wystąpić ograniczenia wywoływań
● Ryzyko DoS zależnych serwisów