Бэкенд мультиплеерной игры: 52 000 игроков одновременно
Студии мобильных игр нужна была серверная часть, которая выдержит рост аудитории, сезонные события и мультиплеер в реальном времени. Мы сделали её на Go, Redis и Kubernetes: на пике — 52 000 игроков одновременно при средней задержке 62 мс и доступности 99,98 %. Клиента не называем, пока он не разрешит письменно.
Результат в цифрах
Источник: кейс на yarvixo.com. Это другая игра, не Metarun: у Metarun свой пик — 39 000 игроков во время события.
Задача: рост без узких мест
Студия готовилась к росту живого трафика, сезонным событиям и мультиплееру в реальном времени со строгими требованиями к задержке. Нагрузка приходит всплесками — события, пики сессий, активность по регионам, — и подбор игроков вместе с обновлением состояния должен оставаться быстрым и под ней, иначе страдает сама игра.
Ещё студии нужны были панели, оповещения и масштабирование, которые работают на практике, а не только на схемах архитектуры: после передачи бэкенд вести ей самой. Инфраструктура не должна была стать узким местом ни для игры, ни для её поддержки после запуска.
Что сделали
Стек намеренно без экзотики: игровой бэкенд обслуживают под давлением, и хитроумность становится помехой в три часа ночи.
Сначала то, что видит игрок
Критичные для игры пути отделили от второстепенных процессов поддержки, а первую часть сервисов построили вокруг подбора игроков и управления сессиями — остальное наращивали потом.
Ядро на Go
Сервисы на Go с gRPC между ними: сессии, координация игрового состояния, обработка событий. Упор — на задержку и простоту эксплуатации.
События через Redis
Redis в режиме публикации и подписки и надёжные очереди: быстрая рассылка событий, координация подбора игроков, обмен между сервисами с малой задержкой. Прогресс и покупки хранятся в PostgreSQL.
Масштабирование в Kubernetes
Автомасштабирование по числу подключений, а не по загрузке процессора, и правила выкатки, настроенные под то, как ведёт себя игровой трафик: игра остаётся в сети во время всплесков, патчей и событий.
Нагрузочные тесты с первого среза
Нагрузку моделировали каждый спринт, начиная с первого рабочего среза, а не оставляли проверку масштаба на конец. Поэтому первый настоящий пик трафика прошёл спокойно, без истории о трудном запуске.
Мониторинг и передача
Метрики, панели Grafana и оповещения команда студии получила ещё до запуска. В первые пиковые окна мы были рядом: следили за поведением системы и подтягивали узкие места.
Результат и что можно проверить
52 000 игроков одновременно на пике — реальная нагрузка, а не допущение тестовой среды. Средняя задержка 62 мс сохраняла качество игры именно тогда, когда это важнее всего, а доступности 99,98 % хватило для живых событий, сезонов и предсказуемого плана выпусков. У студии появился запас роста: не нужно перестраивать инфраструктуру при каждом скачке спроса.
Бэкенд на 500 игроков одновременно и на 50 000 — разные системы, а не одна и та же система разного размера. Объём работ задают четыре вещи: сколько игроков должно быть онлайн одновременно, как часто обновляется состояние, кто решает исход матча — сервер или устройство игрока — и нужна ли поддержка живой игры после запуска.
Открыть эту игру и проверить нас по ней нельзя: клиент не назван. Поэтому здесь только то, что опубликовано на yarvixo.com, — стек, порядок работ и три измеренные цифры.
Оставить заявку
Опишите задачу в двух-трёх предложениях и укажите бюджет: по нему сразу видно, какой вариант вам подходит. Проекты начинаются от 14 700 BYN. Если бюджет меньше, предложим платную консультацию за 150 BYN в час.
- 1–3 дняЧитаем заявку и созваниваемся: задача и бюджет. Если нам нечего предложить — так и скажем.
- Неделя 1Письменно: что входит, срок и одна сумма. Что не входит — тоже письменно.
Заявка отправлена
Мы прочитаем её и свяжемся с вами по указанному контакту.