Serverless ― гэта не пра фізічную адсутнасць сервераў. Гэта не "забойца" кантэйнераў і не мімалётны трэнд. Гэта новы падыход да пабудовы сістэм у воблаку. У сённяшнім артыкуле кранем архітэктуры Serverless-прыкладанняў, паглядзім, якую ролю гуляе правайдэр Serverless-паслугі і open-source праекты. У канцы пагаворым аб пытаннях ужывання Serverless.
Я хачу напісаць серверную частку прыкладання (ды хоць інтэрнэт-крамы). Гэта можа быць і чат, і сэрвіс для публікацыі кантэнту, і балансавальнік нагрузкі. У любым выпадку галаўнога болю будзе нямала: давядзецца падрыхтаваць інфраструктуру, вызначыць залежнасці прыкладання, задумацца наконт аперацыйнай сістэмы хаста. Потым спатрэбіцца абнавіць невялікія кампаненты, якія не закранаюць працу астатняга маналіта. Ды і пра маштабаванне пад нагрузкай не будзем забываць.
А што калі ўзяць эфемерныя кантэйнеры, у якіх патрабаваныя залежнасці ўжо прадусталяваныя, а самі кантэйнеры ізаляваныя сябар ад сябра і ад АС хаста? Маналіт разаб'ём на мікрасэрвісы, кожны з якіх можна абнаўляць і маштабаваць незалежна ад іншых. Змясціўшы код у такі кантэйнер, я змагу запускаць яго на любой інфраструктуры. Ужо лепш.
А калі не жадаецца наладжваць кантэйнеры? Не хочацца думаць пра маштабаванне дадатку. Не жадаецца плаціць за просты запушчаных кантэйнераў, калі нагрузка на сэрвіс мінімальная. Жадаецца пісаць код. Засяродзіцца на бізнес-логіцы і выпускаць прадукты на рынак з хуткасцю святла.
Такія думкі прывялі мяне да бессерверных вылічэнняў. Serverless у дадзеным выпадку азначае не фізічная адсутнасць сервераў, а адсутнасць галаўнога болю па кіраванні інфраструктурай.
Ідэя ў тым, што логіка дадатку разбіваецца на незалежныя функцыі. Яны маюць падзейную структуру. Кожная з функцый выконвае адну "мікразадачу". Усё, што патрабуецца ад распрацоўніка ― загрузіць функцыі ў прадстаўленую хмарным правайдэрам кансоль і суаднесці іх з крыніцамі падзей. Код будзе выконвацца па запыце ў аўтаматычна падрыхтаваным кантэйнеры, а я заплачу толькі за час выканання.
Давайце разбяромся, як зараз будзе выглядаць працэс распрацоўкі прыкладання.
З боку распрацоўшчыка
Раней мы пачалі казаць пра прыкладанне для інтэрнэт-крамы. У традыцыйным падыходзе асноўную логіку сістэмы выконвае маналітнае дадатак. І сервер з дадаткам запушчаны ўвесь час, нават калі нагрузкі няма.
Каб перайсці да serverless, разбіваем дадатак на мікразадачы. Пад кожную з іх пішам сваю функцыю. Функцыі незалежныя сябар ад сябра і не захоўваюць інфармацыю аб стане (stateless). Яны нават могуць быць напісаны на розных мовах. Калі адна з іх «упадзе», прыкладанне цалкам не спыніцца. Архітэктура прыкладання будзе выглядаць вось так:
Дзяленне на функцыі ў Serverless падобна на працу з мікрасэрвісамі. Але мікрасэрвіс можа выконваць некалькі задач, а функцыя ў ідэале павінна выконваць адну. Уявім, што стаіць задача збіраць статыстыку і выводзіць па запыце карыстальніка. У мікрасэрвісным падыходзе задачу выконвае адзін сервіс з двума кропкамі ўваходу: на запіс і на чытанне. У бессерверных вылічэннях гэта будуць дзве розныя функцыі, не злучаныя паміж сабой. Распрацоўнік эканоміць вылічальныя рэсурсы, калі, напрыклад, статыстыка абнаўляецца часцей, чым выгружаецца.
Serverless-функцыі павінны выконвацца за кароткі прамежак часу (timeout), які вызначае правайдэр паслугі. Напрыклад, для AWS timeout складае 15 хвілін. Значыць, доўгажывучыя функцыі (long-lived) давядзецца змяніць пад патрабаванні ― гэтым Serverless адрозніваецца ад іншых папулярных сёння тэхналогій (кантэйнераў і Platform as a Service).
Кожнай функцыі прызначаем падзею. Падзея ― гэта трыгер для дзеяння:
Падзея
Дзеянне, якое выконвае функцыя
У сховішча загрузілі карцінку тавару.
Сціснуць карцінку і выгрузіць у каталог
У базе даных абнавіўся адрас фізічнай крамы
Падгрузіць у карты новае месцазнаходжанне
Кліент аплачвае тавар
Запусціць апрацоўку плацяжу
Падзеямі могуць выступаць HTTP-запыты, струменевыя дадзеныя, чэргі паведамленняў і гэтак далей. Крыніцы падзей ― гэта змена ці з'яўленне дадзеных. Акрамя таго, функцыі можна запускаць па таймеры.
Архітэктуру прапрацавалі, і дадатак амаль стала serverless. Далей ідзем да правайдэра паслугі.
З боку правайдэра
Звычайна бессерверныя вылічэнні прапануюць правайдэры хмарных паслуг. Завуць па-рознаму: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Карыстацца паслугай будзем праз кансоль ці асабісты кабінет правайдэра. Код функцый можна загрузіць адным са спосабаў:
- напісаць код ва ўбудаваных рэдактарах праз вэб-кансоль,
- загрузіць архіў з кодам,
- працаваць з публічнымі або прыватнымі git-рэпазітарамі.
Тут жа наладжваем падзеі, якія выклікаюць функцыю. У розных правайдэраў наборы падзеяў могуць адрознівацца.
Правайдэр на сваёй інфраструктуры пабудаваў і аўтаматызаваў сістэму Function as a Service (FaaS):
- Код функцый пападае ў сховішча на боку правайдэра.
- Калі з'яўляецца падзея, на серверы аўтаматычна разгортваюцца кантэйнеры з падрыхтаваным асяроддзем. Кожнаму экзэмпляру функцыі ― свой ізаляваны кантэйнер.
- Са сховішча функцыя адпраўляецца ў кантэйнер, вылічаецца, аддае вынік.
- Колькасць паралельных падзей расце - расце колькасць кантэйнераў. Сістэма аўтаматычна маштабуецца. Калі карыстачы не звяртаюцца да функцыі, яна будзе неактыўная.
- Правайдэр задае час прастою кантэйнераў ― калі на працягу гэтага часу функцыі не з'яўляюцца ў кантэйнеры, ён знішчаецца.
Такім чынам мы атрымліваем Serverless "са скрынкі". Плаціць за паслугу будзем па мадэлі pay-as-you-go і толькі за тыя функцыі, якія выкарыстоўваюцца, і толькі за той час, калі яны выкарыстоўваліся.
Каб пазнаёміць распрацоўшчыкаў з паслугай, правайдэры прапануюць да 12 месяцаў бясплатнага тэсціравання, але абмяжоўваюць агульны час вылічэнняў, колькасць запытаў у месяц, грашовыя сродкі або спажываныя магутнасці.
Асноўная перавага працы з правайдэрам - магчымасць не турбавацца аб інфраструктуры (серверах, віртуальных машынах, кантэйнерах). Са свайго боку правайдэр можа рэалізаваць FaaS як на ўласных распрацоўках, так і з дапамогай open-source прылад. Пра іх і пагаворым далей.
З боку open source
Апошнія некалькі гадоў суполка open-source актыўна працуе над інструментамі Serverless. У тым ліку фундуш у развіццё бессерверных платформаў уносяць найбуйныя гульцы рынка:
- Google прапануе распрацоўшчыкам свой open-source інструмент ― . У яго распрацоўцы ўдзельнічалі IBM, RedHat, Pivotal і SAP;
- IBM працавалі над Serverless-платформай , якая затым стала праектам Apache Foundation;
- Microsoft часткова адкрылі код платформы .
Распрацоўкі вядуцца і ў напрамку serverless-фрэймворкаў. и разгортваюцца ўнутры загадзя падрыхтаваных Kubernetes-кластэраў, працуе як з Kubernetes, так і з Docker Swarm. Фрэймворк выступае ў ролі своеасаблівага кантролера ― па запыце рыхтуе ўнутры кластара асяроддзе выканання, потым запускае там функцыю.
Фрэймворкі пакідаюць прастору для канфігурацыі прылады пад свае патрэбы. Так, у Kubeless распрацоўшчык можа наладзіць timeout выканання функцыі (дэфолтнае значэнне ― 180 секунд). Fission у спробе вырашыць праблему халоднага старту прапануе частку кантэйнераў трымаць увесь час запушчанымі (хоць гэта і цягне выдаткі на просты рэсурсаў). А OpenFaaS прапануе набор трыгераў на любы густ і колер: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs і іншыя.
Інструкцыі да пачатку працы можна знайсці ў афіцыйнай дакументацыі фрэймворкаў. Праца з імі мае на ўвазе наяўнасць крыху большай колькасці навыкаў, чым пры працы з правайдэрам ― гэта як мінімум уменне запусціць Kubernetes-кластар праз CLI. Максімум, уключыць у працу іншыя open-source прылады (дапусцім, мэнэджар чэргаў Kafka).
Незалежна ад таго, якім спосабам мы будзем працаваць з Serverless - праз правайдэра або з дапамогай open-source, мы атрымаем шэраг пераваг і недахопаў Serverless-падыходу.
З пазіцыі пераваг і недахопаў
Serverless развівае ідэі кантэйнернай інфраструктуры і мікрасэрвіснага падыходу, пры якіх каманды могуць працаваць у мультымоўным рэжыме, не прывязваючыся да адной платформы. Пабудова сістэмы спрашчаецца, а выпраўляць памылкі робіцца лягчэй. Мікрасэрвісная архітэктура дазваляе дадаваць у сістэму новы функцыянал значна хутчэй, чым у выпадку з маналітным дадаткам.
Serverless скарачае час распрацоўкі яшчэ больш, дазваляючы распрацоўніку засяродзіцца выключна на бізнес-логіцы прыкладання і напісанні кода. Як следства, час выхаду распрацовак на рынак скарачаецца.
Бонусам мы атрымліваем аўтаматычнае маштабаванне пад нагрузку, а плацім толькі за выкарыстоўваныя рэсурсы і толькі ў той час, калі яны выкарыстоўваюцца.
Як і любая тэхналогія, Serverless мае недахопы.
Напрыклад, такім недахопам можа быць час халоднага старту (у сярэднім да 1 секунды для такіх моў як JavaScript, Python, Go, Java, Ruby).
З аднаго боку, на справе час халоднага старту залежыць ад шматлікіх зменных: мова, на якім напісана функцыя, колькасць бібліятэк, аб'ём кода, зносіны з дадатковымі рэсурсамі (тыя ж базы дадзеных або серверы аўтэнтыфікацыі). Паколькі распрацоўшчык кіруе гэтымі зменнымі, ён можа скараціць час старту. Але з іншага боку, распрацоўшчык не можа кіраваць часам запуску кантэйнера ― тут усё залежыць ад правайдэра.
Халодны старт можа ператварыцца ў цёплы, калі функцыя перавыкарыстоўвае запушчаны папярэднім івэнтам кантэйнер. Такая сітуацыя ўзнікне ў трох выпадках:
- калі кліенты часта выкарыстоўваюць сэрвіс і расце колькасць зваротаў да функцыі;
- калі правайдэр, платформа ці фрэймворк дазваляюць трымаць частку кантэйнераў запушчанымі ўвесь час;
- калі распрацоўшчык запускае функцыі па таймеры (скажам, кожныя 3 хвіліны).
Для многіх прыкладанняў халодны старт не праблема. Тут трэба адштурхоўвацца ад тыпу і задачаў сэрвісу. Затрымка старту на секунду не заўсёды крытычная для бізнэс-прыкладанні, але можа стаць крытычнай для медыцынскіх службаў. Верагодна, у гэтым выпадку бессерверны падыход ужо не падыдзе.
Наступным недахопам Serverless называюць кароткі час жыцця функцыі (timeout, за які функцыя павінна выканацца).
Але, калі маецца быць працаваць з доўгажывучымі задачамі, можна выкарыстоўваць гібрыдную архітэктуру - скамбінаваць Serverless з іншай тэхналогіяй.
Не ўсе сістэмы змогуць працаваць па Serverless-схеме.
Некаторыя прыкладанні па-ранейшаму будуць захоўваць дадзеныя і стан падчас выканання. Некаторыя архітэктуры застануцца маналітнымі, а некаторыя функцыі будуць даўгавечнымі. Аднак (як калісьці хмарныя тэхналогіі, а затым і кантэйнеры), Serverless ― тэхналогія з вялікай будучыняй.
У гэтым ключы мне б жадалася плыўна перайсці да пытання ўжывання Serverless-падыходу.
З боку прымянення
За 2018 год працэнт выкарыстання Serverless . Сярод кампаній, якія ўжо ўкаранілі тэхналогію ў свае сэрвісы, такія гіганты рынку як Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Пры гэтым трэба разумець, што Serverless ― не панацэя, а інструмент для вырашэння пэўнага кола задач:
- Скараціць просты рэсурсаў. Не трэба ўвесь час трымаць віртуальную машыну пад сэрвісы, да якіх мала зваротаў.
- "На лёце" апрацаваць дадзеныя. Сціскаць карцінкі, выразаць фон, мяняць кадоўку відэа, працаваць з датчыкамі IoT, выконваць матэматычныя аперацыі.
- "Склеіць" паміж сабой іншыя сэрвісы. Git-рэпазітар з унутранымі праграмамі, чат-бот у Slack з Jira і з календаром.
- Балансаваць нагрузку. Тут спынімся падрабязней.
Дапушчальны, ёсць сэрвіс, на які прыходзіць 50 чалавек. Пад яго стаіць віртуальная машына са слабым жалезам. Перыядычна нагрузка на сэрвіс узрастае ў разы. Тады слабое жалеза не спраўляецца.
Можна ўключыць у сістэму балансавальнік, які будзе размяркоўваць нагрузку, скажам, на тры віртуальныя машыны. На дадзеным этапе мы не можам дакладна спрагназаваць нагрузку, таму нейкую колькасць рэсурсаў трымаем запушчанымі "пра запас". І пераплачваем за просты.
У такой сітуацыі мы можам аптымізаваць сістэму праз гібрыдны падыход: за балансавальнікам нагрузкі пакідаем адну віртуальную машыну і ставім спасылку на Serverless Endpoint з функцыямі. Калі нагрузка перавышае парог ― балансавальнік запускае асобнікі функцый, якія бяруць на сябе частку апрацоўкі запытаў.
Такім чынам, Serverless можна выкарыстоўваць там, дзе даводзіцца не занадта часта, але інтэнсіўна апрацоўваць вялікую колькасць запытаў. У гэтым выпадку запускаць некалькі функцый на 15 хвілін больш выгадна, чым увесь час трымаць віртуальную машыну або сервер.
Пры ўсіх перавагах бессерверных вылічэнняў, перад укараненнем у першую чаргу варта ацаніць логіку прыкладання і зразумець, якія задачы зможа вырашыць Serverless у пэўным выпадку.
Serverless і Selectel
У Selectel мы ўжо праз нашу панэль кіравання. Цяпер мы будуем уласную FaaS-платформу. Мы жадаем, каб распрацоўнікі маглі вырашаць свае задачы з дапамогай Serverless праз зручны, гнуткі інтэрфейс.
Калі ў вас ёсць ідэі, якой павінна быць ідэальная FaaS-платформа і як вы жадаеце выкарыстоўваць Serverless у сваіх праектах, падзяліцеся імі ў каментарах. Мы ўлічым вашыя пажаданні пры распрацоўцы платформы.
Матэрыялы, выкарыстаныя ў артыкуле:
Крыніца: habr.com