Проектирование системы аудиостримингового сервиса

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

Успешный сервис потокового аудио должен обрабатывать миллионы активных пользователей и тысячи поставщиков контента из различных географических регионов. Разные устройства и платформы (смартфоны, настольные компьютеры, умные колонки) могут поддерживать разные аудиоформаты такие как MP3, FLAC, ALAC и так далее.

В этом блоге мы рассмотрим нюансы проектирования такой сложной системы, охватывающей функциональные и нефункциональные требования.

Функциональные требования

Функциональные требования будут охватывать функции, необходимые для создателей контента и пользователей или слушателей аудио.

• Управление контентом. Создатель контента может загружать, удалять или обновлять аудио в любом формате. У каждого аудио должны быть метаданные, такие как заголовок, автор, описание, категория и метаданные теги.
• Уведомление. Создатель контента получает уведомления о успешной или неудачной загрузке аудио. Слушатель аудио или пользователь получает уведомления о успешной загрузке аудио.
• Бесшовная потоковая передача. Пользователи могут воспроизводить, ставить на паузу, перематывать и загружать аудио в выбранном ими формате.
• Подписка. Пользователи должны иметь возможность подписываться на выбранный аудио-контент для получения уведомлений о новом или обновленном контенте.
• Вход пользователя. Создатели контента должны быть аутентифицированы и авторизованы для доступа к системе. Пользователи могут зарегистрироваться в системе, чтобы настроить свои профили.
• Поиск. Пользователи должны иметь возможность искать аудио на основе определенных атрибутов или метаданных.

Примечание: Прямая трансляция и платежные сервисы не входят в рамки этой статьи.

Диаграмма последовательности функционального использования

Архитектурное проектирование

Давайте определим сервисные компоненты для поддержки функциональных требований.

Первое функциональное требование – загрузка аудио в любом формате, таком как MP3, FLAC, ALAC и т. д. Эти аудиофайлы могут содержать впечатляющее количество данных. Кодек аудио играет ключевую роль в эффективном хранении, передаче и воспроизведении этих данных. Существует в основном два типа кодеков:

1. Без потерь – сжимает аудио без потери данных и может быть полностью восстановлен без потери качества.
2. С потерями – удаляет некоторые данные, что помогает значительно уменьшить размер. Это может отразиться на качестве звука.

Поставщик контента обычно работает с без потерь форматами для записи и редактирования. Это гарантирует отсутствие потерь качества при обработке аудио, применении эффектов и мастеринге конечного продукта. Проще говоря, мастеринг аудио – последний этап в процессе производства аудио.

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

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

Для поддержки изменяющейся пропускной способности сети кодек может использовать механизм “адаптивной битрейтовой” передачи. Поток с адаптивным битрейтом в реальном времени определяет пропускную способность пользователей, автоматически корректируя поток. Он может динамически изменять битрейт потока в зависимости от текущей пропускной способности пользователя. Это приводит к меньшему буферизации, более быстрым временам запуска и хорошему опыту как для высокоскоростных, так и для низкоскоростных подключений.

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

 

Создатель контента дополнительно предоставляет метаданные при запросе на загрузку аудио, которые могут быть напрямую сохранены в NoSQL DB через сервис данных аудио. Эти данные будут проиндексированы для обеспечения более эффективной возможности поиска для аудиослушателя.

Аудиосистеме требуется служба аутентификации и авторизации для обработки регистрации новых пользователей, входа в систему с использованием учетных данных пользователя и авторизации на основе ролей, связанных с пользователями (слушателями и создателями контента). Служба шлюза API, которая может централизованно управлять аутентификацией и авторизацией. Эта служба может быть использована для выполнения маршрутизации запросов и оркестрации процесса от фронтенда к бэкенд-сервису.

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

Служба Профиля пользователя управляет настройками пользователя, подписчиками и подписками.

Вышеуказанная диаграмма изображает базовый процесс “загрузки аудио”, запущенный создателем контента, и процесс “прослушивания аудио”, запущенный пользователем/слушателем аудио.

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

Теперь перейдем к нефункциональным требованиям.

Нефункциональные требования

• Масштабируемость. Система должна поддерживать тысячи одновременных пользователей и иметь возможность масштабироваться.
• Отказоустойчивость. Система должна быть отказоустойчивой, обычно с избыточными данными, с минимальным временем простоя.
• Производительность. Система должна иметь низкую задержку и высокую отзывчивость во время воспроизведения контента.
• Безопасность. Система должна быть защищена от несанкционированного доступа или вредоносных атак, таких как DDoS.

Масштабируемость

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

Однако это не будет масштабироваться с увеличением количества создателей контента. Аудиофайлы обычно крупные, что потребует большой сетевой и вычислительной мощности при прохождении через несколько службных компонентов. Для оптимизации использования ресурсов системы может использоваться подписанный URL (также называемый предварительно подписанным URL) для предоставления временно ограниченного доступа к объектному хранилищу для прямой загрузки аудиофайлов. Это позволяет избежать направления трафика через шлюз API и веб-службу API. Подписанные URL могут быть настроены с детализированными разрешениями и правилами истечения срока действия для обеспечения лучшей безопасности.

Это покрывает требование масштабируемости для загрузки аудиофайлов поставщиками контента.

Миллионы запросов на поиск от слушателей аудио могут нагрузить систему, вызвав перегрузку службы аудиоданных. Для масштабирования системы, поддерживающей эту массовую операцию поиска, можно использовать шаблон проектирования CQRS (Content Query Responsibility Segregation). Операции чтения и записи из/в хранилище данных могут управляться независимо, поддерживая различные требования к задержке, масштабируемости и безопасности.

 

Отказоустойчивость

Существует несколько аспектов дизайна отказоустойчивости. Некоторые из них уже включены в дизайн.

• Использование нескольких экземпляров службы для масштабируемости и отказоустойчивости
• Очередь сообщений с обработкой конвейером для поддержки отказоустойчивости на уровне потока данных
• Разделение служб транскодирования и упаковки
• Несколько экземпляров базы данных с репликацией
• Доступные зоны, соответствующие географическим регионам, таким как Восточное побережье США, Западное побережье США и Азиатско-Тихоокеанский регион, для развертывания всей системы, поддерживающей определенный регион и пользовательскую базу.

Производительность

Сеть доставки контента (CDN) — это распределенная сеть серверов, объединенных для более быстрой и эффективной доставки контента, такого как аудио- и видеофайлы. Он кэширует контент на краевом сервере для обеспечения лучшей производительности с низкой задержкой. 

Безопасность

CDN также повышает безопасность, предоставляя защиту от DDoS и несколько других мер безопасности.

Сервис Package будет распределять аудиофайлы по CDN для кэширования на краевых серверах. Сервис Audio Data будет обновлять местоположение CDN в своих метаданных, которые будут направлены в сервис Search для запросов пользователей.

 

Вышеуказанная диаграмма изображает архитектуру компонентов высокого уровня типичной аудиосистемы.

Заключение

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