- PVSM.RU - https://www.pvsm.ru -
В 2016 году мы рассказывали, как МегаФон.ТВ справился со всеми желающими посмотреть новый сезон «Игры Престолов». На этом развитие сервиса не остановилось, и к середине 2017 года нам пришлось иметь дело с нагрузками в несколько раз больше. В этом посте мы расскажем, как такой бурный рост вдохновил нас кардинально поменять подход к организации CDN и как этот новый подход прошел проверку чемпионатом мира по футболу.
МегаФон.ТВ — это ОТТ-сервис для просмотра различного видеоконтента — фильмов, сериалов, тв-каналов, программ в записи. Через МегаФон.ТВ доступ к контенту можно получить практически на любом устройстве: на телефонах и планшетах с iOS и Android, на умных телевизорах LG, Samsung, Philips, Panasonic разных годов выхода, с целым зоопарком ОС (Apple TV, Android TV), в десктопных браузерах на ОС Windows, MacOS, Linux, в мобильных браузерах на iOS и Android, и даже на таких экзотических устройствах как STB и детских Android-проекторах. По устройствам ограничений практически нет — важно лишь наличие интернета с полосой от 700 Кбит/с. О том, как мы организовали поддержку такого количества устройств, в будущем будет отдельная статья.
Большинство пользователей услуги — абоненты МегаФон, что объясняется выгодными (а чаще всего даже бесплатными) предложениями, входящими в тарифный план абонента. Хотя мы также отмечаем существенный рост пользователей других операторов. В соответствии с таким распределением, 80% трафика МегаФон.ТВ потребляется внутри сети МегаФон.
Архитектурно, с момента запуска услуги контент распространялся через CDN. У нас есть отдельный пост [1], посвященный работе этой CDN. В нем мы рассказывали, как она позволила обработать пиковый трафик, который лег на сервис в конце 2016 года, во время выхода нового сезона «Игры престолов». В этом посте мы расскажем о дальнейшем развитии МегаФон.ТВ и о новых приключениях, которые свалились на сервис вместе с ЧМ-2018.
По сравнению с событиями из прошлого поста, к концу 2017 года количество пользователей Мегафон.ТВ увеличилось в несколько раз, фильмов и сериалов также стало на порядок больше. Запускалась новая функциональность, появились новые пакеты, доступные «по подписке». Пики трафика времен «Игры престолов» мы теперь видели каждый день, доля фильмов и сериалов в общем потоке неуклонно росла.
Вместе с этим начались проблемы с перераспределением трафика. Наш мониторинг, настроенный на загрузки чанков для разных типов трафика в разных форматах, все чаще стал выдавать ошибки скачивания видеочанка по таймауту. В услуге МегаФон.ТВ длина чанка равна 8 секундам. Если чанк не успевает загрузиться за 8 секунд, возможно появление ошибок.
Пик ошибок ожидаемо приходился на часы наибольшей нагрузки. Как это должно было сказываться на пользователях? Как минимум, они могли наблюдать ухудшение качества видео. Оно даже не всегда заметно невооруженным глазом, из-за достаточно большого количества профилей мультибитрейта. В худшем случае видео зависало.
Начался поиск проблемы. Практически сразу стало понятно, что ошибка отдачи возникает на EDGE-серверах CDN. Тут надо сделать небольшое отступление и рассказать, как работают сервера с live- и VOD-трафиком. Схема немного разная. Пользователь, пришедший на EDGE-сервер за контентом (плейлистом или чанком), при наличии контента в кэше получает его оттуда. В противном случае EDGE-сервер идет за контентом на Origin, нагружая основной канал. Вместе с плейлистом или чанком отдается заголовок Cache-Control: max-age, который сообщает EDGE-серверу, насколько надо кэшировать ту или иную единицу контента. Разница между LIVE и VOD заключается как раз во времени кэширования чанков. Для live-чанков выставляется небольшое время кэширования, обычно от 30 секунд до нескольких минут — это связано с небольшим временем актуальности live-контента. Этот кэш хранится в оперативной памяти, так как необходимо постоянно отдавать чанки и перезаписывать кэш. Для VOD-чанков выставляется большее время, от нескольких часов до недель и даже месяцев — в зависимости от величины библиотеки контента и распределения его просмотров среди пользователей. Что касается плейлистов, то они кэшируются, как правило, не более чем за две секунды, либо они не кэшируются вовсе. Стоит уточнить, что мы говорим только о так называемом PULL-режиме работы CDN, в котором работали наши сервера. Использование PUSH-режима в нашем случае было бы не совсем оправданным.
Но вернемся к поиску проблемы. Как мы уже заметили, все сервера одновременно работали на отдачу обоих типов контента. При этом сами сервера имели неодинаковую конфигурацию. В результате некоторые машины перегружались по IOPS. Чанки не успевали записываться/читаться из-за небольшой производительности, количества, объемов дисков, большой библиотеки контента. С другой стороны, более мощные машины, которые получали больше трафика, начали проваливаться по использованию CPU. Ресурсы процессора расходовались на обслуживание SSL-трафика, чанков, доставляемых по https, в то время как IOPS на диски едва доходил до 35%.
Требовалась схема, которая с минимальными затратами позволила бы использовать имеющиеся мощности оптимальным образом. Тем более, что через полгода должен был стартовать чемпионат мира по футболу, и по предварительным расчетам пики по live-трафику должны были возрасти в шесть раз…
Проанализировав проблему, решили разделить VOD- и live- трафик по разным PAD, составленным из разных по конфигурации серверов. А еще создать функцию распределения трафика и его балансировки по разным группам серверов. Всего таких групп было выделено три:
Распределение шло по следующей схеме:
За выбор PAD, с которого пользователь должен был получать контент, отвечал специальный логический модуль. Вот его задачи:
Origin-сервера были доукомплектованы SSD. К сожалению, HIT_RATE по VOD-чанкам при переключении трафика на Origin оставлял желать лучшего (около 30%), но свою задачу они выполняли, поэтому на пакетайзерах в ЧНН мы проблем не наблюдали.
Поскольку серверов для конфигурации EDGE_PAD было немного, было решено аллоцировать их в регионах с самой большой долей трафика — Москва и Поволжье. На Поволжье при помощи средств GeoDNS был направлен трафик с областей Поволжского и уральского федеральных округов. Московский узел обслуживал всё остальное. Нам не очень нравилась идея доставлять трафик в Сибирь и Дальний восток из Москвы, но суммарно эти регионы дают около 1/20 от всего трафика, и каналы МегаФона оказались достаточно широкими для таких объемов.
После разработки плана провели следующие работы:
Некоторые работы получилось запараллелить, и в итоге на все ушло шесть недель.
После тюнинга общая производительность системы составляла 250 Гбит/сек. Решение с вынесением VOD-трафика на отдельные сервера сразу показало свою эффективность после выкатки в продакшн. С начала чемпионата мира проблем с VOD-трафиком зафиксировано не было. Несколько раз в силу разных причин приходилось переключать VOD трафик на Origin, но в принципе, они тоже справлялись. Возможно, такая схема не слишком эффективна из-за очень малого использования кэша, так как мы заставляем SSD-диски постоянно перезаписывать контент. Но схема работает.
Что касается live-трафика, то соответствующие объемы для проверки нашего решения появились со стартом чемпионата мира. Проблемы начались, когда мы во второй раз столкнулись с переключением трафика при достижении лимита во время матча Россия – Египет. Когда сработало переключение трафика, он весь полился на резервный PAD. В эти пять минут количество запросов (кривая роста) было настолько велико, что резервный CDN забивался полностью и начинал сыпать ошибками. При этом основной PAD освобождался за это время и начинал немного простаивать:
Из этого было сделано 3 вывода:
Доработки заняли три дня, и уже на матче Россия – Хорватия мы проверили, сработала ли наша оптимизация. В целом результат нас порадовал. В пике системой были обработаны 215 Гбит/сек смешанного трафика. Это не являлось теоретическим лимитом производительности системы — у нас еще оставался солидный запас. В случае необходимости сейчас мы можем подключить любой внешний CDN, если понадобится и «выбрасывать» излишки трафика туда. Такая модель хороша, когда не хочется платить каждый месяц солидные деньги за использование чужого CDN.
У нас в планах — дальнейшее развитие CDN. Для начала хотелось бы распространить схему EDGE_PAD по всем федеральным округам — это приведет к меньшему использованию каналов. Также проводятся тесты схемы с резервированием VOD_PAD, и некоторые результаты уже сейчас выглядят довольно впечатляющими.
Вообще все сделанное за последний год наводит меня на мысли о том, что CDN у сервиса, занимающегося распространением видеоконтента, — это must have. И даже не потому, что это позволяет экономить много денег, а скорее из-за того, что CDN становится частью самой услуги, напрямую влияет на качество и функциональность. В таких условиях отдавать его в чужие руки — как минимум неразумно.
Автор: MegaFon
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/cdn/294693
Ссылки в тексте:
[1] пост: https://habr.com/company/megafon/blog/283358/
[2] Источник: https://habr.com/post/425229/?utm_campaign=425229
Нажмите здесь для печати.