Pull to refresh
98.61
CloudMTS
Виртуальная инфраструктура IaaS

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

Reading time 4 min
Views 11K
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. Другие материалы из нашего блога:

Tags:
Hubs:
+11
Comments 3
Comments Comments 3

Articles

Information

Website
cloud.mts.ru
Registered
Founded
Employees
201–500 employees
Location
Россия