W dzisiejszym wpisie postaram się Wam przybliżyć jedną z najbardziej rozpoznawalnych usług cloudowych z portfolio AWS. Mowa o Serverlessowym rozwiązaniu AWS Lambda. Bezapelacyjnie Lambda to usług, która miała bardzo duży wpływ no rozwój technologi Serverless. Oficjalnie, Lambda została zaprezentowana światu już w 2014 roku i od tej pory przecierała szlaki w dziedzinie rozwiązań typu FaaS. Dopiero w późniejszych latach, inni duzi vendorzy zaczęli rozwijać i prezentować swoje analogiczne rozwiązania m.in. Google Cloud Functions czy Azure Functions. Obecnie Lambda jest najpopularniejszym i najczęściej wybieranym rozwiązaniem Serverless ze względu na największą dojrzałość i możliwości. Właśnie dlatego jej przedstawienia i opisu nie mogło zabraknąć tutaj na blogu.
Koncepcja AWS Lambda
AWS Lambda to bezserwerowa usługa obliczeniowa pozwalająca na uruchamianie kodu bez jakiejkolwiek ingerencji w administrowanie i zarządzanie serwerami. Zgodnie z ideą Serverless nie musimy nawet deklarować jak duże obciążenie i ruch ma obsługiwać kod naszej logiki biznesowej. Napisane przez nas funkcje hostujemy w AWS i to właśnie vendor odpowiada za ich uruchomienie, obsługę i skalowanie. Funkcję są sterowane zdarzeniami – event driven. Gdy nasza Lambda jest już utworzona, określamy jakie zdarzenie będzie powodowało jej wykonanie. Może to być żądanie HTTP wywołane za pośrednictwem usługi API Gateway, bądź pojawienie się nowego pliku w buckecie na AWS S3.
Ile płacimy za AWS Lambda ?
Jedną z najważniejszych zalet Lambdy jest jej model rozliczeniowy Pay-as-you-go. Płacimy tylko i wyłącznie za czas, w którym nasza funkcja jest wykonywana. Załóżmy, że nasza Lambda wykonywana byłby co minutę, a czas jej trwania wynosiłby 2 sekundy Przy zaalokowaniu 1 GB pamięci dla funkcji, nasz miesięczny rachunek oscylowałby w granicy 1,45 $. Pod tym linkiem, możecie sami sprawdzić i wyliczyć koszty dla Lambdy.
Zastosowanie AWS Lambda
Bardzo wiele usług AWS posiada możliwość integracji z Lambdą, dzięki czemu zastosowanie Lambdy może być bardzo wszechstronne. Może ona służyć jako element scalający usługi, które w bezpośredni sposób są niemożliwe do zintegrowania. Przykładowo usługa nierelacyjne bazy danych DynamoDb jest w stanie wyemitować zdarzenie pojawienia się nowego rekordu w tabeli. Za pomocą Lambdy możemy zareagować na takie zdarzenie. Obsługą takiego zdarzenia może być np. dodanie wpisu w innej nierelacyjnej bazie AWS RDS (Relational Database Service) albo wysyłanie notyfikacji mailowej przy pomocy AWS SES (Simple Email Service). Takich piplajanów zdarzeniowych przy użyciu Lambdy i innych usług możemy tworzyć niezliczone ilości. Lambdę możemy w tym przypadku porównać do kleju, który w elastyczny sposób potrafi zintegrować masę innych usług AWS jak i również systemów zewnętrznych.
Innym bardzo często wykorzystywanym przypadkiem użycia Lambdy jest budowanie API. Dzięki wykorzystaniu Lambdy w połączeniu z usługą API Gateway jesteśmy w stanie zbudować pełnoprawne REST-owy serwis. W przypadku takiego podejścia nasz wskaźnik TTM (Time To Market) będzie niebywale korzystny. Od samego początku bowiem, jako deweloper możemy poświęcić 100% uwagi na implementację logiki biznesowej. Nie musimy w tym przypadku spalać cennego czasu na infrastrukturę i konfigurację środowiska. Dodatkowo nasze rozwiązanie z paczki jest w pełni skalowalne i wysoce dostępne. Koszt takiego rozwiązania również będzie zdecydowanie bardziej optymalny niż w przypadku tradycyjnego podejścia serwerowego.
Uruchamianie funkcji Lambda
Z punktu widzenia infrastruktury Lambda jest odizolowanym, efemerycznym kontenerem posiadającym przydzielone zasoby takie jak pamięć czy CPU. W kontenerze tym, uruchomiony jest system operacyjny Amazon Linux ze wszystkimi niezbędnymi narzędziami oraz środowiskiem programistycznym (np. Node.js) umożliwiające odpalenie naszego kodu. Jeśli chodzi o kod naszej funkcji, to jest on przechowywany przez AWS w usłudze S3. Za każdym razem gdy funkcja Lambda jest wywoływana, AWS inicjalizuje dla nas kontener funkcji i w nim instaluje nasz kod źródłowy. Proces tworzenia nowej instancji, jak się można domyślać jest kosztowny w czasie. Częstym przypadkiem jest, że przygotowanie Lambdy trwa dłużej niż wykonanie jej kodu. Warto jednak podkreślić, że czas potrzebny na zainicjalizowanie Lambdy nie wlicza się w czas, za który jesteśmy chargowani.
Cold start vs Warm start w Lambdzie ?
Wspomniałem, że każde wywołanie – event, na który nasłuchuje Lambda tworzy nową instancję funkcji. Tutaj jednak powinna pojawić się gwiazdka. Instancja funkcji Lambda, może obsługiwać jednocześnie tylko jedno żądanie. Skalowanie wygląda w ten sposób, że w przypadku pojawienia się kilku żądań jednocześnie, AWS inicjalizuje dla każdego żądania odrębną funkcję Lambda, aby móc obsłużyć ruch równolegle. Gdy Lambda kończy swoje wykonywanie, jej kontener nie jest jednak od razu ubijany. Mam on bowiem możliwość obsłużenia kolejnego żądania, jeśli owe się pojawi. Dzięki takiemu rozwiązaniu, funkcje Lambda nie muszą być każdorazowo inicjalizowane. Mówimy, że mamy wtedy do czynienia z rozgrzaną funkcją albo z warm startem. Szacuje się, że funkcja Lambda pozostaje w rozgrzanym trybie nie dłużej niż 5 minut (w trybie No-VPC), po tym czasie kontener funkcji zostaje permanentnie ubity i do obsługi kolejnego żądania wymagana będzie jego ponowna inicjalizacja. Takie uruchomienie Lambdy, które wymaga pełnej inicjalizacji środowiska nazywane jest cold startem. Poniższy rysunek obrazuje ten proces.
Bezstanowość funkcji Lambda
Istotną specyfiką funkcji Lambda jest bezstanowość. W praktyce oznacza to, że funkcja nie może wykorzystywać swojego wewnętrznego stanu do zapisu czy odczytu wartości. Inaczej mówiąc nie mamy możliwości przekazywania danych między poszczególnymi wywołaniami funkcji Lambda. Tak jak sobie wcześniej powiedzieliśmy, kontener funkcji Lambda jest tymczasowy i krótkotrwały. Z punktu widzenia naszego kodu, musimy uznać, że każde uruchomienie naszej funkcji jest wykonywane na zupełnie nowym środowisku, kropka.
Podobnie jest z przestrzenią dyskową, do której każda Lambda ma odstęp (domyślnie 512MB w katalogu /tmp). Tej przestrzeni również nie wykorzystamy to współdzielenia zasobów między odrębnymi wywołaniami Lambdy. Jedynym drogą do współdzielenia stanu między funkcjami Lambda jest wykorzystanie innych usługa AWS np. S3, DynamoDb, ElastiCache. Bez problemu możemy zapisać plik na S3 lub wartość w bazie danych podczas wywołania funkcji, a już w kolejnym wywołaniu odczytać ten zasób.
Środowisko uruchomieniowe AWS Lambda
Lambda do pisania kodu funkcji oferuje wiele platform językowych. Pod tym kątem wyróżnia się na tle swoich głównych konkurentów Azure Functions czy Google Functions . Do wyboru mamy następujące środowiska programistyczne.
Lambda dla wszystkich z wyżej wymieniony środowisk zapewnia pełne wsparcie w postaci aktualizacji, poprawek bezpieczeństwa czy utrzymania. W przypadku gdy wspierane przez AWS platformy nas nie satysfakcjonują mamy również możliwość dostarczenia własnej implementacji runtimu. W tym przypadku jednak to my sami musimy zadbać o wszystkie rzeczy związane z utrzymaniem i aktualizacją środowiska uruchomieniowego. Wiele customowych runtimów takich jak Haskell, Elixir czy nawet Cobol, została udostępniona przez parterów AWS, bądź przez community open source.
Raporty, między innymi State of Serverless opublikowany ostatnio przez Data Dog pokazują, że obecnie najczęściej używanymi platformami są Node.js oraz Pythona.
Podsumowanie
Mam nadzieje, że w sposób jasny udało mi się przybliży Ci koncepcje oraz podstawowe zagadnienia związane z funkcjami Lambda. Aspekty takie jak cold start czy bezstanowość są zazwyczaj uniwersalne i mają zastosowanie w innych rozwiązaniach typu FaaS. Myślę, że po tym wstępie teoretycznym dużo łatwiej będzie Ci zrozumieć specyfikę pracy z Lambdą. W kolejnej części wpisu poświęconego tej usłudze przedstawię jak stworzyć i uruchomić Lambdę w infrastrukturze AWS oraz pokaże jak łatwo może ona integrować się z innymi usługami. Do usłyszenia !
