Бессерверные вычисления (serverless) попали в тренды — 2019. Мы писали об этом в начале года. Эксперты пророчат этой сравнительно новой парадигме статус ключевой для реализации бэкэнда приложений в центрах обработки данных. Однако массовому переходу на serverless препятствуют несколько важных нюансов, о которых рассказали ученые Калифорнийского университета в Беркли. Их мнение интересно, поэтому мы решили поделиться им с вами.
Что такое serverless?
Бессерверные вычисления, или FaaS (Function-as-a-Service) — это разновидность облачных технологий. Они позволяют запускать функции (например, микросервисы, бэкэнд приложений), написанные на языках высокого уровня, прямо в инфраструктуре провайдера. Пользователю не нужно беспокоиться об управлении инфраструктурой и возиться с конфигурациями сервера. При этом он платит только за ресурс, по факту использованный для выполнения кода функции (pay-as-you-go), а не за его резерв (пропускная способность, количество серверов и т.д.), как в других облачных моделях.
Сам термин «бессерверный», конечно же, не означает, что в этом виде вычислений не задействованы серверы (не представляем, как такое вообще возможно). Такое название всего лишь акцентирует внимание на том, что все вопросы, связанные с серверами и инфраструктурой в целом, решаются поставщиком услуги. В то же время разработчики могут спокойно выполнять свою работу, не отвлекаясь на непрофильные задачи.
Serverless-вычисления отличают от облачных три основных момента. Помимо модели биллинга, о которой мы упоминали выше, разница заключается еще и в том, что ресурсы для хранения и вычислительные ресурсы масштабируются независимо друг от друга. Функции работают stateless, то есть не хранят данные о своем состоянии (предшествующих взаимодействиях), и они должны быть хорошо изолированы друг от друга.
Ограничения бессерверных платформ
Несмотря на свое удобство, бессерверные вычисления имеют ряд ограничений. Большинство из них связано с их работой в «режиме» stateless. На stateless-платформе трудно координировать задачи между собой. Например, если функции 2 на вход требуются выходные данные функции 1, она должна уметь отслеживать, когда функция 1 их выдает, что в случае serverless достаточно проблематично. Кроме того, консистентность данных тоже требует соответствующих процессов согласования. Поскольку между облачными сервисами практически нет систем уведомлений, их необходимо реализовать в функциях, что дополнительно усложняет работу программистам.
В зависимости от приложения, функции на бессерверных платформах могут работать медленнее, чем принято считать. Дополнительное время уходит на инициализацию программной среды для запуска функции — например, загрузку библиотек Python и выполнение специфичных для конкретного приложения операций инициализации. Во-вторых, одна и та же функция может запускаться на различном оборудовании с отличающимися характеристиками (например, могут использоваться CPU разных поколений). С одной стороны, вы как пользователь можете не заботиться о ресурсах процессора. С другой — вы не способны предсказать производительность бессерверной среды для работы своих приложений.
Не для всех алгоритмов
Ученые из Беркли провели исследование пяти конкретных приложений, использующих различные алгоритмы, чтобы проверить эффективность serverless-вычислений. Оказалось, что кодирование видео в режиме реального времени, алгоритмы машинного обучения и массивные алгебраические вычисления, которые обычно выполняются на суперкомпьютерах, на бессерверных платформах работали относительно хорошо. Однако алгоритмы MapReduce и их аналоги имели проблемы с распределением данных. Хуже всего serverless показал себя в работе с приложениями баз данных, ориентированных на транзакции и интенсивную запись.
Как улучшить FaaS?
Сегодня разработчикам разрешено указывать только требования к памяти и ограничение времени выполнения своих функций. Однако если бы пользователи могли дополнительно называть конкретные необходимые ресурсы (например, количество GPU, CPU и прочих ускорителей ИИ), результаты работы на stateless-платформах могли бы быть лучше. К тому же оптимальным решением было бы проведение поставщиком анализа кода и предоставление оптимальных ресурсов для функций в автоматическом режиме.
Сервисы хранения, используемые для FaaS, должны иметь возможность автоматически подгонять емкость хранилища и вычислительную мощность ad hoc, тем самым освобождая память, которая больше не нужна, для других задач.
Чтобы убедиться, что коммуникация между функциями не выходит за рамки ресурса, можно выделить больше ядер для обработки данных. Это позволит им обмениваться информацией и сопоставлять данные до фактического запуска вычислений.
Кроме того, несколько облачных функций возможно разместить на одной виртуальной машине. Для каждой можно создать вычислительный граф, благодаря которому наглядно представить взаимосвязь между отдельными функциями и вычислительными этапами. Это поможет оптимально распределить ресурсы.
Отдельно стоит отметить тот факт, что оптимизированных под FaaS процессоров пока не существует. Однако, по словам экспертов, вскоре появится возможность предложить вычислительные устройства, адаптированные к конкретным языкам программирования высокого уровня. В качестве примера они приводят RISC-V и платформy ARM Neoverse.
Ученые также считают, что оптимизировать производительность бессерверных вычислений помогут доменно-специфические архитектуры (DAS) (например, GPU или TPU).
Заключение
Как и у любой другой технологии, у бессерверных вычислений есть свои недостатки. Но это совершенно не означает, что FaaS нежелательно использовать. Все зависит от специфики приложения и целей, которые разработчики ставят перед собой. Критический взгляд на вещи ученых из университета в Беркли вряд ли помешает дальнейшему развитию этой модели. Скорее, наоборот, он поможет ее лучше адаптировать под выполнение своих функций.
