Як ми будували хмарний бекенд для мобільного шутера

Привіт, Хабр!

Зовсім нещодавно ми запустили в Росії і ще кількох країнах багатокористувацький мобільний шутер Guns Of Boom, який вже скачало понад півмільйона осіб. Для забезпечення плавної і безперебійної ігри такої кількості користувачів потрібен хороший бекенд. У цій статті ми розповімо, чому ми вирішили використати для цього хмара, та коротко опишемо особливості побудови бекенду на основі хмарних сервісів.



В цілому, хмарні сервіси мають ряд незаперечних переваг перед класичним бекендом у вигляді працюючого в підвалі у розробника сервера. На відміну від стаціонарних серверів, число яких неможливо різко збільшити або скоротити (гра не популярна, «не сезон» та устаткування простоює), вони можуть включати і вимикати додаткові потужності автоматично, залежно від навантаження.

Дві основних переваги хмари, що допомагають зрозуміти його глибинну суть (тм) — забезпечення надмірності і швидкості масштабування. Під швидкістю масштабування тут мається на увазі можливість швидко забезпечити додаткові апаратні ресурси при різкому збільшенні числа користувачів, а при зменшенні — скоротити витрату серверного часу і заощадити гроші і ресурси.

У випадку з надмірністю мова йде про автоматичне дублювання ресурсів ігри, даних або апаратних систем в хмарі. Найчастіше надлишковість забезпечується зберіганням однакового набору даних на декількох серверах в межах одного або декількох дата-центрів у межах однієї географії. Це потрібно для екстреного відновлення при збоях, забезпечення автоматичного аварійного перемикання на доступні сервера і захисту від DDOS-атак.



Так як ми говоримо про створення онлайн-шутера, дуже важливо забезпечити низьку затримку в передачі даних. Як мінімум чверть від усіх користувачів грає у Guns of Boom через 3G/4G, і для плавного геймплея потрібна затримка, не перевищує 100 мілісекунд. Ролик вище ілюструє динаміку гри, яку необхідно забезпечувати і підтримувати на якісному рівні для кожного гравця в будь-якій точці світу.


По-перше, це забезпечується автоматичним підключенням гравця до найближчого сервера, розташованого, як правило, в тому ж географічному регіоні. По-друге, для забезпечення максимальної продуктивності і плавності ми використовуємо сесійні та мета-сервера. Мета-сервера — підмножина реалтаймовых сервісів, які ми для простоти розуміння об'єднали в одну роль, некритичну по розташуванню для геймплея. В якийсь момент ми розглядали використання моделі мікро-сервісів, але в результаті не знайшли значних переваг і зупинилися на цьому варіанті.

До мета-сервера ігровий клієнт звертається для авторизації і синхронізації даних, це з'єднання є постійним і не розривається під час ігрової сесії. Зазвичай в шутерах намагаються цього уникнути, але з поточним рівнем навантаження ми вирішили, що цей підхід виправдовує себе. Крім іншого, саме мета-сервер вирішує, до якого сесійній сервера в кожен момент часу буде підключений клієнт. Безпосередньо ігрова сесія відбувається, як підказує назва, на сесійному сервері.

Завдяки використанню хмари ми отримуємо можливість автоматично масштабувати інфраструктуру і споживати тільки те кількість ресурсів, яка потрібна в даний момент. Хмара легко може надати більшу кількість апаратних ресурсів (ПРОЦЕСОР, оперативна пам'ять, інтернет-канал) для обробки збільшеного числа користувачів і, відповідно, ігрових сесій.

Масштабування працює і у зворотний бік. У 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 на весь світ, ощаслививши всіх гравців, які його чекають. І ми про це теж обов'язково розповімо.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.