Легкость использования и экономическая эффективность — наиболее желательные свойства программных сервисов. Простота работы привлекает пользователей и способствует сохранению пользовательской базы, а экономичность содействует более широкому и продолжительному использованию сервисов. Кроме того, в эпоху, когда приложения стали поглощать значительную долю вырабатываемой в мире электроэнергии, экономическая эффективность помогает устойчивому развитию. Но до сих пор не удавалось одновременно достичь и легкости использования, и экономической эффективности: чем проще ПО в применении, тем меньше сведений оно предоставляет платформе, на которой работает, из-за чего последней приходится решать сложные задачи управления. Бессерверные вычисления не панацея, но они обеспечивают и легкость использования, и экономическую эффективность для стандартных программных сервисов, работающих на облачных ресурсах. Для каких целей могут быть полезны бессерверные вычисления, для чего их лучше применять и каким образом?

Платформа бессерверных вычислений — это любая платформа, маскирующая использование серверов от разработчиков, выполняющая код по запросу с автоматическим масштабированием и тарифицирующая только реальное время выполнения кода [1,2]. Обычно в бессерверных приложениях используются функции в виде сервиса (Function as a Service, FaaS) — управляемые решения для кратковременных вычислений без сохранения состояния (AWS Lambda, Azure Functions или Google Cloud Functions), а также полностью управляемые оператором сервисы обмена сообщениями, хранения файлов, баз данных, поточной передачи и аутентификации — программы, поставляемые в виде сервиса (Backend as a Service, BaaS). Бессерверные вычисления сегодня активно осваиваются предприятиями и научно-исследовательским сообществом благодаря важной особенности: они позволяют разработчикам сосредоточиться на реализации бизнес-логики, возложив на провайдера все эксплуатационные задачи, включая развертывание, резервирование ресурсов и масштабирование [1].

 

Мобильная основа приложений социальной сети

На платформах социальных сетей вроде Facebook, Twitter и Instagram статусы пользователей обновляются миллиарды раз в день. С технической точки зрения этот процесс состоит из четырех этапов: 1) пользователь составляет новое статусное сообщение в мобильном приложении; 2) пользователь отправляет сообщение; 3) платформа обеспечивает оркестровку операций, необходимых для распространения сообщения и его доставки друзьям пользователя; 4) друзья получают новый статус через клиентов социальных сетей, например через мобильные приложения. Этап 2 — это «секретный ингредиент» платформы социальной сети: ПО и серверы, на которых оно работает, обеспечивают выполнение технических функций социальной сети прозрачно для пользователя и его друзей.

При использовании традиционных технологий для этапа 3 операторам платформы пришлось бы разрабатывать и тестировать логику маршрутизации нового статуса между друзьями пользователя и обеспечивать управление ресурсами (серверами), на которых работает логика. Между тем управление ресурсами, в частности подготовка и резервирование, — это далеко не самая простая задача. Сложности, связанные с масштабированием ресурсов по мере роста количества пользователей и их друзей, усугубляются из-за наличия множества особенностей, которые нужно учесть при каждой такой операции. Есть трудности и с выполнением логики в связи со строгими требованиями к производительности, ведь пользователь рассчитывает на то, что все его друзья сразу увидят обновленный статус и смогут мгновенно ответить.

Пример бессерверного приложения — мобильной основы для приложения социальной сети

При использовании бессерверных технологий оператор облака абстрагирует управление серверами, обеспечивая их подготовку с тонкой настройкой по запросу и с оплатой по мере потребления. Чтобы пользоваться этими возможностями, бессерверное ПО реализуют иначе, чем обычное. Упрощенно процедура публикации обновления выглядит следующим образом: после отправки нового статуса пользователем мобильный клиент выдает HTTP-запрос к API-шлюзу, который выполняет роль бессерверного маршрутизатора запросов, причем реализует только одну эту функцию, эффективно действуя без участия разработчика. На этапе 3 API-шлюз запускает лямбда-функцию (бессерверные вычисления) для запроса списка друзей из таблицы DynamoDB (бессерверного хранилища) и публикации обновленного статуса для них с помощью службы Simple Notification Service — бессерверного механизма публикации и подписки. Последний создает push-уведомления с новым статусом для друзей пользователя. При этом происходит вызов десятков других бессерверных функций: аутентификация пользователя, проверка полномочий на публикацию сообщений, копирование данных между несколькими пунктами и т. д. Оркестровка работы всех этих функций происходит на серверах, управляемых оператором облака. Каждая бессерверная функция отвечает лишь за малую часть всей работы, благодаря чему обеспечивается лучшая масштабируемость, чем при традиционных подходах, хотя и за счет более сложной оркестровки.

 

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

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

Почему выбирают бессерверные вычисления?

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

В 27 случаях мотивация перехода осталась неясной. Что касается остальных, то в 47% случаев выбор был сделан из-за экономии затрат — такая возможность реализуется благодаря схеме с оплатой по мере потребления, эффективной при нерегулярных и скачкообразных нагрузках, которые при традиционных вариантах хостинга приводили бы к нерациональному расходованию средств. При этом у 84% рассмотренных бессерверных приложений были именно нерегулярные нагрузки.

Еще одна причина внедрения бессерверных вычислений, обнаруженная в 34% случаев, — избавление разработчиков от необходимости решать эксплуатационные задачи, связанные с развертыванием, масштабированием, мониторингом, а также предоставление возможности сосредоточиться на новых функциях. Об этом говорят не только применительно к вспомогательной функциональности с редким, нерегулярным выполнением (например, конвейер непрерывной интеграции и поставки или распознавание вредоносных программ). То же самое указывается в отношении ориентированных на пользователей API, которые обслуживают большой трафик, хотя в этом случае, казалось бы, в приоритете другие характеристики: доступность и производительность.

Третья причина, тоже отмеченная в 34% случаев, — масштабируемость бессерверных приложений, практически безграничная и доступная без особых инженерных усилий. Масштабируемость обеспечивается за счет использования FaaS — небольших функций, оформленных в виде сервиса, которые хорошо подходят для выполнения в параллельном режиме.

Итак, чаще всего в качестве причин внедрения бессерверных вычислений называют экономию затрат на обслуживание нерегулярных и скачкообразных нагрузок, возможность избежать выполнения эксплуатационных задач и легкодоступную масштабируемость (см. рис.). Еще две причины: более высокая производительность и более быстрый выпуск на рынок — встречаются реже, в 19% и 31% случаев соответственно. Похожие результаты были получены в ходе недавнего опроса с участием 160 пользователей. К числу преимуществ бессерверных вычислений 51% отнесли событийно-зависимую архитектуру, 44% — экономию на стоимости ресурсов, 36% — ускорение разработки, 31% — гибкость масштабирования, а 19% — высокую производительность приложений.

Когда используются бессерверные приложения?

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

Выяснилось, однако, что бессерверные приложения применяются не только для поддержки вспомогательной функциональности — этому служат 39% приложений, тогда как основные функции реализуют 42%, а 16% используются для выполнения исследовательских программ. Это согласуется с выводом о том, что значительное количество бессерверных приложений (39%) работают с высокоинтенсивным трафиком. При этом доля приложений, выполняемых по запросу и работающих с малым объемом трафика, составляет 47%, а доля приложений, выполняемых по расписанию, — 17%.

Распространенный аргумент против бессерверных систем: при «холодном» запуске они не подходят для приложений со строгими требованиями к задержке. Однако, как показало исследование, бессерверные приложения все же применяются и для критичных к задержке задач, хотя холодный запуск увеличивает ее максимальное значение. В частности, 38% бессерверных приложений, участвовавших в обзоре, не имеют требований к задержке, однако у 32% есть такие требования для всей функциональности, а у 28% — для части функций; более того, 2% бессерверных приложений работают в режиме реального времени.

Еще один аргумент против состоит в том, что существующие на сегодня бессерверные платформы могут не подходить для задач, выполняющихся длительно или обрабатывающих большие объемы данных. Полученные результаты подтверждают это предположение: 69% рассмотренных приложений работают с данными объемом меньше 10 Мбайт, а у 75% время выполнения составляет считанные секунды. Чтобы избавить бессерверные платформы от этого ограничения, требуется их усовершенствовать.

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

Как реализуются бессерверные приложения?

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

Среди платформ подавляющее большинство (80%) предпочитают AWS. У остальных доли сильно ниже: Azure — 10%, IBM — 7%, Google Cloud — 3%. Отрыв AWS можно объяснить двумя причинами: платформа FaaS у Amazon, AWS Lambda, появилась на два года раньше, чем у остальных провайдеров, поэтому ее считают наиболее зрелой; кроме того, AWS владеет самой большой долей рынка облачных вычислений в целом, соответственно, многие пользователи при освоении бессерверных вычислений выбирают того же провайдера. Примерно 8% рассмотренных приложений работают в частных облаках, но большинство из них — это научно-исследовательские применения.

Ограниченное использование частных облаков резко контрастирует с доступностью большого количества фреймворков FaaS с открытым кодом. Напомним, что одна из привлекательных черт бессерверных приложений — автоматизация эксплуатационных задач, поэтому можно предположить, что открытые FaaS-фреймворки внедряют в связи с увеличением количества таких задач из-за необходимости обслуживать дополнительные серверы и ПО. Кроме того, в большинстве бессерверных приложений используются управляемые сервисы (хранилища, базы данных, механизмы обмена сообщениями, журналирование, доставка потоков и т. д.), которых обычно нет в готовом виде в средах частного облака.

Бессерверные платформы поддерживают популярные языки программирования. Лидируют с большим отрывом JavaScript и Python — по 42%. Некоторые приложения написаны на Java (12%), Си/С++ (11%) и C# (8%), совсем мало — на Go (5%) и Ruby (2%). У интерпретируемых языков, таких как JavaScript и Python, по сравнению с компилируемыми меньше время холодного запуска, то есть время, необходимое на инициализацию нового экземпляра. Однако по мере развития технологий это различие нивелируется, появляются новые способы избавиться от холодного запуска. В AWS, например, ввели функцию зарезервированной мощности, которая позволяет заранее подготовить функциональные экземпляры, чтобы избежать холодного пуска. Внедрение подобных методик может привести к росту применения компилируемых языков.

Провайдеры облаков предлагают управляемые сервисы в составе BaaS: обмен сообщениями, хранение файлов, базы данных, поточная передача, журналирование, машинное обучение. Самые популярные внешние сервисы — это облачные хранилища (например, S3) и базы данных (Dynamo DB и др.). Поскольку бессерверные функции имеют краткий период выполнения и не сохраняют состояние, для постоянного хранения данных и управления состоянием им нужно пользоваться внешними сервисами. В 38% бессерверных приложений также применяются различные виды управляемого обмена сообщениями: на основе публикации и подписки (17%), поточной доставки (11%) или очередей (10%). Сервисы обмена сообщениями широко используются, поскольку бессерверные функции редко обмениваются данными с помощью внешних вызовов, так как это приводит к двойной тарификации. Популярность сервисов обмена сообщениями согласуется с выводом о том, что в бессерверных приложениях для координации многочисленных функций чаще всего используются событийно-зависимая архитектура (60%) или движки управления рабочими процессами (38%). Отметим, что лишь в 12% приложений не применяются BaaS-решения, то есть в целом преобладает симбиоз FaaS и BaaS.

Единого мнения относительно необходимого уровня гранулярности бессерверных функций еще нет. Обсуждаются различные варианты — от создания отдельной функции для каждой функции программы и каждой конечной точки API до преобразования всех микросервисов в бессерверные функции. По данным исследования, 82% бессерверных приложений состоят из пяти или менее функций, а 93% — из 10 или менее функций. Почти все остальные имеют до 20 функций. Таким образом, сейчас гранулярность бессерверной функции больше соответствует полноценному микросервису или конечной точке API. Соответственно, само название «бессерверные функции» является неточным ввиду отсутствия связи с общей концепцией функций из программирования.

Итак, бессерверные приложения чаще всего реализуют на платформе AWS на Python или JavaScript, обычно используя при этом облачные сервисы хранилища, управляемых баз данных и обмена сообщениями. При этом по объему бессерверные функции несопоставимы с традиционными функциями в программировании.

***

Анализ бессерверных приложений показал, что чаще всего их внедряют для экономии расходов на нерегулярные, скачкообразные нагрузки, а также, чтобы избежать проблем с эксплуатацией и масштабируемостью. Бессерверные приложения обычно применяются для задач с коротким периодом выполнения, но часто используются для основной функциональности, критичной к задержке и обслуживающей большое число пользователей. Основная платформа реализации — AWS, языки программирования — Python или JavaScript; в приложениях активно используются бэкенды в виде сервиса.

Литература

1. P. Castro, V. Ishakian, V. Muthusamy, A. Slominski. The rise of serverless computing // Commun. ACM. — 2019 (Nov). — Vol. 62, N. 12. — P. 44–54. doi: 10.1145/3368454.

2. S. Eismann et al. A review of serverless use cases and their characteristics. SPEC RG, Gainesville, Tech. Rep., Aug. 2020. Accessed: May 2020. [Online]. URL: https://bit.ly/36Ntvgy (дата обращения: 20.03.2021).

Симон Айсманн (simon.eismann@uni-wuerzburg.de), Максимилиан Швингер (maximilian.schwinger@dlr.de), Йоханнес Громанн (johannes.grohmann@uni-wuerzburg.de)  —  аспиранты, Николас Хербст (nikolas.herbst@uni-wuerzburg.de)  —  руководитель исследовательской группы, Вюрцбургский университет; Джоэл Шойнер (scheuner@chalmers.se)  —  аспирант, Технический университет Чалмерса и Гетеборгский университет; Эрвин Ван Эйк (erwinvaneyk@gmail.com)  —  аспирант, Александру Йосуп (a.iosup@vu.nl)  —  профессор, Амстердамский свободный университет; Кристина Абад (cabad@fiec.espol.edu.ec)  —  доцент, Высшая политехническая школа Литораля (Эквадор).

Simon Eismann, Joel Scheuner, Erwin van Eyk, Maximilian Schwinger, Johannes Grohmann, Nikolas Herbst, Cristina L. Abad, Alexandru Iosup, Serverless Applications: Why, When, and How? IEEE Software, January/February 2021, IEEE Computer Society. All rights reserved. Reprinted with permission.