Всё, что вы хотели знать о бессерверных технологиях, но боялись спросить

Развитие программного обеспечения и управление им — самые значимые и стремительно развивающиеся области IT. Сегодня, чтобы в условиях высокой конкуренции достичь в этой области хороших результатов, нужно добиться супергибкости и суперскорости разработки, а капиталовложения в инфраструктуру успешно преобразовывать в операционные расходы.

В стремлении к гибкости многие IT‑команды переходят от функциональной структуры к кросс‑функциональной. Так снижается зависимость между отделами, ответственными за тот или иной компонент системы.

Широкое распространение получили гибкие методологии и фреймворки разработки программного обеспечения.

В ответ на новые потребности индустрии провайдеры представили сначала облачные платформы в целом, а затем новую модель размещения и разработки программного обеспечения, известную как Serverless.

Со временем на облачных платформах появились удобные сервисы, объединяющие различные инструменты. Теперь разработчики не задумываются об эксплуатации инфраструктуры и оплачивают только те ресурсы, которые используются для работы приложения.

Serverless в Yandex CloudServerless в Yandex Cloud

Специалисты Yandex Cloud создают множество cloud‑native‑сервисов, назначение которых — предоставить пользователям возможность строить устойчивые, масштабируемые продукты для решения задач клиентов.

Serverless‑инструменты в Yandex Cloud можно разделить на несколько категорий:

При этом платформа постоянно развивается и всё больше сервисов работают по serverless‑модели.

Преимущества ServerlessПреимущества Serverless

В первую очередь следует отметить, что зоны ответственности и операционные задачи по‑разному распределяются между провайдером и клиентом. Отсюда — разные подходы облачных провайдеров к размещению приложений.

Попробуем объединить эти подходы в несколько групп:

• Традиционные сервисы. Пример: приложение и все его компоненты размещаются на виртуальных машинах.

• Управляемые сервисы. Пример: вместо виртуальных машин используются в основном Managed Kubernetes^®, базы данных размещаются в Data Platform.

• Бессерверный подход. Пример: бизнес‑логика работает внутри Cloud Functions, данные хранятся в Object Storage и YDB.

Кто отвечает за выполнение типовых задач при разработке, эксплуатации и запуске приложения:

При традиционных способах размещения приложений в облаке — с помощью виртуальных машин в Compute Cloud — часто возникает желание построить очередную монолитную архитектуру. Такое приложение легко повторить в developer‑среде, оно гораздо проще для быстрого старта, понимания и отладки. Правда, по мере развития вашего сервиса его сложность будет расти по экспоненте, с ним будет интегрироваться всё больше внешних систем — эксплуатация, поддержка и развитие инфраструктуры сильно усложнятся. Взамен вы получаете полную свободу реализации — вместе с ответственностью за надёжность и масштабируемость системы.

Чуть проще ситуация с использованием Kubernetes как основного оркестратора вашей контейнерной инфраструктуры. Здесь ваши бонусы — несложное масштабирование системы, привычный интерфейс для дистрибуции кода в виде контейнера и т. д. Но даже при managed‑решениях в облаке стоимость размещения повышается, а разработчики и инженеры должны хорошо изучить инструмент.

Принципы же создания serverless‑приложений накладывают некоторые ограничения на архитектурные паттерны запускаемого приложения:

• микросервисность;

• ориентация на события в системе;

• слабая связанность и высокая атомарность выполняемых задач.

Таким образом, вы по умолчанию создаёте приложение с гибкой и легко масштабируемой архитектурой, а значит, избежите сложностей с этим по мере развития вашего сервиса.

Заложенная в вашу архитектуру высокая неоднородность выделенных вычислительных ресурсов позволяет экономить там, где нагрузка не носит постоянного, легко прогнозируемого характера, — вы оплачиваете только те ресурсы, которые действительно нужны для выполнения операции.

Ещё один плюс — вам не нужно планировать размер инфраструктуры своего сервиса и закладывать дополнительные ресурсы.

Всё это существенно ускоряет выпуск на рынок новых продуктов и позволяет быстрее разбираться со сложностями эксплуатации больших сервисов.

Специфика serverless‑разработкиСпецифика serverless‑разработки

При всех преимуществах serverless‑подхода мы заинтересованы в надёжной работе инструментов. Поэтому расскажем вам о специфике подхода и затруднениях, с которыми сталкиваются разработчики при реализации бессерверных приложений.

Писать код по‑новомуПисать код по‑новому

При создании бессерверных приложений очень важна событийно ориентированная архитектура (event‑driven architecture, EDA) — современный архитектурный паттерн, построенный из децентрализованных сервисов, которые публикуют, обрабатывают или маршрутизируют события^*. Такой подход облегчает масштабирование, обновление и независимый деплой различных компонентов системы. Само явление не новое. Приложения, построенные на базе происходящих в системе событий, можно встретить не только в serverless‑мире. Но именно здесь такой подход раскрывается целиком, позволяя эффективно использовать все преимущества serverless‑модели.

^* События — сообщения, отправляемые между сервисами.

Бессерверный режим обработки — не для всех нагрузокБессерверный режим обработки — не для всех нагрузок

Serverless ориентируется на события — все операции должны решать одну небольшую задачу и не могут работать в фоне. Сервис не может работать в виде демона и постоянно слушать определённый порт.

Код, запущенный в бессерверном режиме, может быть исполнен, только если вызван через HTTP/HTTPS: напрямую, через триггер или через сервис API Gateway, консолидирующий HTTP‑эндпоинты вашего API.

Изучать новые инструментыИзучать новые инструменты

Это, конечно, не назовёшь страшным недостатком — учиться сейчас приходится постоянно. А Serverless — это целый мир со своим инструментарием, способами тестирования, деплоя и отладки. Вот этот нюанс нужно учесть.

Возможен рост стоимости при интенсивных нагрузкахВозможен рост стоимости при интенсивных нагрузках

Нагрузка на SaaS‑сервисы достаточно неравномерна: днём — выше, ночью падает практически до нуля. Чтобы сохранять устойчивость, нужно покрывать эластичность спроса доступными для сервиса ресурсами, то есть большую часть времени ресурсы простаивают и не используются эффективно.

Serverless решает эту проблему по умолчанию: масштабирование до нуля при отсутствии запросов к сервису. Это позволяет не думать о задачах масштабирования инфраструктуры и даёт экономию.

Но, если нагрузка вашего сервиса хорошо прогнозируема, постоянна и интенсивна, то есть запросы к нему равномерно распределены в течение всего оцениваемого периода, — serverless‑сервисы могут оказаться накладными.

Типовые сценарии для serverless‑архитектурыТиповые сценарии для serverless‑архитектуры

Практически любое современное приложение можно представить как в серверном, так и в бессерверном варианте, ведь большую часть задач можно решать и с помощью serverless‑инструментов, и на виртуальных машинах. Ключевой момент здесь не в том, какую задачу вы хотите решить, а в том, подходит ли задуманная архитектура для реализации в экосистеме Serverless.

Типичный паттерн — событийно‑ориентированное приложение, построенное по принципам EDA.

Рассмотрим задачи, которые несложно решаются при бессерверном подходе.

Event‑driven‑веб‑сервисEvent‑driven‑веб‑сервис

Представим сервис, реализующий вот такую базовую функциональность для пользователя:

• авторизация пользователя;

• просмотр каталога кино;

• выставление оценок понравившейся картине;

• добавление фильма в каталог.

Каждое действие из этого списка можно выразить как событие, происходящее в системе. В качестве точки входа используется сервис API Gateway, который имеет нативную интеграцию с другими сервисами:

• статические объекты находятся в объектном хранилище и доступны с помощью интеграции с сервисом Object Storage;

• динамические элементы сайта формируются с помощью логики, реализованной внутри Cloud Functions и Serverless containers.

Для получения доступа к функциональности сервиса реализуется логика авторизации пользователя через сторонний сервис и авторизационной функции, интегрированной с API Gateway.

Коллекции фильмов мы можем сохранить в Managed YDB, работающей в serverless‑режиме. А для выставления оценок используем отдельную функцию vote‑function, которая запускается с помощью триггера при появлении сообщения в очереди YMQ. Информацию о выставленных оценках можем также складывать в поток votes‑stream для перекладывания и трансформации данных для дальнейшего анализа. Также мы можем пополнять нашу коллекцию из внешних источников с помощью импортирующей данные функции.

MicroserviceMicroservice

Serverless можно интегрировать в инфраструктуру отдельными микросервисами. Так вы получаете высокую скорость разработки новых возможностей, не меняя общей архитектуры своего приложения.

Для примера рассмотрим сервис загрузки, конвертации и просмотра видео. Сервис можно реализовать с использованием виртуальных машин Compute Cloud и расширить его функциональность serverless‑инструментами — Cloud Functions и Message Queue.

Для загрузки видеозаписей используется Object Storage, что позволяет недорого хранить довольно объёмные файлы.

Конвертация видеофайлов может потребовать аппаратных ресурсов (ASIC‑/FPGA‑чипы или GPU), и эту логику удобно оставить в существующем контуре виртуальных машин или нод Kubernetes‑кластера.

После загрузки файла мы хотим записать его метаданные в отдельную базу, которую можно будет использовать потом для поиска файлов по разным параметрам.

Также метаданные позволяют формировать рекомендации по похожим видеофайлам и выдавать их вместе с результатами поиска или на странице просмотра отдельных файлов. Операции поиска и формирования рекомендаций не носят постоянного характера и отличаются предсказуемо коротким временем обработки запроса. Поскольку такие операции могут быть запрошены параллельно для разных пользователей, число которых сильно варьируется, их можно вынести в отдельные функции, которые разбирают очередь Message Queue по триггеру.

Работа с даннымиРабота с данными

Serverless‑инструменты также предоставляют широкие возможности работы с данными. Например, иногда при построении единого хранилища данных, необходимых для анализа, мы объединяем их из разных внешних источников и приводим в единый формат хранения. Новые данные постоянно поступают, и нужно поддерживать их потоковую загрузку:

• принять эти данные;

• трансформировать;

• сохранить;

• прочитать.

Для приёма данных из разных источников по HTTP мы можем использовать связку API Gateway → Data Streams → Cloud Functions / Data Transfer. Это позволит нам в потоковом режиме принимать, трансформировать и сохранять данные в хранилища Managed ClickHouse и Object Storage, из которых их удобно визуализировать с помощью DataLens или анализировать с использованием Yandex Query.

Многие сценарии изложены в практических руководствах и показаны на вебинарах.

Как сравнить стоимость serverless‑подхода и традиционных подходовКак сравнить стоимость serverless‑подхода и традиционных подходов

Два противоположных мнения о стоимости Serverless: дёшево и дорого — и оба справедливы, всё зависит от ситуации.

Например, при реализации сценариев, для которых предполагается плавающая и неравномерная нагрузка, стоимость самого решения часто ниже, чем реализация этого же сценария на виртуальных машинах или в кластере Kubernetes.

Так, если разместить часть компонентов из сценария Microservice для конвертации видеофайлов из примера выше, в существующем кластере Kubernetes и предположить, что:

• сервис поиска вызывается в среднем 5 раз в секунду;

• сервис формирования рекомендаций (а его имеет смысл вызывать при каждом обращении для просмотра конкретных видеофайлов) вызывается в среднем 90 раз в секунду;

• выполнение каждого запроса потребляет 1 CPU и 256 MB RAM, а время исполнения запроса составляет 0,5 с, —

то для осуществления работы обоих сервисов нам понадобится:

• 95 CPU

• 24 (256×95/1000) GB RAM в месяц (среднее потребление ресурсов/сек).

Если использовать текущую тарификацию ресурсов в Yandex Cloud, то конфигурация 96 CPU/96 GB RAM (минимальная доступная конфигурация с 96 ядрами) на момент написания статьи составляет порядка 92 000  руб/мес. А также необходимо позаботиться об отказоустойчивости и потенциальной масштабируемости решения, что также увеличит стоимость решения.

Если реализовать данные микросервисы с использованием Cloud Functions, то получаем следующий расчёт:

5,47 × ((256 / 1024) × (500 / 3 600 000) × 246 240 000 — 10) + 16 × ((246 240 000 — 1 000 000) / 1 000 000) = 50637,64.

Подробное пояснение о том, как тарифицируются облачные функции можно найти в документации.

Верно и обратное: перенос постоянной и высокой нагрузки на бессерверную инфраструктуру может обойтись дороже, чем при традиционном подходе.

Обеспечение непрерывной работы, масштабирование под нагрузку — это всегда время и усилия инженеров. Сервисы, построенные по бессерверной модели, призваны сместить фокус инженеров с эксплуатации на добавление ценности: создание новых возможностей, упрощение системы доставки кода, сокращение времени выпуска продукта и т. д.

Бонусом становятся расширенные возможности для контроля стоимости решения и FinOps при использовании Serverless, поскольку приложение, реализованное в бессерверной архитектуре, имеет высокую степень гранулярности ресурсов.

Что значит быть cloud‑native?Что значит быть cloud‑native?

В этой статье мы рассмотрели преимущества и недостатки serverless‑подхода в облаке, узнали, проекты каких архитектур могут быть разработаны или перенесены в бессерверную инфраструктуру полностью, а какие — частично.

Yandex Cloud даёт большую свободу выбора сервисов, и нет необходимости выбирать что‑то одно. Быть cloud‑native — это значит комбинировать все инструменты платформы, обладать гибкостью, выбирать наиболее эффективное решение для текущих и будущих задач.

Happy Coding!