Amazon Prime Video: переход от микросервисов к монолиту сократил косты на 90%
В этой статье переводим Case-study команды Amazon, которое было опубликовано в их блоге.
Amazon Prime Video транслирует тысячи видео клиентам. Для получения контента клиентами, в Prime Video создан инструмент для мониторинга каждой просматриваемой клиентами трансляции. Этот инструмент позволяет автоматически определять проблемы с восприятием качества например, повреждения блоков или проблемы с синхронизацией аудио/видео и запускать процесс их устранения.
У команды анализа качества видео (Video Quality Analysis, VQA) в Prime Video уже был инструмент для проверки качества аудио/видео, он не разрабатывался для работы в большом масштабе (целью был мониторинг тысяч параллельных потоков и постепенное увеличение этого числа). При добавлении ещё большего количества потоков в сервис, команда обнаружила, что поддержка инфраструктуры в большом масштабе стоит очень дорого. Они также заметили проблемы с масштабированием, которые мешали мониторить тысячи потоков. Поэтому они сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточившись на стоимости и проблемах масштабирования.
Изначальная версия сервиса состояла из распределенных компонентов, которые оркестрировались с помощью AWS Step Functions. Две самые затратные операции с точки зрения стоимости были связаны с оркестрацией рабочего процесса и передачей данных между распределенными компонентами. Чтобы справиться с этим, команда переместила все компоненты в один процесс, чтобы передача данных оставалась в пределах памяти этого процесса, что также упростило логику оркестрации. Поскольку команда скомпилировала все операции в один процесс, можно все задеплоить на экземпляры Amazon Elastic Compute Cloud (Amazon EC2) и Amazon Elastic Container Service (Amazon ECS).
Distributed systems overhead
Сервис состоит из трех компонентов. Медиа конвертер преобразует входные аудио/видеопотоки в кадры или расшифрованные аудиобуферы, которые отправляются на "детекторы". Детекторы выполняют алгоритмы, анализирующие кадры и аудио буферы в реальном времени в поиске дефектов таких, как: замирание видео, повреждение блоков или проблемы синхронизации аудио/видео и отправляют уведомления в режиме реального времени при обнаружении дефекта. Дополнительную информацию по этой теме прочитать в блоге Amazon.
Как было описано выше, первоначальное решение состояло из: AWS Step Functions или AWS Lambda. В теории это позволяло масштабировать каждый компонент сервиса независимо. Однако, способ использования некоторых компонентов привел к достижению жесткого предела масштабирования при примерно 5% от ожидаемой нагрузки. Кроме того, общая стоимость была слишком высокой для применения решения в большом масштабе.
На следующей схеме показана serverless архитектура сервиса которая была до перехода к "монолиту":
Главным узким местом масштабирования в архитектуре было управление оркестрацией, которое было реализовано с помощью AWS Step Functions. Сервис выполнял много переходов состояний для каждой секунды стрима, поэтому Amazon быстро достигали лимитов учетной записи. Кроме того, AWS Step Functions взимает плату у пользователей за "per state transition"
Вторая проблема с затратами связана с тем, как Amazon передавали видео фреймы между различными компонентами. Чтобы уменьшить вычислительно затратные задачи по преобразованию видео, команда создала микросервис, который разбивает видео на кадры и временно загружает изображения в хранилище Amazon Simple Storage Service (Amazon S3). Затем детекторы дефектов (каждый из них также работает в качестве отдельного микросервиса) загружают изображения и обрабатывают их параллельно с использованием AWS Lambda. Однако большое количество вызовов Tier-1 к хранилищу S3 было дорогостоящим.
От распределенной микросервисной архитектуры к монолитному приложению
Для устранения узких мест в Amazon изначально рассматривали возможность исправления проблем по отдельности, чтобы снизить затраты и увеличить возможности масштабирования. Провели эксперименты и приняли смелое решение: решили переработать нашу инфраструктуру.
Amazon пришли к выводу, что распределенный подход не приносит много преимуществ в их конкретном случае, поэтому они упаковали все компоненты в один процесс. Это позволило избавиться от необходимости использования хранилища S3 в качестве промежуточного хранилища для видео фреймов, поскольку передача данных теперь происходила в памяти. Также реализовали оркестрацию, которая управляет компонентами в рамках одного экземпляра.
На следующей схеме показана архитектура системы после перехода к монолиту:
В концептуальном плане, высокоуровневая архитектура осталась неизменной. Есть те же компоненты, которые использовали в начальном проектировании (преобразование медиа, детекторы и оркестрация). Это позволило нам повторно использовать много кода и быстро перейти к новой архитектуре.
На следующей схеме показана деплоймент схема для детекторов, когда капасити одного инстанса не хватает:
Результаты и полученные уроки
Микросервисы и компоненты serverless – это инструменты, которые работают в условиях высокой нагрузки, но выбор между ними и монолитной архитектурой должен быть принят в каждом конкретном случае.
Перенос сервиса на монолитную архитектуру позволил сократить затраты на инфраструктуру более чем на 90%. Это также увеличило возможности масштабирования. Приложение может обрабатывать тысячи потоков, и все еще есть возможность дальнейшего масштабирования сервиса. Перенос на Amazon EC2 и Amazon ECS также позволил амазону использовать программы экономии вычислительных ресурсов Amazon EC2, что поможет еще больше снизить затраты.
Некоторые принятые амазоном решения не являются очевидными, но они привели к значительным улучшениям. Например, они создали несколько реплик вычислительно затратного процесса преобразования медиа и разместили их ближе к детекторам. Хотя можно было бы считать более дешевым вариантом запускать процесс преобразования медиа один раз и кэшировать его результат, но они поняли, что это неэффективный подход с точки зрения затрат.
Внесенные изменения позволяют Prime Video отслеживать все потоки, просматриваемые клиентами, а не только те, у которых наибольшее количество зрителей. Этот подход приводит к еще более высокому качеству и улучшенному опыту для клиентов.