Как мы помогли CDN МегаФон.ТВ не обрушиться на ЧМ-2018
В 2016 году мы рассказывали, как МегаФон.ТВ справился со всеми желающими посмотреть новый сезон «Игры Престолов». На этом развитие сервиса не остановилось, и к середине 2017 года нам пришлось иметь дело с нагрузками в несколько раз больше. В этом посте мы расскажем, как такой бурный рост вдохновил нас кардинально поменять подход к организации CDN и как этот новый подход прошел проверку чемпионатом мира по футболу.
Вкратце о МегаФон.ТВ
МегаФон.ТВ — это ОТТ-сервис для просмотра различного видеоконтента — фильмов, сериалов, тв-каналов, программ в записи. Через МегаФон.ТВ доступ к контенту можно получить практически на любом устройстве: на телефонах и планшетах с iOS и Android, на умных телевизорах LG, Samsung, Philips, Panasonic разных годов выхода, с целым зоопарком ОС (Apple TV, Android TV), в десктопных браузерах на ОС Windows, MacOS, Linux, в мобильных браузерах на iOS и Android, и даже на таких экзотических устройствах как STB и детских Android-проекторах. По устройствам ограничений практически нет — важно лишь наличие интернета с полосой от 700 Кбит/с. О том, как мы организовали поддержку такого количества устройств, в будущем будет отдельная статья.
Большинство пользователей услуги — абоненты МегаФон, что объясняется выгодными (а чаще всего даже бесплатными) предложениями, входящими в тарифный план абонента. Хотя мы также отмечаем существенный рост пользователей других операторов. В соответствии с таким распределением, 80% трафика МегаФон.ТВ потребляется внутри сети МегаФон.
Архитектурно, с момента запуска услуги контент распространялся через CDN. У нас есть отдельный пост, посвященный работе этой 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-трафику должны были возрасти в шесть раз…
Новый подход к CDN
Проанализировав проблему, решили разделить VOD- и live- трафик по разным PAD, составленным из разных по конфигурации серверов. А еще создать функцию распределения трафика и его балансировки по разным группам серверов. Всего таких групп было выделено три:
- Серверы с большим количеством высокопроизводительных дисков, наилучшим образом подходящих по кэширование VOD-контента. На самом деле наилучшим образом подходили бы SSD RI диски максимальной емкости, но таких в наличии не было, а на приобретение нужного количества потребовался бы слишком большой бюджет. В итоге было решено использовать лучшее, что имелось в наличии. Каждый сервер вмещал восемь 1ТБ SAS-дисков 10k в RAID5. Из этих серверов был составлен VOD_PAD.
- Серверы с большим количеством оперативной памяти для кэширования всех возможных форматов доставки live-чанков, с процессорами, способными обработать ssl-трафик, и «толстыми» сетевыми интерфейсами. Мы использовали следующую конфигурацию: 2 процессора по 8 ядер / 192Гб оперативной памяти / 4 интерфейса 10ГБит. Из этих серверов был составлен EDGE_PAD.
- Оставшаяся группа серверов, не способная обслуживать VOD-трафик, но подходящая для небольших объемов live-контента. Их можно использовать в качестве резерва. Из серверов был составлен RESERVE_PAD.
Распределение шло по следующей схеме: 
За выбор PAD, с которого пользователь должен был получать контент, отвечал специальный логический модуль. Вот его задачи:
- Анализировать URL, применять приведенную выше схему при каждом запросе потока и выдавать необходимый PAD
- Снимать нагрузку с интерфейсов EDGE_PAD каждые 5 минут (и это была наша ошибка), а при достижении предела выполнять переключение излишков трафика на RESERVE_PAD. Для снятия нагрузки был написан небольшой скрипт на perl, который возвращал следующие данные:
— timestamp — дата и время обновления данных о нагрузке (в формате RFC 3339);
— total_bandwidth — текущая загруженность интерфейса (суммарная), Кбит/с;
— rx_bandwidth — текущая загруженность интерфейса (входящий трафик), Кбит/с;
— tx_badwidth — текущая загруженность интерфейса (исходящий трафик), Кбит/с. - Направлять трафик в ручном режиме на любой PAD или Origin-сервер при возникновении непредвиденных ситуаций, либо при необходимости провести работы на одном из PAD. Конфиг лежал на сервере в формате yaml и позволял увести на нужный PAD либо весь трафик, либо трафик по одному из параметров:
— Тип контента
— Шифрование трафика
— Платность трафика
— Тип устройства
— Тип плейлиста
— Регион
Origin-сервера были доукомплектованы SSD. К сожалению, HIT_RATE по VOD-чанкам при переключении трафика на Origin оставлял желать лучшего (около 30%), но свою задачу они выполняли, поэтому на пакетайзерах в ЧНН мы проблем не наблюдали.
Поскольку серверов для конфигурации EDGE_PAD было немного, было решено аллоцировать их в регионах с самой большой долей трафика — Москва и Поволжье. На Поволжье при помощи средств GeoDNS был направлен трафик с областей Поволжского и уральского федеральных округов. Московский узел обслуживал всё остальное. Нам не очень нравилась идея доставлять трафик в Сибирь и Дальний восток из Москвы, но суммарно эти регионы дают около 1/20 от всего трафика, и каналы МегаФона оказались достаточно широкими для таких объемов.
После разработки плана провели следующие работы:
- За две недели разработали функциональность переключения CDN
- Месяц понадобился на установку и настройку серверов EDGE_PAD, а также на расширение каналов под них
- Две недели понадобилось, чтобы разделить текущую группу серверов на две части, плюс еще две недели — на применение ко всем серверам настроек на сетевом и серверном оборудовании
- И, наконец, неделя ушла на тестирование (к сожалению, не под нагрузкой, что сказалось впоследствии)
Некоторые работы получилось запараллелить, и в итоге на все ушло шесть недель.
Первые результаты и планы на будущее
После тюнинга общая производительность системы составляла 250 Гбит/сек. Решение с вынесением VOD-трафика на отдельные сервера сразу показало свою эффективность после выкатки в продакшн. С начала чемпионата мира проблем с VOD-трафиком зафиксировано не было. Несколько раз в силу разных причин приходилось переключать VOD трафик на Origin, но в принципе, они тоже справлялись. Возможно, такая схема не слишком эффективна из-за очень малого использования кэша, так как мы заставляем SSD-диски постоянно перезаписывать контент. Но схема работает.
Что касается live-трафика, то соответствующие объемы для проверки нашего решения появились со стартом чемпионата мира. Проблемы начались, когда мы во второй раз столкнулись с переключением трафика при достижении лимита во время матча Россия — Египет. Когда сработало переключение трафика, он весь полился на резервный PAD. В эти пять минут количество запросов (кривая роста) было настолько велико, что резервный CDN забивался полностью и начинал сыпать ошибками. При этом основной PAD освобождался за это время и начинал немного простаивать:
Из этого было сделано 3 вывода:
- Пять минут — это все-таки слишком много. Было решено уменьшить период снятия нагрузки до 30 секунд. В результате трафик на резервном PAD перестал расти скачкообразно:
- Надо по минимуму перекидывать пользователей между PAD при каждом срабатывании переключателя. Это должно обеспечить дополнительную плавность переключения. Мы решили каждому пользователю (а точнее устройству) присваивать куку, по которой модуль, отвечающий за распределение, понимает, нужно ли оставлять пользователя на текущем PAD или надо выполнить переключение. Тут технология может быть на усмотрение того, кто ее реализует. В итоге мы не роняем трафик на основном PAD.
- Порог для переключения был выставлен слишком низкий, в итоге трафик на резервном PAD рос лавинообразно. В нашем случае это было перестраховкой — мы были не полностью уверены что произвели корректный тюнинг серверов (идея для которого, кстати, была взята с Хабра). Порог был увеличен до физической производительности сетевых интерфейсов.
Доработки заняли три дня, и уже на матче Россия — Хорватия мы проверили, сработала ли наша оптимизация. В целом результат нас порадовал. В пике системой были обработаны 215 Гбит/сек смешанного трафика. Это не являлось теоретическим лимитом производительности системы — у нас еще оставался солидный запас. В случае необходимости сейчас мы можем подключить любой внешний CDN, если понадобится и «выбрасывать» излишки трафика туда. Такая модель хороша, когда не хочется платить каждый месяц солидные деньги за использование чужого CDN.
У нас в планах — дальнейшее развитие CDN. Для начала хотелось бы распространить схему EDGE_PAD по всем федеральным округам — это приведет к меньшему использованию каналов. Также проводятся тесты схемы с резервированием VOD_PAD, и некоторые результаты уже сейчас выглядят довольно впечатляющими.
Вообще все сделанное за последний год наводит меня на мысли о том, что CDN у сервиса, занимающегося распространением видеоконтента, — это must have. И даже не потому, что это позволяет экономить много денег, а скорее из-за того, что CDN становится частью самой услуги, напрямую влияет на качество и функциональность. В таких условиях отдавать его в чужие руки — как минимум неразумно.
