Как мы разгружаем разработчиков благодаря архитектуре Serverless
Серверную инфраструктуру, как и многие другие услуги, можно получить в облаке и передать все задачи по управлению, поддержке и масштабированию серверов провайдеру. Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, как работает архитектура 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:
1. Это альтернативный подход к обеспечению серверов: вы платите только за ресурсы, которые фактически используете, а поставщик автоматически предоставляет необходимое количество мощностей.
2. Serverless лучше всего подходит для приложений с непостоянной и небольшой нагрузкой. Чаще всего по этой схеме запускают функции, которые выполняют микрозадачи в рамках приложения.
3. Serverless снимает с команды нагрузку, связанную с интеграцией, мониторингом, поддержкой серверов и отчетности по ним.
В силу особенностей архитектуры Serverless подойдет не для всех задач. Но там, где этот подход работает, попробовать его стоит каждой команде. Кроме прямого сокращения расходов он позволяет экономить самый ценный ресурс — время и труд разработчиков.
