Как Spotify масштабирует Apache Storm

Original author: Kinshuk Mishra
  • Translation
Spotify — шведский сервис потокового воспроизведения музыки с которым сотрудничают такие компании как Sony, EMI, Warner, и Universal. Сервис Spotify был запущен в октябре 2008 года, сейчас он предоставляет более 30 млн композиций. Многие считают его попыткой повторить успех Napster и легализовать его модель. Шведам все это удалось едва ли не лучше всех в мире.

Сам сервис работает следующим образом (общее описание): алгоритм анализирует плейлисты пользователей с учетом точечной классификации по жанрам и сравнивает полученные «профили предпочтений» с миллионами других плейлистов. В результате — вы получаете песни, которые подходят вашим вкусам и не воспроизводились ранее.


/ фото Sunil Soundarapandian CC

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

В Spotify были созданы несколько конвейеров задач. Здесь разработчики решили разделить все по смыслу и предполагаемой нагрузке. Таким образом, были разделены как рекламные и рекомендательные сервисы, так и все, что связано с визуализацией. С технической точки зрения такое разделение организовано на основе Apache Storm.

В наших материалах на Хабре мы много рассказываем о том, каким образом виртуальная инфраструктура решает задачи связанные с масштабируемостью с учетом увеличивающейся рабочей нагрузки. Ситуация с быстрорастущим сервисом Spotify не является исключением — логика разрешения данного кейса абсолютно аналогична.

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

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

Кластер Kafka — собирает темы для различных видов событий, а Storm подписывается на пользовательские события и снабжает их специальными метаданными, которые считываются из Cassandra. Такой подход позволяет учитывать персональный опыт работы с сервисом каждого отдельного пользователя. На основе дальнейших вычислений возможно получить общие и усредненные модели, которые будут уже применимы для рекомендации интересного контента другим пользователям сервиса Spotify.

Учитывая всю сложность настройки и отладки подобного механизма, разработчики советуют придерживаться определенных принципов, которые (по их словам) помогают упростить работу. Здесь все стандартно: дробление топологии на логическом уровне для разных по своей сути задач и использование универсальных библиотек — сокращение базы кода и блоков с тестами.

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


/ фото stuartpilbrow CC

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

Мы уже немного познакомились с тем, что из себя представляет конвейер персонализации. Теперь посмотрим, зачем здесь использован Apache Storm. Итак, с учетом независимости вычислений в нескольких топологиях персонализации и дублирования обработки событий системе требуется определенный уровень производительности (кластер Storm).

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

Apache Storm, который необходим для работы системы, является распределенным инструментом обработки больших обьемов данных в реальном времени. Его использование гарантирует отказоустойчивость благодаря механизму контроля за качеством обработки данных (подробнее). Согласно лучшим практикам, здесь он использован в комбинации с Apache Kafka.

Автор говорит о том, что на данный момент сервис обрабатывает более 3 миллиардов событий в день. Эта задача требует стабильной пропускной способности и минимизации латентности, что можно достигнуть путем балансировки нагрузки в Kafka и использования различных групповых id для каждого KafkaSpout.

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

Авторы данной презентации советуют обратить внимание на самые медленные из заданий, которые требуют распараллеливания и выделения ресурсов. Быстрые — не нуждаются в таком пристальном внимании.

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

P.S. Другие материалы из нашего блога:

  • +11
  • 10.3k
  • 3
ИТ-ГРАД
300.02
vmware iaas provider
Share post

Comments 3

    –1
    В описании Сторма есть яркий маркетинг про: «процессинг более миллиона записей в секунду на одной ноде».
    А сколько в итоге ваша система перемалывает в секунду на ноде? (а также сколько памяти/цпу на ноду)
    И какое среднее время обработки одной записи?
    Как я понимаю при 50 миллионах активных пользователей и среднем времени трека 3-4 минуты (или нет?) будет около 200-300 тысяч событий в секунду, тоесть теоретически даже одна сферическая нода в вакууме должна справляться? ;)
      +3
      Решил затеять чятик с переводом? Похвально!
        0
        Не заметил, надо больше спать…
        и то что itgrad не имеет отношения к разработке спотифай меня почему-то тоже не смутило :)

    Only users with full accounts can post comments. Log in, please.