Serverless - це не про фізичну відсутність серверів. Це не «вбивця» контейнерів і не скороминущий тренд. Це новий підхід до побудови систем у хмарі. У сьогоднішній статті торкнемося архітектури Serverless-додатків, подивимося, яку роль грає провайдер Serverless-послуги та open-source проекти. Насамкінець поговоримо про питання застосування Serverless.
Я хочу написати серверну частину програми (та хоч інтернет-магазину). Це може бути і чат, і сервіс для опублікування контенту, і балансувальник навантаження. У будь-якому разі головного болю буде чимало: доведеться підготувати інфраструктуру, визначити залежності програми, задуматися щодо операційної системи хоста. Потім знадобиться оновити невеликі компоненти, які не торкаються роботи решти моноліту. Ну і про масштабування під навантаженням не забуватимемо.
А якщо взяти ефемерні контейнери, в яких необхідні залежності вже встановлені, а самі контейнери ізольовані один від одного і від ОС хоста? Моноліт розіб'ємо на мікросервіси, кожен з яких можна оновлювати та масштабувати незалежно від інших. Помістивши код у такий контейнер, я зможу запускати його на будь-якій інфраструктурі. Вже краще.
А якщо не хочеться налаштовувати контейнери? Не хочеться думати про масштабування програми. Не хочеться платити за простий запущених контейнерів, коли навантаження на сервіс мінімальне. Хочеться писати код. Зосередитись на бізнес-логіці та випускати продукти на ринок зі швидкістю світла.
Такі думки привели мене до безсерверних обчислень. Serverless у цьому випадку означає не фізична відсутність серверів, а відсутність головного болю з управління інфраструктурою.
Ідея в тому, що логіка програми розбивається на незалежні функції. Вони мають структуру подій. Кожна з функцій виконує одне "мікрозавдання". Все, що потрібно від розробника ― завантажити функції у надану хмарним провайдером консоль та співвіднести їх із джерелами подій. Код буде виконуватися на запит в автоматично підготовленому контейнері, а я заплачу тільки за час виконання.
Давайте розберемося, як тепер виглядатиме процес розробки програми.
З боку розробника
Раніше ми почали говорити про програму для інтернет-магазину. У традиційному підході основну логіку системи виконує монолітний додаток. І сервер із програмою запущений постійно, навіть якщо навантаження немає.
Щоб перейти до serverless, розбиваємо програму на мікрозавдання. Під кожну їх пишемо свою функцію. Функції незалежні друг від друга і зберігають інформацію про стан (stateless). Вони навіть можуть бути написані різними мовами. Якщо одна з них «впаде», програма повністю не зупиниться. Архітектура програми виглядатиме ось так:
Розподіл на функції в Serverless схожий на роботу з мікросервісами. Але мікросервіс може виконувати кілька завдань, а функція в ідеалі має виконувати одну. Уявимо, що стоїть завдання збирати статистику та виводити на запит користувача. У мікросервісному підході завдання виконує один сервіс із двома точками входу: на запис та на читання. У безсерверних обчисленнях це дві різні функції, не пов'язані між собою. Розробник заощаджує обчислювальні ресурси, якщо, наприклад, статистика оновлюється частіше, ніж вивантажується.
Serverless-функції повинні виконуватися за короткий проміжок часу, який визначає провайдер послуги. Наприклад, для 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 розробник може налаштувати часвиконання функції (дефолтне значення ― 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