«Эмьюз»: как построить масштабируемый музыкальный сервис с помощью DBaaS и контейнеризации

«Эмьюз»: запуск музыкальных сервисов требует масштабируемой инфраструктуры хранения данных

Мы занимаемся запуском — разработкой и поддержкой — музыкальных сервисов под white label для B2B и B2C, работаем с ведущими операторами РФ и СНГ.

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

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

Типичное решение для таких задач — переход на получение вычислительных ресурсов, хранение и обработку данных в облаке.

Облако — идеальный вариант для непредсказуемой нагрузки

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

На момент старта проекта VK Cloud еще не существовало, и мы изначально запустились на Azure. В 2018 году, когда появилась облачная платформа от VK, переехали на нее. Во-первых, тарифы VK Cloud гораздо интереснее, мы существенно сократили текущие ИТ-затраты. Во-вторых, команда VK Cloud иначе подходит к поддержке клиентов. У нас всегда есть доступ к поддержке и экспертам-архитекторам VK Cloud в реальном времени, в чате, а не в тикетной системе.

На старте мы пользовались существовавшими на тот момент сервисами: S3-хранилищем и виртуальными машинами, постепенно расширяя вариации их использования еще до того, как на платформе появились DBaaS и кластеры Kubernetes. Нам приходилось самим запускать на инфраструктуре свои сервисы, приложения, базы данных.

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

В итоге мы храним данные следующим образом:

• Весь аудиоконтент находится в объектном S3-хранилище VK Cloud. Здесь же хранятся отчеты и некоторые другие файлы. Объектное хранилище сняло для нас вопрос о масштабируемом хранении аудиотреков.
• В качестве основной базы используется PostgreSQL.
• Такие данные, как логи для аналитики и рекомендаций, хранятся в управляемой базе ClickHouse от VK Cloud.
• Для поисковых данных используется поисковое хранилище Elasticsearch.

Оптимизация затрат на эксплуатацию баз данных

У нас несколько кластеров баз данных. Один из них — большая база данных PostgreSQL в конфигурации Master/Slave. Нашей команде приходилось собственными силами следить за ее размером, делать и проверять бэкапы. Мы решили уйти от этих трудоемких операций за счет миграции базы данных в формат DBaaS. На сегодняшний день мы уже перевели один кластер и тестируем результат, потом хотим перевести второй.

ClickHouse у нас задействован для работы с большими данными — в частности, для долговременного хранения метаинформации о музыкальных треках и последующей аналитики. Изначально мы сами настраивали ClickHouse. Но его репликация с помощью ZooKeeper подразумевала, что для двух серверов ClickHouse нам нужно пять серверов под инфраструктуру, что неудобно. Когда на VK Cloud появилась ClickHouse aaS с полностью готовой реализацией репликации, мы перешли на нее. Специально для нас VK Cloud провели ряд улучшений, например расширили размер хранилища под метаданные.

Задачи потоковой обработки данных пока решаются с помощью собственных брокеров очередей.

Перевод инфраструктуры приложений с Docker Swarm на Kubernetes

Помимо самого хранения данных, в проекте есть различные операции по их обработке: конвертации треков, созданию персонализированных рекомендаций и так далее. Для приложений, которые выполняют такие операции, мы первоначально задействовали кластеризацию на базе Docker Swarm, который самостоятельно развернули поверх виртуальных машин VK Cloud, добавив Elasticsearch, брокеры очередей, балансировку нагрузки и другие сервисы.

Docker Swarm — простой и понятный сервис, работать с ним удобно. Но ввиду простоты в нем сложно реализовать что-то дополнительно. Ни о каком автомасштабировании не было речи, все приходилось делать вручную. Нужные нам функции доступны в Kubernetes. В 2018 году он появился на VK Cloud в виде управляемого сервиса, и мы решили перевести приложения на него.

Сейчас перевели в кластер Kubernetes часть внутренних сервисов проекта, но планируем также перевести с Docker Swarm на Kubernetes все приложения и задействовать автомасштабирование.

Один из самых востребованных процессов, который мы полностью перевели на Kubernetes, — конвертация аудио. После получения от поставщика музыкальный контент конвертируется для конечных пользователей в несколько вариантов в разном качестве. Этот процесс ресурсоемкий, но выполняется не постоянно, только при появлении нового контента. Обработка может занять, к примеру, 2-3 дня, а потом ресурсы становятся не нужны. Под эту задачу мы создали динамический кластер, позволяющий привлекать ресурсы в нужный момент и отключать, когда в них нет необходимости. В VK Cloud Containers это можно делать «по кнопке» в интерфейсе и платить только за диски в случае отключенных кластеров.

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

Эффект от перехода на VK Cloud

Для проектов, где хранится очень много контента, использовать облако выгодно и при росте, и при сокращении объема данных.

В момент роста, когда появляется новый поставщик и планируется большой прирост контента, облако позволяет быстро организовать заливку треков: подписали договор, интегрировались и начинаем заливать контент. Облачная платформа уже готова и располагает нужным объемом для хранения данных. Не надо тратить время на закупку оборудования, считать, сколько контента будет залито через Х лет, чтобы купить его на перспективу. Не нужно вводить новое оборудование в ЦОД и настраивать, внедрять в инфраструктуру и снова тратить время и деньги. С облаком мы работаем без задержек, и неважно, сколько контента будет залито: 10 или 500 Тбайт.

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

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

Планы по дальнейшему развитию технологического стека

• Первоочередная задача — переход на Kubernetes для управления приложениями с целью снижения трудозатрат и получения дополнительных функциональностей.
• Также мы планируем больше баз данных получать в виде DBaaS, в том числе перевести на PostgreSQL aaS второй кластер. Все они сейчас поддерживаются вручную на инфраструктуре виртуальных машин — назрела необходимость переехать в удобный сервис с возможностью масштабирования по потребностям.
• Планируется внедрение новой системы рекомендаций. Сейчас идет ее разработка и тестирование. В бою для нее потребуются ресурсы под обработку данных, чтобы определять предпочтения пользователей и давать правильные рекомендации.

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