Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



21.02.2019

Wdrażanie projektów AI

Infrastruktura OVH
21.02.2019

Certyfikacja kluczy

HEUTHES-CAK
21.02.2019

Kopie zapasowe

Veeam Availability for AWS
21.02.2019

Dysk SSD Samsung 970 EVO Plus

Dysk SSD Samsung 970 EVO Plus
21.02.2019

Szyfrowane USB

Kingston IronKey D300 Serialized
21.02.2019

Bezpieczeństwo sieci

Check Point Maestro i seria 6000
21.02.2019

Ochrona danych

Commvault IntelliSnap i ScaleProtect
21.02.2019

Ułatwienie telekonferencji

Plantronics Calisto 3200 i 5200
21.02.2019

Transformacja centrów danych

Fujitsu PRIMEFLEX for VMware vSAN

Serverless, czyli przetwarzanie bezserwerowe

Data publikacji: 20-12-2018 Autor: Jarosław Sobel
Rys.1. Przykład logiki...

Deweloperzy nie zdążyli się jeszcze nacieszyć kontenerami, a na świat przyszło kolejne przełomowe rozwiązanie, które bardzo szybko zdobywa zainteresowanie programistów. Mowa o serverless, czyli o przetwarzaniu „bez” użycia serwerów.

 

Tak naprawdę serwery w dalszym ciągu są potrzebne, zostały one jednak ukryte przed programistą w taki sposób, aby ten nie zaprzątał sobie głowy koniecznością ich powoływania, konfiguracji i utrzymywania.

Na czym polega to rozwiązanie? W dużym uproszczeniu funkcja (bo tak potocznie nazywa się ten mechanizm) to nic innego jak „kawałek” kodu, który jest uruchamiany w momencie, gdy zajdzie pewne zdarzenie (rys. 1). Tym zdarzeniem może być np. zapytanie HTTP lub umieszczenie obiektu (pliku) we wcześniej zdefiniowanej lokalizacji.

> ZASADA DZIAŁANIA

Funkcja (FaaS – Function as a Service) to mechanizm runtime, służący do wykonania pewnej logiki aplikacyjnej, gdy nastąpi pewne zdarzenie. To zdarzenie nazywane jest wyzwalaczem (trigger).

Sama funkcja nie przechowuje danych – należy ją traktować jako bezstanową – dostaje pewne parametry na wejściu, przetwarza je, a następnie w zależności od konfiguracji zapisuje dane i zwraca wynik działania. Bezstanowość jest tutaj kluczowa, ponieważ umożliwia dynamiczne skalowanie rozwiązania w zależności od liczby koniecznych do przetworzenia żądań.

Programista, tworząc funkcję, pisze kod (w zależności od usługodawcy może to być np. Python, Java, Node.js), który następnie osadza w szkielecie funkcji. Sam szkielet to nic innego jak runtime (czyli mechanizm uruchamiania oraz zestaw bazowy bibliotek), definicja wyzwalacza, zabezpieczenia oraz ewentualne parametry uruchomieniowe. Podczas zapisywania funkcji tworzony jest obraz kontenera, który zostanie użyty do jej uruchomienia.

W momencie gdy zajdzie zdarzenie inicjujące wyzwalacz – w naszym przypadku żądanie HTTP (np. REST API z aplikacji) – mechanizm obsługujący funkcję uruchamia kontener, a następnie przesyła do niego parametry z wyzwalacza (np. informacje przekazane w żądaniu HTTP). Po obsłużeniu danego żądania kontener pozostaje aktywny jeszcze przez pewien czas (w razie gdyby musiał obsłużyć kolejne zapytania), a później (jeśli nic nie jest przetwarzane) zostaje zatrzymany.

> AUTOSKALOWANIE I COLD START

Główną zaletą funkcji jest ich autoskalowanie. Oznacza to, że gdy zwiększa się liczba wyzwalaczy, zwiększy się też liczba równolegle wywoływanych funkcji. W takim przypadku należy pamiętać o limitach, które obowiązują u każdego z dostawców.

Wiemy też, jak działa funkcja – jest to kontener zawierający nasz kod, który w momencie wywołania jest uruchamiany. To właśnie pierwsze wywołanie (gdy żaden z kontenerów jeszcze nie działa) jest nazywane cold startem i wydłuża czas wykonania samej funkcji. Po uruchomieniu i wykonaniu kodu kontener pozostaje aktywny jeszcze przez pewien czas (aby przyjąć kolejne żądania już bez dodatkowej zwłoki). Jeśli w określonym przedziale czasowym nie pojawi się nowe żądanie, kontener zostanie zatrzymany. Podobna sytuacja ma miejsce w przypadku autoskalowania, gdy mechanizm powołuje kolejną instancję do obsłużenia dodatkowego ruchu.

Na rys. 2 przedstawione są wyniki testu opóźnień startu funkcji – cold start. W każdej z chmur przygotowana została funkcja (AWS – Python 2.7; Azure i Google – Node.js 6.x), która następnie była wywoływana cyklicznie przez 168 godzin (7 dni). Na wykresie przedstawione zostały mediany czasów opóźnień agregowane w poszczególnych godzinach. Jak widać, najstabilniejsze zachowanie prezentował AWS – ok. 200 ms. W przypadku Azure’a poza kilkoma pikami czasy również były na w miarę jednakowym poziomie. Natomiast w GCP opóźnienia wahały się od 1,5 do nawet 16 sekund.

Wiemy już, że instancja funkcji uruchamiana jest w momencie pojawienia się wyzwalacza, a następnie gaszona po upływie pewnego zadanego czasu. Czas bezczynności jest różny w zależności od usługodawcy. W AWS-ie funkcja może żyć przez prawie 27 minut (przy czym 80% instancji zatrzymywanych jest po 26 minutach). W Azure tego typu ograniczenie nie istnieje. W GCP czas bezczynności może dochodzić do 120 minut.

> ZALETY I WADY ROZWIĄZANIA

NIŻSZE KOSZTY

Większość dostawców chmurowych rozlicza swoje funkcje na podstawie liczby wywołań (np. 1 mln wywołań / 0,20 dol.). Jest to zgodne z modelem kosztowym przyjętym w chmurze, czyli pay-as-you-go. W większości przypadków koszt może okazać się znacznie niższy zarówno od podejścia tradycyjnego (aplikacja na wirtualnych serwerach), jak i od rozwiązania autoskalowanego bazującego np. na kontenerach uruchomionych w klastrze kubernetesowym. Wynika to m.in. z faktu, że w tym rozwiązaniu nie płacimy za czas bezczynności aplikacji, tylko za faktyczne jej użycie.

Należy jednak pamiętać, w jaki sposób przeliczane są poszczególne wywołania na koszt. Koszt podany dla 1 mln wywołań jest prawdziwy, pod warunkiem że nasza funkcja będzie działała przez X s i utylizowała Y MB pamięci RAM. Jeśli czas jej wywołania zwiększy się 4-krotnie, to wówczas samych wywołań będziemy mieli już tylko 250 tys. (dla podanego kosztu jednostkowego). Co więcej, niektórzy usługodawcy doliczają również koszty za ruch sieciowy (wchodzący lub wychodzący) lub dodatkową opłatę za przestrzeń dyskową. Należy o tym pamiętać przy szacowaniu kosztów.

AUTOMATYCZNA SKALOWALNOŚĆ

Drugą niewątpliwą zaletą rozwiązania jest jego automatyczne skalowanie. Dzięki temu, że kontenery uruchamiające daną funkcję są bezstanowe, można powołać dowolną liczbę ich instancji. W związku z tym w momencie gdy liczba wywołań przekroczy pewien próg, system automatycznie powoła kolejny kontener, który zacznie obsługiwać następne wywołania.

[...]

 

Autor jest architektem zajmującym się projektowaniem i implementacją rozwiązań wirtualizacyjnych. Posiada certyfikacje firm: Citrix, VMware, Microsoft, NetApp i RedHat. Prelegent oraz autor bloga poświęconego technologii Citrix i wirtualizacji. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"