Как мы строили облачный бэкенд для мобильного шутера
Совсем недавно мы запустили в России и еще нескольких странах многопользовательский мобильный шутер Guns Of Boom, который уже скачало более полумиллиона человек. Для обеспечения плавной и бесперебойной игры такого количества пользователей нужен хороший бэкенд. В этой статье мы расскажем, почему мы решили использовать для этого облако, и кратко опишем особенности построения бэкенда на основе облачных сервисов.
В целом, облачные сервисы имеют ряд неоспоримых преимуществ перед классическим бэкендом в виде работающего в подвале у разработчика сервера. В отличие от стационарных серверов, число которых невозможно резко увеличить или сократить (игра не популярна, «не сезон» и оборудование простаивает), они могут включать и выключать дополнительные мощности автоматически, в зависимости от нагрузки.
Два основных преимущества облака, помогающие понять его глубинную суть (тм) — обеспечение избыточности и скорости масштабирования. Под скоростью масштабирования здесь подразумевается возможность быстро обеспечить дополнительные аппаратные ресурсы при резком увеличении числа пользователей, а при уменьшении — сократить расход серверного времени и сэкономить деньги и ресурсы.
В случае с избыточностью речь идет об автоматическом дублировании ресурсов игры, данных или аппаратных систем в облаке. Чаще всего избыточность обеспечивается хранением одинакового набора данных на нескольких серверах в пределах одного или нескольких дата-центров в пределах одной географии. Это нужно для экстренного восстановления при сбоях, обеспечения автоматического аварийного переключения на доступные сервера и защиты от DDOS-атак.
Так как мы говорим о создании онлайн-шутера, очень важно обеспечить низкую задержку в передаче данных. Как минимум четверть от всех пользователей играет в Guns of Boom через 3G/4G, и для плавного геймплея нужна задержка, не превышающая 100 миллисекунд. Ролик выше иллюстрирует динамику игры, которую необходимо обеспечивать и поддерживать на качественном уровне для каждого игрока в любой точке света.
Во-первых, это обеспечивается автоматическим подключением игрока к ближайшему серверу, расположенному, как правило, в том же географическом регионе. Во-вторых, для обеспечения максимальной производительности и плавности мы используем сессионные и мета-сервера. Мета-сервера — подмножество реалтаймовых сервисов, которые мы для простоты понимания объединили в одну роль, некритичную по расположению для геймплея. В какой-то момент мы рассматривали использование модели микро-сервисов, но в итоге не нашли значительных преимуществ и остановились на текущем варианте.
К мета-серверу игровой клиент обращается для авторизации и синхронизации данных, это соединение является постоянным и не разрывается во время игровой сессии. Обычно в шутерах стараются этого избежать, но с текущим уровнем нагрузки мы решили, что этот подход оправдывает себя. Кроме прочего, именно мета-сервер решает, к какому сессионному серверу в каждый момент времени будет подключен клиент. Непосредственно игровая сессия происходит, как подсказывает название, на сессионном сервере.
Благодаря использованию облака мы получаем возможность автоматически масштабировать инфраструктуру и потреблять только то количество ресурсов, которое требуется в текущий момент. Облако легко может предоставить большее количество аппаратных ресурсов (CPU, оперативная памяти, интернет-канал) для обработки возросшего числа пользователей и, соответственно, игровых сессий.
Масштабирование работает и в обратную сторону. В Guns of Boom игровые сессии длятся по 5 минут для 8 одновременно подключенных игроков. Когда игрок отключается от сессионного сервера, нагрузка снижается. Если на сервере запущено меньше 4 боевых сессий (т.е. подключено менее 32 человек), он становится недоступным для клиента игры. Как только все сессии на таком сервере заканчиваются, игроки с него перенаправляются на другие сессионные сервера со свободными слотами, а текущий сервер помечается как неактивный.
Когда мы принимали решение об использовании облака в Guns of Boom, мы сформулировали такие требования к нему:
- Поддержка основных *nix систем «из коробки»;
- Поддержка собственных образов;
- Поддержка гибридной инфраструктуры;
- Поддержка статических внешних айпи;
- Поддержка CDN;
- Поддержка автомасштабирования по задаваемым параметрам (с учетом скорости развертывания);
- Высокий SLA;
- Поддержка ВМ различных конфигураций;
- Поддержка внутренних и внешних балансировщиков нагрузки;
- Поддержка сервисов и контейнеров;
- Поддержка инструментов CLI и оркестрации;
- Наличие реализованных игровых проектов;
- Наличие ЦОДов на разных континентах.
При этом важно было использовать платформу, уже зарекомендовавшую себя в запуске индустриальных проектов похожего масштаба. Таким образом, для Guns of Boom была выбрана Amazon Web Services.
Следующим этапом выбора стал вопрос сайзинга инфраструктуры и типов виртуальных машин, которые будут использованы в качестве основы. После долгого тестирования, мы остановились на c4.xlarge машинах в качестве основной платформы для большинства сервисов и c4.4xlarge для серверов с боевыми сессиями.
Одним из основных факторов выбора для нас была бесперебойная и быстрая работа сетевой подсистемы, а также большой запас оперативной памяти. Это оказалось важным при масштабировании, т.к. при оптимизации качества и переносе всех ресурсов в оперативную память (и отключении использования файла подкачки), у нас должен гарантированно оставаться запас даже при большой нагрузке на сервер.
AWS, со своей стороны, подготовил нам несколько сюрпризов, к которым мы оказались не вполне готовы. К примеру, сетевая подсистема, не смотря на Enchanced Networking от Amazon, оказалась не так проста. Все началось с того, что под нагрузкой у нескольких боевых серверов разом отказала сеть, что привело к серьезным проблемам в работе кластера, отключением части узлов, а вместе с ними и игроков.
После внутреннего расследования, причины сбоя в архитектуре бэкенда так и не нашлись (логи чистые, в консоли ошибок нет), зато после привлечения Amazon Premium Support, выяснилось, что это маловероятный, но допустимый вариант поведения виртуальных машин в маленьком проценте случаев, не выбивающийся из заявленного SLA. После этого нам пришлось оптимизировать архитектуру для обеспечения отказоустойчивости в том числе при аппаратных сбоях облачной инфраструктуры.
Таким образом, облачные сервисы с красивым SLA тоже не решают всех ваших проблем и несут в себе дополнительные риски, которые нужно учитывать.
Сейчас игра находится на софт-лонче в нескольких странах с более чем полумиллионом установок. Перед запуском по всему миру мы должны убедиться, что бэкенд выдержит и правильно отмасштабируется, обеспечивая позитивный пользовательский опыт для миллионов игроков.
К сожалению, многие онлайн-игры на старте испытывают критические сложности с бэкендом сразу после запуска и набором некоторой критической массы онлайна. Из последних таких примеров — Pokemon GO, Tom Clancy’s The Division и Total War: Warhammer.
На данный момент перечисленные выше функции реализованы не идеально, но мы продолжаем совершенствовать клиент-серверные протоколы связи, чтобы снизить нагрузку на сеть и уменьшить задержки. Используя географию инфраструктуры облачных дата-центров Amazon, мы активно улучшаем гео-распределенную архитектуру, чтобы все могли играть в Guns of Boom одинаково комфортно. И только после успешного выполнения всех этих пунктов можно будет запускать Guns of Boom на весь мир, осчастливив всех игроков, которые его ждут. И мы об этом тоже обязательно расскажем.
