ПОНИМАНИЕ ПРИЧИН, ПОЧЕМУ ОДИН РАЗМЕР НЕ ПОДХОДИТ ДЛЯ ВСЕХ, ДАЖЕ С БЕССЕРВЕРНЫМИ
Что произойдет, если Amazon откажется от безсерверной версии?
Начиная с противоречивой статьи, мы исследуем причины, которые могут привести к внедрению бессерверных технологий или вызвать разногласия.
Если вы недавно не жили под скалой, весь бессерверный мир был потрясен, когда даже Amazon, по-видимому, решила отойти от бессерверных технологий.
Давайте сделаем глубокий вдох и попытаемся понять вещи такими, какие они есть, а не такими, какими кто-то хотел бы их видеть. Короче говоря, более месяца назад команда Amazon Prime опубликовала спорную статью под названием Масштабирование службы аудио/видео мониторинга Prime Video и снижение затрат на 90%, в которой они заявили, что им необходимо перейти на монолитную архитектуру, чтобы соответствовать ряду сложных требований. Мы углубимся в статью в несколько строк, но остановимся на заголовке и притворимся, что у нас есть предварительное понимание.
Статья оставалась незамеченной в течение почти пяти недель, пока хорошо зарекомендовавший себя антиоблачный пророк DHH не написал сердечную статью, которую ChatGPT смог точно обобщить, как я вам и сказал. Я был прав. Я не знаю, кусала ли когда-нибудь собака Безоса Дэвида за руку в прошлом, или того, что он был отцом монолита Ruby on Rails, было достаточно, чтобы он возмутился. Честно говоря, от такого высококвалифицированного специалиста, как он, я ожидал лучшего баланса и более глубокого анализа, чем просто кричать на облако.
К сожалению, DHH сильно самоуверен, так как он ушел из облака с Basecamp. Я не располагаю подробностями этого выбора, которые имели бы для него смысл, но его публичные аргументы были как минимум сомнительными. Для начала он написал сложную статью, в которой описал экономию средств, связанную с переходом от облака, в которой необходимо было упомянуть расходы на жилье, людей и техническое обслуживание.
Недавно он поднял планку своей самоуверенности этой наивной позицией по поводу serverless, придя, таким образом, сразу после однотипных заявлений против микросервисов. Давайте сделаем еще один шаг и проанализируем то, что объяснила команда Amazon.
Что сказала команда Amazon?
Внимательно прочитав статью, мы можем выделить некоторые ключевые моменты их использования, о которых стоит упомянуть.
«Наша команда по анализу качества видео (VQA) в Prime Video уже имела инструмент для проверки качества аудио/видео, но мы никогда не планировали и не разрабатывали его для работы в больших масштабах (наша цель состояла в том, чтобы отслеживать тысячи одновременных потоков и расширять это число со временем). Подключая больше потоков к сервису, мы заметили, что запуск инфраструктуры в больших масштабах обходится очень дорого. Мы также заметили узкие места масштабирования, из-за которых нам не удавалось отслеживать тысячи потоков».
Это ясно: у них был инструмент, предназначенный для обработки нескольких потоков, который в конечном итоге использовался для обработки тысяч потоков в режиме реального времени.
Мы разработали наше первоначальное решение как распределенную систему с использованием бессерверных компонентов (например, AWS Step Functions или AWS Lambda), что было хорошим выбором для быстрого создания сервиса. Теоретически это позволило бы нам независимо масштабировать каждый сервисный компонент. Однако то, как мы использовали некоторые компоненты, привело к тому, что мы достигли жесткого предела масштабирования на уровне около 5% от ожидаемой нагрузки. Кроме того, общая стоимость всех строительных блоков была слишком высока, чтобы принять решение в больших масштабах.
Эта часть довольно сложная: оркестровка была проблемой. Это имеет смысл, потому что оркестровка сервисов неизбежно приводит к трениям, а масштабирование означает, что ваша система должна масштабироваться, чтобы поддерживать пропускную способность самой быстрой части системы. Кроме того, возникает еще один важный аспект: все упомянутые функции относятся к одной и той же бизнес-области. Это фундаментальный аспект приложения: команда разобрала архитектуру как распределенную систему с множеством компонентов, чтобы добиться быстрых итераций при построении решения, вероятно, потому, что требования были неясными, и в процессе было много переделок. Это был мудрый выбор, который нужно было изменить позже, когда приложение достигло стабильности функций, и необходимо было гарантировать высокую масштабируемость с временем отклика в реальном времени.
Нам нужно выяснить, с какими ограничениями они столкнулись в отношении времени отклика и можно ли ослабить некоторые из них в пользу асинхронной хореографии вместо оркестровки StepFunction, тем самым избегая затрат на переходы состояний StepFunction.
Вторая проблема, которую мы обнаружили, связана с тем, как мы передавали видеокадры (изображения) по разным компонентам. Чтобы сократить количество задач по конвертации видео, требующих значительных вычислительных ресурсов, мы создали микросервис, который разбивает видео на кадры и временно загружает изображения в корзину Amazon Simple Storage Service (Amazon S3). Детекторы дефектов (где каждый из них также работает как отдельный микросервис) затем загружают изображения и одновременно обрабатывают их с помощью AWS Lambda. Однако большое количество вызовов уровня 1 в корзину S3 обходилось дорого.
Здесь нам нужно получить информацию о требованиях, которые мешали команде сохранять видеокадры в нечто вроде EFS, а затем подтягивать их в контекст выполнения Lambda. Я бы рассмотрел этот подход, потому что S3 отлично подходит для хранения данных, но становится очень дорогим, когда вам нужно масштабировать количество обращений. Если ваш вариант использования позволяет это, лучше предпочесть EFS S3, у которого есть модель оплаты по мере использования, не привязанная к количеству запросов.
Один размер не подходит всем.
Микросервисы характеризуются меньшим размером и большей простотой управления. Они могут использовать технологические стеки, адаптированные к их бизнес-потребностям, что приводит к сокращению времени развертывания и ускорению адаптации разработчиков. Кроме того, микросервисы позволяют добавлять новые компоненты без нарушения работы всей системы; если один микросервис выходит из строя, остальная часть системы может продолжать функционировать. Эта архитектура известна своей эволюционируемостью, которую можно легко адаптировать и модифицировать. Начиная с простой структуры, она может постепенно усложняться, чтобы соответствовать общему видению.
Это не обязательный рецепт, а набор преимуществ, которые можно и нужно тщательно оценить. Монолиты могут быть хорошим выбором для небольшого стартапа из-за простоты разработки. Команда может выбрать технологию, которая увеличивает коммуникационные трения, но значительно снижает когнитивную нагрузку команды, не требуя от них управления различными аспектами своего приложения, от экземпляров до масштабируемости базы данных или передовых методов инфраструктуры.
Микросервисы и бессерверные компоненты — это инструменты, которые действительно работают в больших масштабах, но использовать ли их вместо монолита нужно решать в каждом конкретном случае.
У каждого архитектора есть несколько вариантов или параметров анализа, которые могут повлиять на результат проекта: от монолитных/распределенных до бессерверных/виртуальных машин, единого языка для всего и правильного инструмента для нужной задачи. За свою карьеру я видел, как разработчики неоднократно использовали одну и ту же базу данных, потому что они были уверены только в ней, а команды меняли язык/фреймворк каждые три месяца, чтобы быть в курсе последних событий. Все эти позиции глубоко ошибочны, потому что они не учитывают ценность результата для бизнеса и не учитывают множество ограничений, с которыми приходится сталкиваться архитектору.
Вот почему я не верю в религию отказа DHH от облачных вычислений не потому, что я люблю бессерверные технологии (которые я считаю средством создания эволюционных архитектур, управляемых событиями), а потому, что это абсолютная позиция, совершенно неотличимая от того, что кто-то кричит: вы должны использовать serverless для всего.
Мы все должны были усвоить, что только ситхи имеют дело с абсолютами.
