Немного о внедрении Unreal Engine Pixel Streaming в облаке MS Azure

Не так давно делали проект по разворачиванию приложения на основе Unreal Engine в MS Azure. Довольно интересная была задача и расскажу немного основы и с чем пришлось столкнуться.

О Pixel Streaming

Pixel Streaming позволяет вам забросить ваше упакованное приложение Unreal Engine на какой-нибудь сервер с GPU и получать оттуда потоковое видео через браузер, например, на мобильном устройстве.

Как это выглядит у MS и зачем вообще нужно это авто-масштабирование...
Ну начнем с того, что в Azure вы платите за время использования виртуальной машины. Виртуальная машина с GPU может обходится вам в $1500 / мес при использовании. Авто-масштабирование позволяет освободить ненужные мощности когда минимум пользователей и добавить ресурсов, когда начинают подключаться пользователи.

Если вам не нужно авто-масштабирование, то вариант настройки чрезвычайно прост.

В принципе, и авто-масштабирование описано подробно тут, но есть нюансы.

1. Вся процедура разворачивания строится на том, что у вас должен быть некий репозиторий, например на Github-е. Он может быть частный, может быть публичный. Доступ к частному репозиторию осуществляется по PAT (Personal Access Token). Его вы можете создать в настройках Github-а.

2. Клонируете исходники отсюда. Учтите, скрипты от MS прям не идеальны. Мы исправляли прям совсем смешные ошибки когда в скриптах MS вот так:
$Arguments = @("cirrus", "--peerConnectionOptions=""$peerConnectionOptions""", "--publicIp=$fqdn")
а нужно:
$Arguments = @("cirrus", "--peerConnectionOptions=""$peerConnectionOptions""", "--PublicIp=$fqdn")
т.к. скрипт cirrus.js чувствителен к регистру.

3. Вносите изменения в файлы: iac\terraform.tfvars, iac\region\variables.tf, iac\variables.tf в которых прописываем нужные вам регионы, настройки, планы и SKU, которые будете использовать. Мы меняли, например, использование Standard SSD вместо HDD, порты для Network Security Group и еще некоторые вещи. Разворачивание всех необходимых ресурсов происходит через Terraform. Конфигурация авто-масштабирования настраивается через конфигурационный файл MatchMaker-а, который можно менять после всей процедуры инсталляции. Там можно указать время бездействия виртуальной машины, сколько должно быть свободных в каждый момент времени и прочее.

4. Делаем Push на свой репозиторий. Учтите, что файлы больше 100Мб вынудят вас использовать LFS. А если ваш проект больше 1 Гб, то придется кинуть денежку на свой аккаунт. Также эта денежка будет расходоваться при авто-масштабировании - каждый раз новый образ виртуальной машины будет использовать ваш репозиторий и клонить ваш проект с него.

5. Дальше стартуем:
terraform init
terraform validate
terraform apply -var 'git-pat=PUT_GIT_PAT_HERE' --auto-approve
и ждем довольно продолжительное время, пока развернутся все необходимые объекты в MS Azure.

6. Если скрипт не выдал никаких ошибок красным цветом, то проверяем наличие всего в Azure. У вас создатся 2 ресурсные группы: в одной будут менеджер трафика, Key Vault (в нем вы можете обнаружить админский пароль для подключения к вашим виртуальным машинам) и Application Insight (для мониторинга). По замерам время на разворачивание одного образа виртуальной машины из ScaleSet составляет около 15-20 минут. Так что этот факт надо учитывать при планировании доступных ресурсов.

7. Дальше нам пришлось решать проблемы с использованием STUN/TURN серверов. Не все мобильные устройства подключались и могли использовать TURN. Проблему решили пробросом диапазона Udp портов на каждый Signal Server.

Опыт был интересен тем, что кроме знаний о MS Azure на пришлось достаточно много разбираться в скриптах powershell и java, т.к. исправлялись ошибки и что-то дорабатывалось под конкретную ситуацию.