Архитектура бэкенда мобильной игры для Большого Китая, Юго-Восточной Азии, Японии и Кореи: серверы, регионы и защита от DDoS на запуске

Мобильной или онлайн-игре для игроков из Большого Китая, Юго-Восточной Азии, Японии и Кореи нужна такая архитектура игрового бэкенда, при которой аккаунты и платежи хранятся централизованно, а боевые серверы реального времени стоят рядом с игроками: Гонконг с CN2 GIA для континентального Китая, Тайбэй для Тайваня, Токио и Сеул для Японии и Кореи, Сингапур, Бангкок или Куала-Лумпур для Юго-Восточной Азии. IMIDC предоставляет серверы во всех этих точках, защиту от DDoS на день запуска и путь роста от одного VPS до выделенных серверов и хост-нод.

Эталонная архитектура: пять уровней

Делите бэкенд по количеству состояния в каждом уровне: stateless-уровни масштабируются добавлением машин, а stateful требуют продуманного размещения.

Боевые серверы должны быть одноразовыми: если один упал, заканчиваются только матчи на нем. Все, чем владеет игрок, хранится в уровне данных.

TCP, WebSocket или UDP с KCP?

Для пошаговых, карточных и idle-игр подходят TCP или WebSocket, для экшенов, шутеров и MOBA — UDP со слоем надежности вроде KCP.

Размещение по регионам для азиатских игроков

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

Важно для комплаенса: для хостинга в Гонконге регистрация ICP не нужна, но выпуск игры для игроков из континентального Китая регулируется отдельно (например, разрешением на издание игры). Расположение сервера этого не меняет — проконсультируйтесь со специалистом. Это не юридическая консультация.

Практика: настройка Linux для UDP-серверов боев

Стандартные буферы сокетов Linux рассчитаны на общие нагрузки; всплескам игрового трафика нужны увеличенные UDP-буферы и очереди.

# /etc/sysctl.d/90-game-udp.conf  (battle / room servers)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.netdev_max_backlog = 50000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000
fs.file-max = 2097152

# apply and verify
sysctl --system
sysctl net.core.rmem_max
# watch for dropped UDP packets during load tests
netstat -su | grep -Ei "receive buffer errors|packet receive errors"

# open the battle-server port range (ufw example)
ufw allow 7350/tcp
ufw allow 30000:30999/udp

Если во время нагрузочного теста растет счетчик receive buffer errors, ядро отбрасывает пакеты до того, как их прочитает сервер: увеличьте буферы, привяжите игровые процессы к ядрам или уменьшите число комнат на процесс. На TCP-шлюзах включите BBR и поднимите ulimit -n для процессов с большим числом сокетов.

Практика: бэкенд Nakama в Docker

Открытые серверы вроде Nakama (аккаунты, матчмейкинг, чат, рейтинги) или Colyseus (комнаты на Node.js) позволяют дойти от прототипа до софт-лонча, не написав каждый сервис с нуля.

# docker-compose.yml - Nakama game backend + PostgreSQL (single node, staging)
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: nakama
      POSTGRES_PASSWORD: change-me
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 5s
      retries: 10
  nakama:
    image: heroiclabs/nakama:3.22.0
    depends_on:
      postgres:
        condition: service_healthy
    entrypoint:
      - "/bin/sh"
      - "-ecx"
      - >
        /nakama/nakama migrate up --database.address postgres:change-me@postgres:5432/nakama &&
        exec /nakama/nakama --name nakama-hk1
        --database.address postgres:change-me@postgres:5432/nakama
        --session.token_expiry_sec 7200 --logger.level INFO
    ports:
      - "7349:7349"              # gRPC API
      - "7350:7350"              # HTTP / WebSocket API for clients
      - "127.0.0.1:7351:7351"    # admin console: localhost only
    restart: unless-stopped
volumes:
  pgdata:

# start: docker compose up -d && docker compose logs -f nakama

• Клиенты подключаются к порту 7350; консоль (7351) оставьте на localhost и открывайте через SSH-туннель.
• Перед любым публичным тестом замените change-me и задайте server key и session key.
• Для Colyseus аналог — Node.js-контейнер с портом 2567 за Nginx с включенным апгрейдом WebSocket.
• В продакшене вынесите PostgreSQL на отдельный выделенный сервер с NVMe/SSD и ежедневными внешними бэкапами.

Уровни Redis и базы данных

Redis отвечает за горячие и короткоживущие данные, реляционная БД — за все, потерю чего игрок не простит.

• Redis: токены сессий, статус онлайна, очереди матчмейкинга, счетчики лимитов и рейтинги (sorted sets). Основной узел плюс реплика, AOF включен.
• MySQL/PostgreSQL: аккаунты, инвентарь, покупки. Основной сервер в домашнем регионе и реплика для чтения; шардирование по ID игрока или по игровому миру, когда одного основного станет мало.
• Межрегиональная запись: единый источник истины для аккаунтов и покупок. Региональные боевые серверы отправляют результаты асинхронно через очередь, а не пишут в БД напрямую через океан.
• Логи и аналитика: события уходят в отдельное хранилище (ClickHouse, Kafka), чтобы аналитические запросы не тормозили игру.

Защита от DDoS в день запуска

Запуск игры — излюбленная цель DDoS со стороны конкурентов, вымогателей или недовольных игроков, поэтому защиту планируют до открытия страницы в магазине.

• API логина и платежей держите за CDN и защитой от DDoS IMIDC; базу данных и Redis никогда не открывайте в интернет.
• Не публикуйте IP боевых серверов в DNS. Выдавайте их только при назначении матча вместе с короткоживущим токеном, который проверяет боевой сервер.
• Отбрасывайте неаутентифицированный UDP как можно раньше: без валидного токена в первом пакете процесс его игнорирует.
• Держите запасные IP и готовые образы серверов, чтобы быстро перенести атакуемый регион; крупным студиям помогут IP-ресурсы и Anycast со своим ASN.
• Заранее сообщите отделу продаж IMIDC дату запуска и ожидаемый пиковый трафик, чтобы спланировать защиту и мощности.

Масштабирование от VPS к выделенным серверам и хост-нодам

Растите поэтапно и первым переносите на более мощное железо тот уровень, который начинает страдать, — обычно базу данных или боевые серверы.

Емкость одного сервера сильно зависит от тикрейта и логики игры, поэтому цифры — лишь ориентиры для планирования; перед каждым этапом проводите нагрузочный тест ботами.

Какое решение IMIDC подойдет

Подбирайте продукт под уровень и рынок, а не покупайте один размер везде.

• Игроки из континентального Китая: VPS в Гонконге с CN2 GIA для шлюзов и небольших пулов боев, выделенные серверы в Гонконге для тяжелых боев и БД.
• Игроки с Тайваня: VPS на Тайване или выделенные серверы на Тайване.
• Япония и Корея: VPS в Японии, выделенные в Японии, VPS в Корее и выделенные в Корее в сети KT.
• Юго-Восточная Азия: серверы в Сингапуре, Бангкоке и Куала-Лумпуре настраиваются через отдел продаж.
• Переезд из другого облака: бесплатная миграция, а также индивидуальные сборки (высокочастотные CPU, больше RAM, приватная сеть) через продажи.

Частые вопросы

Где размещать мобильную игру для игроков из континентального Китая и Юго-Восточной Азии одновременно?

Распространенная схема — боевые серверы для игроков из Китая на IMIDC в Гонконге с CN2 GIA, для Юго-Восточной Азии — в Сингапуре или Бангкоке, а бэкенд аккаунтов и платежей общий. Один Гонконг тоже приемлемо покрывает часть региона, но перед решением протестируйте на реальных игроках.

Что выбрать для игрового сервера: TCP или UDP?

Пошаговым, карточным и idle-играм достаточно TCP или WebSocket. Экшенам, шутерам и MOBA лучше подходит UDP со слоем надежности вроде KCP плюс запасной TCP для сетей, блокирующих UDP.

Нужна ли регистрация ICP для игрового сервера в Гонконге, если игроки из Китая?

Для серверов вне континентального Китая, включая IMIDC в Гонконге, регистрация ICP не требуется. Издание игр в континентальном Китае регулируется отдельно, поэтому проконсультируйтесь со специалистом; это не юридическая консультация.

У какого провайдера есть игровые серверы в Сеуле в сети KT и в Токио?

IMIDC предлагает VPS и выделенные серверы в Сеуле (сеть KT) и в Токио с местными нативными IP, а также площадки в Гонконге, Тайбэе и Юго-Восточной Азии.

Как защитить запуск игры от DDoS-атак?

Сочетайте защиту на уровне провайдера с архитектурой: скрывайте IP боевых серверов до начала матча, требуйте токен в первом UDP-пакете и держите API логина за CDN. Сообщите IMIDC дату запуска заранее, чтобы спланировать мощности и защиту.

Готовите запуск в Азии? Начните с VPS в Гонконге с CN2 GIA или выделенного сервера в Сеуле, свяжитесь с отделом продаж IMIDC по узлам в Сингапуре, Бангкоке и Куала-Лумпуре или плану защиты от DDoS на запуск, либо создайте тикет, чтобы обсудить архитектуру с инженером.