Иногда инфраструктура перестает справляться ещё до того, как игра выходит к первым пользователям. Так произошло с The Firstborn — многопользовательской мобильной deck-builder RPG. В этой игре исход боя определяется не нажатием кнопок, а тем, как игрок собирает колоду, комбинирует расовые и классовые способности, прокачивает героев и строит долгосрочную стратегию. В игре десять рас, три класса, пять альянсов и несколько сотен уникальных активных и пассивных эффектов. Бой 6×6 может развернуться тысячами разных способов.

Но сама боевая система — только часть проекта. The Firstborn строится вокруг социального взаимодействия между игроками. В игре есть система контрактов, в которой пользователи соревнуются за ценные награды; кланы с общей прокачкой; свободный рынок, где игроки торгуют предметами друг с другом; крафты со скрытыми рецептами; охота на мировых боссов, где десятки людей одновременно сражаются с одним противником. Это с��здаёт формат живой MMO-экономики, что добавляет нагрузки на серверную часть.

На закрытом бета-тесте планируется около трёхсот одновременных игроков. На релиз — до десяти тысяч. Чтобы подготовиться заранее, потребовалась инфраструктура, которая выдержит значительные пиковые нагрузки и обеспечит стабильный ответ сервера во всех игровых задачах.

Проблема

Изначально проект работал на обычной виртуальной машине Selectel с четырьмя vCPU, восемью гигабайтами RAM и HDD. Этого хватало только на самые лёгкие внутренние тесты. При попытках провести нагрузочные испытания сервер начинал работать нестабильно и иногда просто падал. Это делало разработку и проверку новых функций невозможными.

Кроме низкой производительности диска, появилась проблема долга при деплое: большинство процессов выполнялось вручную, что затягивало цикл разработки. Пинг был приемлемым только в России, а при размещении боевой системы в продакшн-окружении расходы в Selectel оказывались в четыре–пять раз выше желаемого бюджета. Виртуалка также не позволяла запустить полноценный нагрузочный тест. Это стало критической точкой.

Почему нельзя было просто выбрать сервера в разных странах

Вся игровая экономика The Firstborn, включая кланы, рынок, контракты и мировых боссов, опирается на единую централизованную базу данных. Геораспределенная структура в данном случае невозможна: она привела бы к конфликтам транзакций, рассинхронизации состояния игры и некорректной работе всей боевой системы. Однако это не означает, что игра работает на одном сервере. Централизована только база. Сам backend распределён, работает под балансировщиком, использует микросервисную архитектуру, CDN для ассетов и может масштабироваться горизонтально — добавлением новых рабочих нод рядом с основной инфраструктурой.

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

Как нашли оптимальное решение

Мы протестировали десятки серверов через CloudSell и проверили их в реальных условиях. Измеряли задержки из разных стран, пропускную способность диска, устойчивость под нагрузкой и стоимость владения. В итоге лучшей точкой неожиданно стал Хельсинки. Через Финляндию проходят крупные международные каналы, и она оказалась оптимальной для связности сразу с несколькими регионами. Пинг из Европы и Азии оказался стабильным, а из России — в районе 40–50 миллисекунд. Этого более чем достаточно для deck-builder проекта, где основная нагрузка лежит на серверном просчёте боевой логики.

Мы отказались от виртуалки и развернули выделенный сервер в Hetzner на базе Intel Core i9-9900K с 128 ГБ памяти и NVMe-диском на 1 ТБ. Стоимость аналогичного сервера в Selectel почти в четыре раза выше, при том что он предлагает только половину объёма ОЗУ.

Переход на NVMe дал огромный прирост к скорости работы базы данных и контейнеров. CI/CD теперь работает автоматически, а деплой выполняется значительно быстрее. Новая инфраструктура стабильно выдерживает нагрузку до пятисот запросов в секунду на самую тяжёлую игровую операцию — запуск боя. Мы смогли проводить полноценные нагрузочные тесты даже до появления живых игроков, чего прежний сервер попросту не позволял.

Время просчёта боя сократилось с двух с половиной секунд до одной. Это заметно улучшило отклик игры: игрок практически сразу получает результат своего выбора колоды и стратегии. Производительность диска выросла на порядок, деплой стал быстрее, а стоимость инфраструктуры снизилась в четыре–пять раз по сравнению с размещением аналогичного оборудования в России. Пинг по миру стабилизировался, а основные сервисы начали работать предсказуемо и без резких скачков нагрузки.

Опыт показал, что для MMO-экономики и сложной deck-builder системы не всегда нужен дорогой распределённый кластер. Достаточно правильно выбрать точку размещения базы данных и построить вокруг неё горизонтально масштабируемый backend. В нашем случае это позволило не только ускорить серверную часть в два с половиной раза, но и сократить расходы на инфраструктуру в несколько раз. CloudSell значительно упростил процесс подбора и тестирования серверов, что сэкономило команде недели работы и позволило сосредоточиться на разработке игры.