Компьютинг без серверов. Технологии, изменяющие менталитет

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

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

Бессерверная архитектура — что стоит за этим загадочным понятием?

Говоря о serverless computing, нужно понимать, что на самом деле без физических и виртуальных серверов не обойтись ни при каких условиях, значит, речь идет не об отказе от железа, а о новом подходе к предоставлению сервисов в виде функций.

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

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

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

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

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

Впервые такие сервисы FaaS были реализованы в 2014 году в проекте Open-Source Microservice Hosting Platform. Вскоре появились сервисы Amazon AWS Lambda, в 2016 году — Google Cloud Functions, Microsoft Azure Functions, IBM/Apache’s OpenWhisk и в 2017-м — Oracle Cloud Fn.

А какова разумная форма предоставления услуг бессерверных вычислений?

Самая банальная форма — IaaS. Вам предоставляется в пользование стандартная серверная инфраструктура или СХД.
Затем были DaaS, DBaaS, PaaS… — одним словом, XaaS, то есть «все что угодно как сервисы». Все это не что иное, как поиск форм для предоставления тех услуг, о которых Джон Маккарти писал полвека назад.

Форма предоставления ПО как сервисов — Software as a Service (SaaS) — за годы своего существования серьезно изменилась. Она имеет три лица: контейнеры (CaaS), приложения (PaaS), к ним прибавляются функции (FaaS). Можно было бы на этом остановиться, но маркетологам по душе serverless computing. То есть FaaS есть не что иное, как очередной шаг в сторону Utility computing.

Как и когда у вас появилась необходимость в таком подходе?

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

Расскажите подробнее о проекте.

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

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

Какие были пути решения, было ли что-то готовое?

На рынке на тот момент уже, конечно, были и AWS Lambda, и Google Functions, но это закрытые облачные провайдеры, тем более не в российской юрисдикции, — нам не подходили сразу.

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

Какой результат в итоге получился? Какой эффект дала собственная разработка?

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

Есть планы по развитию этой платформы?

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

Вы сторонник сторонник свободного и открытого кода?

Я всегда интересовался ПО с открытым кодом, но не всегда компаниям удается использовать такие решения в производственных системах. Думаю, со временем парадигма будет меняться. Например, в своих рабочих проектах я успешно применяю решения PostgreSQL, Cassandra, OpenShift, Docker, Kubernetes от компании Google и являюсь экспертом по многим продуктам компании Red Hat и их открытым веткам — Ceph, Gluster, Ansible. Поэтому считаю, что это единственно верная модель развития.

Планируете привлечение инвестиций?

Да, прорабатываю этот вопрос. Инвестиции помогают достигать поставленных целей быстрее, совершенствовать свой продукт.

Когда наступит неизбежное бессерверное будущее?

Минувшее десятилетие приучило нас к удобствам облачных сервисов. Следующий шаг — платформы, которые предоставляют сервисы более высокого уровня: очереди, API, шлюзы, средства аутентификации. Сейчас инструменты улучшаются очень быстро. И бессерверные вычисления, основанные на функциях, и системы, основанные на блок-схемах, серьезно продвинулись за последний год. Контейнерные технологии все еще в стадии активной разработки, но их востребованность делает свое дело.

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

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

Источник