Serverless to nie o fizycznym braku serwerów. To nie jest "zabójca" kontenerów ani chwilowy trend. To nowe podejście do budowania systemów w chmurze. W dzisiejszym artykule zajmiemy się architekturą aplikacji Serverless, zobaczymy, jaką rolę pełni dostawca usług Serverless oraz projekty open-source. Na koniec porozmawiamy o kwestiach zastosowania Serverless.
Chcę napisać część serwera aplikacji (nawet sklepu internetowego). Może to być czat, serwis do publikacji treści lub równoważnik obciążenia. W każdym przypadku będzie sporo problemów do rozwiązania: trzeba przygotować infrastrukturę, określić zależności aplikacji, pomyśleć o systemie operacyjnym hosta. Następnie trzeba będzie zaktualizować kilka komponentów, które nie wpływają na działanie reszty monolitu. No i nie zapominajmy o skalowaniu pod obciążeniem.
A co jeśli weźmiemy efemeryczne kontenery, w których wymagane zależności są już zainstalowane, a same kontenery są izolowane od siebie i od systemu operacyjnego hosta? Podzielimy monolit na mikrousługi, z których każdą można aktualizować i skalować niezależnie od innych. Umieszczając kod w takim kontenerze, mogę go uruchamiać na każdej infrastrukturze. Już lepiej.
A jeśli nie chcę konfigurować kontenerów? Nie chcę myśleć o skalowaniu aplikacji. Nie chcę płacić za bezczynność uruchomionych kontenerów, gdy obciążenie usługi jest minimalne. Chcę pisać kod. Skupić się na logice biznesowej i wprowadzać produkty na rynek z prędkością światła.
Takie myśli doprowadziły mnie do obliczeń bezserwerowych. Serverless w tym przypadku oznacza nie fizyczną nieobecność serwerów, ale brak bólu głowy związanego z zarządzaniem infrastrukturą.
Idea polega na tym, że logika aplikacji dzieli się na niezależne funkcje. Mają one strukturę zdarzeniową. Każda z funkcji wykonuje jedno „mikrozadanie”. Wszystko, czego wymaga się od programisty, to załadować funkcje do konsoli dostarczonej przez dostawcę chmury i powiązać je z źródłami zdarzeń. Kod będzie wykonywany na żądanie w automatycznie przygotowanym kontenerze, a ja zapłacę tylko za czas wykonywania.
Zobaczmy, jak teraz będzie wyglądał proces rozwoju aplikacji.
Ze strony programisty
Wcześniej zaczęliśmy mówić o aplikacji dla sklepu internetowego. W tradycyjnym podejściu główną logikę systemu realizuje monolityczna aplikacja. A serwer z aplikacją działa nieprzerwanie, nawet jeśli nie ma obciążenia.
Aby przejść do serverless, dzielimy aplikację na mikrozadania. Dla każdej z nich piszemy swoją funkcję. Funkcje są niezależne od siebie i nie przechowują informacji o stanie (stateless). Mogą być nawet napisane w różnych językach. Jeśli jedna z nich „padnie”, aplikacja całkowicie się nie zatrzyma. Architektura aplikacji będzie wyglądać tak:
Podział na funkcje w Serverless przypomina pracę z mikroserwisami. Jednak mikroserwis może wykonywać kilka zadań, a funkcja w idealnym przypadku powinna wykonywać jedno. Załóżmy, że zadaniem jest zbieranie statystyk i ich wyświetlanie na żądanie użytkownika. W podejściu mikroserwisowym zadanie wykonuje jeden serwis z dwoma punktami dostępu: do zapisu i odczytu. W obliczeniach bezserwerowych będą to dwie różne funkcje, niezwiązane ze sobą. Programista oszczędza zasoby obliczeniowe, jeśli na przykład statystyki są aktualizowane częściej, niż są wyładowywane.
Funkcje Serverless powinny być wykonywane w krótkim przedziale czasowym (timeout), który określa dostawca usługi. Na przykład dla AWS timeout wynosi 15 minut. Oznacza to, że funkcje długoterminowe (long-lived) będą musiały być zmienione zgodnie z wymaganiami – to jest to, co różni Serverless od innych popularnych dzisiaj technologii (kontenery i Platform as a Service).
Każdej funkcji przypisujemy zdarzenie. Zdarzenie to wyzwalacz działania:
Zdarzenie
Działanie, które wykonuje funkcja
W magazynie załadowano zdjęcie produktu
Skompresować zdjęcie i załadować do katalogu
W bazie danych zaktualizowano adres fizycznego sklepu
Załadować nowe lokalizacje na mapy
Klient płaci za produkt
Rozpocząć przetwarzanie płatności
Zdarzeniami mogą być żądania HTTP, dane strumieniowe, kolejki wiadomości itd. Źródła zdarzeń to zmiany lub pojawienie się danych. Ponadto funkcje można uruchamiać na podstawie zegara.
Architektura została zaplanowana, a aplikacja prawie stała się bezserwerowa. Następnie przechodzimy do dostawcy usługi.
Ze strony dostawcy
Zazwyczaj obliczenia bezserwerowe oferują dostawcy usług chmurowych. Nazywa się je różnie: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Będziemy korzystać z usługi przez konsolę lub osobisty panel dostawcy. Kod funkcji można załadować na kilka sposobów:
- napisać kod w wbudowanych edytorach przez konsolę internetową,
- załadować archiwum z kodem,
- pracować z publicznymi lub prywatnymi repozytoriami git.
Tut konfigurujemy zdarzenia, które wywołują funkcję. W zależności od dostawcy zestawy zdarzeń mogą się różnić.
Dostawca zbudował i zautomatyzował system Function as a Service (FaaS) na swojej infrastrukturze:
- Kod funkcji trafia do magazynu po stronie dostawcy.
- Gdy pojawia się zdarzenie, na serwerze automatycznie uruchamiają się kontenery z przygotowanym środowiskiem. Każdemu instancji funkcji przypisany jest osobny, izolowany kontener.
- Funkcja jest wysyłana z magazynu do kontenera, obliczana i zwraca wynik.
- Liczba równoległych zdarzeń rośnie — rośnie liczba kontenerów. System automatycznie się skalibruje. Jeśli użytkownicy nie korzystają z funkcji, pozostaje ona nieaktywna.
- Dostawca określa czas bezczynności kontenerów — jeśli w tym czasie funkcje nie pojawią się w kontenerze, zostaje on zniszczony.
W ten sposób uzyskujemy Serverless «prosto z pudełka». Będziemy płacić za usługę w modelu pay-as-you-go i tylko za te funkcje, które były używane, oraz tylko za czas ich użycia.
Aby zaznajomić programistów z usługą, dostawcy oferują do 12 miesięcy bezpłatnych testów, ale ograniczają całkowity czas obliczeń, liczbę zapytań w miesiącu, środki finansowe lub zużywane moce.
Podstawową zaletą pracy z dostawcą jest możliwość nie martwienia się o infrastrukturę (serwery, maszyny wirtualne, kontenery). Ze swojej strony dostawca może wdrażać FaaS zarówno na własnych rozwiązaniach, jak i przy pomocy narzędzi open-source. O tym porozmawiamy dalej.
Ze strony open source
W ostatnich kilku latach społeczność open-source aktywnie pracuje nad narzędziami Serverless. W rozwój platform bezserwerowych zaangażowani są także największe firmy w branży:
- Google oferuje programistom swoje narzędzie open-source — . W jego rozwój zaangażowane były IBM, RedHat, Pivotal i SAP;
- IBM pracowali nad platformą Serverless , która następnie stała się projektem Apache Foundation;
- Microsoft częściowo otworzyli kod platformy .
Prace trwają także nad frameworkami serverless. i rozwiązują się wewnątrz wcześniej przygotowanych klastrów Kubernetes, działa zarówno z Kubernetes, jak i Docker Swarm. Framework pełni rolę swoistego kontrolera – na żądanie przygotowuje środowisko wykonawcze wewnątrz klastra, a następnie uruchamia funkcję.
Frameworki dają możliwość konfiguracji narzędzia według własnych potrzeb. Na przykład, w Kubeless deweloper może ustawić limit czasu wykonywania funkcji (domyślna wartość to 180 sekund). Fission w próbie rozwiązania problemu zimnego startu proponuje, aby część kontenerów była cały czas uruchomiona (choć wiąże się to z kosztami stanu bezczynnego zasobów). OpenFaaS oferuje natomiast zestaw triggerów, które można dostosować: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs i inne.
Instrukcje dotyczące rozpoczęcia pracy można znaleźć w oficjalnej dokumentacji frameworków. Praca z nimi wymaga nieco większej wiedzy niż przy korzystaniu z dostawcy - to przynajmniej umiejętność uruchomienia klastra Kubernetes za pomocą CLI. Na maksymalnym poziomie, włączenie do pracy innych narzędzi open-source (przykładowo, menedżera kolejek Kafka).
Bez względu na to, w jaki sposób będziemy pracować z Serverless – przez dostawcę czy z pomocą open-source – uzyskamy szereg zalet i wad podejścia Serverless.
Z perspektywy zalet i wad
Serverless rozwija idee infrastruktury kontenerowej i podejścia mikroserwisowego, w którym zespoły mogą pracować w trybie wielojęzycznym, nie przywiązując się do jednej platformy. Budowanie systemu staje się prostsze, a naprawa błędów łatwiejsza. Architektura mikroserwisowa pozwala na dodawanie nowego funkcjonalności do systemu znacznie szybciej niż w przypadku aplikacji monolitycznej.
Serverless jeszcze bardziej skraca czas rozwoju, pozwalając deweloperowi skupić się wyłącznie na logice biznesowej aplikacji i pisaniu kodu. W efekcie czas wprowadzenia rozwiązań na rynek skraca się.
Dodatkowo otrzymujemy automatyczne skalowanie w odpowiedzi na obciążenie, a płacimy tylko za używane zasoby i tylko w czasie, gdy są one wykorzystywane.
Jak każda technologia, Serverless ma wady.
Na przykład, taką wadą może być czas zimnego startu (średnio do 1 sekundy dla takich języków jak JavaScript, Python, Go, Java, Ruby).
Z jednej strony, w rzeczy samej czas zimnego startu zależy od wielu zmiennych: języka, w którym napisana jest funkcja, liczby bibliotek, objętości kodu, komunikacji z dodatkowymi zasobami (takimi jak bazy danych czy serwery uwierzytelniające). Ponieważ programista zarządza tymi zmiennymi, może skrócić czas startu. Z drugiej strony, programista nie ma wpływu na czas uruchamiania kontenera ― tutaj wszystko zależy od dostawcy.
Zimny start może przekształcić się w ciepły, gdy funkcja ponownie wykorzystuje kontener uruchomiony przez poprzednie zdarzenie. Taka sytuacja wystąpi w trzech przypadkach:
- jeśli klienci często korzystają z usługi i rośnie liczba wywołań funkcji;
- jeśli dostawca, platforma lub framework pozwalają na utrzymanie części kontenerów uruchomionych przez cały czas;
- jeśli programista uruchamia funkcje na podstawie zegara (powiedzmy co 3 minuty).
Dla wielu aplikacji zimny start nie jest problemem. Należy tutaj kierować się rodzajem i celami usługi. Opóźnienie startu o sekundę nie zawsze jest krytyczne dla aplikacji biznesowej, ale może stać się krytyczne dla służb medycznych. Prawdopodobnie w takim przypadku podejście serverless już się nie sprawdzi.
Następną wadą Serverless jest krótki czas życia funkcji (timeout, w jakim funkcja musi się wykonać).
Jednak, jeśli zamierzamy pracować z zadaniami o długim czasie życia, można zastosować architekturę hybrydową ― połączyć Serverless z inną technologią.
Nie wszystkie systemy będą mogły działać w schemacie Serverless.
Niektóre aplikacje nadal będą przechowywać dane i stan podczas wykonywania. Niektóre architektury pozostaną monolityczne, a niektóre funkcje będą miały długi czas życia. Jednak (jak kiedyś technologie chmurowe, a potem kontenery), Serverless to technologia z dużą przyszłością.
W tym kontekście chciałbym płynnie przejść do pytania o zastosowanie podejścia Serverless.
Z perspektywy zastosowania
W roku 2018 procent wykorzystania Serverless . Wśród firm, które już wdrożyły tę technologię w swoich usługach, znajdują się takie giganty rynku jak Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Należy przy tym zrozumieć, że Serverless to nie panaceum, a narzędzie do rozwiązania określonego kręgu zadań:
- Skrócenie przestojów zasobów. Nie ma potrzeby, aby cały czas trzymać wirtualną maszynę dla usług, do których jest mało zapytań.
- Przetwarzanie danych "w locie". Kompresja zdjęć, usuwanie tła, zmiana kodowania wideo, praca z czujnikami IoT, wykonywanie operacji matematycznych.
- "Sklejenie" innych usług razem. Repozytorium Git z wewnętrznymi programami, bot czatu w Slack z Jira i kalendarzem.
- Balansowanie obciążenia. Tutaj zatrzymamy się na chwilę.
Załóżmy, że jest usługa, do której przychodzi 50 osób. Dla niej stoi wirtualna maszyna z niezbyt mocnym sprzętem. Okresowo obciążenie na usłudze wzrasta wielokrotnie. Wtedy słaby sprzęt nie wytrzymuje.
Można włączyć do systemu balansujący obciążenie, który będzie rozdzielać obciążenie na trzy wirtualne maszyny. Na tym etapie nie możemy dokładnie prognozować obciążenia, dlatego trzymamy pewną ilość zasobów uruchomionych "na zapas". I przepłacamy za bezczynność.
W takiej sytuacji możemy zoptymalizować system poprzez hybrydowe podejście: pozostawiamy jedną wirtualną maszynę za balansującym obciążeniem i stawiamy link do Endpointu Serverless z funkcjami. Jeśli obciążenie przekracza próg — balansujący obciążenie uruchamia instancje funkcji, które przejmują część przetwarzania zapytań.
W ten sposób Serverless można używać tam, gdzie konieczne jest intensywne przetwarzanie dużej liczby zapytań, chociaż nie zbyt często. W tym przypadku uruchomienie kilku funkcji na 15 minut jest bardziej opłacalne niż ciągłe trzymanie wirtualnej maszyny lub serwera.
Pomimo wszystkich zalet obliczeń bezserwerowych, przed wdrożeniem przede wszystkim należy ocenić logikę aplikacji i zrozumieć, jakie problemy Serverless może rozwiązać w danym przypadku.
Serverless i Selectel
W Selectel już przez nasz panel sterowania. Teraz budujemy naszą własną platformę FaaS. Chcemy, aby programiści mogli rozwiązywać swoje problemy za pomocą Serverless przez wygodny, elastyczny interfejs.
Jeśli masz pomysły na to, jaka powinna być idealna platforma FaaS i jak chcesz używać Serverless w swoich projektach, podziel się nimi w komentarzach. Uwzględnimy Twoje sugestie przy tworzeniu platformy.
Materiały wykorzystane w artykule:
Źródło: habr.com
