Архитектура системы — бессерверные вычисления (baas & faas)

С тех пор как AWS запустила сервис Lambda в 2014 году, термин «бессерверный» становится все более популярным и становится новым типом архитектуры разработки программного обеспечения, а именно бессерверной архитектурой. Каковы преимущества и недостатки бессерверной архитектуры как архитектуры общедоступного облака? Можно ли применить его к традиционным корпоративным процедурам? Подходит ли он для сценариев частного облака? Станет ли он основой изменения облачных вычислений в будущем, как утверждается во многих статьях? Как ветеран индустрии облачных вычислений, автор хотел бы поделиться некоторыми своими взглядами в этой статье.

Что такое бессерверное

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

В этой архитектуре веб-сервер Tomcat работает на облачном хосте, который мы приобрели для размещения приложений ИИ, написанных на Java. Пользователи загружают изображения через API. Ограниченное локальным пространством хранения облачного хоста, чтобы удовлетворить большое количество клиентов, загружающих изображения одновременно, приложение AI реализует шлюз хранилища для импорта изображений в хранилище объектов общедоступного облака. После импорта изображения приложение ИИ считывает изображение из хранилища объектов для идентификации и сохраняет результат в общедоступной облачной базе данных (такой как RDS), а пользователь использует API для запроса результата. После того, как приложение ИИ было запущено в течение определенного периода времени, его приветствовали пользователи, и все больше и больше компаний стали использовать эту услугу. По статистике, большинство компаний загружают изображения централизованно с 9:00 до 11:00 и с 14:00 до 17:00. Стратегия автоматического масштабирования общедоступного облака. Время от времени динамически создавайте дополнительные облачные хосты, чтобы реагировать на потребности клиентов. Архитектура приложений ИИ эволюционирует в:

В этой архитектуре нам нужно сделать следующее:

Управление облачными хостами. Нам нужно позаботиться о конфигурации на уровне системы, такой как количество процессоров, объем памяти, IP-адреса и так далее. В то же время необходимо позаботиться об операционной системе облачного хоста и сформулировать стратегию развертывания приложений ИИ. Патчи безопасности для операционной системы и Tomcat также нельзя игнорировать, иначе конкуренты могут нанять хакеров для атаки на наши системы.
Настройте политику автоматического масштабирования общедоступного облака, чтобы справляться с внезапным трафиком в часы пик.
Объектное хранилище и базы данных с использованием публичного облака.
Пишите приложения ИИ. Для выполнения этих задач мы должны не только разрабатывать приложения ИИ, но и управлять вспомогательными предприятиями (например, управлять жизненным циклом облачных хостов, управлять операционными системами). Такова реальность нынешней архитектуры: 80% вспомогательного бизнеса приходится на 20% основного бизнеса.

Перепишем ИИ-приложение с бессерверной архитектурой:

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

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

По сравнению с предыдущей архитектурой мы больше не используем облачные хосты, операционные системы, Tomcat и не нуждаемся в настройке Auto-Scaling Group.Бессерверная структура общедоступного облака запускает процесс запуска приложений ИИ после загрузки каждого изображения, и автоматически достичь горизонтального расширения. Наконец, нам нужно заботиться только об основном бизнесе.Мы пишем приложения ИИ на языках, поддерживаемых бессерверным фреймворком (например, AWS Lambda поддерживает языки на основе Java, Python и JVM).Все непрофильные направления бизнеса передаются на аутсорсинг операторы публичного облака.

В нашем приложении Serverless AI используются две технологии. Во-первых, используются службы хранения объектов и баз данных, предоставляемые общедоступным облаком, которые в совокупности называются BaaS (Backend as a Service). Во-вторых, используется фреймворк Lambda, который называется FaaS (Functions as a Service).

Использование BaaS и FaaS — это основные характеристики бессерверных приложений, и приложения, отвечающие этим двум основным характеристикам, можно назвать бессерверными приложениями.

Это BaaS, а не PaaS

Приложения ИИ используют хранилище объектов и базы данных, а в будущем могут также использовать очереди сообщений. Интуитивное ощущение состоит в том, чтобы использовать PaaS, зачем создавать новое слово BaaS? В мире технологий слишком много запутанных терминов.

BaaS — это не PaaS, разница между ними в том, что PaaS должен участвовать в управлении жизненным циклом приложений, в то время как BaaS предоставляет только сторонние сервисы, на которые полагаются приложения. Типичная платформа PaaS должна предоставлять разработчикам средства для развертывания и настройки приложений, такие как автоматическое развертывание приложений в контейнерах Tomcat и управление жизненным циклом приложений. BaaS не содержит этого содержимого. BaaS предоставляет только серверные службы, на которые полагаются приложения, такие как базы данных и хранилище объектов, в форме API. BaaS может предоставляться поставщиками общедоступных облачных услуг или сторонними поставщиками.Например, Parse, приобретенный Facebook, является известным поставщиком MBaaS (Mobile Backend as a Service). Функционально BaaS можно рассматривать как подмножество PaaS, то есть часть, которая предоставляет сторонние зависимые компоненты.

FaaS — основа бессерверных решений

Приложение AI изначально представляет собой типичную Java-программу, которая может использовать такие технологии, как Spring, потому что нам нужен фреймворк для обеспечения корректной загрузки различных компонентов программы, а MVC необходим для обеспечения того, чтобы REST API обрабатывается правильным контроллером. Приложения ИИ развертываются в контейнерах Tomcat, запускаются на облачных хостах и работают 7 x 24 ч. Мы предоставляем бесперебойные услуги. С 12:00 до 8:00 пользователи почти не используют его, но мы должны держать его там, чтобы случайные ночные пользователи не получили ошибку 503 и не поняли, что сервис ИИ нестабилен. Мы платим за облачный хостинг, который мы покупаем, и хотя половину времени он почти не использует ЦП, никакое общедоступное облако не оплачивается по использованию ЦП, и вам приходится платить за нерабочие часы. Мы должны позаботиться о настройке Auto-Scaling Group.Как точно настроить стратегию Auto-Scaling — техническая задача, требующая многолетнего накопления опыта.На начальном этапе нам пришлось развернуть несколько простаивающих облачных хостов, чтобы на службу не повлияет автоматическое масштабирование Неправильная конфигурация и перегрузка.

После переписывания приложений ИИ с бессерверной архитектурой все эти проблемы исчезли. Фреймворк Spring и Tomcat удалены.С Lambda Java SDK вам нужно только реализовать обработчик функций для обработки события завершения загрузки изображения, что так же просто, как написать обратный вызов. Соответствующая логика распознавания изображений вызывается в обработчике функций, а затем вызывается REST API базы данных для сохранения результата. Нет необходимости создавать MVC или настраивать XML-файл Tomcat, мы полностью удалили функцию шлюза хранилища, поскольку пользователи могут напрямую загружать изображения в хранилище объектов.

Приложение AI не работает 7 x 24 часа, это просто скомпилированный код, когда ни один пользователь не загружает изображения. Когда загрузка изображения пользователя будет завершена, FaaS запустит новый процесс для выполнения кода для приложения ИИ. Процесс автоматически уничтожается после завершения выполнения кода. Мы платим только за эти десятки секунд выполнения кода, экономя много денег.

Наконец, нам не нужно беспокоиться об автоматическом масштабировании, FaaS автоматически расширяется при необходимости.

Это ядро FaaS, и его характеристики можно резюмировать из приведенного выше примера:

FaaS запускает серверный код, а не всю серверную программу. Например, приложение ИИ содержит только логику для обработки события завершения загрузки изображения, а не полную внутреннюю программу, а часть внутреннего кода.
Код запускается событиями. Поскольку больше нет длительного процесса, ожидающего или опрашивающего пользовательские запросы, код может запускаться только специальными событиями. Эти события определяются инфраструктурой FaaS, например загрузка файла в хранилище объектов, очередь сообщений, получающая новое сообщение, шлюз API, получающий новый запрос API и т. д.
Жизненный цикл кода очень короткий. Например, в нашем приложении ИИ с момента вызова обработчика функций после получения события и до конца вызова не будет выполняться резидентный процесс в памяти. Кроме того, провайдер общедоступного облака также ограничит время выполнения кода, после превышения которого процесс выполнения кода будет принудительно уничтожен. Например, максимальное время выполнения Lambda AWS составляет 5 минут.
Код должен быть полностью апатридным, а состояние памяти не может использоваться совместно вызовами. Наше приложение ИИ сначала использовало глобальную переменную для подсчета количества обработанных изображений, и счетчик увеличивался на единицу после обработки каждого изображения. После использования FaaS мы больше не можем использовать какие-либо глобальные переменные или структуры данных памяти (например, Hashmap) для обмена данными между вызовами, потому что код выполняется в отдельном процессе и не может получить доступ к адресному пространству памяти друг друга. Поэтому мы переработали код, чтобы поместить глобальный счетчик в службу Redis в общедоступном облаке, что усложнило код.
Горизонтальное масштабирование больше не является проблемой, FaaS запускает новый фрагмент кода для каждого события и запроса.
Метод развертывания приложения меняется с загрузки и настройки всей программы на загрузку упакованного файла кода (например, файла JAR или файла Zip).

Что нам дает Serverless

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

Бизнес также стал более динамичным. Нам нужно только написать код, связанный с основным бизнесом, например, часть распознавания изображений приложения AI. Нет необходимости писать какой-либо код для загрузки, развертывания и настройки приложения, например, больше не нужно настраивать systemd для загрузки приложения при запуске системы.

Горизонтальное масштабирование тоже не проблема. Как неоднократно упоминалось, платформа FaaS запускает новый код выполнения процесса для каждого события, каждого запроса API. Это похоже на метод пула потоков традиционных приложений.Каждый запрос выполняется в отдельном потоке.Разница в том, что потоки используют одно и то же адресное пространство памяти, а процессы FaaS не используют общую память. Подобно ограничению максимального количества потоков в пуле потоков, платформы FaaS обычно ограничивают максимальное количество процессов.Например, максимальное количество одновременных вызовов, которые AWS Lambda может выполнять в регионе, по умолчанию составляет 600, что означает, что наше приложение ИИ может выполнять до 600 процессов одновременно.

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

Serverless — это не серебряная пуля, это будущее серверных апплетов.

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

Запуск нового процесса для каждого запускаемого события/запроса кода является ядром FaaS, а задержка запуска процесса — первая проблема, с которой сталкивается Serverless. В зависимости от языка, на котором написано приложение, задержка запуска может составлять 10 миллисекунд (для простого приложения Python) или 1 минуту (для сложного приложения Java). Такая задержка неприемлема для программ реального времени. В настоящее время бессерверные приложения обычно работают в мультитенантной среде общедоступного облака, а задержка запуска также зависит от нагрузки на систему, и трудно гарантировать, что приложение может быть запущено в течение заданного времени. Поставщики публичных облаков в настоящее время не предоставляют соответствующих гарантий SLA для Serverless.На момент написания этой статьи у AWS Lambda не было соответствующих условий SLA.

Serverless нельзя использовать для приложений с высокой степенью параллелизма, а накладные расходы на запуск процесса для каждого запроса слишком велики. Например, Alipay обрабатывает 85 900 транзакций в секунду в пиковый период Double Eleven.Если используется бессерверная архитектура, это означает, что каждую секунду в нашей системе создается и уничтожается 85 900 процессов, что является невыносимыми накладными расходами.

Бессерверные приложения не могут находиться в памяти, а время их работы ограничено. Если ваше приложение не может завершить работу за несколько минут, то Serverless вам не вариант, например, AWS Lambda дает максимальное время выполнения процесса 5 минут, а по истечении таймаута процесс будет принудительно остановлен. Это создает проблемы для программирования, например, наше приложение ИИ должно быть оптимизировано для распознавания сложных изображений менее чем за 5 минут. Мы также не можем писать приложения, которые выполняют длительные операции ввода-вывода, такие как сложное кодирование данных 1T в хранилище объектов.

Невозможность совместного использования состояния между бессерверными вызовами чрезвычайно затрудняет написание сложных программ. Безгражданство — это цель, которую преследуют интернет-приложения, такие как приложения, отвечающие «12 элементам». Но Serverless более не имеет состояния и не может совместно использовать состояние памяти между различными вызовами, например, с использованием хэш-карты. Глобальный счетчик, который подсчитывает общее количество обработанных изображений в нашем приложении ИИ, является просто глобальной переменной в традиционной архитектуре, но в бессерверной архитектуре он становится записью, хранящейся в базе данных в памяти (Redis), затраты на обновление, гарантирующие атомарность. и другие факторы Делает наш код в несколько раз сложнее. Для большинства облачных интернет-приложений эта архитектура без учета состояния является огромной проблемой, а для корпоративных приложений, заполненных состоянием с сотнями тысяч или миллионами строк кода, бессерверное преобразование состояния — практически невыполнимая задача.

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

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

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

В облачных приложениях существует большое количество сценариев апплетов, таких как распознавание изображения, кодирование и декодирование фрагмента аудио/видео, возврат небольшого фрагмента данных на запрос от устройства IoT и уведомление персонала службы поддержки о работе. заказ, отправленный клиентом по электронной почте и т. д. Эти небольшие программы, инициируемые событиями, относительно сложно реализовать в традиционной архитектуре, и вам часто приходится выполнять 80 % вспомогательного бизнеса для 20 % основного бизнеса. Serverless прекрасно решает эти проблемы и может стать дополнительной архитектурой для сложных приложений. Мы можем разделить предприятия без сохранения состояния, инициируемые событиями, на бессерверные приложения, сделав всю архитектуру более лаконичной и эффективной.

Бессерверные технологии также развиваются: например, AWS недавно представила Step Functions, которая пытается решить проблему совместного использования состояния между вызовами, и ее эффект еще предстоит увидеть.

Serverless — это не традиционная PaaS

Грань между serverless и PaaS довольно размыта.Многие думают, что serverless — это тип PaaS.Я также склонен думать, что serverless — это особая форма PaaS.

Serverless состоит из двух частей: BaaS и FaaS.BaaS отвечает за предоставление бизнес-зависимых услуг, а FaaS отвечает за бизнес-развертывание и управление жизненным циклом.В этом смысле роль serverless такая же, как у PaaS. Отличие от традиционного PaaS заключается в том, что традиционный PaaS управляет жизненным циклом приложения на уровне программ, а Serverless управляет жизненным циклом приложения на уровне функций. Приложения в традиционной PaaS — это процессы, которые находятся в памяти, тогда как бессерверные приложения уничтожаются после запуска. Кроме того, при использовании традиционного PaaS пользователям по-прежнему необходимо заботиться о горизонтальном масштабировании, например о настройке Auto-Scaling Group, но у Serverless этой проблемы нет.Горизонтальное масштабирование является естественной особенностью архитектуры.

Бессерверные и микросервисы

Serverless не имеет прямого отношения к микросервисам, но у них есть общие черты, такие как разделение бизнеса, упор на безгражданство и гибкие функции. Бессерверные решения во многих отношениях более детализированы и более строги, чем микросервисы. Например, микросервисы разделяют сервисы на основе сервисов, а бессерверные сервисы разделяют сервисы на основе функций; микросервисы могут совместно использовать состояния памяти между вызовами, а бессерверные требуют, чтобы вызовы были полностью апатридными. Кроме того, бессерверные решения полагаются на BaaS для обеспечения сторонних зависимостей, в то время как микросервисы могут свободно выбирать сторонние зависимости, например, используя локально созданные традиционные стеки промежуточного программного обеспечения (такие как локальный MySql и шина сообщений).

Бессерверные решения и контейнеры

Serverless и контейнеры — это яблоки и апельсины, не лежащие в одной плоскости. Serverless — это архитектура разработки программного обеспечения, а контейнеры — это носители этой архитектуры. Хотя общедоступной информации нет, мы можем предположить, что бессерверные фреймворки, такие как AWS Lambda, в некоторой степени используют технологию контейнеров, иначе будет сложно добиться независимого от языка запуска на уровне миллисекунд. Хотя некоторые проекты с открытым исходным кодом использовали Docker для реализации FaaS-части Serverless, я не думаю, что общедоступные бессерверные фреймворки, такие как AWS Lambda, напрямую используют Docker, который должен быть более легкой и компактной контейнерной технологией. Нано-Контейнер.

Имеет ли Serverless смысл для частного облака?

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

С дальнейшей облачностью корпоративных приложений и зрелостью бессерверных сред с открытым исходным кодом сценарии DevOps для частного облака также могут использовать бессерверные технологии в качестве CI/CD. framework для соответствия самому Jenkins, загруженный код соответствует сценарию Bash в задании Jenkins, а исходный API Jenkins, запускающий задание, изменен для запуска кода в FaaS.

Суммировать

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