Переход от архитектуры распределённых микросервисов к монолитному приложению помог добиться более высокого масштаба, отказоустойчивости и снизить затраты.
В Prime Video мы предлагаем нашим клиентам тысячи прямых трансляций. Чтобы гарантировать, что клиенты беспрепятственно получают контент, Prime Video создала инструмент для мониторинга каждого потока, просматриваемого клиентами. Этот инструмент позволяет нам автоматически выявлять проблемы с качеством воспринимаемого контента (например, повреждение блока или проблемы с синхронизацией аудио / видео) и запускать процесс их устранения.
У нашей команды анализа качества видео (VQA) в Prime Video уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования.
Первоначальная версия нашего сервиса состояла из распределенных компонентов, которые были организованы AWS Step Functions. Двумя наиболее дорогостоящими операциями с точки зрения затрат были рабочий процесс оркестровки и передача данных между распределёнными компонентами. Чтобы решить эту проблему, мы переместили все компоненты в единый процесс, чтобы сохранить передачу данных в памяти процесса, что также упростило логику оркестровки. Поскольку мы объединили все операции в единый процесс, мы могли полагаться при развёртывании на масштабируемые экземпляры Amazon Elastic Compute Cloud (Amazon EC2) и Amazon Elastic Container Service (Amazon ECS).
Накладные расходы распределённых систем
Наш сервис состоит из трёх основных компонентов. Медиаконвертер преобразует входные аудио/видеопотоки в кадры или расшифрованные аудиобуферы, которые отправляются на детекторы. Детекторы дефектов выполняют алгоритмы, которые анализируют кадры и аудиобуферы в режиме реального времени в поисках дефектов (таких как замораживание видео, повреждение блоков или проблемы с синхронизацией аудио/ видео) и отправляют уведомления в режиме реального времени при обнаружении дефекта. Для получения дополнительной информации по этой теме ознакомьтесь с нашей статьёй о том, как Prime Video использует машинное обучение для обеспечения качества видео. Третий компонент обеспечивает оркестровку, которая управляет потоком в сервисе.
Мы разработали наше первоначальное решение как распределённую систему с использованием serverless-компонентов (например, AWS Step Functions или AWS Lambda), что было хорошим выбором для быстрого создания сервиса. Теоретически, это позволило бы нам масштабировать каждый компонент сервиса независимо. Однако то, как мы использовали некоторые компоненты, привело к тому, что мы упирались в жёсткий предел масштабирования — около 5% от ожидаемой нагрузки. Кроме того, общая стоимость всех строительных блоков была слишком высока, чтобы использовать это решение для ещё больших масштабов.
На следующей диаграмме показана serverless-архитектура нашего сервиса.
Основным узким местом масштабирования в архитектуре было управление оркестровкой, которое было реализовано с использованием функций AWS Step. Наш сервис выполнял несколько переходов состояний за каждую секунду потока, поэтому мы быстро достигли учётных лимитов. Кроме того, AWS Step Functions взимает плату с пользователей за каждый переход состояния.
Вторая проблема с затратами, которую мы обнаружили, была связана с тем, как мы передавали видеокадры (изображения) по разным компонентам. Чтобы сократить вычислительные затраты на преобразование видео, мы создали микросервис, который разбивает видео на кадры и временно загружает изображения в корзину Amazon Simple Storage Service (Amazon S3). Детекторы дефектов (где каждый из них также работает как отдельный микросервис) затем загружают изображения и обрабатывают их одновременно с помощью AWS Lambda. Однако большое количество вызовов уровня 1 в корзину S3 было дорогостоящим.
От распределённых микросервисов к монолитному приложению
Чтобы устранить узкие места, мы изначально рассматривали возможность устранения проблем отдельно, чтобы снизить затраты и расширить возможности масштабирования. Мы поэкспериментировали и приняли смелое решение: решили перестроить нашу инфраструктуру.
Мы поняли, что распределённый подход не приносит больших преимуществ в нашем конкретном случае использования, поэтому мы объединили все компоненты в единый процесс. Это устранило необходимость в корзине S3 в качестве промежуточного хранилища для видеокадров, поскольку наша передача данных теперь происходила в памяти. Мы также внедрили оркестровку, которая управляет компонентами в пределах одного экземпляра.
На следующей диаграмме показана архитектура системы после перехода на монолитную компоновку.
Концептуально высокоуровневая архитектура осталась прежней. У нас по-прежнему есть точно те же компоненты, что и при первоначальном проектировании (преобразование мультимедиа, детекторы или оркестровка). Это позволило нам повторно использовать большой объём кода и быстро перейти на новую архитектуру.
В первоначальном проекте мы могли масштабировать несколько детекторов горизонтально, поскольку каждый из них работал как отдельный микросервис (поэтому для добавления нового детектора требовалось создать новый микросервис и подключить его к оркестровке). Однако в нашем новом подходе количество детекторов масштабируется только вертикально, поскольку все они выполняются в одном экземпляре. Наша команда регулярно добавляет в сервис новые детекторы, и мы уже превысили возможности одного экземпляра. Чтобы преодолеть эту проблему, мы клонировали сервис несколько раз, параметризируя каждую копию с помощью другого подмножества детекторов. Мы также внедрили облегчённый уровень оркестровки для распределения запросов клиентов.
На следующей диаграмме показано наше решение для развертывания детекторов при превышении пропускной способности одного экземпляра.
Результаты и выводы
Микросервисы и бессерверные компоненты — это инструменты, которые действительно работают в больших масштабах, но вопрос о том, использовать ли их с монолитной компоновкой, должен решаться в каждом конкретном случае.
Перевод нашего сервиса в монолитный формат снизил стоимость нашей инфраструктуры более чем на 90%. Это также увеличило наши возможности масштабирования. Сегодня мы можем обрабатывать тысячи потоков, и у нас все еще есть возможности для дальнейшего масштабирования сервиса. Перенос решения на Amazon EC2 и Amazon ECS также позволил нам использовать планы экономии вычислений Amazon EC2, которые помогут еще больше снизить затраты.
Некоторые решения, которые мы приняли, неочевидны, но они привели к значительным улучшениям. Например, мы воспроизвели дорогостоящий с точки зрения вычислений процесс преобразования носителей и разместили его ближе к детекторам. В то время как однократное преобразование мультимедиа и кэширование его результатов можно было бы считать более дешёвым вариантом, мы пришли к выводу, что это не самый экономичный подход.
Внесенные нами изменения позволяют Prime Video отслеживать все трансляции, просматриваемые нашими клиентами, а не только те, у которых наибольшее количество зрителей. Такой подход приводит к еще более высокому качеству и еще лучшему обслуживанию клиентов.
Автор: Михаил Соколов
