Строить и жить: как устроена инфраструктура для ААА-игр в России

Богдан Дочич, руководитель департамента мультипродуктовых сервисов в ГК «Леста Игры», объяснил, как изменилась специфика выстраивания инфраструктуры для ААА-проектов в России и какое будущее их ждет

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

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

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

Самыми важными аспектами инфраструктуры я считаю отказоустойчивость и катастрофоустойчивость. Обе отвечают за непрерывность и максимальную доступность продукта, к чему стремится любой разработчик.

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

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

С этой точки зрения я выделил бы три ключевых аспекта принятия решения:

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

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

Что нужно для онлайн-игры? Если говорить упрощенно, то три компонента:

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

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

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

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

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

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

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

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

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

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

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

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

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

Все пути ведут в ЦОД

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

К тому же, никуда не исчезает и вопрос локации. Она не так ярко выражена, как для других пунктов, но есть тем не менее. Дальний Восток и центральная часть России достаточно хорошо застроены, и это всё равно не спасает от критической нехватки мест. Сейчас крупный бизнес помогает закладывать гигантские мощности для решения этой проблемы по всей стране, и при достаточном количестве электричества и этот вопрос будет решен.

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

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

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

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

Вместо итога

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

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

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

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