Как в России создают инфраструктуру для ААА-игр: от серверов до облаков

Разработка ААА-игр — это не только про сложную графику и захватывающий геймплей. Без надежной инфраструктуры даже самый продуманный проект рискует столкнуться с перебоями, отключениями и потерей игроков. Сегодня игровая индустрия сталкивается с беспрецедентными вызовами: от необходимости перехода на новые CDN-решения до переосмысления подходов к облачным технологиям. При этом требования игроков к стабильности и доступности сервисов только растут. В этой статье мы разберем ключевые аспекты построения надежной инфраструктуры для онлайн-игр и рассмотрим актуальные решения, которые позволяют разработчикам оставаться на плаву в новых реалиях.

Начну с базовых задач инфраструктуры. 

Базовый фундамент

У любой современной онлайн-игры есть инфраструктура, которую необходимо поддерживать с обеих сторон — и со стороны разработчика, и со стороны игроков. Не буду долго объяснять перипетии глубоких сервисов и интеграций — это тема для отдельного разговора. Самыми важными аспектами инфраструктуры я считаю отказоустойчивость и катастрофоустойчивость. Обе они отвечают за некую непрерывность и максимальную доступность продукта, к чему стремится любой разработчик. 

• Отказоустойчивость контролирует отказы локальных систем: здесь разработчик сам может забэкапить (сделать резервные копии) и замасштабировать свои сервисы, защитить данные от потерь разными способами. 
• Катастрофоустойчивость, которой, кстати, многие пренебрегают, имеет более широкие рамки. Она отвечает за выполнение задач при выходе из строя всего дата-центра, резкого прекращения всего электроснабжения или физического уничтожения оборудования. 

Любую задачу такого плана, которая доходит до нашего продакшена, мы прокручиваем через самые пессимистичные варианты, пытаемся все поставить под сомнение. И это правильно: не думать о таких рисках — дорогое удовольствие.

Инфраструктура и разработка должны развиваться параллельно. Чем раньше они синхронизируются, тем дешевле обходятся решения. Не раз видел, как инфраструктурная команда принимает решения «на лету», чтобы не упустить бизнес-возможности. Обычно это приводит к состоянию «потом разберемся». С этой точки зрения я выделил бы три ключевых аспекта принятия решения:

1. Гибкость продукта. Зависит от архитектуры и кодовой базы — их лучше закладывать на старте. Изменить архитектуру продукта позже сложно и дорого. Иногда архитектурные решения приходится компенсировать инфраструктурными. То же и с кодовой базой. Так, например, при распределении компонентов по разным регионам система может отказать, и ее придется перестраивать — а это дополнительные затраты.
2. Наличие экспертизы. Применяемые и реализуемые решения будут зависеть от того, если ли у вас эксперты. Это либо команда, которая готова регулярно тестировать и внедрять решения самостоятельно эдаким методом «проб и ошибок», либо уже существующий опыт. В игровой индустрии много экспертов, но из-за высокой мобильности кадров команде может не хватать нужных компетенций. Получается перекос. В какой-то степени это тоже вариант гибкости, когда решения могут реализовываться через тот поток, в котором экспертизы больше. 
3. Стоимость решения. Чем раньше мы внедряем или применяем решение, тем дешевле оно в долгосрочной перспективе — конечно, при условии, что мы его правильно выбрали. Чем больше проект обрастает ресурсами, финансами, аудиторией, чем дальше уходит от точки старта и момента внедрения, тем сложнее поменять решение. Это распространяется на все, кроме, пожалуй, вопросов безопасности. Математика в почти всех случаях крайне проста — удваиваете текущие косты и получаете цифру, в которую на дистанции полгода-год встанет замена решения. Получаются действительно внушительные, если не сказать безумные, стоимости.

Разницу в подходах можно показать на примере трех продуктов «Лесты». При одном движке во всех продуктах трилогии — «Мире танков», «Мире кораблей» и Tanks Blitz — абсолютно по-разному заложены активности и применены разные решения. Один из продуктов решал проблему масштабирования путем создания новых периферий, действующих независимо друг от друга; в этом решении необходимо было только синхронизировать базы данных на финализации. Во втором проекте мы применили гибкую мультикластерную масштабируемую систему; точка отказа минимальна, но требуется постоянно ее резервировать — в противном случае проседает катастрофоустойчивость. Третий же проект вообще пошел путем шардирования. В итоге мы имеем три совершенно разных пути развития проекта, и при этом невозможно сказать, какое из них хорошее. Каждое решение имеет право на существование, но требует разного подхода.

Задача доставки

Что нужно для онлайн-игры? Упрощенно — три компонента: 

1) Система доставки билда

2) Площадка для игры

3) Стабильный канал связи

Это совсем базовые вещи, которые необходимы в основе игры. Рассмотрим их через призму отказо- и катастрофоустойчивости.

Когда мы говорим про SLA, стабильность, качество, доставку билда с большой скоростью — все те характеристики, чтобы у игрока не болела голова, где ему достать билд, — обычно мы используем сеть доставки контента, или CDN (content distribution network). 

В настоящий момент в России всего несколько компаний предоставляют собственный CDN с командой, которая умеет им правильно оперировать. И мы сталкиваемся, во-первых, с тем, что очень много информации не будет доступно до подписания NDA — то есть поверхностно ознакомиться с сервисами будет невозможно до вступления в деловые переговоры, а зачастую и после первого раунда их проведения. Когда же эта информация, наконец, появляется, можно легко обнаружить, что этот CDN потенциальный партнер закупает у другой компании — той, услугами которой мы уже пользуемся. Ситуация получается достаточно неловкой. 

Во-вторых, еще сложнее получить информацию о том, как существующие CDN раздеплоены (развернуты в рабочей среде) относительно территории страны. Если в столичном регионе наличие точки почти стопроцентное, то локацию на Урале, на Дальнем Востоке узнать часто очень проблематично, а учитывать ее в работе надо. При этом окно возможностей сужается по мере продвижения на восток: уменьшается количество точек, где можно вообще что-то построить. При этом шанс того, что где-то два CDN пересекутся на одной магистрали и в случае их отказа «отвалится» целый регион, возрастает в разы. И самое негативное в таком сценарии то, что быстро и легко проблема точно не разрешится.

Механические облака

Качество игровой платформы во многом зависит от гибкости инфраструктуры. Сегодня доминирует тренд на автоматизацию и облачные решения — немногие разработчики хотят работать с «железом». Такой подход понятен: он дает гибкость, экономию масштаба и преимущества грамотного балансирования нагрузки. Однако применительно к российскому рынку возникают нюансы. 

Есть задача от команды: найти альтернативное «облако», в России и на российском хостинге. Поиск показывает, что альтернатив много. Однако тут нужно учитывать, что «облако» — это продукт, а у каждого продукта такого плана есть разработчик. И каждый разработчик преследует свои цели, по-разному видит пути развития, а сам продукт находится в разных состояниях. Здесь нужно понимать, что свой продукт вы несете в чужой продукт, который оперируется чужими людьми, и если ваш проект не занимает большую долю в инфраструктуре «облака», он автоматически встает в очередь за командами крупнее. А таких много. На рынке достаточно компаний, которые могут позволить себе пользоваться «облаками» больше, чем любой разработчик видеоигр. 

Необходимо учитывать, что разнообразие решений — палка о двух концах. С одной стороны, провайдеры предлагают удобные инструменты для экономии времени и ресурсов. С другой — глубокая интеграция создает эффект «запертости»: чем больше вы используете специфические функции облака, тем сложнее будет мигрировать в будущем. Особенно это касается: 

• Нестандартных API и интерфейсов
• Функций, находящихся в стадии бета-тестирования
• Решений, которые существуют только у конкретного провайдера

Для стартапов это приемлемый компромисс, но растущим проектам стоит заранее продумывать стратегию сохранения независимости.

Другая скрытая проблема — неравномерное распределение облачных мощностей. При всей гибкости системы для нашей страны характерна либо концентрация «облаков» в одном регионе, либо их расположенность, так скажем, тонким слоем. Это создает риски, аналогичные описанным для CDN: сбой на ключевой магистрали может отключить целые регионы, и точно так же сложно преодолеть информационный барьер с поставщиками сервиса. Кто-то не видит проблемы и указывает местоположение своих точек, кто-то держит их в секрете. Определить заранее, как будет у конкретного провайдера, зачастую очень сложно.

Оборудование размещается в дата-центрах, и здесь свои вызовы:

• Дефицит мощностей. ЦОДы заполняются за полгода-год, новые строятся медленно.
• Оборудование требует замены, но из-за импортозамещения это сложно.
• Локации. На Дальнем Востоке и в Сибири дата-центров меньше, чем в центральной России.

Ситуация, конечно, постепенно улучшается, но нужно больше времени.

Обратная связь

Итак, у нас уже есть основа: через что доставлять клиент, где выстроить внутреннюю структуру игры и на чем все это обрабатывать. Остается всего ничего — включить в эту цепочку систему мониторинга и эскалации. 

Почему это важно? Мы видим, как инфраструктура ведет себя с точки зрения пользователя. Например, если у нас онлайн упал на 100 человек — это инцидент. Но если такая проблема случится на стороне провайдера или ЦОДа, заметить и решить ее сложнее. Получается эдакий слоеный пирог зависимостей проекта от разных сервисов. 

Идеально, когда игрок сперва направляет обращение в центр поддержки игры, а потом звонит провайдеру — тогда время на поиск проблемы сокращается, так как несколько команд мобилизуются одновременно и примерно понимают, где искать. 

Вывод

Рынок инфраструктуры для ААА-игр в России демонстрирует позитивные тенденции. У нас есть альтернативы для большинства необходимых функций онлайн-проектов. Восточный регион России имеет отличный потенциал для роста и вполне может достичь уровня, сопоставимого с западным.

Однако важно заранее готовиться и планировать. Не стоит забывать, что в случае, если вас не устроит конкретный провайдер или дата-центр, «встать и выйти» будет крайне затратно по ресурсам. Задачи, которые ранее казались сложными, сейчас становятся еще более комплексными.

Взаимодействие с разработчиками на разных этапах создания инфраструктуры позволяет сократить инвестиции. Лучше предусмотреть дополнительные ресурсы на начальном этапе и внести изменения в инфраструктуру позже, нежели столкнуться с необходимостью закрыть неучтенный элемент. Это, несомненно, будет стоить чрезвычайно дорого. 

Интеграции должны быть взвешенными. Да, «облака» — это хорошо, но о классической инфраструктуре тоже забывать не стоит. В идеале вам нужно собственное «облако» и собственные сервисные команды, которые хотя бы часть будут делать сами, а не через услуги других участников рынка. Если такой возможности нет, имеет смысл зарезервировать ее для будущего. В целом, все умещается в одно простое правило: делайте заранее, и не будет проблем.