Amazon Prime перейшов з мікросервісів на моноліт й зменшив кости на 90%

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Марчін Кольни, Senior SDE у Prime Video, поділився кейсом про те, як скейлінг Prime Video аудіо та відео моніторингового сервісу дозволив зменшити кости на 90%. Даємо переклад його матеріалу з найцікавішими тезами.

Щоб переконатися, що клієнти безперебійно отримують контент, Prime Video створила інструмент для моніторингу кожного потоку, який переглядають клієнти. Цей інструмент дозволяє нам автоматично виявляти проблеми з якістю сприйняття (наприклад, проблеми із синхронізацією аудіо/відео) і запускати процес для їх усунення.

Команда з аналізу якості відео (VQA) у Prime Video вже володіла інструментом для перевірки якості аудіо/відео, але ніколи не планувала й не проєктувала його для роботи у високому масштабі (мета полягала в тому, щоб відстежувати тисячі одночасних потоків і з часом збільшувати їх кількість). Впроваджуючи більше потоків у службу, ми помітили, що запуск інфраструктури у високому масштабі коштує дуже дорого. Ми також помітили вузькі місця масштабування, через які не було можливості контролювати тисячі потоків. Отже, довелось переглянути архітектуру існуючої служби, зосередившись на вартості та масштабуванні вузьких місць.

Перша версія цього сервісу складалася з розподілених компонентів, які були організовані AWS Step Functions.

Двома найдорожчими операціями з точки зору вартості були:

• оркестровка робочого процесу;
• передача даних між розподіленими компонентами.

Щоб розв’язати цю проблему, ми перемістили всі компоненти в єдиний процес, щоб передача даних залишалася в пам’яті, це також спростило логіку оркестровки. Оскільки ми зібрали всі операції в єдиний процес, ми могли покластися на масштабовані екземпляри Amazon Elastic Compute Cloud (Amazon EC2) і Amazon Elastic Container Service (Amazon ECS) для деплойменту.

З мікросервісу на моноліт

Продукт складається з трьох основних компонентів:

1. Медіаконвертер перетворює вхідні аудіо/відеопотоки на кадри або розшифровані аудіобуфери, які надсилаються на детектори.
2. Детектори дефектів виконують алгоритми, які аналізують кадри та аудіобуфери в режимі реального часу, шукаючи дефекти (наприклад, зависання відео, пошкодження блоку або проблеми синхронізації аудіо/відео) і надсилають сповіщення в реальному часі щоразу, коли виявлено дефект.
3. Третій компонент забезпечує оркестровку, яка контролює потік.

Початкове рішення було розроблено як розподілена система з використанням безсерверних компонентів (наприклад, AWS Step Functions або AWS Lambda), що було хорошим вибором для швидкого створення сервісу. Теоретично це дозволить масштабувати кожен компонент служби незалежно. Однак те, як ми використовували деякі компоненти, призвело до того, що ми досягли жорсткого обмеження масштабування на рівні приблизно 5% від очікуваного навантаження. Крім того, загальна вартість усіх блоків була надто високою, щоб прийняти рішення у масштабі сервісу.

На діаграмі показано безсерверну архітектуру власне сервісу:

Основним вузьким місцем масштабування в архітектурі було керування оркеструванням, що було реалізовано за допомогою AWS Step Functions. Сервіс виконував кілька state transition для кожної секунди потоку, тому ми швидко досягли лімітів облікових записів. Крім того, AWS Step Functions стягує плату з користувачів за state transition.

Друга проблема вартості стосувалась того, як ми передавали відеокадри (зображення) навколо різних компонентів. Щоб скоротити обчислювальні дорогі завдання з перетворення відео, ми створили мікросервіс, який розбиває відео на кадри та тимчасово завантажує зображення до сегмента Amazon Simple Storage Service (Amazon S3). Потім детектори дефектів (де кожен із них також працює як окремий мікросервіс) завантажують зображення та одночасно обробляють їх за допомогою AWS Lambda. Однак велика кількість звернень Tier-1 до сегмента S3 була дорогою.

Спочатку розглядали можливість окремого розв’язання проблем, щоб зменшити вартість і збільшити можливості масштабування. Ми експериментували та прийняли сміливе рішення: перебудувати інфраструктуру.

Розподілений підхід не надає багато переваг у конкретному випадку використання, тому логічно було об’єднати всі компоненти в єдиний процес. Це усунуло потребу у S3 як проміжному сховищі для відеокадрів, оскільки передача даних тепер відбувалася в пам’яті. Також реалізували оркестровку, яка контролює компоненти в одному екземплярі.

На наступній діаграмі показано архітектуру системи після переходу до моноліту.

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

У початковій версії ми могли масштабувати кілька детекторів горизонтально, оскільки кожен із них працював як окремий мікросервіс (тому для додавання нового детектора потрібно було створити новий мікросервіс і підключити його до оркестровки). Однак у новому підході кількість детекторів масштабується лише вертикально, оскільки всі вони працюють в одному екземплярі. Ми регулярно додаємо нові детектори до служби, і вони вже перевищили потужність одного екземпляра. Щоб подолати цю проблему, довелось кілька разів клонувати сервіс, параметризуючи кожну копію за допомогою іншої підмножини детекторів. Також був реалізований легкий рівень оркестровки для розподілу запитів клієнтів.

На наступній діаграмі показано рішення для деплойменту детекторів, коли пропускна здатність одного екземпляра перевищена.

Висновки

Мікросервіси та безсерверні компоненти — це інструменти, які працюють у високому масштабі, але чи використовувати їх поверх моноліту, слід вирішувати в кожному конкретному випадку.

Перенесення послуг на монолітну систему знизило витрати на інфраструктуру більш ніж на 90%. Це також збільшило можливості масштабування. Сьогодні ми можемо обробляти тисячі потоків і все ще мати можливості для подальшого масштабування сервісу. Перенесення рішення на Amazon EC2 і Amazon ECS також дозволило нам використовувати плани економії обчислювальних ресурсів Amazon EC2, які допоможуть ще більше знизити витрати.

Деякі прийняті рішення неочевидні, але вони призвели до значних покращень. Наприклад, був відтворений дорогий процес перетворення медіафайлів і розміщення його ближче до детекторів. Хоча одноразове перетворення медіафайлів і кешування його результатів може вважатися дешевшим варіантом, з’ясувалось, що це нерентабельний підхід.

Зміни дозволяють Prime Video відстежувати всі потоки, а не лише ті, які мають найбільшу кількість глядачів. Цей підхід забезпечує вищу якість і кращий досвід клієнтів.