Serverless-архитектура или бессерверные вычисления: обзор технологии

12 декабря 2023 года Yandex Cloud и Ipsos опубликовали исследование РФ рынка бессерверных вычислений среди технических специалистов и руководителей компаний. В данном исследовании 43% опрошенных ответили, что Serverless-подход экономически выгоден, а ключевыми преимуществами назвали сокращение времени на поддержку инфраструктуры (49% опрошенных) и быстрое масштабирование (46% опрошенных).

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

Экосистема Serverless

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

Упрощение работы с инфраструктурой уходит корнями в появление первых IaaS (Infrastructure as a Service), где провайдер просто предлагал виртуальную инфраструктуру в аренду, до широкого BaaS (Backend as a Service), где микросервис разработчика или база данных — это несколько запущенных контейнеров в среде провайдера. А в случае с БД — настроенная репликация. 

Еще один продукт — FaaS (Function as a Service), в котором единицей запущенного кода является функция. Отчасти это напоминает микросервисный подход. Ваша функция не должна полагаться на состояние между вызовами (быть stateless), поскольку будет запускаться провайдером как отдельный инстанс в контейнере. Также есть некоторые ограничения со стороны облачной платформы: не все языки программирования могут быть использованы для написания кода (хотя их список у провайдеров обычно широкий), ограничение по времени выполнения функции и использованию памяти — у платформ данные ограничения различны и могут зависеть от тарифа. Многие провайдеры дают пробный период от трех месяцев до года с лимитами по количеству запросов.

В основе Serverless лежит FaaS и экосистема продуктов провайдера. Обычно среди продуктов есть Базы Данных, Сервис Авторизации, API Шлюз, Брокеры сообщений (например, Kafka) — все представлены в виде сервисов (BaaS), с которыми может быть интегрирована функция.

Архитектура

У каждого провайдера может быть свой набор сервисов, но архитектура приложений, которые построены на FaaS будет схожей. В качестве примера интеграции между продуктами провайдера можно рассмотреть приложение TODO (сам пример на сайте AWS).  

^{Примечание: Доступ к сайту aws.amazon.com может быть ограничен в РФ.}

Код логики приложения упакован в lambda functions, которые взаимодействуют с базой данных dynamodb, предоставляемой AWS как отдельный сервис. Перед функциями работает сервис API Gateway, который выполняет обработку запросов и их дальнейший роутинг. Также в архитектуре участвуют сервисы Amplify Console для работы с Web-интерфейсом приложения и сервис аутентификации Amazon Cognito.

^{Изображение: aws.amazon.com}

В данной схеме отражено, что приложение может быть сильно привязано к архитектуре, сменить провайдера позднее может быть непросто ввиду сильной разницы продуктовой линейки, и архитектура приложения изменится. Yandex Cloud учитывает такую разницу, и одним из продуктов является библиотека от Yandex для AWS, которая позволяет использовать обе облачные платформы одновременно. Также у Yandex Cloud есть сопоставление собственных продуктов с решениями от AWS, Google Cloud, Microsoft Azure.

Архитектура приложений тоже будет схожей. Маршрутизация запросов будет в API Gateway, код с логикой размещается в Cloud Functions (аналог lambda от AWS), вместо Amazon Cognito можно использовать сервис Yandex IAM. Cloud Functions интегрируются с решениями от Yandex, например, Message Queue — сервис очереди сообщений, который совместим с HTTP API Amazon SQS. Для хранения статических данных и документов используется Yandex Object Storage — хранилище данных S3. В качестве базы данных на схеме используется YDB с прослойкой от Yandex — Yandex Managed Service for YDB, хотя ничего не мешает использовать другую СУБД, например Postgres, для которой у Yandex есть аналогичный сервис Managed Service for PostgreSQL.

^{Изображение: yandex.cloud}

Прямого аналога Amplify Console нет в списке сопоставлений, но контейнер с Frontend-приложением можно развернуть в Serverless Containers.

cloud

Преимущества и недостатки

Основным позитивными аспектами обычно считаются:

Гибкая масштабируемость

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

Тарификация

Оплата только за время работы функции. Например для AWS цена складывается из стоимости запуска функции и количества памяти GB/s, выделяемой при ее работе. При доступности функции 24/7 (с нюансами) нет оплаты за время простоя.

Автоматизация

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

В сравнении с инфраструктурой типа BaaS или при полном контроле сервера (VPS) размещение приложения в облачных функциях у провайдера имеет свои недостатки

Лимит ресурсов

У cloud-функций есть ограничения по используемой памяти и времени во время выполнения. А также ряд ограничений, связанных с размерами передаваемых или получаемых данных. Вот примеры таких лимитов у Yandex и AWS.

Холодный старт

Провайдер не будет все время держать контейнер с функцией поднятым. Если функция не была востребована некоторое время, то при ее следующем запросе провайдер потратит время на ее запуск. Время старта будет зависеть от языка программирования, размера кода, внутренних процессов провайдера и может достигать 10 секунд. Вот небольшая статья с примерами на эту тему и git с кодом и результатами исследования. 

^{Примечание: Доступ к сайту pluralsight.com может быть ограничен в РФ.}

Best Practices

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

Теплый старт

Если приложение всегда требует быстрый отклик, холодный старт может стать большой проблемой. Решение заключается в постоянном «подогреве» функции, например, периодической отправке запросов в приложение, которые создадут нагрузку, и провайдер продолжит держать функцию в активном состоянии. Сама нагрузка не имеет значения, важен именно запуск функции, а при необходимости провайдер масштабирует (запустит дополнительные инстансы) на лету. Иногда у провайдеров такой функционал уже есть на платформе (например, у AWS), который позволяет держать некоторое количество инстансов запущенными всегда.

Fan-Out Pattern

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

Event Driven Pattern

Облачные FaaS могут быть вызваны не только через API Gateway или напрямую. Запуск функции инициирует триггер, которым может быть событие из любых интегрированных сервисов, например, сообщение от Kafka. Организация кода в event-driven-стиле очень хорошо подходит для FaaS.

Cost Optimization

В отличие от постоянной цены услуги (например, аренда VPS на год), для Serverless стоимость складывается из нескольких разных сервисов с разной тарификацией. Постоянный мониторинг затрат и утилизации ресурсов, а также планирование нагрузки — ключи к снижению стоимости инфраструктуры решения. Иногда у облачных провайдеров есть специальные предложения, например, функционал AWS Lambda Reserved Concurrency, который позволяет зарезервировать инстансы Lambda и держит их поднятыми по дешевому тарифу.

Инструменты для работы с Serverless

Serverless Framework 

Инструмент с открытым исходным кодом, предназначенный для упрощения разработки, развертывания и управления serverless приложениями. Он позволяет разработчикам сосредоточиться на написании кода, не беспокоясь о деталях инфраструктуры и конфигурации облачного провайдера. Serverless Framework работает с разными облачными платформами, включая AWS, Azure, Google Cloud, IBM Cloud, Oracle Cloud. Позволяет локально тестировать функции, интегрируется с CI/CD-системами, например, Jenkins или Travis, обладает большой базой плагинов и позволяет создавать свои.

Terraform

Terraform, инструмент HashiCorp, определяет подход к управлению инфраструктурой как кодом. Он позволяет определять инфраструктуру с использованием конфигурационных файлов в формате HCL (HashiCorp Configuration Language), в которых описывается желаемое состояние инфраструктуры, а не шаги для ее достижения. Как и Serverless Framework, поддерживает многих популярных облачных провайдеров и позволяет определять модули — наборы конфигурационных файлов Terraform, которые могут быть использованы повторно для создания и управления инфраструктурными компонентами. Модули могут включать в себя любые ресурсы, параметры и зависимости, которые необходимы для определенной задачи или сервиса.

AWS SAM

Serverless Application Model — это открытый фреймворк, созданный Amazon Web Services (AWS) для разработки, тестирования и развертывания serverless-приложений на платформе AWS. SAM предоставляет упрощенный способ создания serverless-приложений, который базируется на конфигурационном формате CloudFormation, основном инструменте AWS для управления инфраструктурой как кодом. 

Kubeless

Если предыдущие инструменты помогают работать с другими провайдерами, то Kubeless — это серверный фреймворк для Kubernetes, который позволяет создавать и управлять serverless-функциями в вашем кластере Kubernetes. Фреймворк умеет работать с объектами Kubernetes, такими как Deployment, Service, Ingress и другими. Дает возможности масштабирования и отказоустойчивости serverless-функциям, имеет CLI, интегрируется с другими сервисами и ресурсами экосистемы Kubernetes

OpenFaaS

Серверный фреймворк с открытым исходным кодом. Позволяет создавать функции на различных языках программирования, включая Python, Node.js, Go, Ruby, Java и другие. Умеет масштабировать функции и обеспечивает отказоустойчивость. OpenFaaS интегрируется с Kubernetes и Docker Swarm.

Область применения Serverless

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

Крупные IT-компании переносят часть своих процессов на Serverless, например, Netflix использует FaaS при кодировании и транскодировании видео для подготовки видеопотока для различных устройств. Airbnb применяет Serverless в системе StreamAlert для анализа данных в реальном времени. В России также есть примеры — например, кикшеринг Whoosh в своем блоге рассказывает, как разрабатывает Backend на AWS Lambda.

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

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

Развитие Serverless

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

В будущем можно ожидать развития технологий в нескольких направлениях:

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

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

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

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

Выгодные тарифы на облако в Timeweb Cloud

Что почитать

1. Что такое Serverless от AWS.

2. Serverless от Selectel, еще один способ применения технологий для балансировки нагрузки.

3. Отчет о применении облачных технологий от 2024 года.

4. Набор примеров от Serverless Framework.

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

6. Две полезные статьи на Хабре о том, почему важно планировать, ограничивать и мониторить бюджет при работе с облачными провайдерами: про Google Cloud и AWS Lambda.

7. Исследование использования Serverless в России от Yandex Cloud и Ipsos.