×Закрыть

Архитектура видеосервиса Megogo: варианты решений и переход от монолита к микросервисам

Megogo превратился из стартапа в один из крупнейших видеосервисов в странах Восточной Европы и СНГ. За это время наши технологии и подходы претерпели множество изменений и улучшений. Быстрый рост непременно вызывает массу проблем, к которым молодые компании часто попросту не готовы. Выбранный язык программирования не слишком подходит для выполнения поставленных целей, фреймворки сложно масштабировать, узкие места в каналах CDN. Поэтому технологическая трансформация Megogo была неизбежной.

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

API 1.0

Все началось с монолита, а точнее — с веб-сайта megogo.net. В 2011 и 2012 он был основой сервиса, с него начиналась экспансия. Некоторое время сайт, написанный на PHP, справлялся с быстрым ростом количества пользователей сервиса и набора функциональных возможностей, которыми он обрастал. Необходимость трансформации стала очевидной во время расширения онлайн-кинотеатра на другие платформы — следующим на очереди было приложение для Smart TV. По сути, сайт кинотеатра выступал в качестве API для этого приложения, поэтому нагрузка на веб-версию повысилась. Скоро должны были появиться приложения для смартфонов и планшетов. Стало понятно, что систему необходимо модифицировать.

У нас были различные варианты выхода из сложившейся ситуации. Но наиболее удобной и прогрессивной нам казалась возможность отказа от монолита в пользу микросервисной архитектуры. Чтобы расставить все точки над «і»: мы не считаем, что разделение на множество небольших сервисов — единственно правильный подход. Постепенный переход на микросервисную архитектуру подкупал гибкостью в выборе решений и технологий, распределенностью команд, масштабируемостью и модульностью, благодаря которой можно собрать платформу «по кубикам», как домик из Lego.

Переход на микросервисы

Конечно же, на практике получалось все не так гладко. API 1.0, то есть сайт megogo.net, стал основой для выделения отдельных сервисов системы. Разработка нового, полноценного и чистого REST API велась на Java с мыслью об обратной совместимости с уже существующими сервисами CDN, Smart TV и сайтом. Это делалось для того, чтобы в процессе перехода на микросервисы существующие решения работали и были доступны пользователям Megogo. Так появился jAPI Megogo.

Он создавался не за один день. Да и после получения первой инкарнации jAPI до появления полноценной микросервисной архитектуры нужно было преодолеть несколько горных хребтов. Под раздачу попали сервисы оплаты и подписки пользователей, написанные на PHP. Первым отдельным компонентом платформы, написанным на Java, стал сервис электронной телепрограммы (EPG v1). После него появился сервис пользовательских подписок — он отвечает за активацию услуг для пользователей кинотеатра и предоставление информации об активных подписках. Так что параллельно был выделен еще один сервис — биллинг, то есть выполнение оплаты пользователями (при помощи сторонних сервисов) и получение информации о проведенной оплате.

Параллельно с этим jAPI усиленно развивался и расширялся, фактически с его помощью реализовывались core-функции платформы. Затем в момент необходимости мы выделяли из jAPI самостоятельные сервисы, когда понимали, что в виде отдельного компонента функциональность позволит реализовать более гибкий процесс внедрения новых фич. Обычно так происходит с небольшими функциями. Например, сервис Stream, который отвечает за передачу в плеер нужного контента (видео, аудио, субтитры), и Loyalty, который выполняет расчет и начисление баллов пользователям по программе лояльности, были выделены именно по такому принципу. По этой причине сервисы часто выделялись на основе бизнес-логики, которую они реализуют.

Второй наиболее популярный у нас принцип разграничения на микросервисы — размер функциональности. Большой модуль, который изначально развивается самостоятельно и обособленно по сравнению с другими компонентами, сразу же выделяется в микросервис (даже если он не очень маленький). Так было с историей просмотров пользователей и электронной телепрограммой (EPG) для трансляций телеканалов. Кроме того, отдельные компоненты платформы появляются, когда разработка микросервиса оправдана с точки зрения используемого языка программирования или интерфейсов взаимодействия. Хороший пример — система рекомендаций, которая предлагает пользователям онлайн-кинотеатра персонализированный контент на основе различных данных об их поведении на платформе. Здесь полноценный Data Science, поэтому сервис написан на Python.

В итоге постепенно в процессе разделения монолита и расширения функциональности платформа Megogo разрослась до более чем 30 сервисов, в основном написанных на Java и Scala, а также Python.

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

Распределенность работы

Очевидное преимущество микросервисной архитектуры — разработка отдельных функциональных компонентов платформы Megogo ведется параллельно. Несколько команд разработки создают на основе бизнес-логики различные блоки-сервисы, которые затем при помощи API подключаются в общую систему. Так что развитие системы и внедрение новых компонентов происходит быстрее, при условии, что API не сломан и новые сервисы независимы между собой.

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

Кроме того, у нас есть возможность экспериментировать с языками, фреймворками и технологиями. Правда, в качестве основы мы остановились на Java, Scala и Python, хотя также экспериментировали с PHP и Ruby on Rails, от которых впоследствии пришлось отказаться. Тем не менее, мы не ограничиваем себя. Если в какой-то момент придет понимание, что новый ЯП или технология лучше подходит для текущих задач, мы обязательно попробуем.

Отдельные сервисы для отдельных частей платформы

Положительная сторона микросервисов — возможность для каждого блока MSA реализовать строго определенную функциональность. Опять же, в этом случае упрощается поддержка и тестирование системы. Кроме того, учитывая особенности самого сервиса, намного легче для каждого из них подобрать наиболее оптимальное «железо», заточенное под выполнение определенных задач.

Распределенность системы и отказоустойчивость

Платформа Megogo технически разделена на два максимально непересекающихся периметра — CDN и сервисы. Для обеспечения и поддержания инфраструктуры команды NOC, системных администраторов и DevOps-инженеров также распределены для обеих частей платформы. CDN в данном случае — слишком громоздкая тема, заслуживающая отдельной статьи, поэтому сфокусируемся на сервисах.

Примечательно, что платформа не разделена на множество дата-центров. Каждый из них самостоятельный и содержит все данные платформы, что позволяет в каждом дата-центре обслуживать всех клиентов. Такая концепция предопределяет сложность задач масштабирования. Желательно увеличить производительность не одного дата-центра, а сразу всех ЦОД-ов с сервисами Megogo.

Важным слоем управления платформой является балансировка нагрузки. Основным инструментом для реализации гибкости стала быстрота и эффективность переключения трафика из одного дата-центра в другой с соблюдением хоть каких-то пропорций (желательно точных) при передаче по цепочке всех свойств сессий и данных о пользователях — cookie, IP, GEO и т.п. В нашем случае обязательна возможность горизонтального масштабирования, поэтому все сервисы, за исключением редких legacy-функций, горизонтально масштабируются и во многих случаях не хранят состояние (stateless). Некоторые из сервисов Megogo достигают 50 нод в пуле.

Естественно, в платформе одновременно используются реляционная и NoSQL базы данных, поэтому помимо эффективного общения нод также необходимо правильно обеспечить связь с БД, кластеризация которых очень важна. Такой подход предопределил для нас выбор продуктов в FoS-мире. Чем лучше они поддаются кластеризации и горизонтальному масштабированию — тем лучше для нас. Что, правда, не защитило от использования CouchDB :)

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

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

Reliability and performance-мониторинг

Для OSCentric мониторинга мы не нашли ничего лучше, чем Zabbix, в то время как мониторинг производительности осуществляют Grafana, Prometheus и Elastic. Опыт показывает, что контроль производительности необходимо выполнять не конкретным пользователям, а по всем системам. Поэтому мы стараемся вовлечь в создание в мониторинг-дашбордов как можно больше членов команд.

Какое-то время у нас получалось обслуживать платформу без поддержки второго уровня. Удивительно, но подход работал, даже когда сервис разросся. Однако сейчас техническая поддержка стала неотъемлемой частью наших agile-практик.

Технические тренды, на которые мы ориентируемся

Мы абсолютно точно двигаемся в сторону гибридного облака, которое в течение ближайших пары лет будет must-have. Конечно, операционная парадигма Infrastructure as code давно упрощает жизнь команд, но переход к гибридному облаку был бы сейчас достаточно серьезным испытанием. Кроме того, Megogo все больше основывается на распределенных вычислениях, за ними будущее.

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

LinkedIn

59 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

И всё равно сервис временами падает и глючит. Не помогли вам ваши новые костылики и велосипедики.

все таки хочется спросить, почему CIO пишет в заголовке про

Архитектура

, а в статье история вашего хождения по граблям? ;) Если поменять заголовок на «как мы его слепили из того что было, но почитали стандарты индустрии и хотим исправиться» то вопрос снимается ))) и когда таки решите что-то кроме «воды» поведать про архитектуру, позовите пожалуйста вашего CAO с нормальными диаграммами и конкретными кейсами, почему тут так а не иначе, вдруг там и правда есть что-то интересное )

Выгоните нахрен свою Smart TV team. Они криворукие.

Які причини того, що вся інфраструктура на своїх дата-центрах, а не в Cloud (AWS , Google)?

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

Гарна стаття, побільше би таких.
Думаю, цей форум власне мав би містити технічні статті про накопичені знання, а не лише топіки про релокацію і політику.

Дмитрий, спасибо за статью. Какие технологии вы используете для load balancing/service discovery/tracing/fault tolerance?

Для load balancing на периметре используем Nginx и HAproxy. Внутри дата-центров задействован Linkerd.
Service discovery — Consul в паре с Linkerd.
Для трейсинга активно тестируем Opentracing и Jaeger.

Користуючись нагодою, хочу передати привіт підтримці... Е-м-м. Себто запитати як активувати екранну клавіатуру в SmartThing про роботі з додатком Megogo на Samsung 7?
В інших додатках вона якось сама активується коли фокус отримує Text input, а в Megogo — ніяк

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

Напишите, пожалуйста, письмо на support@megogo.net с данными об аккаунте и телевизоре, обязательно сделайте в письме пометку, что пришли с DOU. Постараемся найти проблему.

Всё написала в декабре 2018, до сих пор ищут

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

Smart TV team

;)

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

Попробовал «Максимальную» подписку. Ради пары интересных каналов в месяц и без архива (!!!) - платить бессмысленно. В топку.

Єдиний сервіс, що не вважає мій Chromium за браузер.

Я чекав цього моменту. )) Все це мабуть дуже цікаво, але воно не працює. Точніше глючить безбожно на моєму smartTV.
Перейшов на sweetTV. Жодних нарікань.
Так шо там за мікросервіси кажуть? ))

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

если не переходить то можно потерять бизнес )

Именно так. Лечение редко бывает приятным.

как оффтоп) у меня при запуске Megogo запускается Fork Player) хотел купить подписку, но новых фильмов и сериалов которые смотрю не нашел в каталоге ((

и не найдешь) Ну или купишь подписку, а потом еще будешь покупать фильмы и сериалы )

по максимальной подписке всё равно надо покупать фильмы???

Тільки прем’єри. Старі фільми по підписці ідуть.

особенно гордо звучит — премьеры))))))) предзаказ фильмов, которые выходят из проката, тоже норм)

Так почитай цикл прокату фільмів. Переважно прем’єра на блюреї завжди пізніше за кінотеатр. Онлайн походу ще пізніше. Такий у них ланцюжок заробітків. Тому і мають право називати це прем’єрою.

кстати, да) этого прикола я вообще не понял) это наверно специфика бизнеса «по украински»))

Це специфіка продажу прав на фільми. До чого тут бізнес по українськи?

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

Бля, я наверно никогда не пойму, зачем платить за сервис который дает мне фильмы черт знает когда, или не дает вообще. С музыкой как-то дела получше обстоят. (И не надо говорить про пиратство, так как в Европе оно тоже есть)

С музыкой как-то дела получше обстоят.

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

С одной стороны — да, но выбор музыки гораздо больше, и 99% доступны (при чём, сразу после выхода). В кино же всё наоборот — большая часть нужного будет сразу недоступна.

Это уже к правообладателям вопросы, они решают. А прокатные сервисы только стримят (опционально) и дают ключи к DRM лицензии, как Дисней или еще кто сказал.

Prometheus и Elastic

Є пара питань.
1. Це ж мається на увазі Elasticsearch чи ввесь ELK stack?
2. Можна плз. детальніше як зв’язаний Prometheus з elastic, якщо вони взагалі якось пов’язані?

есть подозрение, но я могу ошибаться, что в Prometheus собираются метрики, просто все которые есть. Потом с использования ElasticSearch из них делаются так называемые «бизнес-метрики», которые значимы в контексте домена. Например, просто по количеству запросов к сервису поиска анализируется частота поисковых запросов по какому-то ключевому слову. Такая возможность есть, так как логируются запросы пользователей и потом уже анализируются. Механизм сбор -> анализ.

Ставлю на простіший варіант: ELK stack збирає логи, Prometheus — метрики.

Давайте по порядку:
1. Все зависит от конечной функциональности. Где-то используется только Elasticsearch, например, в поисковой системе. А где-то — весь ELK stack, например, при анализе логов системы. В некоторых случаях Elasticsearch и ELK stack используются одновременно и независимо.
2. Некоторые метрики при мониторинге мы действительно берем из Elasticsearch. Но мы не так часто используем Elastic в качестве data source для Prometheus — эффективнее собирать метрики прямо с сервисов. Например, в случае с Nginx для быстрого понимания ситуации лучше использовать телеметрию Virtual Host’а, которую можно получить при помощи плагинов, чем парсить логи.

В ELK stack є теж сервіси для моніторингу хостів, jvm and etc — MetricBeat, плагіни для Logstash and etc. Я чого питаю то — цікавить чи ви розглядали можливість їх використання, можливо вони чимось не підійшли. Тобто цікавить чим Prometheus кращий за ELK stack в плані збору hw метрик хоста, jvm and etc..

Шо сталося з купою РНР програмістів?

Представил качество scala-кода, написанного бывшими php-программистами :)

А вот если бы бывшие php программисты написали бы на go вместо scala, тогда было бы другое дело!

Отлично написана статья! Хорошо раскрыты преимущества микросервисной архитектуры на конкретном примере. Не понял этот кусок: «Примечательно, что платформа не разделена на множество дата-центров. Каждый из них самостоятельный и содержит все данные платформы, что позволяет в каждом дата-центре обслуживать всех клиентов.» — все-таки дата-центров много?

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

Дмитрий, спасибо за уточнение. Именно так, каждый отдельный дата-центр Megogo содержит все core-сервисы, необходимые для выполнения бизнес-функций, поэтому каждый отдельный дата-центр способен обслуживать пользователей платформы. И таких ДЦ много, они размещены с привязкой к популярным ГЕО наших клиентов.

Хотів купити підписку заради мультиків для дітей, але не знайшов фільтрації по мові перекладу. Чи можна додати гібридну хмаринку для фільтрації контенту?

Расширенная фильтрация контента Megogo запланирована и, скорее всего, скоро пойдет в разработку.

Это было бы отличным преимуществом Megogo перед, например, Google Play Movies.

було б супер! на сайті контент переважно російською, і важко знайти мультик українською мовою. З фільтрацією було б краще :-)

Можливо вам буде корисно. Ми jarvis.net.ua інтегрували з API Megogo. Зараз інформацію про ті мультики, які по рекламі на Megogo і мають українську доріжку можна отримати за посиланням:
jarvis.net.ua/...​nimation]=1&engine=normal

вы плохо ищете. Отдельного фильтра нет, но есть подборка megogo.net/...​llection/multfilmukr_free
так же взял подписку из-за мультиков для ребенка.

Не читал статью, но интересно одно — когда перестанет звук пропадать при просмотре телеканалов?

Мы уже знаем о существовании проблемы и активно работаем с производителями телевизоров над ее решением. Но вам также стоит написать в support@megogo.net модель, версию и год выпуска телевизора, а также на каких каналах наблюдается проблема (HD, SD и т.п.).

Что значит с производителями телевизоров? проблема будет решена на уровне приложения для этих устройств?

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

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

Подписаться на комментарии