Serverless není o fyzické absenci serverů. Není to 'zabiják' kontejnerů a není to přechodný trend. Je to nový přístup k budování systémů v cloudu. V dnešním článku se dotkneme architektury Serverless aplikací, podíváme se, jakou roli hraje poskytovatel Serverless služeb a open-source projekty. Na závěr se budeme zabývat otázkami aplikace Serverless.
Chci napsat serverovou část aplikace (třeba internetového obchodu). Může to být i chat, služba pro publikování obsahu, nebo vyvažovač zátěže. V každém případě mě čeká spousta problémů: budu muset připravit infrastrukturu, určit závislosti aplikace a zamyslet se nad operačním systémem hostitele. Poté bude třeba aktualizovat malé komponenty, které se netýkají fungování ostatního monolitu. A nezapomínejme na škálování pod zátěží.
A co když vezmeme efemérní kontejnery, ve kterých jsou požadované závislosti již předinstalovány, a samotné kontejnery jsou od sebe i od OS hostitele izolovány? Monolit rozdělíme na mikroslužby, z nichž každou můžeme aktualizovat a škálovat nezávisle na ostatních. Umístěním kódu do takového kontejneru ho mohu spouštět na jakékoli infrastruktuře. Už je to lepší.
A co když se mi nechce konfigurovat kontejnery? Nechci přemýšlet o škálování aplikace. Nechci platit za nečinnost spuštěných kontejnerů, když je zátěž služby minimální. Chci psát kód. Soustředit se na byznys logiku a uvádět produkty na trh neuvěřitelnou rychlostí.
Tyto myšlenky mě přivedly k bezserverovým výpočtům. Serverless v tomto případě znamená ne fyzickou absenci serverů, ale absenci bolesti hlavy s řízením infrastruktury.
Myšlenka je, že logika aplikace je rozdělena na nezávislé funkce. Mají událostní strukturu. Každá z funkcí vykonává jeden „mikroúkol“. Všechno, co se očekává od vývojáře, je nahrát funkce do konzole poskytované cloudovým poskytovatelem a přiřadit je k událostem. Kód se bude spouštět na požádání v automaticky připraveném kontejneru a já zaplatím pouze za čas vykonání.
Pojďme se podívat, jak nyní bude vypadat proces vývoje aplikace.
Z pohledu vývojáře
Dříve jsme začali mluvit o aplikaci pro internetový obchod. V tradičním přístupu vykonává hlavní logiku systému monolitní aplikace. A server s aplikací běží neustále, i když není žádná zátěž.
Abychom přešli k serverless, rozdělíme aplikaci na mikroúkoly. Pro každou z nich píšeme svou funkci. Funkce jsou nezávislé na sobě a neuchovávají informace o stavu (stateless). Mohou být dokonce napsány v různých jazycích. Pokud jedna z nich 'spadne', aplikace se celá nezastaví. Architektura aplikace bude vypadat takto:
Dělení na funkce v Serverless připomíná práci s mikroslužbami. Mikroslužba však může vykonávat několik úkolů, zatímco funkce by měla vykonávat ideálně pouze jeden. Představme si, že cílem je shromažďovat statistiky a zobrazovat je na základě požadavků uživatele. V mikroslužbovém přístupu tuto úlohu vykonává jeden servis se dvěma vstupními body: pro zápis a čtení. V bezserverovém výpočetním přístupu to budou dvě různé funkce, které nejsou navzájem spojeny. Vývojář šetří výpočetní zdroje, pokud například statistika je aktualizována častěji, než je vykládána.
Serverless funkce by měly být prováděny během krátkého časového úseku (timeout), který určuje poskytovatel služby. Například pro AWS je timeout 15 minut. To znamená, že dlouhotrvající funkce (long-lived) budou muset být přizpůsobeny požadavkům − to je to, čím se Serverless liší od dalších dnes populárních technologií (kontejnerů a Platform as a Service).
Každé funkci přiřadíme událost. Událost je spouštěč pro akci:
Událost
Akce, kterou funkce vykonává
Do úložiště byla nahrána fotografie produktu
Zmenšit obrázek a nahrát do katalogu
V databázi se aktualizovala adresa fyzického obchodu
Na mapách načíst novou lokaci
Zákazník platí za zboží
Spustit zpracování platby
Událostmi mohou být HTTP požadavky, streamová data, fronty zpráv a podobně. Zdroje událostí jsou změna nebo vznik dat. Funkce lze také spouštět na základě časovače.
Architektura byla promyšlena a aplikace se téměř stala serverless. Dále přecházíme k poskytovateli služby.
Z pohledu poskytovatele
Obvykle bezserverové výpočty nabízejí poskytovatelé cloudových služeb. Nazývají se různě: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Službu budeme používat prostřednictvím konzole nebo osobního účtu poskytovatele. Kód funkcí lze nahrát jedním ze způsobů:
- napsat kód ve vestavěných editorech prostřednictvím webové konzole,
- nahrát archiv s kódem,
- pracovat s veřejnými nebo soukromými git repozitáři.
Zde nastavujeme události, které vyvolávají funkci. Sady událostí se mohou lišit mezi různými poskytovateli.
Poskytovatel na své infrastruktuře vybudoval a automatizoval systém Function as a Service (FaaS):
- Kód funkcí se dostává do úložiště na straně poskytovatele.
- Když dojde k události, na serveru se automaticky spouštějí kontejnery s připraveným prostředím. Každá instance funkce má svůj izolovaný kontejner.
- Z úložiště se funkce odesílá do kontejneru, vykonává se a vrací výsledek.
- Počet paralelních událostí roste — roste i počet kontejnerů. Systém se automaticky škáluje. Pokud uživatelé na funkci nevolají, zůstane neaktivní.
- Poskytovatel určuje dobu nečinnosti kontejnerů — pokud v této době funkce v kontejneru neexistují, bude zničen.
Tak získáváme Serverless "out of the box". Budeme platit za službu podle modelu pay-as-you-go a pouze za ty funkce, které se používají, a pouze za dobu, kdy byly používány.
Aby se vývojáři seznámili se službou, poskytovatelé nabízejí až 12 měsíců bezplatného testování, ale omezují celkový čas výpočtů, počet požadavků za měsíc, finanční prostředky nebo spotřebované zdroje.
Hlavní výhodou práce s poskytovatelem je možnost nezatěžovat se infrastrukturou (servery, virtuální stroje, kontejnery). Z pohledu poskytovatele může být FaaS realizován jak na vlastních řešeních, tak pomocí open-source nástrojů. O těch budeme hovořit dále.
Z pohledu open source
V posledních dvou letech aktivně pracuje open-source komunita na nástrojích Serverless. Mezi největšími hráči na trhu přispívají k rozvoji bezserverových platforem:
- Google nabízí vývojářům svůj open-source nástroj — . Na jeho vývoji se podíleli IBM, RedHat, Pivotal a SAP;
- IBM pracovali na platformě Serverless , která se později stala projektem Apache Foundation;
- Microsoft částečně otevřeli kód platformy .
Vývoj také pokračuje směrem ke serverless frameworkům. a se deployují uvnitř předem připravených clusterů Kubernetes, funguje jak s Kubernetes, tak i s Docker Swarm. Framework se chová jako kontroler, který na požádání připraví prostředí pro běh uvnitř clusteru a pak spustí funkci.
Frameworky umožňují flexibilní přizpůsobení nástroje vlastním potřebám. Například v Kubeless si může vývojář nastavit timeout vykonání funkce (výchozí hodnota je 180 sekund). Fission se snaží vyřešit problém studeného startu tím, že některé kontejnery drží neustále spuštěné (i když to s sebou nese náklady na nečinnost zdrojů). OpenFaaS nabízí široký výběr spouštěčů podle libosti: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs a další.
Pokyny k zahájení práce lze nalézt v oficiální dokumentaci frameworků. Práce s nimi vyžaduje o něco více dovedností než práce s poskytovatelem — to minimálně zahrnuje schopnost spustit Kubernetes cluster přes CLI. Maximálně zahrnout do práce další open-source nástroje (například správce front Kafka).
Bez ohledu na to, jakým způsobem budeme pracovat se Serverless — prostřednictvím poskytovatele nebo pomocí open-source, získáme řadu výhod a nevýhod přístupu Serverless.
Z pohledu výhod a nevýhod
Serverless rozvíjí myšlenky kontejnerové infrastruktury a mikroslužeb, kde týmy mohou pracovat v multijazyčném režimu, aniž by byly vázány na jednu platformu. Budování systému se zjednodušuje a opravit chyby je snažší. Mikroslužbová architektura umožňuje mnohem rychleji přidávat do systému nové funkce než v případě monolitické aplikace.
Serverless ještě více zkracuje čas vývoje, což umožňuje vývojářům soustředit se výhradně na byznys logiku aplikace a psaní kódu. V důsledku toho se zkracuje čas uvedení vývoje na trh.
Jako bonus získáváme automatické škálování podle zatížení, a platíme pouze za použité zdroje a jen v tu dobu, kdy jsou využívány.
Stejně jako každá technologie má Serverless své nevýhody.
Jednou z takových nevýhod může být doba studeného startu (průměrně až 1 sekunda pro takové jazyky jako JavaScript, Python, Go, Java, Ruby).
Z jedné strany doba studeného startu ve skutečnosti závisí na mnoha proměnných: jazyk, ve kterém je funkce napsána, počet knihoven, objem kódu, komunikace s dalšími zdroji (těmi jsou databáze nebo servery pro autentizaci). Jelikož vývojář tyto proměnné řídí, může zkrátit dobu startu. Na druhou stranu však vývojář nemůže řídit dobu spuštění kontejneru – zde záleží vše na poskytovateli.
Studený start se může změnit na teplý, když funkce znovu využije kontejner, který byl spuštěn předchozí událostí. Tato situace nastane ve třech případech:
- pokud zákazníci často používají službu a roste počet volání funkcí;
- pokud poskytovatel, platforma nebo rámec umožňují, aby části kontejnerů byly spuštěny nepřetržitě;
- pokud vývojář spouští funkce podle časovače (řekněme, každé 3 minuty).
Pro mnohé aplikace není studený start problém. Je třeba vycházet z typu a úkolů služby. Zpoždění startu o sekundu nemusí být vždy kritické pro podniková řešení, ale může se stát kritickým pro zdravotnické služby. Pravděpodobně v tomto případě serverless přístup již nebude vyhovovat.
Dalším nedostatkem serverless je krátká doba života funkce (timeout, během kterého musí funkce být vykonána).
Pokud však máte v plánu pracovat s dlouhodobými úkoly, můžete použít hybridní architekturu – zkombinovat serverless s jinou technologií.
Ne všechny systémy budou moci fungovat na základě serverless schématu.
Některé aplikace stále budou uchovávat data a stav během vykonávání. Některé architektury zůstanou monolitní, a některé funkce budou dlouhodobé. Přesto (jako kdysi cloudové technologie a později kontejnery) je serverless technologií s velkou budoucností.
V tomto ohledu bych chtěl plynule přejít k otázce použití přístupu serverless.
Z pohledu použití
V roce 2018 vzrostl procentuální podíl využívání serverless . Mezi společnostmi, které již tuto technologii implementovaly do svých služeb, jsou takoví giganti trhu jako Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Je třeba rozumět tomu, že serverless není panacea, ale nástroj pro řešení určitého okruhu úkolů:
- Snížit nečinnost zdrojů. Není nutné neustále udržovat virtuální stroj pro služby, na které se jen málokdy obrací.
- Zpracovat data „za chodu“. Snižovat velikost obrázků, odstraňovat pozadí, měnit kódování videa, pracovat se senzory IoT, provádět matematické operace.
- „Spojit“ různé služby dohromady. Gitová repositorář s interními aplikacemi, chat-bot ve Slacku s Jira a kalendářem.
- Vyvažovat zátěž. Zde se na chvíli pozastavíme.
Představme si službu, na kterou přichází 50 lidí. Pro tuto službu je vyhrazen virtuální stroj s slabým hardwarem. Občas se zátěž na službu zvýší několikanásobně. V té chvíli slabý hardware selže.
Můžeme do systému zahrnout vyvažovač zátěže, který rozdělí zátěž například na tři virtuální stroje. V této fázi nemůžeme přesně předpovědět zátěž, a proto držíme nějaké prostředky spuštěné jako „rezervu“. A platíme za nečinnost.
V takové situaci můžeme optimalizovat systém hybridním přístupem: za vyvažovačem zátěže ponecháme jeden virtuální stroj a zavedeme odkaz na Serverless Endpoint s funkcemi. Pokud zátěž překročí práh, vyvažovač spustí instance funkcí, které převezmou část zpracování požadavků.
Tímto způsobem lze Serverless využívat tam, kde je třeba zpracovat velké množství požadavků, i když ne příliš často. V takovém případě je levnější spustit několik funkcí na 15 minut, než trvale udržovat virtuální stroj nebo server.
Přestože mají serverless výpočty mnoho výhod, před jejich zavedením je potřeba nejprve posoudit logiku aplikace a pochopit, jaké úkoly může Serverless vyřešit v konkrétním případě.
Serverless a Selectel
V Selectel jsme již prostřednictvím našeho ovládacího panelu. Nyní budujeme vlastní FaaS platformu. Chceme, aby vývojáři mohli řešit své úkoly pomocí Serverless prostřednictvím pohodlného a flexibilního rozhraní.
Pokud máte nápady, jak by měla vypadat ideální FaaS platforma a jak chcete používat Serverless ve svých projektech, podělte se o ně v komentářích. Vaše přání vezmeme v úvahu při vývoji platformy.
Materiály použité v článku:
Zdroj: habr.com
