Что происходит за кадром, когда 2 миллиона человек одновременно включают ТВ
Роман Тамашевский почти десять лет строит и возглавляет инженерные команды в IT-инфраструктуре. Он работал с системами масштаба МТС IPTV и Kinescope, прошёл путь от руководителя пяти инженеров до IT-топ-менеджера с командой в 70 специалистов, а в одном из проектов сократил расходы на инфраструктуру примерно на $3,6 млн в год. Сегодня он развивает собственную геймдев-студию Painless Games Co. в Остине.
В интервью Роман рассказывает, что происходит с серверами, когда миллионы зрителей одновременно включают трансляцию матча, почему инфраструктуру убивает не сама нагрузка, а скорость её роста, что делать, если в эфире отключается целый дата-центр, и как проектировать систему, которая ломается контролируемо.
– Расскажите о своем опыте работы с ТВ-трансляциями. Что происходит с серверами, когда миллионы людей одновременно включаются в эфир, и почему это самая опасная ситуация для интернет-сервисов?
Я работал с инфраструктурой крупных IPTV и видеоплатформ, в том числе с системами масштаба МТС IPTV и Kinescope. Особенность телевидения в том, что аудитория здесь ведёт себя совсем не так, как в обычных интернет-сервисах.
Если у интернет-магазина два миллиона пользователей, они обычно распределены во времени. Во время крупного спортивного события всё иначе. Миллионы людей могут почти одновременно открыть трансляцию, причём нагрузка растёт не плавно, а скачком. Начался матч. Забили гол, кто-то получил сообщение от друзей и тоже открыл трансляцию. Матч закончился, и огромное количество клиентов почти одновременно отключается. Для инфраструктуры опасно именно такое синхронное поведение.
При этом нагрузка возникает не только на видеосерверы. При включении телевизора происходит целая цепочка действий. Авторизация, список каналов, проверка подписки, адрес потока, DRM, аналитика, и только потом начинается сам просмотр. Поэтому два миллиона зрителей это не просто два миллиона видеопотоков, а огромная волна запросов, которая проходит сразу через десятки компонентов.
Инфраструктуру чаще убивает не сама большая нагрузка, а скорость её изменения. Система может прекрасно обслуживать миллион постоянных пользователей и упасть, если ещё миллион придёт за несколько десятков секунд.
– Как устроена система ТВ, чтобы трансляция не зависала и не «рассыпалась», когда весь город одновременно смотрит важный матч?
Главный принцип в том, что видео должно находиться как можно ближе к зрителю. Передавать один и тот же матч миллионам пользователей из одного центрального дата-центра крайне неэффективно, поэтому используются распределённые системы доставки контента, то есть CDN.
Можно представить это как сеть складов. Если два миллиона человек захотят одновременно купить один товар, бессмысленно отправлять каждую посылку с единственного склада на другом конце страны. Гораздо эффективнее заранее разместить товар на региональных складах и доставлять его оттуда. Но одного CDN недостаточно. В системе не должно быть единственной точки, отказ которой остановит просмотр, поэтому дублируются критические компоненты, есть несколько маршрутов доставки и балансировка нагрузки.
Кроме того, постоянно собираются технические метрики, например время запуска видео и buffering events. Для инженеров телевизор пользователя в каком-то смысле становится последним элементом системы мониторинга. Можно иметь полностью «зелёный» мониторинг серверов, но если у зрителей каждые двадцать секунд останавливается изображение, сервис фактически не работает.
– Зачем телеком-компаниям собирать сотни миллионов сообщений от ТВ-приставок пользователей каждый день?
Потому что без этих данных практически невозможно понять реальное качество сервиса. Каждая приставка постоянно генерирует технические события, например включение, запуск канала, переключение, buffering, ошибки. На масштабе миллионов устройств это превращается в сотни миллионов сообщений.
Допустим, мониторинг дата-центра говорит, что все серверы работают нормально. А данные с приставок внезапно показывают, что в определённом регионе у 15% пользователей резко выросло время запуска видео. Это уже сигнал, что проблема может быть не на сервере приложения, а на конкретном CDN-узле, сетевом маршруте или у определённого оператора связи. Фактически миллионы приставок превращаются в распределённую сеть датчиков, которая показывает состояние платформы глазами конечного пользователя.
– Что происходит, если в разгар прямого эфира вдруг отключается целый дата-центр? Как система спасает трансляцию?
Правильно спроектированная система должна исходить из того, что дата-центр однажды обязательно отключится. Вопрос не в том, может ли это произойти, а в том, что будет, когда это произойдёт. Поэтому критические сервисы распределяются между несколькими площадками, и когда одна становится недоступной, трафик переключается на оставшиеся.
Но резерв сам по себе ещё ничего не гарантирует. Представим два дата-центра, каждый способен обслуживать миллион пользователей. Если один отключится, второй внезапно должен принять два миллиона. Если он на это не рассчитан, резервирование существует только на архитектурной схеме.
Причём само переключение тоже создаёт нагрузку. Миллионы клиентов начинают reconnect, повторно проходят авторизацию и запрашивают поток. Возникает так называемый retry storm, когда система уже испытывает проблемы, а клиенты своими повторными запросами делают ситуацию ещё хуже. Хорошая отказоустойчивость это когда зритель вообще не знает, что несколько минут назад инженеры потеряли целый дата-центр.
– Как обновлять программу на миллионах ТВ-приставок по всей стране так, чтобы ничего не «сломать» у людей дома?
Главное правило в том, чтобы никогда не обновлять сразу миллион устройств. Какой бы хорошей ни была лаборатория, невозможно воспроизвести все реальные условия.
Поэтому обновление идёт постепенно. Сначала новая версия ставится на внутренние тестовые устройства, затем на небольшую группу реальных пользователей. После этого мы смотрим на crash rate, ошибки, время запуска. Если всё нормально, аудитория постепенно растёт, условно 1%, 5%, 10%, 25%, 50%, а потом вся сеть. Это называется staged rollout или canary deployment.
Очень важно иметь возможность остановить распространение версии, если метрики начали ухудшаться. Хорошо бы иметь и rollback, но с физическими устройствами это намного сложнее, чем с серверным приложением. На сервере плохую версию можно заменить за несколько минут. А если неудачное обновление уже встало на сотни тысяч приставок и часть из них потеряла возможность нормально подключаться к сети, проблема становится намного серьёзнее. Поэтому rollout должен быть очень консервативным.
– В чем разница между арендой чужих серверов для видео и постройкой собственной сети доставки контента?
Это прежде всего вопрос масштаба и экономики. На небольшом объёме почти всегда разумнее пользоваться готовым CDN.
Но видео генерирует огромный объём трафика. Когда аудитория становится действительно большой, даже небольшая разница в стоимости передачи одного гигабайта превращается в очень серьёзные деньги, и тогда появляется смысл строить собственную CDN.
Но я бы не противопоставлял эти варианты как «чужое или своё». На практике очень хорошо работает гибридная модель. Предсказуемый основной объём трафика можно обслуживать своей инфраструктурой, а внешние CDN использовать для географического покрытия, резких пиков и дополнительного резерва. По сути, это классический инженерный выбор между CapEx, OpEx, контролем и сложностью эксплуатации.
– Как проверить, выдержит ли система нагрузку в 2 миллиона зрителей, до того как начнется реальный прямой эфир?
Полностью проверить это невозможно, и это, пожалуй, самый неприятный ответ для бизнеса. Можно построить очень хороший нагрузочный стенд и сгенерировать миллионы запросов. Обязательно нужно тестировать и отказные сценарии, например убрать один дата-центр.
Но лабораторный тест всегда остаётся моделью реального мира. Самая сложная часть это воспроизвести поведение настоящих пользователей. Синтетический клиент обычно ведёт себя предсказуемо, реальный нет. Если изображение зависло, человек может пять раз нажать кнопку переключения канала, перезапустить приложение, выключить приставку и включить её снова, и одна проблема порождает дополнительную нагрузку.
Поэтому проверять нужно не только выдержим ли мы два миллиона, а выдержим ли мы два миллиона, если одновременно потеряем 30% инфраструктуры. Вот это уже значительно более интересный тест.
– Вспомните самый крупный сбой во время прямого эфира за вашу практику. Что произошло и какой урок вы из этого извлекли?
У меня был важный опыт с инцидентами в высоконагруженных системах, но я бы не стал придумывать красивую историю про конкретную катастрофу. Гораздо интереснее общий паттерн, который я не раз наблюдал. Самые опасные инциденты редко происходят из-за одного сломавшегося сервера. Настоящие проблемы начинаются с цепной реакции. Один компонент начинает работать медленнее, растут очереди, клиенты не получают ответ вовремя и повторяют запросы, нагрузка увеличивается ещё сильнее, и проблема идёт дальше.
Поэтому один из главных уроков для меня в том, что недостаточно проектировать систему на максимальную нагрузку. Нужно проектировать её поведение в деградированном состоянии. Иногда правильная реакция на перегрузку не в том, чтобы любой ценой обслужить все запросы, а в том, чтобы сознательно отказаться от второстепенных функций и сохранить главное. Во время финала крупного чемпионата приоритет очевиден, зритель должен продолжать смотреть матч. Если на несколько минут пропадут рекомендации фильмов, это значительно меньшая проблема, чем потерять трансляцию.
Наверное, именно это высоконагруженные системы научили меня понимать лучше всего. Отказоустойчивость это не способность сделать так, чтобы ничего никогда не ломалось. Это способность системы ломаться контролируемо.
Автор: Евгений Пархоменко
