中華圏・東南アジア・日韓向けモバイルゲームのバックエンド設計：サーバー構成、リージョン配置とリリース時のDDoS対策

中華圏、東南アジア、日本・韓国のプレイヤーを対象とするモバイル／オンラインゲームのゲームバックエンド設計では、アカウントと決済データは一元管理し、リアルタイムのバトルサーバーはプレイヤーの近くに置くのが基本です。中国本土向けは香港CN2 GIA、台湾は台北、日本と韓国は東京とソウル、東南アジアはシンガポール・バンコク・クアラルンプール。IMIDCはこれらすべての拠点でサーバーを提供し、リリース日のDDoS対策と、VPSから専用サーバー、ホストノードへの拡張経路も用意しています。

リファレンス構成：5つの層

各層が保持する状態の量でバックエンドを分けます。ステートレス層は台数を増やせば伸び、ステートフル層は配置を慎重に決める必要があります。

バトルサーバーは使い捨てにします。1台が落ちても影響はその上の試合だけで、プレイヤーの所有物はすべてデータ層にあります。

TCP、WebSocket、それともUDP＋KCP？

ターン制、カード、放置系はTCPかWebSocket、アクション・シューター・MOBAなどのリアルタイム対戦はKCPのような信頼性レイヤーを載せたUDPが適しています。

アジアのプレイヤー向けリージョン配置

プレイヤーの実際の所在地とISPの経路でバトルサーバーを配置し、各ターゲット網からの mtr で検証します。

コンプライアンス上の注意：香港でのホスティングにICP届出は不要ですが、中国本土のプレイヤー向けにゲームを配信することは別途規制されています（ゲーム出版の審査など）。サーバーの場所はそれを変えないため、専門家に確認してください。法的助言ではありません。

実践：UDPバトルサーバー向けLinuxチューニング

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 が増え続けるなら、プロセスが読む前にカーネルがパケットを捨てています。バッファを増やす、ゲームプロセスをCPUコアに固定する、1プロセスあたりのルーム数を減らす、のいずれかで対処します。TCPゲートウェイではBBRを有効にし、多数のソケットを持つプロセスの ulimit -n も上げましょう。

実践：DockerでNakamaバックエンドを構築

Nakama（アカウント、マッチメイキング、チャット、ランキング）やColyseus（Node.jsのルーム）などのOSSサーバーを使えば、全サービスを一から書かずにプロトタイプからソフトローンチまで進めます。

# 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なら、2567番ポートを公開するNode.jsコンテナをNginxの背後に置き、WebSocketのアップグレードを有効にします。
• 本番ではPostgreSQLをNVMe/SSDの専用サーバーに移し、毎日オフサイトバックアップを取ります。

Redisとデータベースの層

ホットで短命なデータはRedis、失うとプレイヤーから苦情が来るデータはリレーショナルDBに置きます。

• Redis：セッショントークン、オンライン状態、マッチング待ち行列、レート制限カウンター、ランキング（ソート済みセット）。プライマリ＋レプリカ構成でAOFを有効化。
• MySQL/PostgreSQL：アカウント、インベントリ、課金履歴。ホームリージョンにプライマリと読み取りレプリカ。単一プライマリが逼迫したらプレイヤーIDやサーバー（ワールド）単位でシャーディング。
• リージョン間の書き込み：アカウントと課金の正本は1つに。各リージョンのバトルサーバーは結果をキュー経由で非同期に返し、海を越えてDBへ直接書き込まないようにします。
• ログと分析：イベントは別ストア（ClickHouse、Kafka）へ送り、分析クエリがゲームを遅くしないようにします。

リリース日のDDoS対策

ゲームのリリースは競合、恐喝者、不満を持つプレイヤーなどからDDoSを受けやすいタイミングです。ストアページ公開前に対策を計画しましょう。

• ログインと決済APIは CDN とIMIDCのDDoS対策の背後に置き、データベースやRedisは絶対に公開しません。
• バトルサーバーのIPはDNSに載せず、試合割り当て時にのみ、バトルサーバーが検証する短命トークンと一緒に配布します。
• 未認証のUDPは早い段階で破棄します。最初のパケットに有効なトークンがなければ無視します。
• 予備IPとサーバーイメージを用意し、攻撃されたリージョンを素早く移せるようにします。大規模スタジオなら IPリソース と自社ASNのAnycastも有効です。
• リリース日と想定ピークトラフィックを事前にIMIDCの営業へ伝え、対策と容量を計画しておきます。

VPSから専用サーバー、ホストノードへのスケール

段階的に拡張し、最初に苦しくなる層（多くはデータベースかバトルサーバー）から大きなハードウェアへ移します。

1台あたりの同時接続数はティックレートとゲームロジックで大きく変わります。数字は計画用の目安とし、各段階の前にボットで負荷試験してください。

どのIMIDC構成が合うか

全拠点で同じ構成を買うのではなく、層と市場に合わせて製品を選びます。

• 中国本土のプレイヤー：ゲートウェイや小規模バトルには 香港CN2 GIA VPS、重いバトル層とDBには 香港専用サーバー。
• 台湾のプレイヤー：台湾VPS または 台湾専用サーバー。
• 日本・韓国：日本VPS、日本専用サーバー、韓国VPS、KT回線の 韓国専用サーバー。
• 東南アジア：シンガポール、バンコク、クアラルンプールのサーバーは営業経由で構成。
• 他クラウドからの移行：無料サーバー移行。高クロックCPU、メモリ増設、プライベートネットワークなどのカスタム構成は営業へ。

よくある質問

中国本土と東南アジアの両方のプレイヤーを抱えるモバイルゲームは、どこでホスティングすべき？

よくある分け方は、本土プレイヤー向けのバトルサーバーをIMIDC香港CN2 GIAに、東南アジア向けをシンガポールやバンコクに置き、アカウントと決済のバックエンドは共通にする構成です。香港だけでも東南アジアの一部はそれなりにカバーできますが、決める前に実プレイヤーで試験してください。

ゲームサーバーはTCPとUDPのどちらを使うべき？

ターン制、カード、放置系はTCPやWebSocketで十分です。リアルタイムのアクション、シューター、MOBAはKCPなどの信頼性レイヤー付きUDPが有利で、UDPを遮断するネットワーク向けにTCPのフォールバックも用意します。

中国のプレイヤー向けに香港でゲームサーバーを運用する場合、ICP届出は必要？

IMIDC香港を含め、中国本土外でホストするサーバーにICP届出は不要です。ただし中国本土でのゲーム配信は別途規制されているため専門家に確認してください。法的助言ではありません。

ソウルのKT回線と東京でゲームサーバーを提供している事業者は？

IMIDCはソウル（KT回線）と東京で、現地ネイティブIP付きのVPSと専用サーバーを提供しており、香港、台北、東南アジア拠点もあわせて利用できます。

ゲームのリリースをDDoS攻撃から守るには？

事業者のDDoS対策と設計を組み合わせます。試合開始までバトルサーバーのIPを隠し、UDPの最初のパケットにトークンを必須にし、ログインAPIはCDNの背後に置きます。容量と対策を計画できるよう、リリース日を事前にIMIDCへ伝えてください。

アジアでのリリースを計画中なら、香港CN2 GIA VPS や ソウル専用サーバー から始め、シンガポール・バンコク・クアラルンプール拠点やリリース時のDDoS対策は IMIDC営業へお問い合わせ ください。アーキテクチャの相談は チケット からエンジニアにどうぞ。