Pinkapp рассказала об опыте работы с облачной платформой Azure

WarMach — это трёхмерный онлайн-варгейм про войну людей и орков с возможностью управлять войсками на поле боя и клановым взаимодействием.

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

Это если о проекте.

Что касается создания игры, то с самого начала разработки мы решили не изобретать велосипед: уже на этапе проектирования выбрали готовые, проверенные решения для масштабирования и отказоустойчивости. И наш сервер, который является по сути ASP.NET-приложением, мы решили посадить на Microsoft Azure.

И вот в начале 2015 года мы развернули девелоперские сервера на Azure — сначала на триал-подписке, а затем перешли на подписку с оплатой по мере использования.

Работало это тогда (и работает сейчас) примерно так: клиент использует Unity 5, а сервер написан на C# 4.5 и является ASP.NET-приложением. Дальше: в качестве хранилища данных используется AzureSQL (девайсы, базовая информация о игроках, привязки к соцсетям, игровые метрики), DocumentDb (города игроков, история боев) и AzureStorage (записи боёв)Для работы с AzureSql используется ORM Entity Framework. Клиент отправляет данные на игровой сервер с помощью http-запросов. Данные сериализируются в JSON. Для соединения с чат-сервером (он независим от игровых серверов) используются WebSocket-ы.

В процессе разработки и развертывания мы съездили на WhiteNights 2015 и случайно выяснили, что Microsoft активно поддерживает молодых разработчиков в рамках программы BizSpark. Не долго думая, подали заявку на участие, и получили утвердительный ответ.

После этого развернулись в облаке.

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

Летом для софт-ланча развернули продакшн-сервер в Северной Европе. Сервер подняли с запасом мощности, после чего счета за использование Azure сильно превысили лимит поддержки BizSpark. Сейчас обсуждаем возможность получения поддержки более высокого уровня — BizSpark+.

Предварительные тесты нагрузки игровых серверов (пока неоптимизированных) ботами выглядят так:

Так как количество ядер на подписке BizsPark ограничивается 20-ю, а часть ядер уже была занята под софтланч, то более масштабные тесты пока не проводились. Масштаб баз данных был выбран с запасом, чтобы не упираться в производительность БД. По нашим подсчётам, разработка собственной серверной инфраструктуры вместо Azure увеличило бы время создания игры примерно раза в полтора. Так что работой с сервисом довольны.

Что касается тех сложностей, с которыми столкнулись.

Из всех усилий, потраченных на разработку, большинство съел клиент. Работы над сервером начались значительно позже, времени было мало, поэтому начали реализовывать на том, что было привычней, и сделали сервер как веб-сайт. Это повлекло некоторые сложности: http-протокол неудобен для игровых проектов, так как сервер не может сам ничего сообщить клиенту по какому-либо событию. Также невозможно точно понять, когда игрок завершает игровую сессию, так как никакого соединения нет, а логаут-запрос может не отправиться (если юзер просто выгрузил приложение из процессов девайса).

В качестве рекомендации можем посоветовать уже с самого начала разработки иметь тестовый сервер как минимум с двумя инстансами, чтобы отлавливать баги масштабируемости. Также в случае с http-сервером нужно сразу проверить работу stickysession (для игровых проектов подход stateless не годится, хоть он и хорош для сайтов). В Azure Web Sites для stickysession на клиенте надо поддержать ARRAffinitycookie. Для cloudservices привязка происходит по ip и портам (есть разные варианты конфигурации).

Кэшировать игрока на инстансе можно только на протяжении игровой сессии. По её завершению нужно сразу выгружать пользователя из кэша сервера, так как уже через некоторое время он может залогиниться с другого ip и попасть на другой инстанс (например, вышел из метро и зашел в кафе — ip поменялся). Стоит учитывать, что какие-то данные пользователя могут поменяться на другом инстансе, даже когда он будет онлайн (такие данные желательно вынести в отдельные таблицы).

Альтернативный и более правильный вариант — использовать распределенный кэш, который поддерживает подходы read-through и write-behind. Надеюсь, в Azure такой появится, и мы сможем убрать из инстанса самописный мини-кэш, с которым связано много костылей.

Игроки могут взаимодействовать, находясь на разных инстансах, поэтому нужно продумать обмен данными между инстансами. В идеале использовать распределенный кэш или, например, azureservicebus, но можно и через БД. Ещё вариант — для некоторых задач делать отдельную роль, которая не масштабируется, но иметь в виду, что она может стать узким местом. Например, в нашем проекте такой ролью является чат, экземпляр которого всегда один. В случае очень большой нагрузки его придется развёртывать на самой дорогой виртуалке с кучей ядер и памяти.

Исходя из нашего опыта, мы все-таки не рекомендуем в сетевой части игрового проекта баловаться с http, чтобы не плодить костыли, когда сервер хочет отправить клиенту какое-то событие — для сетевого слоя лучше используйте привычный tcp/udp, а данные можно сериализовывать, используя protobuff (получается экономней, чем в json). Если планируется веб-версия или просто хочется попробовать что-то новое, можно посмотреть в сторону websocket. Что касается работы с базой данных, то в случае использования NoSql DB (DocumentDb, MongoDb) проблем с шардингом быть не должно. А вот если выбрана реляционная БД, советуем сразу обстоятельно продумать реализацию горизонтального масштабирования данных, так так для реляционных баз это нетривиальная задача.

К слову, на московской White Nights наш гейм-дизайнер Всеволод Иванов вкратце рассказал об описанном в статье опыте использования Microsoft Azure (видео появится на днях).

Официальный сайт игры: http://warmach.pinkappgames.com

Сам проект на данный момент доступен на Windows Phone-платформах. Его можно скачать отсюда.