Nowości Serverless po AWS re:Invent 2019


Nowości Serverless po AWS re:Invent 2019

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

Nowość Link
Announcing improved VPC networking for AWS Lambda functions https://aws.amazon.com/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
AWS Lambda Supports Amazon SQS FIFO (First-In-First-Out) as an Event Source https://aws.amazon.com/about-aws/whats-new/2019/11/aws-lambda-supports-amazon-sqs-fifo-event-source/
New – Convert Your Single-Region Amazon DynamoDB Tables to Global Tables https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/
Announcing Amazon CloudWatch ServiceLens https://aws.amazon.com/about-aws/whats-new/2019/11/announcing-amazon-cloudwatch-servicelens/ https://aws.amazon.com/blogs/aws/visualize-and-monitor-highly-distributed-applications-with-amazon-cloudwatch-servicelens/
AWS Lambda Now Supports Maximum Event Age and Maximum Retry Attempts for Asynchronous Invocations https://aws.amazon.com/about-aws/whats-new/2019/11/aws-lambda-supports-max-retry-attempts-event-age-asynchronous-invocations/
AWS Lambda Supports Destinations for Asynchronous Invocations https://aws.amazon.com/about-aws/whats-new/2019/11/aws-lambda-supports-destinations-for-asynchronous-invocations/ https://aws.amazon.com/blogs/compute/introducing-aws-lambda-destinations/
następnie przyszła pora na te najciekawsze bo ogłaszane w trakcie sesji (wykłady).

Ogłoszenia w trakcie re:Invent

Nowość Link
Introducing Amazon EventBridge schema registry and discovery – In preview https://aws.amazon.com/blogs/compute/introducing-amazon-eventbridge-schema-registry-and-discovery-in-preview/
Lambda Provisioned Concurrency https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions
AWS Step Functions Express Workflows: High Performance & Low Cost https://aws.amazon.com/blogs/aws/new-aws-step-functions-express-workflows-high-performance-low-cost
Amazon RDS Proxy https://aws.amazon.com/about-aws/whats-new/2019/12/amazon-rds-proxy-available-in-preview/ https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/
Announcing HTTP APIs for Amazon API Gateway - (Preview) https://aws.amazon.com/blogs/compute/announcing-http-apis-for-amazon-api-gateway/
Amplify DataStore – Simplify Development of Offline Apps with GraphQL https://aws.amazon.com/blogs/aws/amplify-datastore-simplify-development-of-offline-apps-with-graphql/
Introducing Amplify for iOS and Android https://aws.amazon.com/about-aws/whats-new/2019/12/introducing-amplify-for-ios-and-android/
Razem trzynaście dużych nowości. Poniżej krótkie podsumowanie wybranych z nich.

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

  1. Zdarzenie wywołujące jest umieszczane na wewnętrznej kolejce (należącej do AWS)
  2. Osobny proces czyta te zdarzenia z kolejki i uruchamia funkcje w naszym imieniu
  3. 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!

Improved VPC networking for AWS Lambda functions

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.