Привет, Хабр! Меня зовут Роман Кармалов, в МТС Диджитал я руковожу группой, которая поддерживает инфраструктуру, в том числе работу прокси-серверов. В компании регулярно проводятся корпоративные онлайн-трансляции: их смотрит от двух до пятнадцати тысяч человек. Если не предпринять необходимых мер, то это вызовет нагрузку, которая может «уронить» внутреннюю инфраструктуру компании. В нашем случае решением проблемы стали кэширующие прокси-серверы на базе ПО 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, чтобы не перегружать фаерволы на границах внутренних сегментов;
надо обязательно применять балансировщик, так как без него запросы могут уйти на один сервер и он не справится с нагрузкой.
На этом у меня все. Если у вас появились вопросы или дополнения, пишите в комментариях.