リアルタイム通信サーバ設計・開発の最新事情をお届けします。

1. 年の瀬！
リアルタイム通信ゲームサーバ
勉強会
2015/12/3

2. ■目次
1.リアルタイム通信サーバ設計・開発の最新事情
1.1. リアルタイム通信サーバ設計の最新トレンド
1.2. ポート番号問題
1.3. 負荷テストってどうやってるの？
1.4. 負荷分散の実例
1.5. Webサーバとの連携方法は？
1.6. どこのクラウドがおすすめなの？
1

3. ■リアルタイム通信サーバ設計の最新トレンド
エリアサーバA エリアサーバB
DB
バックエンドサーバ
（オークション、チャット）
クライアント クライアント クライアント クライアント
１ワールド
エリアサーバN…
■サーバ設計の過去
かつてPCオンラインゲームが全盛だった時代は、
全てをC++で実装したリアルタイム通信のサーバで設計する構成
（下図参照）が主流だった。
2

4. ■リアルタイム通信サーバ設計の最新トレンド
■現在のトレンド
モバイル案件ではソーシャル要素を非同期で実装し、
バトル部分をリアルタイムサーバで実装する構成、
ハイブリッド型のサーバ設計が主流。
→リアルタイム通信が必要ない部分を実装が容易なWEB言語で実装し、
処理負荷の高いバトル部分をC++言語で実装することにより、
生産性と実行効率の両方いいとこ取りしたサーバー構成が実現可能。
また、既にWebの資産がある場合再利用可能というメリットもある。
■実例
今回はこのハイブリッド型のサーバ構成で実際に運用した、
とあるMO系モバイルタイトルのサーバ構成を二種類ご紹介します。
（これから紹介するタイトルは架空の案件を複数組み合わせたものですが、
詳細には事実が含まれております。）
3

5. ■リアルタイム通信サーバ設計の最新トレンド
■タイトルA
Webサーバでソーシャル要素を実装し、
バトルルームに複数人が集まって敵と戦う白猫のようなゲーム。
■設計ポイント
ある程度のプレイヤーのリスティングをWebサーバで行い、
更にレベルマッチング等マッチングの種類によるマッチング処理を、
C++で実装されたリアルタイム通信のマッチングサーバで行う事で、
非常に高速なマッチング処理を行う事が可能になる設計。
そのためマッチングサーバの台数をやや多目に見積もっている。
4

6. ■具体的なサーバ構成
クライアントアプリはマ
ッチングサーバを介して
バトルサーバの接続先を
取得する
インスタンスバトルへの参加
のたびに、
いずれかのBattleサーバに直
接接続。バトルが終了すると
切断。
ＷＥＢ ＳＥＲＶＥＲＳ（ＥＣ２）
Ｃａｓｈｅ Ｄａｔａｂａｓｅ
Ｂａｃｋｅｎｄ Ｇａｍｅ（Ｌｏｂｂｙ）Ｓｅｒｖｅｒｓ Ｂａｃｋｅｎｄ Ｇａｍｅ（Ｏｔｈｅｒｓ）Ｓｅｒｖｅｒｓ
Ｆｒｏｎｔｅｎｄ Ｓｅｒｖｅｒｓ
Ｆｒｏｎｔｅｎｄ （Ｂａｔｔｌｅ）Ｓｅｒｖｅｒｓ
Ｐｒｉｖａｔｅ Ｓｅｃｔｉｏｎ
Ｇｌｏｂａｌ Ｓｅｃｔｉｏｎ
Ｂａｔｔｌｅ Ｂａｔｔｌｅ
Ｒａｎｋｉｎｇ Ｃｈａｔ
ＣｈａｔＲａｎｋｉｎｇ
Ｂａｔｔｌｅ Ｂａｔｔｌｅ
Matching
Ｌｏｂｂｙ Ｌｏｂｂｙ
Ｌｏｂｂｙ Ｌｏｂｂｙ
Sync
Matching Matching Matching
5

7. ■リアルタイム通信サーバ設計の最新トレンド
■タイトルB
Webサーバでソーシャル要素を実装し、
起動するとビジュアルロビーがあり、
そこからバトルフィールドに入って敵と戦うログレスのようなゲーム。
■設計ポイント
グローバルIPアドレスを節約して欲しいというオーダーがあり、
フロントエンドに通信の入り口を一つにまとめるサーバを設置し、
クライアントはフロントエンドサーバにコネクションを張る事で、
そこを介してバックエンドに設置したエリアサーバに通信を行う。
エリア間の移動は全てサーバ間通信で賄えるので、
対象エリアサーバに対してコネクションを張り直すといった事もしなくても良い。
結果として通信料の削減にも繋がった。
6

8. ■具体的なサーバ構成
クライアントアプリは1台
のRelayServerに
常時接続。エリアを移動し
ても切断・再接続は不要。
ＷＥＢ ＳＥＲＶＥＲＳ（ＥＣ２）
Ｃａｓｈｅ Ｄａｔａｂａｓｅ
Ｂａｃｋｅｎｄ （Game）Ｓｅｒｖｅｒｓ
Ｆｒｏｎｔｅｎｄ Ｓｅｒｖｅｒｓ
Ｐｒｉｖａｔｅ Ｓｅｃｔｉｏｎ
Ｇｌｏｂａｌ Ｓｅｃｔｉｏｎ
Ｒｅｌａｙ Ｒｅｌａｙ Ｒｅｌａｙ Ｒｅｌａｙ
Lobby
Lobby
Sync
Area
Game
Area
Game
Area
Game
7

9. ■ 1.2.ポート番号問題
初心者向け
■ポート番号とは？
コンピュータがデータ通信を行う際に通信先のプログラムを特定するための番号のこと。
TCP/UDPのプロトコルそれぞれに対し、０～６５５３５の数値と決まっている。
プログラムでポートを用いて通信するには、一般にソケットと呼ばれる仕組みを用います。
■ソケットプログラミングとは？
（※Wikipedia参照）
１.サーバ機でサービスを提供するプログラムは、ソケットを作成し、サービス固有のポート番号を
ソケットに割り当て (bind)、待ち行列を用意し (listen)、クライアントからの接続を待ち受ける
(accept)。
2.サービスを利用するクライアントプログラムは、ソケットを作成し、そのソケットの通信相手と
してサーバ機のIPアドレスとサービスのポート番号を指定し (connect)、接続を行う。
3.サーバは接続を受け付けると、新規にソケットを作成し、そのソケットとクライアントとの間に
通信を確立する。もとのソケットは再び待ち受けに戻る（これは、会社などで、受付係が来客を担
当者に引き合わせ、その後また受付に戻るようなものと考えることができる）。
４．通信が終わると、2.および3.で作成したソケットは破棄される。
8

10. ■ 1.2.ポート番号問題
リアルタイム通信のゲームサーバではクライアントからの通信を待ち受ける
ポートを決める必要がある。
一般的に設定するポートについては、ウェルノウンポート（０－１０２３）
を避けて設定する事。
ウェルノウンポートを避けて設定すれば基本的に自由に決めて問題ない。
■注意点
特定のポートだと通信が行えなくなる場合がある。
例えば5桁の15000以上に設定し、
通信がうまく行えない場合そのポートは、
サーバサイドでも他サーバへの通信で使っている可能性がある。
つまり、サーバ側がクライアントとなり他サーバに通信をする場合、
システム側で割り当てられたポートとして使われているケースが多い。
（あくまで一例ですがHTTP通信等）
※Linuxでnetstatコマンドで確認すると見知らぬポートが見つかる的な
他にも、
ルータ側の問題で10000以上が繋がらなかったり…。
9

11. ■ 1.2.ポート番号問題
■ポート番号指定の失敗例
セキュリティの観点からHTTP通信で使用する80ポートを設定した所、
結果、一部のユーザーさんだけサーバに接続できない問題が発生。
原因としてはAUのLTE回線で80ポートはHTTP通信しか許可しない設定になっ
ていた。
参考URL：
http://www.au.kddi.com/developer/android/kaihatsu/network/
■解決策
8100ポートも空けておく事で80ポートでアクセスできない場合、
8100ポートにリダイレクトする処理をインフラ側で対応した。
こういったキャリア側の問題も存在するため、
ウェルノウンポートは可能な限り使わない方が良い。
10

12. ■ 1.2.ポート番号問題
■結論
リアルタイム通信サーバのクライアントからの通信の待ち受けポートとし
ては、1万以下が良い。
実際にモノビットエンジンでは、
4000以上9000以下のポートを使用した場合に今までトラブルが少なかっ
たが、トラブルが発生しない事を完全に保証する訳ではない。
ポート問題は奥が深い…。
→それでも設定したポートで通信出来なかったら、
下記ページが何かのヒントになるかも。
・TCPやUDPにおけるポート番号の一覧
https://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3
%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3
%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8
%A6%A7
11

13. ■テスト方法について
・Web系の場合
→JMeter等を用いてテストを行うのが一般的。
・リアルタイム通信ゲームサーバの場合
→JMeterでは独自のプロトコルが使用できないので、
ダミークライアントを自前で作成し、それを用いた負荷テストを行う。
■ダミークライアントとは？
クライアントの通信をエミュレーションしたプログラムの事。
■ダミークライアントの処理の実際
起動したらログインといったアウトゲームの処理を模倣するのではなく、
マッチングサーバに直接接続し、バトルに移行しクライアント、
サーバ間で通信を送り合う処理を作成する事が多い。
■ 1.3.負荷テストってどうやってるの？
12

14. ■ 1.3.負荷テストってどうやってるの？
■ダミークライアントの作り方
バトル中の処理については、
インゲーム（バトル）の部分にログを仕込んで通常プレイを行い、
バトル中のログを取得する事で、
ユーザーのバトル中の行動がある程度把握できるので、
そのログを元にダミークライアントにバトルの通信をエミュレートした
処理を実装していく。
13

15. ■ 1.3.負荷テストってどうやってるの？
■テスト方法について
２種類ある。
方法１：PCや端末を大量に用意してテストクライアントを動かして
テストを行う方法。
方法２：クラウド上に負荷をかけるサーバと負荷をかけられるサーバを用
意し、
Linux上で稼働するダミークライアントをインストールして
テストを行う方法。
■実際は・・・
方法１を採用する事もあるが、
数万接続をエミュレートする際に現実的には方法2を選択する。
14

16. ■方法２でAWSを使用する際の注意点
インスタンスタイプを選択する際、
t2.microを選択しないようにする。
負荷検証等、CPU負荷をかけるような処理の場合Steal （※）問題が発生する。
最低でもt2.medium以上を使うべき。
※Steal問題とは、
短時間であれば問題なく動作するが高負荷状態が一定時間続くと、
強制的に低速モードに切り替わり、
CPU性能が約8～9割劣化し極端に処理速度が低下してしまう問題。
■ダミークライアントをLinux上で使用する上での注意点
ダミークライアントの作りにもよるが、
1つのダミークライアントで数ユーザー等少ない人数をエミュレーションして、
1台のマシンで同時に500プロセス等、
大量のダミークライアントプロセスを起動するような場合、
コンテキストスイッチの切り替えが短い時間で発生し、
1つのプロセスで十分な処理時間が確保できなくなり、
通信が正常に行われなくなる場合がある。
出来る限り1プロセス内に複数ユーザーを処理ようなプログラムにし、
同時起動プロセス数を出来るだけ少なくするのが重要。
■ 1.3.負荷テストってどうやってるの？
15

17. ■ 1.3.負荷テストってどうやってるの？
■モノビットエンジンのダミークライアント
Linuxで動作するダミークライアントのスケルトンを提供しています。
パッケージ構成
dummy_client_base/ => ダミークライアントのベースプログラム
dummy_client => ダミークライアント実行ファイル
dummy_client_multi.sh => dummy_client を複数プロセスで起動するためのシェル
dummy_client_start.sh => ダミークライアント起動シェル
dummy_client_stop.sh => ダミークライアント停止シェル
setup.sh => 初回のみ実行するシェルスクリプト
dummy_client.sh => サーバーのビルドや起動／停止を行うシェルスクリプト
log/ => ダミークライアントがプロセス単位で出力するログファイルディレクトリ
config/ => ダミークライアント用コンフィグファイルディレクトリ
src/ => ダミークライアント用ソースファイルディレクトリ
libmln/ => 必要に応じて接続先のMLNサーバー側で使用しているものと同じMLNライブラリを配置するディレクト
リ
dummy_client_echo_sample_lite/ => echo_sample_lite版ダミークライアントプログラム
dummy_client => ダミークライアント実行ファイル
dummy_client_multi.sh => dummy_client を複数プロセスで起動するためのシェル
dummy_client_start.sh => ダミークライアント起動シェル
dummy_client_stop.sh => ダミークライアント停止シェル
setup.sh => 初回のみ実行するシェルスクリプト
dummy_client.sh => サーバーのビルドや起動／停止を行うシェルスクリプト
log/ => ダミークライアントがプロセス単位で出力するログファイルディレクトリ
config/ => ダミークライアント用コンフィグファイルディレクトリ
src/ => ダミークライアント用ソースファイルディレクトリ
libmln/ => 必要に応じて接続先のMLNサーバー側で使用しているものと同じMLNライブラリを配置するディレクト
リ
16

18. ■ 1.3.負荷テストってどうやってるの？
■カスタマイズ方法について
ゲーム中の通信を定義して出力されたRPCコードを該当箇所にどんどん追加していくだけでOK。
17

19. ■ 1.3.負荷テストってどうやってるの？
■ダミークライアントの起動シェル
ダミークライアントの起動シェル dummy_client_start.sh には、以下の設定値が用意されている。
SELF_NODE_ID : ダミークライアントのノードID
SELF_IP_ADDR : ダミークライアントを実行しているマシンのIPアドレス
SELF_PORT : ダミークライアントのノード待ち受けポート番号(0なら、ランダム)
SYNC_IP_ADDR : Syncサーバーを実行しているマシンのIPアドレス
SYNC_PORT : Syncサーバーのノード待ち受けポート番号
デフォルトではローカル環境の設定になっているので、
SELF_IP_ADDR と SYNC_IP_ADDR を環境に合わせて修正する。
18

20. ■ 1.3.負荷テストってどうやってるの？
■ダミークライアントの起動シェルオプション
ダミークライアントの起動シェル dummy_client_start.sh には、以下のオプションが用意されている。
-m : ダミークライアントで使用する全体のキャラ数（接続数）
-n : 1プロセスで使用する最小キャラ数（接続数）
-i : ダミークライアントで使用するキャラID（接続ID）の開始値
デフォルト（-m 1 -n 1 -i 1）では、キャラID 1 のキャラで 1 プロセスを起動する。
例：
-m 4 -n 4 -i 1 とした場合、キャラID 1, 2, 3, 4 のキャラで 1 プロセスを起動する。
また、 -m 8 -n 4 -i 10 とした場合、キャラID 10, 11, 12, 13 のキャラで 1 プロセス、
キャラID 14, 15, 16, 17 のキャラでもう 1 プロセスを起動する。
19

21. ■ログレスライクゲームの負荷テスト
・ゲーム内容
4人のユーザーが集まってバトルを行うタイプのゲーム。
・リアルタイム通信サーバの使用箇所
マッチングサーバ、バトル、チャット
・テスト対象
どれがかけてもゲームが成立しないため、
マッチング、バトル、チャット、それぞれに対して負荷テストを行う。
今回はバトルサーバの負荷テストの実例を紹介します。
・負荷テストの目標
同時接続10000人でバトルサーバのMAXCPU使用率30％程度を目標とする。
・テストシナリオ
プレイ時間から逆算を行う。
プレイ時間を1時間だと仮定し、
デッキ編成やガチャ等ソーシャル要素をプレイしている時間を考慮し、
10分に1回はバトルをしていると想定。
→ここのさじ加減は非常に重要！
■ 1.3.負荷テストってどうやってるの？
20

22. ■ 1.3.負荷テストってどうやってるの？
■バトルサーバの負荷テストの実例
負荷にもよるが、ログレスのようなターン制のアクションゲームの場合、
1バトルサーバに500～1000プレイヤーを収容するケースが多い。
バトル中の処理が軽いものだと3000以上収容できる事も多い。
今回は余裕をもってバトルサーバは15台用意した。
・負荷テスト一回目
AWS上に負荷をかけるサーバを用意しダミークライアントをインストールした。
クラウドサーバ内
Dummy
Battle
Battle
Dummy
Dummy
負荷テスト開始！
21

23. ■ 1.3.負荷テストってどうやってるの？
■負荷テスト中の状況の確認
CPUの使用率を確認するには、バトルサーバへSSHでログインし、
負荷試験中にtopコマンドで確認を行う。
topコマンドを実行した所、
テスト早々にバトルサーバのCPU使用率が100％になってしまった！
22

24. ■ 1.3.負荷テストってどうやってるの？
■対策
この時点で原因は完全に不明。
どこの処理でCPUコストを食っているのか調べる必要があったので、
バトルサーバのコードに細かくログ出力を仕込み、
ロジック毎の処理時間を計測した。
こういった泥臭い事が実は解決への一番近道。
最初は粒度が荒い所から始め、
徐々にコストが重い処理を絞り込んでいくイメージ。
23

25. ■ 1.3.負荷テストってどうやってるの？
■原因
上述の方法でコストが重い処理を調査した結果、
あたり判定処理に非常にコストがかかってしまっていた事が判明。
■改善策
プレイヤー含む全てのオブジェクトに対し当たり判定を行っていた。
ゲーム仕様的に同期が必要なオブジェクトのみ、
あたり判定を行えば良かったので、
当たり判定処理の最適化を行った。
再度負荷テストを行い、MAXCPU使用率が２５%程度に落ち着くようになった。
また、目標の30％以内には収まってはいるが、本番サーバ構築時に余裕を持たせ
バトルサーバマシンのスケールアップを行った。
■結果
CPU負荷も軽減され負荷テストも滞りなく完走。
これで負荷テストも終わり？
いやまだ終わっていませんでした。 24

26. ■ 1.3.負荷テストってどうやってるの？
■何が起きていたのか。
同接10000人時のネットワークトラフィックを監視していた所、
ネットワークのトラフィックが膨れ上がっていました。
当初1プレイヤー当たり2kbps程度、同接10000人で20mbps前後と
見込んでいたが、35mbps程度になってしまっていた。
→通信処理の最適化を行う必要有
■ネットワークトラフィックの監視について
iftopコマンドにて確認。
※インストール方法については割愛
25

27. ■ 1.3.負荷テストってどうやってるの？
■原因
パケットの送信間隔や量に問題があるとし、解析した所、
通信プログラムがどこから呼ばれてるのかをエクセルに記述し、
ソートしてみた所、
位置情報の更新のためのRPCが毎フレーム呼び出されており、
送信間隔に問題がある事が判明。
■対策
毎フレームポーリングするのはやめて、
オブジェクトが入力による移動や攻撃等、
変化があった際に通信を行うイベントドリブン形式に変更を行った。
その結果、再テストを行うと通信量がほぼ22mbps程度に削減が出来、
ほぼ想定通りのトラフィックになった。
■余談
モノビットエンジンでは、
エクセル等を用いずとも、
通信関数の呼び出し回数等を出力できるようにするデバッグ機能を開発中です！
26

28. ■ 1.4.負荷分散の実例
■負荷分散の考え方
例えばクラウドのインスタンスが8コアのマシンだった場合に、
マシンパワーを使い切るには、
リアルタイム通信サーバのプロセスが8プロセス起動といった形で、
ポートを複数用意し、コア数分だけ立ち上げると良い。
ここから更にマシンの台数を増やす事で冗長化も行う。
バトルサーバの振り分けについては、マッチングサーバ側で、
ラウンドロビンを採用し自然分散に期待する。
■1マシン1ポートしか使えない場合の対策
複数サーバプロセスを立ち上げたものの、
グローバルのポートが一つしか開放できないような場合は、
フロントエンドにクライアントからの接続を待ち受ける専用のサーバプ
ロセスを作成し、
そのサーバプロセスを介してマッチングサーバプロセスに接続させる。
モノビットエンジンでは、Relayサーバというサーバプロセスを用意して
おり、そちらを介して通信する事が可能。
27

29. ケース１．バトル後のレベルアップ処理や戦利品取得したらDBに書き込みたい
→KVS等を経由してデータを受け渡す。
リアルタイム通信のゲームサーバでユーザーデータを
DBに書き込みを行った際、
既存処理が非同期通信で作成された処理だった場合、
タイミングによってはユーザーデータの不整合が起きてしまう。
それを防ぐおすすめの方法としては、
C＋＋でなくWebサーバ側でDBに書き込みを行う方法。
昨今のトレンドではRedisが良く用いられる。
C++用のRedisクライアントを導入しバトル終了時に Redisにデータを
書き込む。
Webサーバ側で書き込んでデータを参照する。
・C++ Redis Client
https://osdn.jp/projects/sfnet_cpp-redis/
バトルの終了時に、KVSへのデータ書き込みが終了したら
リアルタイム通信サーバからWebサーバに通知する。
その場合、libcurl を用いてHTTP通信でリクエストする。
導入も非常に容易なのでおススメ。
・libcurl
http://curl.haxx.se/libcurl/
■ 1.5. Webサーバとの連携方法は？
28

30. ■ 1.5. Webサーバとの連携方法は？
ケース２．バトルルームの情報をWebサーバから取得したい
→モノビットエンジンのプラグインを利用。
リアルタイム通信ゲームサーバから情報を取得するための
PHPやRubyのプラグインを提供している。
PHPはエクステンション、Rubyの場合は拡張ライブラリの形式。
インストール後、Apacheを再起動するだけで使用可能。
RPCベースでリアルタイムサーバから情報を取得する事が可能。
29

31. ■ 1.6.どこのクラウドがおすすめなの？
■クラウドの選び方
基本的にどこのクラウドを選んでも問題ない。
リージョンの場所次第。
AmazonやNiftyクラウドの場合、
海外にもリージョンがあるので、海外展開を検討しやすいのでは。
■注意点
パブリッククラウドでの運用経験がある方の場合、
Microsoft Azuleは少々毛色が違う。
Webオンリーの構成を取る場合はAzuleはむしろ簡単。
AzuleはグローバルのIPアドレスが基本的に一つとなっており、
グローバルネットワーク的に使い勝手が違うので戸惑うかもしれない。
ただしこれは、
他のOpenStackやVMWareをベースとしたパブリッククラウドと少々違う程度。
■モノビットエンジンでは？
国内大手クラウド全てで稼働実績があります。
Nifty、Amazon、IDCF、Azule
30