Rambler's Top100
 
Статьи ИКС № 1 2022
Николай НОСОВ  31 января 2022

Бессерверные вычисления вчера, сегодня, завтра

Облака прочно вошли в нашу жизнь. Стремление максимально гибко разворачивать и запускать в облаках приложения и столь же гибко оплачивать необходимые для их выполнения облачные ресурсы привело к появлению бессерверных вычислений.

Чтобы объединиться, надо размежеваться

Помимо традиционных монолитных приложений, которые создаются как единое целое и в рамках которых запускается несколько подзадач, в последнее время стали широко использоваться микросервисы. Микросервисы работают как небольшие отдельные сервисы (блоки кода), которые соединяются вместе, образуя комплексное приложение. В качестве следующего шага по дезагрегации приложений можно рассматривать выделение функций – небольших фрагментов кода, выполняющих определенные запросы (рис. 1). Хотя функции не заменяют монолитные приложения или микросервисы, они предоставляют разработчикам большую операционную гибкость при создании, развертывании и запуске приложений.
 
Рис. 1. Дезагрегация облачных архитектур

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

Более сложная задача – обеспечить поставки товара производителя в магазины. Совершенно неэффективно, скажем, отправлять авторефрижераторы с рыбой из Владивостока в Москву. Лучше разбить задачу на подзадачи (микросервисы). Одна подзадача – доставить рыбу с рыболовного судна на склад во Владивостоке. Другая – со склада в аэропорт. Третья – отправить самолетом в Москву. Четвертая – перевезти на склад в Подмосковье. Пятая – отгрузить со склада в московский магазин. На каждом этапе работу выполняют несколько транспортных средств, поэтому выход из строя одной машины не приведет к остановке бизнеса. Без прерывания поставки при необходимости проводится ремонт машин и обновляется их парк (модифицируется ПО), причем делают это разные ремонтные мастерские (команды разработчиков).

Арендованными машинами (серверами) надо заниматься: вести, заправлять бензином. Да и оплата взимается в лучшем случае за день использования, чаще за месяц или год. Так и виртуальный сервер тоже требует администрирования. А пользователю (разработчику) нужна не машина как таковая, а услуги, функции, выполняющие его задачи. Например, услуги (функции) погрузки рыбы в машину, перевозки с нужным температурным режимом, доставки ее потребителю. И желательно платить только за полученный сервис.

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

Вчера и сегодня

Бессерверные вычисления (serverless computing) – стратегия организации платформенных облачных услуг, в рамках которой облако автоматически и динамически управляет выделением вычислительных ресурсов в зависимости от пользовательской нагрузки. Наиболее популярный вариант – реализация шаблона «функция как услуга» (Function as a Service, FaaS), в котором для выполнения каждого запроса (вызова функции) создается отдельный контейнер или виртуальная машина, уничтожающиеся после его выполнения.

«Бессерверный» не означает, что серверов нет. Просто пользователю не нужно иметь дело с выделением и настройкой инфраструктурных единиц – виртуальных машин или контейнеров; программных серверов – баз данных, приложений, экземпляров сред выполнения. Все это скрыто от него и управляется облаком. При этом выполняемый по бессерверной модели код может быть частью приложений, использующих традиционные и микросервисные архитектуры.

Cервис FaaS появился в 2014 г.– его предложила американская компания Hook.io. Через пять месяцев AWS представила сервис Lambda. В ноябре 2016 г. FaaS начали продаваться в облаке Azure (Azure Functions), а в июле 2018-го – в облаке Google (Google Cloud Functions). Помимо названных компаний в число лидеров рынка FaaS входят IBM и китайская Alibaba. Согласно отчету о состоянии облачных вычислений Flexera 2020, руководители компаний включают бессерверные вычисления в пятерку самых быстроразвивающихся облачных сервисов (рис. 2).
 
Рис. 2. Рейтинг облачных сервисов по темпам роста

В силу широкого распространения контейнерных технологий сегодня помимо использования функций как сервис все больше востребован запуск контейнеров по бессерверной модели, причем как с возможностью создания этих контейнеров из исходного кода на лету, так и на базе образов контейнеров, размещенных в публичных или частных репозиториях. В качестве примера можно привести сервис Code Engine в облаке IBM Cloud. 

Развитием этого направления стали бессерверные сервисы аналитики. ETL-обработку (Extract, Transform, Load) и другие операции с данными теперь удобнее выполнять с помощью решений на базе бессерверного фреймворка для распределенной обработки слабоструктурированных данных Serverless Spark, задействуя объектное хранение данных вместо распределенного HDF-хранилища, требующего постоянно работающей и дорогостоящей инфраструктуры. Важное дополнение – сервисы Serverless SQL, такие как SQL-Query в IBM Cloud. Они позволяют работать с файлами, находящимися в объектных хранилищах, и на лету преобразовать их в табличные представления без использования традиционных СУБД.

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

Артем Носенко, ведущий архитектор по облачным сервисам в России, IBM

Бочка меда: преимущества бессерверных вычислений
  • Развитие микросервисов и бессерверных вычислений коренным образом меняет практику DevOps, размывая грань между разработкой и штатными операциями, обеспечивая быстрое предоставление новых продуктов, повышающих ценность бизнеса. Приложения, предназначенные для выполнения по бессерверной модели, обладают рядом преимуществ перед традиционными монолитными.
  • Высокая отказоустойчивость. При сбое контейнера с одной из функций остальные остаются в строю, и работа не останавливается.
  • Гибкость. Можно экспериментировать и внедрять новые технологии «малой кровью». Меняя локально одну из функций, программист не рискует всей системой. При этом требуется меньше времени для внесения изменений, а при неудаче их легко «откатить» назад.
  • Простота. Чем меньше кода, тем проще программистам понимать, как работает конкретная функция, поскольку не нужно разбираться в огромном количестве деталей, ее не касающихся. Кроме того, на это уходит меньше времени.
  • Легкость выведения написанного кода в работу. Небольшое количество кода обеспечивает быстрое развертывание.
  • Масштабируемость. Если возникнет необходимость, систему можно дополнить и расширить нужными функциями. Система в целом при этом останется прежней.
Многие из перечисленных преимуществ унаследованы от микросервисной архитектуры. По сравнению с ней serverless-сервисы еще больше сокращают время разработки, позволяя разработчику сосредоточиться исключительно на бизнес-логике приложения и написании кода. Как следствие, время вывода продукта на рынок сокращается, снижаются затраты на инфраструктуру. Клиент платит только за потребляемые ресурсы и только в то время, когда они используются.

Бессерверные вычисления выгодно задействовать в тестовых проектах – это самый экономный из всех возможных вариантов. При малом количестве обращений к приложению расходы на сервис незаметны. То же касается и бессерверных баз данных. Данных мало, и их хранение в облаке обойдется дешево.

Технологию можно применять и в промышленных решениях. 

 
Бессерверные вычисления целесообразно задействовать для простых задач, не требующих разбиения на большое число функций. Для сложных систем такая архитектура получится слишком хрупкой, зависящей от огромного количества настроек, что приведет к появлению ошибок. Однако технология пригодна для оперативного решения временной проблемы. Например, в монолитном приложении выявлена ошибка, которую надо срочно устранить, а новый релиз будет через месяц. Можно использовать serverless-функцию и пустить через нее часть трафика. А после штатной реализации функцию удалить. 

Павел Кутаков, архитектор облачных решений, Huawei

Функции могут вызываться не только по внешним событиям, но и по внутренним, полученным из систем мониторинга. В этом случае функции можно применять для управления облачной инфраструктурой, например, для автоматического добавления ресурсов из-за возросшей нагрузки. Serverless-функции хорошо интегрированы с облачным API и могут автоматизировать нетривиальные, не покрываемые облаком процессы. Простейший вариант – отправка уведомления в Telegram.

Ложка дегтя: ограничения и недостатки

Недостатки бессерверных вычислений также обусловлены их микросервисной природой.
  • Прежде всего, сложно выстраивать коммуникации между блоками (сервисами, функциями) при обмене запросами и ответами. Разбиение приложения на микросервисы уже затрудняет управление системой. Дальнейшее разбиение на функции делает задачу еще более сложной. Каждая функция изолирована, и с увеличением их числа растет сложность взаимодействия.
  • Рост числа функций и сервисов влечет за собой и рост числа баз данных, к которым они обращаются, поскольку в отличие от монолитной архитектуры используют не одну общую базу данных.
  • При тестировании системы сначала нужно тестировать каждую функцию и сервис в отдельности, а потом проверять корректность их взаимодействия.
  • Мониторинг архитектуры гораздо труднее настраивать, и он требует больших затрат на поддержку, нежели мониторинг монолитного приложения.
  • Сложность архитектуры приводит к сложности защиты и повышению рисков информационной безопасности.
Важный недостаток по сравнению с микросервисной архитектурой – «холодный» запуск функций (он требует в среднем до 1 с для таких языков, как JavaScript, Python, Go, Java, Ruby) – следствие выигрыша в стоимости из-за оплаты по факту использования.

Смягчить проблему «холодного» запуска, по мнению ведущего архитектора по облачным сервисам IBM в России Антона Носенко, может совершенствование вычислительной инфраструктуры для уменьшения задержек при работе распределенных узлов и оптимизация работы планировщиков. Например, компания IBM в целях повышения скорости развертывания ресурсов и улучшения характеристик запуска функций предложила облачную инфраструктуру VPC gen2 и драйверы для сетевого стека и хранилищ, а также адаптировала возможности Kubernetes для использования в качестве основы serverless-услуг.


Скорость «холодного» запуска можно увеличить за счет применения мультитенантной платформы и механизмов предсказания нагрузок.

Илья Казначеев, руководитель направления контейнерных приложений, #CloudMTS 

Практически у всех операторов serverless-сервисов первый запуск будет «холодным», но если новый пользователь придет через пару минут, то для него он уже будет «горячим».

Serverless в России

Предпосылкой для работы serverless-платформы является наличие у провайдера современной массивной распределенной инфраструктуры, которая дает возможность множеству пользователей запрашивать и получать необходимые ресурсы. Причем тут требуется еще более тщательный контроль за изоляцией исполняемого кода, оптимизация работы планировщиков и среды комплексного управления этой платформой, а также система учета машинного времени, позволяющая корректно рассчитывать стоимость услуг, оказание которых занимает всего несколько секунд. «Российские облачные провайдеры стараются предоставить все эти возможности, но, судя по всему, с некоторым отставанием, поскольку их вычислительные мощности и количество локаций ограничены. Поэтому пока на местном рынке в основном представлены serverless-функции», – пояснил Артем Носенко.

Несмотря на небольшое отставание, предложения от российских облачных провайдеров имеются. Простой вариант есть в портфеле Selectel. Код загружается в панель my.selectel.ru, для него провайдер создает контейнер. Код запускается по срабатыванию триггера функции, после ее выполнения работа контейнера завершается. Оплачивается только время работы функции. Сервис действует на базе платформы с открытым исходным кодом Apache OpenWhisk.

Более сложный сервис, включающий базу банных, предоставляет из своего облака «Яндекс» (рис. 3). Доступ к шлюзу API возможен через веб-браузер, мобильное приложение или запрос от устройства. Для данных задействуются объектное хранилище, база данных Yandex и PostgreSQL. Причем serverless-сервисы «Яндекс.Облако» совместимы с AWS и могут использовать некоторые присущие последнему методы интеграции, например, HTTP API Amazon S3, сервис очередей сообщений Amazon SQS, систему управления базами данных класса NoSQL в формате «ключ – значение», DynamoDB.
 
Рис. 3. Архитектура serverless-сервисов «Яндекс. Облако»

Своя изюминка есть и у провайдера SberCloud. Помимо ставшего стандартным «код как сервис» FunctionGraph, который эквивалентен AWS Lambda, из облака SberCloud.Advanced провайдер предлагает по бессерверной модели кластер Hadoop – сервис Data Lake Insight (serverless-сервис для Big Data). Он будет экономически выгоден в тех случаях, когда задач для полноценного кластера Hadoop слишком мало. Исходя из того, что сервис используется для решения сложных задач, применяется не посекундная, а почасовая тарификация. DLI более релевантен для обработки данных в офлайн-режиме.

«Иногда Serverless Hadoop можно задействовать и для анализа данных в режиме реального времени. Например, для одного из заказчиков проводился сбор телеметрии с более чем 1 млн устройств, присылающих пакет раз в минуту. Сервис DLI справлялся с нагрузкой при 100 тыс. запросов в секунду, при этом нам не требовалось заботиться о вычислительном кластере», – рассказал архитектор облачных решений Huawei Павел Кутаков. 

Бессерверные вычисления завтра

Технология serverless прошла пик хайпа, заняла свою нишу на облачном рынке и быстро ее осваивает. По прогнозам Mordor Intelligence, в 2021–2026 гг. среднегодовой темп роста превысит 23,17%. 

«Serverless-сервисы используются, когда нужно обеспечить быстрый запуск и снизить затраты на администрирование продукта. Считаю, что в будущем популярны будут serverless-решения, предоставляющие клиенту бесшовную интеграцию с другими составляющими облачного ландшафта – загрузкой файлов, запланированными событиями, очередями сообщений, триггерами баз данных и т.п.», – прогнозирует руководитель направления контейнерных приложений #CloudMTS Илья Казначеев.

По мнению эксперта, в ближайшее время существенное влияние на рынок окажут платформы, построенные на базе Kubernetes. Поскольку Kubernetes является стандартом де-факто современной ИТ-платформы, решения, построенные на его основе, будут быстро внедряться, легко сопровождаться и просто тиражироваться. Однако останется ниша и для более низкоуровневых решений, сфокусированных на производительности. Их бесшовная интеграция обеспечивается за счет грамотного построения инфраструктуры сервисов конкретного облачного провайдера. В этом плане более «стандартизированные» решения на базе Kubernetes – первый кандидат на успешную интеграцию.

Положительное влияние на рынок serverless-сервисов будет оказывать дальнейший рост объемов неструктурированных данных. Другим фактором роста станут расширяющийся переход на микросервисные архитектуры и модернизация цифровых платформ в организациях, для которых использование таких сервисов органично.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!