Переход на Serverless: как выстроить архитектуру своего приложения
Привет, Хабр! Как менеджер продукта и один из амбассадоров serverless я регулярно рассказываю о преимуществах этого подхода и показываю, как с помощью бессерверных вычислений повысить эффективность затрат на инфраструктуру. Но как и у любого подхода, у serverless есть свои ограничения, которые важно учесть в своей IT‑стратегии.
В этой статье я расскажу о затруднениях, с которыми сталкиваются разработчики при переходе на serverless, и покажу, как можно их избежать на уровне архитектуры приложения.
Что говорят айтишники: state of serverless 2023
Осенью совместно с аналитической компанией Ipsos мы провели исследование рынка бессерверных вычислений и спросили разработчиков, архитекторов и IT‑руководителей об их опыте использования serverless. Всего в опросах и интервью поучаствовало более 400 IT‑специалистов, уже знакомых с подходом.
Сценарии и задачи. В 2023 году чаще всего бессерверные решения используют для:
загрузки и хранения данных (41%),
оптимизации работы поиска в приложениях, а также обработки файлов с использованием контейнеров (по 24%),
для проведения вычислений, создания и хранения API сервисов, хранения и управления ключами, доступами и секретами (по 23%).
Если рассматривать укрупнённо, то наиболее популярными сценариями в этом году стали:
аналитика данных (48%),
сбор и поставка данных в системы хранения (44%),
управление облачной инфраструктурой (34%).
Ограничения и организационные трудности. При переходе на serverless перед командами часто возникают задачи чёткого разделения продукта на множество функций или микросервисов, и это не всегда можно сделать легко и быстро. Среди технических сложностей при переходе респонденты называли:
нарушения взаимосвязей и основ интеграции между разными сервисами,
возникновение ошибок в коде,
сбои в конфигурациях разных сервисов.
При этом далеко не все бессерверные решения поддерживают нужные языки программирования и протоколы взаимодействия.
Вероятны и организационные сложности: отсутствие опыта с такими решениями также может вызвать трудности при расчёте необходимых ресурсов. Техническим специалистам может не хватать навыков работы с бессерверными вычислениями и знания тонкостей настройки, требуется дополнительное обучение и обмен опытом.
(Так что надеюсь, эта статья тоже немного поможет).
Техническая изнанка проблем
При создании бессерверных приложений важна событийно ориентированная архитектура (event-driven architecture, EDA). Напомню, что это архитектурный паттерн, построенный из децентрализованных сервисов, которые публикуют, обрабатывают или маршрутизируют события — сообщения, отправляемые между сервисами. Такой подход облегчает масштабирование, обновление и независимый деплой различных компонентов системы.
Приложения, построенные на базе происходящих в системе событий, можно встретить не только в serverless-мире. Но при бессерверном подходе это довольно принципиальный момент.
Serverless ориентируется на события — все операции должны решать одну небольшую задачу и не могут работать в фоне. Так, сервис не может работать в виде демона и постоянно слушать определённый порт.
В частности, код, запущенный в бессерверном режиме, может быть исполнен, только если вызван через HTTP/HTTPS: напрямую, через триггер или через сервис для создания API-шлюзов, который консолидирует HTTP-эндпоинты API.
Практически любое современное приложение можно представить как в серверном, так и в бессерверном варианте. Ключевой момент здесь не в том, какую задачу мы хотим решить, а в том, подходит ли задуманная архитектура для реализации в экосистеме serverless.
Мы рассмотрим три примера событийно-ориентированной архитектуры: один вариант полностью с использованием бессерверных инструментов, и два других, где в бессерверном режиме выполняется конкретная задача. Какие инструменты будем использовать:
Сервисы, с помощью которых исполняется бизнес‑логика задач.
Облачные функции (Cloud Functions) — сервис для запуска кода в виде функции.
Бессерверные контейнеры (Serverless Containers) — про такой сервис мы уже рассказывали подробнее в прошлый раз.
Сервисы для работы с данными.
База данных в режиме serverless.
Сервис для управления потоками данных (Data Streams).
Сервис очередей (Message Queue).
Объектное хранилище (Object Storage).
Интеграционные сервисы, которые являются точками входа для обработки нагрузки.
Типовые сценарии для serverless-архитектуры
Обратимся к конкретным задачам, которые решаются при бессерверном подходе.
Event-driven-веб-сервис. Представим приложение, которое реализует для пользователя такую базовую функциональность:
авторизация пользователя;
просмотр каталога кино;
выставление оценок понравившейся кинокартине;
добавление фильма в каталог.
Каждое действие из этого списка можно выразить как событие, происходящее в системе. В качестве точки входа используется сервис для создания API-шлюзов, который затем интегрируется с другими сервисами:
статические объекты находятся в объектном хранилище;
динамические элементы сайта формируются с помощью логики, реализованной внутри бессерверных контейнеров и облачных функций.
Для того чтобы получить доступ к функциональности сервиса, реализуется логика авторизации пользователя через сторонний сервис и логика авторизационной функции, интегрированной с API-шлюзом.
Коллекции фильмов мы можем хранить в управляемой базе данных, работающей в serverless-режиме. А для выставления оценок используем отдельную функцию, которая запускается с помощью триггера при появлении сообщения в очереди. Информацию о выставленных оценках можно также складывать в поток votes-stream для перекладывания и трансформации данных для дальнейшего анализа. Также мы можем пополнять нашу коллекцию из внешних источников с помощью импортирующей данные функции.
Таким образом, используя только serverless-инструменты, можно получить архитектуру веб-приложения, которая реализует необходимую логику.
Выделенный микросервис. Но мы не всегда хотим строить тотальный serverless. Поэтому бессерверные вычисления можно интегрировать в инфраструктуру и отдельными микросервисами — какой архитектура будет в этом случае?
Для примера возьмём сервис загрузки, конвертации и просмотра видео. Для такого приложения важно обеспечить удобное хранение и поиск нужных видеофайлов. Сервис можно реализовать с использованием виртуальных машин и расширить функциональность serverless‑инструментами ‑ всё теми же облачными функциями и очередями сообщений.
Для загрузки видеозаписей используем объектное хранилище, что позволит недорого хранить довольно объёмные файлы. При этом конвертация видеофайлов может потребовать аппаратных ресурсов (ASIC‑/FPGA‑чипы или GPU), так что эту логику удобно оставить в существующем контуре виртуальных машин или нод Kubernetes‑кластера.
После загрузки файла мы хотим записать его метаданные в отдельную базу, которую потом можно использовать для поиска файлов по разным параметрам.
Метаданные позволят сформировать рекомендации по похожим видеофайлам и выдавать их вместе с результатами поиска или на странице просмотра файлов. Операции поиска и формирования рекомендаций не носят постоянного характера и отличаются предсказуемо коротким временем обработки запроса. Такие операции могут быть запрошены параллельно для разных пользователей, число которых сильно варьируется, поэтому их можно вынести в отдельные функции, разбирающие очередь по триггеру.
Работа с данными. Как показал наш опрос, serverless‑инструменты часто используются для работы с данными. В качестве примера такого кейса возьмём построение единого хранилища данных, которые необходимы для анализа. Данные нужно объединить из разных внешних источников и привести в единый формат хранения.
Поскольку новые данные постоянно поступают, необходимо поддерживать их потоковую загрузку:
Для приёма данных из разных источников по HTTP мы можем использовать связку:
API‑шлюз → управление потоками данных → облачные функции / Data Transfer.
Это позволит нам в потоковом режиме принимать, трансформировать и сохранять данные в управляемом ClickHouse и объектном хранилище, из которых удобно визуализировать данные на дашбордах или анализировать их с помощью сервиса для выполнения потоковых запросов.
Эти три примера хорошо описывают характерные для serverless архитектурные паттерны. Их знание поможет не только упростить переход на бессерверные вычисления, но и сделать этот переход выгодным для компаний. Для сравнения, перенос постоянной и высокой нагрузки на serverless‑инфраструктуру может обойтись дороже, чем при традиционном подходе. А вот «насмотренность» с точки зрения того, какие элементы архитектуры легко и дёшево перенести в бессерверный режим, поможет комбинировать разные инструменты с наибольшей эффективностью.
