Chcesz Wiedzieć, co Łączy AWS Lambdę, Aliasy i Kanarki?

Serverless tu, serverless tam, o AWS Lambda słyszy się coraz więcej i częściej. Z dnia na dzień przybywa firm, które z niej korzystają. Nadszedł czas, aby wreszcie odpowiedzieć na pytanie: „Czym właściwie jest AWS Lambda?”

1. AWS Lambda to usługa

W najprostszym ujęciu, AWS Lambda to usługa pozwalająca stworzyć jakąś funkcję, wgrać jej kod do AWS i z niego korzystać. Bez konieczności martwienia się o serwery, systemy operacyjne, patchowanie oprogramowania, czy skalowanie.

W teorii działa ona tak: my tworzymy kod, a następnie wrzucamy go do AWS i wywołujemy. Kod działa, robi robotę, zwraca wyniki. Idziemy dalej…

Niestety, rzeczywistość programisty nie przedstawia się tak różowo.

Klient chce „odrobinę” zmienić format odpowiedzi na żądanie. W ostatniej chwili przed releasem prosi nas, żeby kurs waluty do przeliczeń nie był brany z wczoraj, tylko z ostatniego wtorku w poprzednim miesiącu. Znacie to? Życie. Nieustanne zmiany.

Nie znoszę zmian w oprogramowaniu.  Wyznaję zasadę Działa – Nie ruszaj!  Ma ona jednak jedną wadę. Rzadko, a właściwie prawie nigdy, da się ją wprowadzić w życie.

Co zatem zrobić, jeśli kolejny raz przychodzi nam złamać naszą ulubioną regułę, a my mamy już kod wrzucony do chmury? Nie chcemy przecież zepsuć działającej aplikacji!

Tutaj przyda się wersjonowanie Lambdy.

2.  Lambda pozwala na tworzenie wersji

Nie każdy wie, że AWS Lambda pozwala stworzyć kilka wersji tej samej funkcji. Tej samej, ale nie takiej samej. Możemy utworzyć osobną wersję dla produkcji, inną do testów, a jeszcze inną np. na potrzeby R&D.

Zobaczmy kilka przykładów.

AWS Lambda – wersja pierwsza

1. W konsoli tworzymy prostą funkcję Lambda:

Runtime nie jest istotny. Najprostsze uprawnienia dla funkcji także wystarczą.

Ja po prostu zwrócę z Lambdy tekst „Cześć”.

def lambda_handler(event, context):
     return 'Cześć'

Mamy naszą lambdę. Zwróćmy uwagę na jej ARN, jest to tak zwany unqualified ARN: arn:aws:lambda:eu-west-3:xxxxxxxxxxxx:function:ChmurowiskoLambda.

2. Aby opublikować wersję, z menu Actions wybieramy opcję Publish new version:

Ostatnia wgrana przez nas wersja to $LATEST. Każda zmiana kodu powoduje nadpisanie tej wersji. Na podstawie jej konfiguracji oraz kodu utworzony zostanie snapshot i to on będzie podstawą dla naszej nowo tworzonej wersji.

3. Dodajemy jeszcze opis i publikujemy.

Zwróćmy jeszcze raz uwagę na ARN. Teraz wygląda on trochę inaczej.

Na końcu widzimy numer wersji. Tym razem jest to qualified ARN.

Uwaga! Jak pamiętamy, z naszej Lambdy stworzyliśmy snapshot, a raz utworzona wersja nie może być zmieniana. Aby edytować kod, należy „wrócić” do wersji $LATEST.

AWS Lambda – kolejne wersje

W ten sam sposób możemy utworzyć wiele wersji jednej funkcji Lambda.

Zmodyfikujmy nieco kod:

def lambda_handler(event, context):
     return 'Cześć. Tu wersja druga'

i opublikujmy jeszcze jedną wersję.

Mając adresy ARN kolejnych wersji, możemy podłączać różne eventy wywołujące naszą funkcję pod różne wersje. Możemy także przełączać się w konsoli AWS na poszczególne wersje i bezpośrednio je testować:

3. Do czego służą aliasy w AWS Lambda?

Funkcje Lambda można wywoływać za pomocą adresów ARN. Poprawianie adresów we wszystkich usługach, które sięgają do naszej funkcji, za każdym razem, gdy tworzymy nową wersję (i zmienia się jej ARN), byłoby jednak kłopotliwe.  Tu z pomocą przychodzą nam Aliasy.

Wracając do naszego przykładu, w tej chwili mamy trzy wersje funkcji. Wersję 1, 2 oraz $LATEST. Dobrym zwyczajem jest stworzenie aliasu dla tej ostatniej wersji. Od tego zaczniemy.

AWS Lambda – tworzenie aliasu latest

1. W konsoli ponownie wchodzimy do menu Actions. Tym razem wybieramy jednak opcję Create alias.
2. W tym kroku możemy podać nazwę dla naszego aliasu oraz wybrać wersję, na którą ma wskazywać.

ARN dla naszego aliasu wygląda następująco:

Możemy też na przykład nazwać ten alias DEV i korzystać z niego w trakcie rozwoju naszego oprogramowania.

Aliasy do produkcji i testów

Możemy stworzyć aliasy dla wersji produkcyjnej (PROD) oraz testowej (TEST).

Alias PROD będzie wskazywał na wersję 1, alias TEST na wersję 2.

Mając taką konfigurację, możemy cały ruch produkcyjny kierować na arn:aws:lambda:eu-west-3:094104221953:function:ChmurowiskoLambda:PROD, a ruch testowy na arn:aws:lambda:eu-west-3:xxxxxxxxxxxx:function:ChmurowiskoLambda:TEST.

Po pomyślnych testach, gdy chcemy aby wersja 2 była tą, która pracuje na produkcji, nie będziemy mieli zbyt dużo pracy. Wystarczy zmienić alias PROD, tak aby wskazywał na wersję 2.

W tym momencie wszystkie usługi korzystające produkcyjnie z naszej funkcji będą miały do dyspozycji nową wersję.

A co jeśli okaże się, że chcemy wrócić na produkcji do starszej wersji? Nie ma problemu. Po prostu wracamy do takiego ustawienia, w którym alias PROD wskazuje na wersję 1.

4. Lambda i kanarki

Zanim udostępnimy nową wersję naszego oprogramowania, często testujemy ją najpierw na niewielkiej części użytkowników, zgodnie z tzw. canary release, czyli releasem kanarkowym. W tym celu tworzymy przeważnie dwa środowiska (lub dzielimy jedno na dwie części) i kierujemy do nich poszczególne grupy odbiorców. Jest na to wiele sposobów.

Jeżeli testowana wersja nie sprawia problemów i funkcjonuje zgodnie z oczekiwaniami, możemy ja udostępnić wszystkim odbiorcom.

W przypadku Lambdy takie rozwiązanie jest już gotowe. Możemy stworzyć alias, który część ruchu będzie kierował na jedną wersję, a część na drugą.

Przykład canary release z AWS Lambda

Załóżmy, że nasza wersja produkcyjna to wciąż wersja 1. Mamy jednak wstępnie przetestowaną wersję 2 i chcielibyśmy udostępnić ją 20% użytkowników.

1. Wchodzimy do menu Actions, wybieramy opcję Create alias.
2. Wybieramy odpowiednie wersje, ustawiamy podział ruchu i gotowe. Dostajemy nowy ARN:

Kiedy skierujemy na niego ruch 20% wywołań, spowoduje to wykonanie nowej wersji funkcji. Reszta zadowoli się starszą wersją.

Uwaga! Taki podział możemy uruchomić pomiędzy dowolnymi wersjami za wyjątkiem wersji $LATEST.

Jedna zmiana, jedna wersja?

AWS rekomenduje publikowanie nowej wersji za każdym razem gdy dokonujemy zmian w kodzie lub konfiguracji. Szczególnie w przypadku, gdy nad jedną funkcją pracuje więcej osób.

Czy to dobra wskazówka? Istnieje uzasadniona obawa, że inny developer nadpisze Wasz kod. Nie przesadzałbym jednak ze skalą tego zagrożenia. Sam wolę najpierw przetestować kod i dopiero wtedy dokonać publikacji.  A do kontroli wersji znam lepsze narzędzia 🙂

Na pewno warto jednak skorzystać z wersji i aliasów, aby ułatwić sobie konfigurację i codzienną pracę z Lambdą. To zastosowanie jak najbardziej wszystkim polecam!