Без сервера на полицама

Без сервера на полицама
Без сервера се не ради о физичком одсуству сервера. Ово није убица контејнера или пролазни тренд. Ово је нови приступ изградњи система у облаку. У данашњем чланку ћемо се дотакнути архитектуре апликација без сервера, да видимо какву улогу имају провајдер услуга без сервера и пројекти отвореног кода. На крају, хајде да разговарамо о проблемима коришћења без сервера.

Желим да напишем серверски део апликације (или чак онлајн продавницу). Ово може бити ћаскање, услуга објављивања садржаја или балансирање оптерећења. У сваком случају, биће много главобоља: мораћете да припремите инфраструктуру, одредите зависности апликације и размислите о оперативном систему домаћина. Затим ћете морати да ажурирате мале компоненте које не утичу на рад остатка монолита. Па, не заборавимо на скалирање под оптерећењем.

Шта ако узмемо ефемерне контејнере, у којима су потребне зависности већ унапред инсталиране, а сами контејнери су изоловани један од другог и од ОС хоста? Поделићемо монолит на микросервисе, од којих се сваки може ажурирати и скалирати независно од других. Постављањем кода у такав контејнер, могу га покренути на било којој инфраструктури. Већ боље.

Шта ако не желите да конфигуришете контејнере? Не желим да размишљам о скалирању апликације. Не желим да плаћам контејнере који раде у празном ходу када је оптерећење услуге минимално. Желим да напишем код. Фокусирајте се на пословну логику и изнесите производе на тржиште брзином светлости.

Такве мисли су ме довеле до рачунарства без сервера. Без сервера у овом случају значи не физичко одсуство сервера, већ одсуство главобоље управљања инфраструктуром.

Идеја је да се логика апликације разбије на независне функције. Имају структуру догађаја. Свака функција обавља један „микрозадатак“. Све што је потребно од програмера је да учита функције у конзолу коју обезбеђује провајдер облака и повеже их са изворима догађаја. Код ће бити извршен на захтев у аутоматски припремљеном контејнеру, а ја ћу платити само време извршења.

Да видимо како ће сада изгледати процес развоја апликације.

Са стране програмера

Раније смо почели да причамо о апликацији за онлајн продавницу. У традиционалном приступу, главну логику система изводи монолитна апликација. А сервер са апликацијом стално ради, чак и ако нема оптерећења.

Да бисмо прешли на сервер без сервера, разбијамо апликацију на микрозадатке. За сваку од њих пишемо сопствену функцију. Функције су независне једна од друге и не чувају информације о стању (без стања). Чак могу бити написане на различитим језицима. Ако један од њих „падне“, цела апликација се неће зауставити. Архитектура апликације ће изгледати овако:

Без сервера на полицама
Подела на функције у Серверлесс је слична раду са микросервисима. Али микросервис може да обавља неколико задатака, а функција би у идеалном случају требало да обавља један. Замислимо да је задатак да прикупимо статистику и прикажемо је на захтев корисника. У микросервисном приступу, задатак обавља један сервис са две улазне тачке: писање и читање. У рачунарству без сервера, то ће бити две различите функције које нису повезане једна са другом. Програмер штеди рачунарске ресурсе ако се, на пример, статистика ажурира чешће него што се преузима.

Функције без сервера морају да се изврше у кратком временском периоду (тимеоут), који одређује провајдер сервиса. На пример, за АВС временско ограничење је 15 минута. То значи да ће дуговечне функције морати да се мењају да би одговарале захтевима – то је оно што разликује Серверлесс од других популарних технологија данас (контејнери и Платформа као услуга).

Свакој функцији додељујемо догађај. Догађај је покретач радње:

Евент
Радња коју функција обавља

Слика производа је отпремљена у спремиште.
Компримирајте слику и отпремите је у директориј

Адреса физичке продавнице је ажурирана у бази података
Учитајте нову локацију у мапе

Клијент плаћа робу
Започните обраду плаћања

Догађаји могу бити ХТТП захтеви, стримовање података, редови порука итд. Извори догађаја су промене или појаве података. Поред тога, функције се могу покренути помоћу тајмера.

Архитектура је разрађена, а апликација је скоро постала без сервера. Затим идемо до добављача услуга.

Са стране провајдера

Обично рачунарство без сервера нуде добављачи услуга у облаку. Зову се другачије: Азуре функције, АВС Ламбда, Гоогле Цлоуд функције, ИБМ Цлоуд функције.

Користићемо услугу преко конзоле или личног налога провајдера. Код функције се може преузети на један од следећих начина:

  • писати код у уграђеним уређивачима преко веб конзоле,
  • преузмите архиву са кодом,
  • рад са јавним или приватним гит репозиторијумима.

Овде постављамо догађаје који позивају функцију. Скупови догађаја могу се разликовати за различите провајдере.

Без сервера на полицама

Провајдер је изградио и аутоматизовао систем функције као услуге (ФааС) на својој инфраструктури:

  1. Код функције завршава у складишту на страни провајдера.
  2. Када дође до догађаја, контејнери са припремљеним окружењем се аутоматски постављају на сервер. Свака инстанца функције има свој изоловани контејнер.
  3. Из складишта, функција се шаље у контејнер, израчунава и враћа резултат.
  4. Расте број паралелних догађаја – расте број контејнера. Систем се аутоматски скалира. Ако корисници не приступе функцији, она ће бити неактивна.
  5. Провајдер поставља време мировања за контејнере - ако се за то време функције не појаве у контејнеру, он се уништава.

На овај начин добијамо Серверлесс из кутије. Плаћаћемо услугу по моделу паи-ас-иоу-го и то само за оне функције које се користе и само за време када су коришћене.

Да би програмере упознали са услугом, провајдери нуде до 12 месеци бесплатног тестирања, али ограничавају укупно време рачунања, број захтева месечно, средства или потрошњу енергије.

Главна предност рада са провајдером је могућност да не бринете о инфраструктури (сервери, виртуелне машине, контејнери). Са своје стране, провајдер може да имплементира ФааС и користећи сопствени развој и користећи алате отвореног кода. Хајде да причамо о њима даље.

Са стране отвореног кода

Заједница отвореног кода је активно радила на алатима без сервера последњих неколико година. Највећи играчи на тржишту такође доприносе развоју платформи без сервера:

  • гоогле нуди програмерима свој алат отвореног кода - Кнативе. У његовом развоју учествовали су ИБМ, РедХат, Пивотал и САП;
  • ИБМ- радио на платформи без сервера ОпенВхиск, који је потом постао пројекат Апацхе фондације;
  • Microsoft делимично отворио код платформе Азуре функције.

Развој је такође у току у правцу оквира без сервера. Кубелесс и Фисија распоређени унутар унапред припремљених Кубернетес кластера, ОпенФааС ради са Кубернетес-ом и Доцкер Сварм-ом. Фрамеворк делује као нека врста контролера - на захтев, припрема окружење за извршавање унутар кластера, а затим тамо покреће функцију.

Оквири остављају простор за конфигурисање алата према вашим потребама. Дакле, у Кубелесс-у, програмер може да конфигурише временско ограничење извршавања функције (подразумевана вредност је 180 секунди). Фиссион, у покушају да реши проблем хладног старта, предлаже да се неки контејнери стално раде (иако то подразумева трошкове застоја ресурса). А ОпенФааС нуди скуп покретача за сваки укус и боју: ХТТП, Кафка, Редис, МКТТ, Црон, АВС СКС, НАТ и други.

Упутства за почетак можете пронаћи у званичној документацији оквира. Рад са њима захтева мало више вештина него када радите са провајдером - ово је барем могућност покретања Кубернетес кластера преко ЦЛИ. Укључите највише друге алате отвореног кода (на пример, Кафка менаџер редова).

Без обзира на то како радимо са сервером без сервера – преко провајдера или коришћењем отвореног кода, добићемо бројне предности и недостатке приступа без сервера.

Са становишта предности и мана

Серверлесс развија идеје о контејнерској инфраструктури и приступу микросервиса, у којем тимови могу да раде у вишејезичном режиму без везивања за једну платформу. Изградња система је поједностављена, а грешке се лакше исправљају. Микросервисна архитектура вам омогућава да додате нове функционалности систему много брже него у случају монолитне апликације.

Без сервера још више смањује време развоја, омогућавајући програмеру да се фокусира искључиво на пословну логику и кодирање апликације. Као резултат тога, време за развој тржишта се смањује.

Као бонус, добијамо аутоматско скалирање за оптерећење, а плаћамо само за утрошена средства и само у време када се користе.

Као и свака технологија, Серверлесс има недостатке.

На пример, такав недостатак може бити хладно време почетка (у просеку до 1 секунде за језике као што су ЈаваСцрипт, Питхон, Го, Јава, Руби).

С једне стране, у стварности, време хладног старта зависи од многих варијабли: језика на коме је функција написана, броја библиотека, количине кода, комуникације са додатним ресурсима (исте базе података или сервери за аутентификацију). Пошто програмер контролише ове варијабле, он може смањити време покретања. Али са друге стране, програмер не може да контролише време покретања контејнера - све зависи од провајдера.

Хладан почетак може да се претвори у топли почетак када функција поново користи контејнер покренут претходним догађајем. Ова ситуација ће се појавити у три случаја:

  • ако клијенти често користе услугу и број позива функцији се повећава;
  • ако вам добављач, платформа или оквир дозвољавају да неки контејнери раде све време;
  • ако програмер покреће функције на тајмеру (рецимо свака 3 минута).

За многе апликације, хладан старт није проблем. Овде треба да се ослањате на врсту и задатке услуге. Кашњење почетка од једне секунде није увек критично за пословну апликацију, али може постати критично за медицинске услуге. У овом случају, приступ без сервера вероватно више неће бити прикладан.

Следећи недостатак сервера је кратак животни век функције (временско ограничење током којег функција мора да се изврши).

Али, ако морате да радите са дуготрајним задацима, можете користити хибридну архитектуру - комбиновати Серверлесс са другом технологијом.

Неће сви системи моћи да раде користећи шему без сервера.

Неке апликације ће и даље чувати податке и стање током извршавања. Неке архитектуре ће остати монолитне, а неке карактеристике ће бити дуговечне. Међутим (као и цлоуд технологије, а затим и контејнери), без сервера је технологија са великом будућношћу.

У том смислу, желео бих да глатко пређем на питање коришћења приступа без сервера.

Са стране апликације

За 2018, проценат коришћења без сервера порастао један и по пут. Међу компанијама које су већ имплементирале технологију у своје услуге су такви тржишни гиганти као што су Твиттер, ПаиПал, Нетфлик, Т-Мобиле, Цоца-Цола. У исто време, морате схватити да Серверлесс није панацеја, већ алат за решавање одређеног спектра проблема:

  • Смањите време застоја ресурса. Нема потребе да стално одржавате виртуелну машину за услуге које имају мало позива.
  • Обрадите податке у ходу. Компресујте слике, исеците позадину, промените видео кодирање, радите са ИоТ сензорима, изводите математичке операције.
  • „Залепите” друге услуге заједно. Гит спремиште са интерним програмима, цхат бот у Слацк-у са Јира и календаром.
  • Уравнотежите оптерећење. Хајде да погледамо ближе овде.

Рецимо да постоји услуга која привлачи 50 људи. Испод њега се налази виртуелна машина са слабим хардвером. С времена на време, оптерећење услуге се значајно повећава. Тада слаб хардвер не може да се носи.

У систем можете укључити балансер који ће распоредити оптерећење, рецимо, на три виртуелне машине. У овој фази, не можемо тачно да предвидимо оптерећење, па држимо одређену количину ресурса „у резерви“. И преплаћујемо застоје.

У таквој ситуацији можемо оптимизовати систем хибридним приступом: остављамо једну виртуелну машину иза балансера оптерећења и стављамо везу на крајњу тачку без сервера са функцијама. Ако оптерећење премашује праг, балансер покреће инстанце функције које преузимају део обраде захтева.

Без сервера на полицама
Дакле, Серверлесс се може користити тамо где је потребно обрадити велики број захтева не пречесто, већ интензивно. У овом случају, покретање неколико функција у трајању од 15 минута је исплативије од сталног одржавања виртуелне машине или сервера.

Уз све предности рачунарства без сервера, пре имплементације, прво би требало да процените логику апликације и разумете које проблеме може решити сервер без сервера у одређеном случају.

Без сервера и Селецтел

У Селецтелу смо већ поједностављен рад са Кубернетесом преко наше контролне табле. Сада градимо сопствену ФааС платформу. Желимо да програмери буду у могућности да реше своје проблеме користећи Серверлесс кроз погодан, флексибилан интерфејс.

Ако имате идеје о томе шта би идеална ФааС платформа требало да буде и како желите да користите без сервера у својим пројектима, поделите их у коментарима. Ваше жеље ћемо узети у обзир приликом развоја платформе.
 
Материјали коришћени у чланку:

Извор: ввв.хабр.цом

Додај коментар