Co to jest cold start Lambdy? Wyjaśnię Ci go w 4 minuty

Jeśli przeczytałeś(aś) punkt siódmy z mojego poradnika 12 Rzeczy o Serverless, Które Musisz Wiedzieć Przed Rozpoczęciem Projektu W Chmurze AWS to na pewno masz już rozeznanie w czym problem. Jednak dla jasności przybliżę go jeszcze raz.

Skąd bierze się cold start / zimny start

Jak wiemy funkcja AWS Lambda jest uruchamia w następstwie zdarzenia (żądanie http, upload pliku, nadejście wiadomości, harmonogram itp.). Zanim to zdarzenie nastąpi funkcja nie istnieje w stanie aktywnym, jest tylko kodem źródłowym (bądź binarnym) oraz konfiguracją, którą wgraliśmy do usługi. Zdarzenie wywołujące inicjalizuje proces, którego celem jest pozyskanie i skonfigurowanie niezbędnych zasobów w celu uruchomienia Twojego kodu.

Uogólniając, AWS musi przydzielić nowy kontener i wgrać tam kod źródłowy lub skompilowaną wersje binarną Twojej funkcji wraz z bibliotekami, a następnie zainicjalizować wywołanie tego kodu (przekazać zdarzenie jako parametr do funkcji). To wszystko trwa.

Bez względu na to jaki język programowania wybierzesz ta procedura zawsze jest taka sama.

Ile trawa cold start?

Tak prezentują się aktualne czasy cold startu dla różnych języków, (rok i dwa lata temu były zupełnie inne; widać, że AWS ciągle nad nimi pracuje). Ciemniejsze fragmenty słupków pokazują typowe czasy startów - statystycznie 67% funkcji ładuje się w tym czasie. Przykładowo dla JavaScript to będzie przedział między 150 a 250 milisekund.

Źródło: https://mikhail.io/serverless/coldstarts/aws/

Co jeszcze wpływa na cold start?

• Wielkość przydzielonej pamięci dla funkcji lambda
• Wielkość naszego kodu (w tym bibliotek, których używamy)
• To czy lambda jest deployowana w VPC (aby np. mieć dostęp do RDS)

Niestety, cold start zawsze występuje, wynika to z budowy tej usługi. Natomiast czasem może być pomijalnie niski, ale to już kwestia indywidualnej oceny w kontekście konkretnego rozwiązania, które budujemy.

Cold start a skalowalność

Co ważne, problem cold startu występuje dla każdej instancji funkcji. Innymi słowy gdy pierwsze zdarzenie uruchomiło pierwszą instancję funkcji i ona wciąż się wykonuje, to drugie zdarzenie będzie musiało uruchomić drugą instancję. AWS musi uruchomić kolejny kontener z kopią Twojej funkcji. Po raz kolejny trzeba przejść przez całe ładowanie i znów mamy cold start.

Źródło: Opracowanie własne

Natomiast trzecie zdarzenie, które nastąpi po wykonaniu się przynajmniej jednej z funkcji, może wykorzystać już uruchomiony kontener z naszą funkcją. Nazywamy ją rozgrzaną funkcją, ponieważ nie ma zimnego startu 😃

Projektując skalowalne systemy koniecznie trzeba mieć świadomość tego mechanizmu.

Nie zawsze musisz się przejmować cold startem

Wbrew pozorom cold start nie zawsze stanowi problem. W przypadku wielu rozwiązań, pracujących batchowo, asynchronicznie bez kontaktu z klientem zewnętrznym nie stanowi różnicy czy funkcja uruchamia się 200ms czy 2000ms (nie płacimy za to). Problem jest tylko wtedy, gdy po drugiej stronie czeka na odpowiedź człowiek, który może się zirytować długim czasem oczekiwania.

Jak walczyć z cold startem?

Można na wiele sposobów. Jednym z najprostszych i darmowych jest programowanie w językach skryptowych, które mają mniejsze wymagania, co do ładowania swoich środowisk uruchomieniowych w stosunku do języków kompilowanych obsługiwanych przez Lambdę. W chwili obecnej można już śmiało napisać, że należy pisać w JavaScript (node.js), z racji szybkości startu oraz popularności tego języka - przeważająca ilość rozwiązań, książek, kursów i przykładów jest właśnie w Node.js.

Oczywiście jeśli Ty lub Twój zespół znacie Pythona czy Go to mogą one być dla Was lepsze niż nauka JavaScript, ale jeśli jesteś ze świata Java lub .Net to nie miej złudzeń - nauka JavaScript na pewno wyjdzie Ci na dobre 😜

Innym popularnym podejściem, które sprawdza się u wielu osób, jest stosowanie asynchronicznego API w miejsce synchronicznego. Na przykład gdy użytkownik naszej aplikacji webowej chce wygenerować raport w PDF to zamiast synchronicznie czekać na zakończenie generowania pliku, można zwrócić mu token z ID raportu i strona WWW będzie się odpytywała backend czy już wygenerował raport dla użytkownika. Można też wykorzystać websocket i wypchnąć powiadomienie do klienta gdy raport będzie gotowy. Opowiadałem o tym na swojej prezentacji na konferencji Greenfield w Łodzi - nagranie tutaj.