Warstwy Lambda i pakiety wdrożeniowe

Pakiety wdrożeniowe Lambda muszą być samodzielne — wszystkie zależności (biblioteki, SDK, pliki binarne) muszą znajdować się w archiwum ZIP. Rozmiar pakietu szybko rośnie: funkcja analityczna w języku Python korzystająca z NumPy, Pandas i SciPy może przekroczyć 200 MB po rozpakowaniu. Każda aktualizacja kodu funkcji wymaga ponownego przesłania całego pakietu, w tym niezmienionych bibliotek. Warstwy Lambda rozwiązują ten problem, oddzielając współdzielone zależności od kodu funkcji.

Warstwa Lambda to archiwum ZIP zawierające biblioteki, niestandardowe środowiska uruchomieniowe, dane lub pliki konfiguracyjne. Warstwy są przechowywane oddzielnie od kodu funkcji i montowane w środowisku wykonywania funkcji w lokalizacji /opt. Wiele funkcji może współdzielić tę samą warstwę — wystarczy zaktualizować ją raz, aby każda korzystająca z niej funkcja odniosła korzyści. Każda funkcja Lambda może mieć maksymalnie 5 warstw, a łączny rozmiar rozpakowanych plików musi być mniejszy niż 250 MB.

Aby utworzyć warstwę, należy umieścić zależności w prawidłowej strukturze katalogów dla danego środowiska uruchomieniowego (np. python/lib/python3.12/site-packages/ w przypadku Pythona), skompresować je do pliku ZIP i opublikować. Po opublikowaniu warstwa otrzymuje ARN wersji. Tego ARN należy użyć podczas dołączania warstwy do funkcji. Przy każdej aktualizacji warstwy tworzona jest nowa wersja. Funkcje nadal korzystają z wersji, z którą zostały skonfigurowane, dopóki nie zaktualizuje ich Pan/Pani jawnie.

Warstwy należy dodawać do funkcji za pomocą parametru --layers podczas tworzenia lub aktualizowania funkcji. Lambda montuje wszystkie dołączone warstwy w lokalizacji /opt przed uruchomieniem funkcji. Pakiety Pythona w katalogu /opt/python są automatycznie dostępne w ścieżce Pythona, a moduły Node.js w katalogu /opt/nodejs/node_modules są automatycznie odnajdywane. Kod funkcji może używać import lub require do wczytywania pakietów z warstwy tak, jakby były zainstalowane lokalnie.

AWS publikuje oficjalne warstwy, z których można korzystać bez tworzenia własnych. Przykłady obejmują warstwę AWS Lambda Powertools (rejestrowanie strukturalne, śledzenie i flagi funkcji), warstwy ze sterownikami baz danych oraz warstwę AWS Parameters and Secrets Lambda Extension do lokalnego buforowania wartości z SSM/Secrets Manager. Dostawcy zewnętrzni, tacy jak Datadog i New Relic, również publikują publiczne warstwy ze swoimi agentami monitorowania. Dostępne publiczne warstwy można sprawdzić w Serverless Application Repository oraz w konsoli Lambda.

Rozszerzenia Lambda działają jako oddzielne procesy obok kodu funkcji, w tym samym środowisku wykonywania. Reagują na zdarzenia cyklu życia Lambda (init, invoke, shutdown), aby wykonywać takie zadania jak zbieranie danych telemetrycznych, skanowanie pod kątem bezpieczeństwa lub buforowanie konfiguracji. Rozszerzenia są dystrybuowane jako warstwy Lambda. AWS udostępnia rozszerzenie CloudWatch Lambda Insights oraz rozszerzenie AWS AppConfig, a dostawcy oferują niestandardowych agentów monitorowania w postaci rozszerzeń.

Lambda obsługuje dwa formaty wdrożeniowe:

• ZIP (do 50 MB po kompresji, 250 MB po rozpakowaniu): szybkie przesyłanie, obsługa warstw, zgodność ze wszystkimi środowiskami uruchomieniowymi.
• Obraz kontenera (do 10 GB): przechowywany w Amazon ECR, wykorzystuje standardowe narzędzia Docker, nie obsługuje warstw i jest idealny w przypadku bardzo dużych zależności (modeli ML, dużych plików binarnych).

Obrazy kontenerów muszą implementować Lambda Runtime Interface (z użyciem obrazów bazowych udostępnianych przez AWS), aby Lambda wiedziała, jak wywołać handler.

Budowanie i wdrażanie obrazu kontenera Lambda przebiega zgodnie ze standardowym procesem pracy z kontenerami: obraz należy zbudować za pomocą docker build, przesłać do Amazon ECR, a następnie podczas tworzenia lub aktualizowania funkcji Lambda podać URI obrazu. Obrazy kontenerów są niezmienne — każdy tag obrazu odpowiada konkretnej wersji funkcji. Lambda buforuje obrazy kontenerów w swojej infrastrukturze, dlatego kolejne zimne starty po pierwszym są szybsze.

Wersje Lambda są niezmiennymi migawkami kodu i konfiguracji funkcji. Przy każdym opublikowaniu wersji Lambda zamraża pakiet wdrożeniowy, zmienne środowiskowe i warstwy. Aliasy to nazwane wskaźniki do konkretnych wersji — alias prod może wskazywać wersję 5, a staging wersję 6. Można również używać aliasów ważonych, aby kierować określony procent ruchu do nowej wersji podczas wdrożeń kanarkowych (np. 10% do v6 i 90% do v5).

Warstwy również są wersjonowane. Po opublikowaniu nowej wersji warstwy istniejące funkcje nadal korzystają z przypiętej wersji, dopóki nie zostaną zaktualizowane. Dzięki temu można bezpiecznie zaktualizować współdzieloną warstwę bez jednoczesnego zakłócania działania wszystkich funkcji — nową wersję można wdrażać stopniowo. Z czasem warto wycofywać stare wersje warstw, aby ograniczyć zajętość pamięci i nakład pracy związany z utrzymaniem. Lambda zachowuje wersje warstw nawet po ich usunięciu z konsoli, dopóki nie odwołuje się do nich żadna funkcja.

Warstw należy używać, gdy łączny rozmiar po rozpakowaniu mieści się w limicie 250 MB, zależności mają być współdzielone przez wiele funkcji i potrzebne są szybkie iteracje (jednokrotna aktualizacja warstwy przynosi korzyści wszystkim funkcjom). Obrazów kontenerów należy używać, gdy zależności przekraczają 250 MB, potrzebne są niestandardowe pakiety bazowego systemu operacyjnego, istnieją już procesy pracy z Dockerem lub konieczne jest dołączenie dużych zasobów (modeli ML, baz referencyjnych). Obrazy kontenerów nie są zgodne z warstwami Lambda, ale zapewniają większą elastyczność.

Sprawdź swoją wiedzę na temat zagadnień z egzaminu AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji poznano: warstwy Lambda, które pakują współdzielone zależności oddzielnie od kodu funkcji, zmniejszając rozmiar pakietu i umożliwiając ponowne użycie w wielu funkcjach; obrazy kontenerów (do 10 GB za pośrednictwem ECR), które są właściwym wyborem, gdy zależności przekraczają limit 250 MB dla ZIP lub gdy używane są już procesy pracy z Dockerem; oraz wersjonowanie i aliasy, które umożliwiają tworzenie niezmiennych wydań i wdrożeń kanarkowych z podziałem ruchu według wag. W następnej części omówimy Lambda@Edge i wzorce sterowane zdarzeniami.