Serverless nie oznacza fizycznego braku serwerów. To nie jest zabójca kontenerów ani przemijający trend. To nowe podejście do budowania systemów w chmurze. W dzisiejszym artykule poruszymy temat architektury aplikacji Serverless, przyjrzyjmy się jaką rolę pełni dostawca usług Serverless i projekty open source. Na koniec porozmawiajmy o kwestiach związanych z korzystaniem z Serverless.
Chcę napisać część serwerową aplikacji (lub nawet sklepu internetowego). Może to być czat, usługa publikowania treści lub moduł równoważenia obciążenia. W każdym razie będzie wiele problemów: będziesz musiał przygotować infrastrukturę, określić zależności aplikacji i pomyśleć o systemie operacyjnym hosta. Następnie konieczna będzie aktualizacja małych komponentów, które nie wpływają na działanie reszty monolitu. No cóż, nie zapominajmy o skalowaniu pod obciążeniem.
A co jeśli weźmiemy efemeryczne kontenery, w których wymagane zależności są już preinstalowane, a same kontenery są odizolowane od siebie i od systemu operacyjnego hosta? Monolit podzielimy na mikroserwisy, z których każdy będzie mógł być aktualizowany i skalowany niezależnie od pozostałych. Umieszczając kod w takim kontenerze, mogę uruchomić go na dowolnej infrastrukturze. Już lepiej.
A co jeśli nie chcesz konfigurować kontenerów? Nie chcę myśleć o skalowaniu aplikacji. Nie chcę płacić za bezczynnie działające kontenery, gdy obciążenie usługi jest minimalne. Chcę napisać kod. Skoncentruj się na logice biznesowej i wprowadzaj produkty na rynek z prędkością światła.
Takie myśli doprowadziły mnie do obliczeń bezserwerowych. Bezserwerowy w tym przypadku oznacza nie fizyczny brak serwerów, ale brak problemów z zarządzaniem infrastrukturą.
Pomysł jest taki, że logika aplikacji jest podzielona na niezależne funkcje. Mają strukturę eventową. Każda funkcja wykonuje jedno „mikrozadanie”. Od programisty wystarczy załadować funkcje do konsoli dostarczonej przez dostawcę chmury i skorelować je ze źródłami zdarzeń. Kod zostanie wykonany na żądanie w automatycznie przygotowanym kontenerze, a ja zapłacę jedynie za czas wykonania.
Zobaczmy jak teraz będzie wyglądał proces tworzenia aplikacji.
Od strony dewelopera
Wcześniej zaczęliśmy rozmawiać o aplikacji dla sklepu internetowego. W podejściu tradycyjnym główną logikę systemu realizuje aplikacja monolityczna. A serwer z aplikacją cały czas działa, nawet jeśli nie ma obciążenia.
Aby przejść na wersję bezserwerową, dzielimy aplikację na mikrozadania. Dla każdego z nich piszemy własną funkcję. Funkcje są od siebie niezależne i nie przechowują informacji o stanie (bezstanowe). Mogą nawet być napisane w różnych językach. Jeśli któryś z nich „upadnie”, cała aplikacja nie zatrzyma się. Architektura aplikacji będzie wyglądać następująco:
Podział na funkcje w Serverless przypomina pracę z mikroserwisami. Jednak mikrousługa może wykonywać kilka zadań, a funkcja powinna w idealnym przypadku wykonywać jedno. Wyobraźmy sobie, że zadaniem jest zbieranie statystyk i wyświetlanie ich na żądanie użytkownika. W podejściu mikroserwisowym zadanie wykonuje jedna usługa posiadająca dwa punkty wejścia: zapis i odczyt. W przypadku przetwarzania bezserwerowego będą to dwie różne funkcje, które nie są ze sobą powiązane. Deweloper oszczędza zasoby obliczeniowe, jeśli np. statystyki są aktualizowane częściej niż pobierane.
Funkcje bezserwerowe muszą zostać wykonane w krótkim czasie (limit czasu), który określa usługodawca. Na przykład dla AWS limit czasu wynosi 15 minut. Oznacza to, że długowieczne funkcje będą musiały zostać zmienione, aby odpowiadały wymaganiom – to właśnie odróżnia Serverless od innych popularnych dziś technologii (kontenery i Platforma jako usługa).
Do każdej funkcji przypisujemy zdarzenie. Zdarzenie jest wyzwalaczem akcji:
Wydarzenie
Akcja wykonywana przez funkcję
Zdjęcie produktu zostało przesłane do repozytorium.
Skompresuj obraz i prześlij do katalogu
Adres sklepu fizycznego został zaktualizowany w bazie danych
Załaduj nową lokalizację do map
Klient płaci za towar
Rozpocznij przetwarzanie płatności
Zdarzeniami mogą być żądania HTTP, dane przesyłane strumieniowo, kolejki komunikatów i tak dalej. Źródłami zdarzeń są zmiany lub wystąpienia danych. Ponadto funkcje można uruchamiać za pomocą timera.
Architektura została dopracowana, a aplikacja stała się prawie bezserwerowa. Następnie udajemy się do usługodawcy.
Ze strony dostawcy
Zazwyczaj przetwarzanie bezserwerowe jest oferowane przez dostawców usług w chmurze. Nazywa się je różnie: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Z usługi będziemy korzystać poprzez konsolę dostawcy lub konto osobiste. Kod funkcji można pobrać na jeden z następujących sposobów:
- pisać kod we wbudowanych edytorach poprzez konsolę webową,
- pobierz archiwum z kodem,
- pracować z publicznymi lub prywatnymi repozytoriami Git.
Tutaj konfigurujemy zdarzenia wywołujące funkcję. Zestawy zdarzeń mogą się różnić dla różnych dostawców.
Dostawca zbudował i zautomatyzował system Function as a Service (FaaS) na swojej infrastrukturze:
- Kod funkcji trafia do pamięci po stronie dostawcy.
- Po wystąpieniu zdarzenia na serwerze automatycznie wdrażane są kontenery z przygotowanym środowiskiem. Każda instancja funkcji ma swój własny izolowany kontener.
- Z pamięci funkcja jest wysyłana do kontenera, obliczana i zwraca wynik.
- Rośnie liczba wydarzeń równoległych – rośnie liczba kontenerów. System automatycznie skaluje się. Jeśli użytkownicy nie uzyskają dostępu do tej funkcji, będzie ona nieaktywna.
- Dostawca ustala czas bezczynności kontenerów - jeśli w tym czasie w kontenerze nie pojawią się funkcje, zostanie on zniszczony.
W ten sposób otrzymujemy Serverless od razu po wyjęciu z pudełka. Za usługę zapłacimy w modelu pay-as-you-go i tylko za te funkcje, z których skorzystaliśmy i tylko za czas ich wykorzystania.
Aby wprowadzić programistów do usługi, dostawcy oferują do 12 miesięcy bezpłatnych testów, ale ograniczają całkowity czas obliczeń, liczbę żądań miesięcznie, fundusze lub zużycie energii.
Główną zaletą współpracy z dostawcą jest możliwość nie martwienia się o infrastrukturę (serwery, maszyny wirtualne, kontenery). Ze swojej strony dostawca może wdrożyć FaaS zarówno przy użyciu własnych rozwiązań, jak i przy użyciu narzędzi typu open source. Porozmawiajmy o nich dalej.
Od strony open source
Społeczność open source od kilku lat aktywnie pracuje nad narzędziami bezserwerowymi. Do rozwoju platform bezserwerowych przyczyniają się także najwięksi gracze rynkowi:
- Google oferuje programistom narzędzie typu open source - . W jego rozwoju uczestniczyły IBM, RedHat, Pivotal i SAP;
- IBM pracował na platformie Serverless , który następnie stał się projektem Fundacji Apache;
- Microsoft częściowo otworzył kod platformy .
Trwają również prace w kierunku frameworków bezserwerowych. и wdrażane w ramach przygotowanych wcześniej klastrów Kubernetes, współpracuje zarówno z Kubernetesem, jak i Docker Swarm. Framework pełni rolę swego rodzaju kontrolera - na żądanie przygotowuje środowisko uruchomieniowe wewnątrz klastra, a następnie uruchamia tam funkcję.
Frameworki pozostawiają miejsce na konfigurację narzędzia pod kątem Twoich potrzeb. Zatem w Kubeless programista może skonfigurować limit czasu wykonania funkcji (wartość domyślna to 180 sekund). Próbując rozwiązać problem zimnego rozruchu, rozszczepienie sugeruje utrzymywanie niektórych kontenerów w ruchu przez cały czas (chociaż wiąże się to z kosztami przestoju zasobów). OpenFaaS oferuje zestaw wyzwalaczy na każdy gust i kolor: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT i inne.
Instrukcje dotyczące rozpoczęcia można znaleźć w oficjalnej dokumentacji frameworków. Praca z nimi wymaga posiadania nieco większych umiejętności niż przy pracy z dostawcą – jest to przynajmniej umiejętność uruchomienia klastra Kubernetes poprzez CLI. Co najwyżej uwzględnij inne narzędzia typu open source (na przykład menedżer kolejek Kafka).
Niezależnie od tego jak będziemy pracować z Serverless – poprzez dostawcę czy korzystając z open source, otrzymamy szereg zalet i wad podejścia Serverless.
Z punktu widzenia zalet i wad
Serverless rozwija idee infrastruktury kontenerowej i podejścia mikroserwisowego, w którym zespoły mogą pracować w trybie wielojęzycznym, bez przywiązania do jednej platformy. Budowa systemu jest uproszczona, a błędy łatwiejsze do skorygowania. Architektura mikroserwisowa pozwala na dodawanie nowych funkcjonalności do systemu znacznie szybciej niż w przypadku aplikacji monolitycznej.
Serverless jeszcze bardziej skraca czas programowania, pozwalając programiście skupić się wyłącznie na logice biznesowej i kodowaniu aplikacji. W rezultacie czas wprowadzania rozwiązań na rynek jest skrócony.
Jako bonus otrzymujemy automatyczne skalowanie pod obciążeniem, i płacimy tylko za wykorzystane zasoby i tylko w momencie ich wykorzystania.
Jak każda technologia, Serverless ma wady.
Przykładowo taką wadą może być czas zimnego startu (średnio do 1 sekundy dla języków takich jak JavaScript, Python, Go, Java, Ruby).
Z jednej strony tak naprawdę czas zimnego startu zależy od wielu zmiennych: języka, w którym napisana jest funkcja, liczby bibliotek, ilości kodu, komunikacji z dodatkowymi zasobami ( tymi samymi bazami danych czy serwerami uwierzytelniającymi). Ponieważ programista kontroluje te zmienne, może skrócić czas uruchamiania. Ale z drugiej strony programista nie może kontrolować czasu uruchamiania kontenera - wszystko zależy od dostawcy.
Zimny start może zamienić się w ciepły start, gdy funkcja ponownie wykorzystuje kontener uruchomiony przez poprzednie zdarzenie. Sytuacja taka wystąpi w trzech przypadkach:
- jeśli klienci często korzystają z usługi i wzrasta liczba wywołań funkcji;
- jeśli dostawca, platforma lub framework pozwala na ciągłe działanie niektórych kontenerów;
- jeśli programista uruchamia funkcje na zegarze (powiedzmy co 3 minuty).
W wielu zastosowaniach zimny start nie stanowi problemu. Tutaj musisz opierać się na rodzaju i zadaniach usługi. Opóźnienie startu o sekundę nie zawsze jest krytyczne dla aplikacji biznesowej, ale może mieć krytyczne znaczenie dla usług medycznych. W tym przypadku podejście bezserwerowe prawdopodobnie nie będzie już odpowiednie.
Kolejną wadą Serverless jest krótki czas życia funkcji (przekroczenie limitu czasu, podczas którego funkcja musi zostać wykonana).
Jeśli jednak musisz pracować z długotrwałymi zadaniami, możesz skorzystać z architektury hybrydowej – połączyć Serverless z inną technologią.
Nie wszystkie systemy będą mogły działać w schemacie Serverless.
Niektóre aplikacje będą nadal przechowywać dane i stan podczas wykonywania. Niektóre architektury pozostaną monolityczne, a niektóre funkcje będą długotrwałe. Jednak (podobnie jak technologie chmurowe, a potem kontenery) Serverless to technologia z wielką przyszłością.
W tym duchu chciałbym płynnie przejść do kwestii wykorzystania podejścia Serverless.
Od strony aplikacji
W roku 2018 odsetek wykorzystania bezserwerowego . Wśród firm, które wdrożyły już tę technologię w swoich usługach, są tacy rynkowi giganci jak Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Jednocześnie musisz zrozumieć, że Serverless nie jest panaceum, ale narzędziem do rozwiązywania określonego zakresu problemów:
- Skróć przestoje zasobów. Nie ma potrzeby ciągłego utrzymywania maszyny wirtualnej w przypadku usług, które mają niewiele wywołań.
- Przetwarzaj dane na bieżąco. Kompresuj zdjęcia, wycinaj tła, zmieniaj kodowanie wideo, pracuj z czujnikami IoT, wykonuj operacje matematyczne.
- „Sklej” ze sobą inne usługi. Repozytorium Git z programami wewnętrznymi, chat bot w Slacku z Jirą i kalendarzem.
- Zrównoważ obciążenie. Przyjrzyjmy się tutaj bliżej.
Załóżmy, że istnieje usługa, która przyciąga 50 osób. Pod nim znajduje się maszyna wirtualna ze słabym sprzętem. Od czasu do czasu obciążenie usługi znacznie wzrasta. Wtedy słaby sprzęt sobie nie poradzi.
Możesz włączyć do systemu moduł równoważący, który rozłoży obciążenie, powiedzmy, na trzy maszyny wirtualne. Na tym etapie nie możemy dokładnie przewidzieć obciążenia, dlatego pewną ilość zasobów utrzymujemy „w rezerwie”. A za przestoje przepłacamy.
W takiej sytuacji możemy zoptymalizować system poprzez podejście hybrydowe: jedną maszynę wirtualną zostawiamy za balanserem obciążenia i umieszczamy link do Serverless Endpoint z funkcjami. Jeżeli obciążenie przekroczy próg, balanser uruchamia instancje funkcji, które przejmują część przetwarzania żądań.
Dzięki temu Serverless można zastosować tam, gdzie konieczne jest przetwarzanie dużej liczby żądań niezbyt często, ale intensywnie. W takim przypadku uruchomienie kilku funkcji przez 15 minut jest bardziej opłacalne niż ciągłe utrzymywanie maszyny wirtualnej lub serwera.
Biorąc pod uwagę wszystkie zalety przetwarzania bezserwerowego, przed wdrożeniem należy najpierw ocenić logikę aplikacji i zrozumieć, jakie problemy Serverless może rozwiązać w konkretnym przypadku.
Bezserwerowe i Selectel
W Selectel już jesteśmy poprzez nasz panel sterowania. Teraz budujemy własną platformę FaaS. Chcemy, aby programiści mogli rozwiązywać swoje problemy za pomocą Serverless poprzez wygodny, elastyczny interfejs.
Jeśli masz pomysły na to, jaka powinna być idealna platforma FaaS i jak chcesz wykorzystać Serverless w swoich projektach, podziel się nimi w komentarzach. Podczas opracowywania platformy uwzględnimy Twoje życzenia.
Materiały użyte w artykule:
Źródło: www.habr.com