AWS re:Invent to największa konferencja poświęcona chmurze Amazon Web Services na świecie. Co roku ściąga do Las Vegas rekordowe ilości specjalistów, w tym roku było to około 65 tysięcy osób!
Poza skalą, szałowym miejscem (Vegas Baby 😎) i przytłaczającą ilością sesji: ponad 3000 wykładów, warsztatów i spotkań, re:Invent jest znany z przytłaczającej ilości ogłoszeń lub zapowiedzi nowy usług bądź funkcjonalności w już istniejących.
Nie inaczej było i w tym roku. Po prawdzie, to nawet przed samą imprezą, która trwała w dniach 2-6 grudnia 2019, ogłoszonych zostało wiele ciekawych rzeczy.
TL; DL;
Nie masz czasu? Zejdź na sam dół do mojego podsumowania, kliknij tutaj.
Nowości Serverless
W tym podsumowaniu zebrałem najważniejsze nowości w dziedzinie serverless, oczywiście w chmurze AWS.s
Ogłoszenia przed re:Invent
Ogłoszenia w trakcie re:Invent
CloudWatch ServiceLens
Nowa usługa z kategorii obserwowalności, czyli narzędzie do szeroko rozumianego monitoringu.
Podobnie jak AWS X-Ray tworzy mapy wywołań i przepływu pomiędzy serwisami, ale dodatkowo agreguje informacje z metryk i przedstawia je w bardzo wygodnej formie. (Patrz obrazek po prawej stronie)
Maximum Event Age & Maximum Retry Attempts
Funkcje, które ustawiamy jako asynchroniczne przez AWS są obsługiwane w następujący sposób
- Zdarzenie wywołujące jest umieszczane na wewnętrznej kolejce (należącej do AWS)
- Osobny proces czyta te zdarzenia z kolejki i uruchamia funkcje w naszym imieniu
- W przypadku wystąpienia błędu w funkcji Lambda, zdarzenia wraca do kolejki i zostanie znów przeprocesowane.
Maksymalnie dwukrotnie może zostać ponowione wywołana Lambda tym samym zdarzeniem (razem 3 razy)
Do tej pory nie mogliśmy sterować tym mechanizmem. To się zmieniło:
- Maximum Retry Attempts - Można ustawić od 0 do 2
- Maximum Event Age - Od 60 sekund do 6 godzin (default)
AWS Lambda Destinations
Funkcje Lambda mają służyć transformacji danych, a nie ich przenoszeniu z miejsca A do B. To jedna z ważniejszych myśli jakie, moim zdaniem, Chris Munns przekazał w trakcie swojej sesji.
Zgodnie z tym pryncypium zostały wprowadzone Lambda Destinations.
Tylko przy asynchronicznych wywołaniach
- Przekazuje wynik funkcji w miejsce docelowe (destynacja) bez konieczności pisania kodu transportującego
- Przekazuje informacje o błędzie funkcji w miejsce docelowe (destynacja)
- Informacje o parametrach wejściowych
- Zawiera więcej informacji niż DLQ (Dead Letter Queue)
Provisioned Concurrency for Lambda Functions
Przeciwdziała cold-startom
- Możemy zdefiniować ilość instancji tej samej funkcji Lambda, które mają być gotowe do działania (rozgrzane)
- Płacimy za czas działania tych funkcji w stanie gotowości!
- Możemy dynamicznie zmieniać ilość rozgrzanych funkcji (analogicznie jak auto-scaling w EC2 – lag około 2 min.)
- Od utylizacji na poziomie 85% zaczyna być tańsze niż zwykły model („on demand”)
Poniższy wykres pokazuje tzw. long-tail czasów wywołania funkcji Lambda. To zjawisko jest powszechne i występuje nie tylko w przypadku Lambd. Chodzi o to, że zdarzają się żądania, które występują rzadko ale trwają bardzo długo. Jak widać na wykresie (niebieskie słupki) 90% wywołań zajmuje nie więcej niż 450 milisekund, natomiast pozostałe 10% dobija prawie do 2 sekund! Ten problem rozwiązuje Provisioned Concurrency.
Jest to oczywiście lepsze rozwiązanie niż dotychczas (sztuczny ruch rozgrzewał funkcje, ale je też wykonywał). Niestety trochę odchodzi od idei pay-as-you-go bo się deklarujemy ile użyjemy
*Amazon RDS Proxy *
To pula połączeń do bazy RDS zarządzania przez AWS
- Eliminuje problem wysycenia połączeń
- Zwiększa skalowalność aplikacji serverless korzystających z relacyjnych baz
- Połączenia TCP, na razie tylko MySQL i Aurora (MySQL)
Jak to działa?
Test przeprowadzony na bazie Aurora, 30 wirtualnych użytkowników, każdy wysyła 300 żądań, wykonany poleceniem artillery quick --count 300 -n 30 https://enpoint-api-gw....
| Bezpośrednio do bazy | Przez RDS Proxy |
|---|---|
| Przed testem: 18 połączeń Max w czasie testu: 124 połączenia |
Przed testem: 18 połączeń Max w czasie testu: 43 połączenia |
| Źródło: https://qiita.com/G-awa/items/b9138cc1c9e4867a905e |
Jak widać RDS Proxy pozwala blisko trzykrotnie ograniczyć ilość otwartych połączeń do bazy, co jest znakomitym wynikiem.
Improved VPC networking for AWS Lambda functions
To jest dosyć stary news, ale wart przypomnienia. Dzięki optymalizacji urządzeń sieciowych w VPC, AWS udało się zmniejszyć cold-start Lambd w VPC z 14 sekund do niecałej sekundy. Dzięki czemu korzystanie z tego typu rozwiązania zaczyna mieć sens również przy synchronicznych wywołaniach!
HTTP APIs for Amazon API Gateway
Kolejny, zupełnie nowy, typ API Gateway obok trzech już istniejących:
- REST API
- REST API Privet
- WebSocket APIs
- HTTP API
Mniejszy koszt:
- Cena spada z $3.50 za milion żądań do $1
- 70% taniej dla większości klientów - tak twierdzi AWS
Szybsze działanie”
- „50% latency reduction” - znów wypowiedź AWS.
HTTP API jest zoptymalizowane pod względem wydajności. Natomiast oferuje ograniczoną funkcjonalność względem REST API:
- tylko proxy
- Brak własnych autoryzatorów (custom authorizer)
- Ale jest wsparcie dla JWT
Podsumowanie
Osobiście jestem zdania, że wśród wielu nowości największe znaczenie ma nowe HTTP API w usłudze API Gateway zapewniające nawet do 70% oszczędności i o około połowę mniejsze opóźnienia w stosunku do REST API.
Drugą równie ważną nowością jest wprowadzenie usługi RDS Proxy, która jest zarządzaną przez AWS pulą połączeń do relacyjnych baz danych w RDS. Wraz z likwidacją cold startów w VPC, która miała miejsce we wrześniu, otwiera bardzo dużo możliwości budowy systemów serverless integrujących się z istniejącymi relacyjnymi bazami danych, których przecież jest najwięcej na świecie. To na pewno przyczyni się do jeszcze większej adopcji serverless przez firmy, gdyż nie będą musiały rezygnować z technologii (SQL), która im towarzyszy od dziesięcioleci.
