Привет, Хабр! Меня зовут Роман Кармалов, в МТС Диджитал я руковожу группой, которая поддерживает инфраструктуру, в том числе работу прокси-серверов. В компании регулярно проводятся корпоративные онлайн-трансляции: их смотрит от двух до пятнадцати тысяч человек. Если не предпринять необходимых мер, то это вызовет нагрузку, которая может «уронить» внутреннюю инфраструктуру компании. В нашем случае решением проблемы стали кэширующие прокси-серверы на базе ПО Squid, сокращающие медиатрафик в десятки раз.
В этой статье я расскажу, как мы настраивали и где в сети размещали серверы, чтобы избежать проблем во время трансляций.
Зачем нам нужны отдельные прокси
Массовые видеотрансляции — всегда испытание для сетевой инфраструктуры. Поток Full HD на один VDI генерирует трафик в 2,5 Мб/с, а пять тысяч зрителей — уже 12,5 Гб/с. Растет нагрузка на межсетевые экраны, из-за чего могут деградировать другие сервисы, а у пользователей возникнут задержки видео и звука.
Для такой проблемы кэширующие прокси-серверы — проверенное решение. Его используют почти все крупные стриминговые платформы, например Netflix или Twitch. Альтернативой ему является настройка мультикаста (многоадресной IP-рассылки), при которой маршрутизатор пересылает трафик всем подключенным пользователям. Мы от него отказались, так как это слишком сложный и недостаточно гибкий в настройке способ, который вдобавок будет работать не у всех пользователей.
У прокси-серверов есть режим кэширования: при обращении к ним они берут контент из своего кэша, а не запрашивают его каждый раз у веб-ресурса. Помню историю на заре интернета, когда провайдеры из регионов с узкими каналами связи закупали и ставили оборудование, чтобы кэшировать трафик от Яндекса. По похожему принципу работают Google Cache Server, но в рамках своей CDN.
Для видеотрансляций мы взяли open-source-прокси Squid, который активно используем в других проектах.
Настройка прокси
Особенность трансляций в том, что зрители смотрят примерно одни и те же фрагменты видео по 2–3 секунды. Прокси должен скачивать, кэшировать, отдавать, а затем удалять их. При этом серверу не нужно много ресурсов для их хранения.
Сначала мы попробовали кэширование на жесткий диск, но провели нагрузочное тестирование и увидели, что у него недостаточно производительности. В итоге отключили настройку кэша на диск и оставили такие настройки:
#Опции вытеснения — процент использования кэша, при котором он будет обновляться
cache_swap_low 85
cache_swap_high 90
#Опция включения задержки: если у нас много запросов к одинаковому URL, который уже скачивается, то они ставятся в режим ожидания.
collapsed_forwarding on
#Объем кэша
cache_mem 5000 MB
#Максимальный размер файла, который можно кэшировать
maximum_object_size_in_memory 10 MB
Обратите внимание на опцию collapsed_forwarding: ее обычно выключают на прокси-серверах, через которые проходит много разного контента. При такой настройке процент обращения к кэшу будет низким и при видеотрансляциях трафик от прокси до удаленного ресурса может нагружать сеть.
В итоге для сервера нам подошла конфигурация 8 CPU, 32 Гб оперативной памяти и 40 Гб на диске под операционную систему. Мы проверили, сколько подключений может выдержать один прокси: без деградации работы сети мы дошли до двух с половиной тысяч соединений.
Размещение прокси в корпоративной сети
Наши трансляции идут с сервера подрядчика из интернета во внутреннюю сеть МТС, где ее уже смотрят сотрудники:
В МТС есть крупные региональные ЦОДы: по два в Москве, Санкт-Петербурге, Нижнем Новгороде, Краснодаре, Екатеринбурге, Новосибирске и на Дальнем Востоке. Мы разместили от одного до семи кэширующих серверов в каждом ЦОД в зависимости от числа сотрудников в регионе. Балансировка осуществляется с помощью механизма BGP ECMP.
Для взаимодействия с внешними ресурсами трафик маршрутизируется через закрытые DMZ-сегменты и проходит несколько межсетевых экранов. В DMZ у нас находятся продуктовые прокси-серверы, которые управляют всем доступом в интернет из корпоративной сети. Кэширование можно было бы настроить на них, но мы решили создать отдельную систему, чтобы она не влияла на работу основных сервисов. Размещение кэширующих прокси во внутренней сети cнижает нагрузку на фаерволы в DMZ.
Пользователи обращаются к серверу в своем регионе и не создают сетевую нагрузку на межрегиональные каналы. Затем трафик идет через технологический прокси региона к CDN-сети транслятора в интернете. При необходимости масштабирования мы просто добавляем дополнительные серверы.
Как это работает
Для направления трафика на кэширующие прокси мы используем PAC/Wpad-файлы. В групповых политиках домена указывается адрес их размещения, настройки доступа и правила использования этих файлов на рабочих станциях. В самих PAC/Wpad-файлах для выделенных доменов видеотрансляции указываем использование кэширующего прокси, DIRECT для трафика на внутренние системы и продуктовые интернет-прокси для ресурсов в интернете.
Таким образом кэширующие серверы получают запросы от пользователей на ресурсы видеотрансляции, распаковывают tls и меняют сертификат ресурса на специально выпущенный доверенный сертификат CA. Через продуктовые прокси кэширующие серверы пересылают запрос от своего имени на CDN транслятора. Ответы кэшируются и возвращаются пользователям без повторных обращений к CDN.
Мои советы по работе с прокси для трансляций
Описанный мной способ уменьшил нагрузку на сеть в десятки раз. По всем прокси-серверам кэшируется до 98% трафика (тут и далее данные усреднены платформой мониторинга):
От каждого сервера к пользователям уходит почти 1 Гб/с:
В это же время от CDN-транслятора поток занимает не больше 14 Мб/с:
У нас есть возможность развивать систему дальше. Например, вынести прокси в удаленные офисы, до которых идет слабый или дорогой канал связи. Или оптимизировать число серверов, чтобы еще сократить объем идущего на них трафика. Но в целом в текущем виде система уже нас устраивает: пользователи смотрят трансляции в хорошем качестве, и сеть работает стабильно.
Если вы сталкиваетесь с похожей задачей кэширования медиатрафика, то учитывайте:
для трансляций лучше отключить использование диска, чтобы кэш хранился только в оперативной памяти — так вы избежите зависаний изображения и звука у зрителей;
по нашим тестам один прокси максимально выдерживает две с половиной тысячи коннектов. Поэтому при расчете своих систем можно ориентироваться на полторы тысячи подключений на сервер;
если у вас трансляция идет из внешней сети, то лучше разместить прокси в inside, чтобы не перегружать фаерволы на границах внутренних сегментов;
надо обязательно применять балансировщик, так как без него запросы могут уйти на один сервер и он не справится с нагрузкой.
На этом у меня все. Если у вас появились вопросы или дополнения, пишите в комментариях.