Серверную инфраструктуру, как и многие другие услуги, можно получить в облаке и передать все задачи по управлению, поддержке и масштабированию серверов провайдеру. Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, как работает архитектура Serverless и почему стоит попробовать это решение.
Serverless (от англ. «бессерверная») архитектура — это логическое продолжение эволюции облачных сервисов. Бессерверные технологии экономят время на управление серверами и серверными приложениями: все задачи, кроме CI/CD и написания кода, берет на себя провайдер.
В базовый Serverless пакет у большинства провайдеров входят облачные функции (в 2014 году эта технология начиналась с Lambda), контейнеры, object storage, базы данных, Message Queue и API Gateway.
Как и другие облачные модели, Serverless предусматривает альтернативный подход к распределению ресурсов. Во-первых, платить нужно только за фактически потребленные ресурсы. Во-вторых, поставщик серверных услуг автоматически предоставляет необходимое количество мощностей в зависимости от нагрузки.
Все это довольно сильно меняет подход компаний к деплою и обслуживанию приложений. Serverless архитектура подходит не для всех задач. Но если использовать ее по назначению, она обеспечивает команду разработчиков дополнительными ресурсами:
Время
Пока не попробуете Serverless, не почувствуете в полной мере, сколько времени уходит на интеграции, мониторинг, поддержку, отчетность и прочую не имеющую прямого отношения к проекту работу.
Деньги
За счет автоматического масштабирования в Serverless вы можете платить за те ресурсы, которые вам реально нужны. При этом нет риска прогадать с инфраструктурой ни в плюс, ни в минус — то есть купить слишком много или недостаточно.
Безопасность
Не совсем очевидное, но важное преимущество. В Serverless функции живут, только когда мы их запускаем. Соответственно, точек, с помощью которых вас могут взломать и эксплуатировать вашу инфраструктуру, становится значительно меньше.
Как понять, когда выгодно использовать Serverless, а когда нет? Главное: если у вас высокая, предсказуемая и постоянная нагрузка, то этот подход не для вас. Эта архитектура по-настоящему «взлетает» во всех случаях, когда нагрузка меняется: сезонные всплески, приток пользователей по вечерам, запуск рекламной кампании. В таких ситуациях выгоднее платить за те ресурсы, которые вам нужны, а не за оборудование, которое простаивает в ожидании притока пользователей.
Из преимуществ Serverless архитектуры логично следует, что чаще всего ее используют для простых функций, которые выполняют точечные задачи. Чтобы запустить приложения в этой архитектуре, их разбивают на множество микрозадач, и под каждую из них создают отдельную функцию. Они независимы друг от друга и не хранят информацию о состоянии, поэтому приложение будет работать, даже если возникнет проблема с одной из функций.
Разберем пример функции Handler для Telegram-бота. В силу низкой и непостоянной нагрузки, боты — одна из самых частых областей применения Serverless.
На вход принимаем запрос, обрабатываем его и отдаем HTTP ответ клиенту со статусом 200 (положительно). Выбираем язык и то, как мы загружаем (как правило, это встроенный редактор):
Далее указываем точку входа и таймаут:
Это все, что нам нужно сделать, чтобы опубликовать функцию. Обо всем остальном позаботится провайдер.
Даже этот нехитрый процесс можно оптимизировать. Например, написать простой bash-скрипт при помощи API, предоставленного облачным провайдером. После этого мы вообще можем не выходить из IDE, код будет автоматически публиковаться.
Разделение приложений на функции в Serverless помогает экономить: код функций будет исполняться по запросу в автоматически подготовленном контейнере, а платить нужно только за время исполнения. Сравним стоимость Serverless и традиционной архитектуры на примере нескольких простых задач.
Возьмем для примера конвертацию файлов:
Дано:
Запросов: 5 в секунду
Потребляет: 1 CPU, 128 MB RAM
Исполнение: 0,5 с
На стандартном виртуальном сервере нам потребуется:
CPU: 5 RPS x 1 CPU = 5 CPU
RAM: 5 RPS x 128 MB = 640 MB = 0.61 GB
При этом брать, скорее всего, придется больше, так как далеко не все VPS провайдеры позволяют гибко настраивать, сколько ядер и ОЗУ требуется, есть предложения по тарифной сетке.
Допустим, мы взяли тариф на RAM: 12 Гб и CPU: 8. Получаем стоимость: 1 833 рублей в месяц.
В Serverless мы не думаем об инфраструктуре, поэтому параметры для расчета другие:
RAM: 128 MB
Количество вызовов: 12 960 000 в месяц
Исполнение: 0,5 c
Формула выглядит так:
5,47 × ((128 / 1024) × (500 / 3 600 000) × 12 960 000 – 10) + 16 × ((12 960 000 – 1 000 000) / 1 000 000)
Где:
5,47 — цена за 1 ГБ×час
128 / 1024 — перевод МБ в ГБ, так как время выполнения считается в ГБ×час
500 / 3 600 000 — перевод мс в часы, так как время выполнения считается в ГБ×час
10 000 000 — количество вызовов функции
10 — вычитаем, потому что первые 10 ГБ×час не тарифицируются
16 — цена за 1 миллион вызовов функции
12 960 000 — количество вызовов функции
1 000 000 — вычитаем, потому что первые миллион вызовов не тарифицируются
1 000 000 — делим, чтобы посчитать количество миллионов вызовов функции
Итого: 1 367,41 рублей в месяц
Для функций с относительно небольшой нагрузкой Serverless может вообще выходить в ноль, так как фактически количество вызовов покрывается Free Tier, который есть у большинства провайдеров.
Например, у нас есть Telegram-бот, который обрабатывает один запрос в секунду. На пиковой нагрузке потребляет: 100 Мб, выполняется 200 мс. При аренде виртуального сервиса получится около 188 рублей в месяц (опять же, с учетом того, что взять ровно нужное количество мощностей скорее всего не получится).
При работе по Serverless сервис может выйти и вовсе бесплатным, поскольку количество вызовов в месяц попадает под бесплатную планку по тарифной сетке (обычно это первый миллион вызовов).
У функций в этой архитектуре есть и сложности:
Холодный старт
Когда в Serverless вызывается функция, она поднимается с чистого листа — у приложений в этой архитектуре по определению не может быть состояний. Это приводит к небольшому лагу. Многие провайдеры предоставляют дополнительную услугу «горячего старта», когда несколько экземпляров функции держится в быстром доступе.
Время выполнения функции
Провайдеры устанавливают лимит на то, сколько может длиться один вызов функции — обычно это около 5-10 минут, после которых включается таймаут. Поэтому через Serverless нельзя запустить функции, которые длятся дольше определенного периода, например, несколько часов или всю ночь.
Зависимость от провайдера
Вся серверная инфраструктура в этой архитектуре зависит от провайдера — у вас нет никаких настроек, все происходит автоматически. Это здорово и освобождает много времени, но создает свои риски.
Во-первых, провайдера нужно выбирать вдумчиво — доверять лучше стабильным, давно работающим на рынке поставщикам. Во-вторых, с ограничениями платформы вы, в отличие от традиционных серверов, ничего не сможете сделать: настроек нет, подключить дополнительные интеграции нельзя. Поэтому сразу выбирайте поставщика, у которого есть все, что вам может понадобиться.
Разделение приложений на функции многим напомнит о микросервисной архитектуре, и Serverless действительно во многом похожа на нее. Еще точнее ее можно сравнить с Event-driven architecture (EDA) — при разработке под Serverless действуют те же подходы и ограничения. Однако гранулярность здесь гораздо сильнее — функции выполняют единственную задачу: например, в Serverless функции Create, Read будут отдельными микросервисами.
Если мы возьмем классический фреймворк, например, Laravel, то многие функции Serverless будут для нас закрыты. Чтобы обойти эти ограничения, мы можем работать с относительно недавно появившимися в Serverless контейнерами, благодаря которым можно использовать и более редкие языки, например, Haskell или Zig.
Разберем архитектуру на примере корпоративного сайта. Есть статичный контент на фронтенде, и все взаимодействие с многочисленными микрофункциями бэкенда происходит через API Gateway. Каждая функция может обращаться к базам данных, которые тоже работают по Serverless, и дополнительным сервисам, например, почтовым. Все очень похоже на микросервисную архитектуру.
Еще один пример Serverless архитектуры для выполнения одной функции — обработка данных.
Часто Serverless архитектура используется для обработки IoT событий, поскольку нагрузка здесь не постоянная, а периодическая и при этом предсказуемая. Например, счетчики водоснабжения собирают информацию в конце каждого месяца. Вот характерная схема:
Поскольку Serverless подходит не для всех задач, очень часто на проектах используется гибридная архитектура. Например, если мы возьмем тот же корпоративный сайт, держать его весь на бессерверном варианте неудобно — слишком много взаимосвязанных функций. Эффективнее будет перевести в такой режим отдельные задачи, например, генерацию рекомендаций на сайте:
Итак, что мы поняли про Serverless:
Это альтернативный подход к обеспечению серверов: вы платите только за ресурсы, которые фактически используете, а поставщик автоматически предоставляет необходимое количество мощностей.
Serverless лучше всего подходит для приложений с непостоянной и небольшой нагрузкой. Чаще всего по этой схеме запускают функции, которые выполняют микрозадачи в рамках приложения.
Serverless снимает с команды нагрузку, связанную с интеграцией, мониторингом, поддержкой серверов и отчетности по ним.
В силу особенностей архитектуры Serverless подойдет не для всех задач. Но там, где этот подход работает, попробовать его стоит каждой команде. Кроме прямого сокращения расходов он позволяет экономить самый ценный ресурс — время и труд разработчиков.