年の瀬リアルタイム通信サーバ勉強会

年の瀬！
リアルタイム通信ゲームサーバ
勉強会
代表取締役本城嘉太郎郎
ミドルウェア事業部部⻑⾧長安⽥田京⼈人
2015/12/03

2
■株式会社モノビット
2005年年よりネットワークゲームの開発と運営を⾏行行っているゲ
ーム制作会社です。2013年年よりミドルウェア事業を開始。『
モノビットエンジン』のブランドで、リアルタイム通信エンジ
ンの販売を⾏行行っています。
＜本城嘉太郎郎＞
神⼾戸出⾝身。モノビット社代表取締役。元ゲームプログラマ＆ネッ
トワークエンジニア。CEDECで5年年連続でネットワークゲームの
運営企画やサーバ技術の講演を⾏行行っています。そのうち2講演はト
ップクラスの評価を頂き、翌年年のCEDEC AWARDの選考委員を務
めました。
＜安⽥田京⼈人（Kyoto Yasuda)＞
株式会社モノビットミドルウェア事業部部⻑⾧長。IT系企業でSE
兼PGとして2年年勤務後、6年年間⼤大⼿手デベロッパーでコンシューマ
ーゲームプログラマーとしてアクションゲームを中⼼心に様々な
ジャンルのゲーム開発に携わる。オンラインゲームの知識識を⾝身
に付けるため株式会社モノビットに⼊入社。現在はモノビットエ
ンジンの開発指揮とエヴァンジェリストとしても活動。
・登壇者紹介
■本日の登壇者

■本日の勉強会のアジェンダ
第一部：リアルタイム通信サーバ設計・開発の最新事情
＜登壇者：安田＞
リアルタイム通信サーバに関する最新トレンドや、
設計や負荷テストについてのtipsを実例を交えてお話します。
第二部：リアルタイム通信エンジンの最新事情
＜登壇者：本城＞
リアルタイム通信エンジンについて、
各社製品の特徴の違いや、通信エンジンの選び方をお話しします。
3

4
第一部：リアルタイム通信サーバ設計・開発の
最新事情

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

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

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

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

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

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

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

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

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

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

■結論論
リアルタイム通信サーバのクライアントからの通信の待ち受けポートとし
ては、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
15

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

■ダミークライアントの作り⽅方
バトル中の処理理については、
インゲーム（バトル）の部分にログを仕込んで通常プレイを⾏行行い、
バトル中のログを取得する事で、
ユーザーのバトル中の⾏行行動がある程度度把握できるので、
そのログを元にダミークライアントにバトルの通信をエミュレートした
処理理を実装していく。
17

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

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

■モノビットエンジンのダミークライアント
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ライブラリを配置するディレクト
リ
20

■カスタマイズ⽅方法について
ゲーム中の通信を定義して出⼒力力されたRPCコードを該当箇所にどんどん追加していくだけでOK。
21

■ダミークライアントの起動シェル
ダミークライアントの起動シェル 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 を環境に合わせて修正する。
22

■ダミークライアントの起動シェルオプション
ダミークライアントの起動シェル 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 プロセスを起動する。
23

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

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

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

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

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

安⼼心してください。
終わってませんよ。
29

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

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

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

ケース１．バトル後のレベルアップ処理理や戦利利品取得したら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サーバとの連携方法は？
33

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

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

36
第二部：リアルタイム通信エンジンの最新事情

37
■第二部もくじ
２，リアルタイム通信エンジンの最新事情
リアルタイム通信エンジンについて、
各社製品の特徴の違いや選び方などをお話します。
＜アジェンダ＞
１，Photonとモノビットエンジンの違いについて
２，リアルタイム通信サーバ製品の選び方

38
１，Photonとモノビットエンジンの違いについて

39
モノビットエンジンにお問い合わせを頂くお客様から、
「Photonとモノビットエンジンって、どう違うの？」
といつも質問を頂きますので、
ここでまとめて比較をしてみたいと思います。
■Photonとモノビットエンジンの違いについて

40
質問１：Photonとモノビットエンジンって仲が悪いの？
回答１：とっても仲良しです（棒読み）

41
→嘘です、本当に仲良しです！
実は現場では仲が良く、下北沢で一緒にお酒を飲んだりしています。
（証拠写真）
GMOクラウドの丸山さんは、Photon事業の総責任者をされています。
ゆきえさんは、Photonのマニュアルを英語から日本語へ翻訳されています。
モノビット本城
モノビット高橋
GMOクラウド
丸山さん
（目が座っています）
GMOクラウド
ゆきえさん

42
というわけで、本日のPhotonとモノビットエンジンの比較は、
GMOクラウドさんにも
「どうぞ自由にやってください！」と許可を頂きました！
後で丸山さんに怒られないよう、なるべく中立の視点で比較を
行いたいと思います。

43
まずはPhotonについての概要
＜特徴＞
・ドイツ生まれの通信エンジン
・GMOクラウドさんが販売代理を行っている
・海外でも数多くの実績がある
・もともとゴルフの対戦ゲームを作っていて、
その通信エンジンを抜き出して提供し始めたものが起源（らしい）
・主に、PhotonRealtimeと、PhotonServerという2種類の製品がある
・PhotonRealtimeはクラウドサービスとして利用できる
・PhotonServerはWindowsサーバで動作する
注）PhotonTurnbase、PhotonChatなどの製品もあるようですが、
今回はリアルタイム通信がテーマなので割愛します。

44
次に、モノビットリアルタイム通信エンジンについて
＜特徴＞
・日本生まれの通信エンジン
・国内の有名タイトルで実績がある
・もともと本格的なオンラインゲームを作る目的で、
10年前から研究開発していた社内通信ライブラリを製品化したもの。
・クラウドサービスは行っていない（今のところ）
・主にLinuxサーバで動作

45
■比較の前提
Photonには主に2つのリアルタイム通信製品がある。
→『PhotonRealtime』と、『PhotonServer』
１，PhotonRealtimeについて
・主にクライアント同士の通信をリレーする製品
・マッチング機能とルーム（通信リレー）機能がある
・クラウドサービスとして提供されているため、サーバ立ち上げが不要
・従量課金で、安価に使える
・ただし、サーバにはコードを書くことはできない。
→簡単にマッチングとP2P通信だけができればいい、というニーズに
合った製品。クラウド提供されているので、自分でサーバを立ち上げ
なくても簡単に使える。
→ただし、サーバにゲームロジックを書くことはできないので、
利用シーンはクライアントtoクライアントのみの通信で成立する
ゲームに限定される

46
■比較の前提
２，PhotonServerについて
・サーバにコードを書くことができるサーバ製品
・マッチングやルーム以外に、様々な機能を自分で書くことが出来る。
・クラウドサービスは提供されていない
・カスタマイズ可能
・Windowsサーバのみで動作
→サーバでも処理を行う、本格的なオンラインゲームを作りたい時に使う製品。
クラウド提供はされておらず、自分でサーバを用意しなければならない。
→『PhotonRealtime』と、『PhotonServer』について、
それぞれの製品の特徴がまったく違うので、製品ごとに、
モノビットリアルタイム通信エンジンと比較を行います。

47
■比較の前提
・モノビットリアルタイム通信エンジンについて
モノビットリアルタイム通信エンジンは、PhotonRealtimeのようなクラウドサービ
スを提供していません。（今のところ）
そして、PhotonServerとほとんど同じ特徴を持っています。
１，モノビットリアルタイム通信エンジンの特徴
・サーバでコードを書くことができるサーバ製品
・マッチングやルーム以外に、様々な機能を自分で書くことが出来る。
・クラウドサービスは提供されていない
・カスタマイズ可能
・Linuxサーバで動作

48
■比較の前提
それでは、それぞれ細かく見ていきましょう！
１，『PhotonRealtime』 vs 『モノビットリアルタイム通信エンジン』
→まずはここから！
２，『PhotonServer』 vs 『モノビットリアルタイム通信エンジン』

49
１，PhotonRealtime vs モノビットリアルタイム通信エンジン
項目ごとに比較表を作ってみました！！
それでは、比較内容についてそれぞれ見ていきましょう。
PhotonRealtime モノビットエンジン
同時接続性能 ○ ○
通信速度性能 ○ ○
クラウドサービス ○ ×
導入のしやすさ ◎ △
実績の数 ◎ ○
ライセンス料 ○ ○
運用コスト ○ ○
カスタマイズ × ◎
サポート体制 ○ ○

50
＜同時接続性能＞
PhotonRealtimeは、接続数によって従量制で料金があがっていき、オートスケ
ールする仕組みになっています。よって、接続数による制限や性能劣化はあり
ません（のはず！）
モノビットリアルタイム通信エンジンは、クラウド提供されていませんので、自分
でサーバの台数を増やすことで、いくらでもスケールが可能です。
＜通信速度性能＞
両製品とも、RTTは十数ms〜数十ms以内と、ほとんど同じ性能です。
→上記2点においては、どちらを選んでもそれほど大きな差はありません。

51
＜クラウドサービス＞
PhotonRealtimeは、機能をリレーとマッチングに限定する代わりに、クラウドサ
ービスとして提供しています。
モノビットエンジンは、サーバにコードが自由に書けるため、サーバ負荷が予想
できないため、クラウド提供を行っていません。(PhotonServerと同じ）
＜導入のしやすさ＞
PhotonRealtimeは、クラウド提供されているため、ID登録するだけで、簡単に通
信のテストが行え、そのまま本番サーバとしても利用できます。
モノビットエンジンは、自分でサーバを立ち上げる必要があります。
（PC上でテストするだけなら、VMWareのイメージを配布しているので、簡単にテ
ストは可能です）

52
＜実績の数＞
PhotonRealtime（およびPUN）の実績に
ついて、海外も含め合計で39タイトルが
PhotonのHPにて公表されています。
(PhotonのHPより→）
モノビットリアルタイム通信エンジンの採用実績は、
現在6タイトルで、すべて国内タイトルです。
（モノビットエンジンHPより→）

53
＜ライセンス料＞
＜運用コスト＞
PhotonRealtimeは、同時接続が1000人
までで、月額33,766円だそうで、それ
以上の同時接続については、
お問い合わせ下さいとのことです。
モノビットエンジンは、サーバ1台あたり月額3万円です（ライセンスのみ）。
ただし、同時接続数に制限はありません。1サーバあたり同時接続数3000は
捌けますので、同時接続が2000を超えるなら、サーバ代込みでも、こちらの方
が安くなる可能性はあります。
同接1000以下なら、PhotonRealtimeの方が安価です。

54
＜カスタマイズ＞
PhotonRealtimeは、
・ルーム（※ゲームのこと）作成
・ルーム検索（マッチング）
・ルーム内でのクライアント同士のリアルタイム通信
の3つの機能が提供されているのみで、これ以外のことは出来ません。
しかし、サーバロジックを利用しない、P2P型のゲームでは、上記3つの機能で
必要十分というケースも多くあり、必ずしも悪いという訳ではありません。
モノビットエンジンの場合は、マッチングサーバやルームサーバのサンプルが
ソースコードごと提供されているため、自由に処理をカスタマイズすることがで
きます（サーバにゲームロジックを書くことができます）。

55
＜補足＞
サーバにロジックを書けなくて困るシーンとは？
コンシューマゲームによくある対戦機能のように、ワンボタンで簡単にマッチン
グして、対戦が終わったらオフラインモードに戻ってくる、というゲームであれば
、PhotonRealtimeで提供されている機能で十分です。
しかし、たとえばファンタシーアースZEROのマップ画面
のような、対戦中の戦局や、各ルームに入っている人数
をリアルタイムに表示する画面を作りたい場合は、
PhotonRealtimeでは対応できず、モノビットリアルタイム
通信エンジンか、PhotonServerを利用して、独自の
サーバロジックを記述する必要があります。
これ以外でも、複数ルームをまとめて管理したい場合や、サーバ側でルームの
戦局や戦績を管理する必要がある場合も、PhotonRealtimeでは対応できませ
ん。

56
＜サポート体制＞
PhotonRealtimeは機能も限定されており、
ドキュメントも日本語化されているため、
困ることはあまりなさそうです。
もし困っても、GMOクラウドのサポートスタッフが
すぐに対応してくれる（はずです！）
モノビットリアルタイム通信エンジンの場合は、
サポートスタッフだけでなく、エンジン開発技術者も日本にいるため、
質問に対しての1営業日以内の返答保証を行っています。
（ただし利用申し込みか、サポート契約をされている方のみとなります）

57
＜まとめ＞
１，PhotonRealtimeは、
導入の敷居の低さや、
クラウド提供の利便性が
最大の利点
２，提供されている機能のみ
でゲームが作れるなら、
PhotonRealtimeを
そのまま使うのが
一番早い。
３，ただし、サーバ側の
カスタマイズができないので、
実現できない仕様があった場合は、
モノビットエンジンかPhotonServerを検討する必要がある。

58
１，『PhotonRealtime』 vs 『モノビットリアルタイム通信エンジン』
２，『PhotonServer』 vs 『モノビットリアルタイム通信エンジン』
→次はこちら！PhotonServerと比較してみます。

59
１，PhotonServer vs モノビットリアルタイム通信エンジン
またまた項目ごとに比較表を作ってみました！！
それでは、比較内容についてそれぞれ見ていきましょう。
PhotonServer モノビットエンジン
クラウドサービス × ×
導入のしやすさ △ △
ライセンス料 ○ ◎
開発環境 VisualStudio gcc
使いやすさ ◎ △
カスタマイズ ○ ○
運用コスト △ ◎
サポート体制 ○ ◎
開発依頼ー可能

60
＜同時接続性能＞
＜通信速度性能＞
1プロセスにおける同時接続性能は最大3000〜4000くらい
（サーバ性能に依存）、
RTTは十数ms〜数十ms以内と、ほとんど変わりません。
＜クラウドサービス＞
＜導入のしやすさ＞
どちらもクラウドサービス(SaaS)は行っておらず、オンプレミス環境（もしくはお
客様が用意したクラウド上のサーバ）にインストールする前提の製品となります。

61
PhotonServer、
モノビットエンジンともに、
ほとんど同じ料金体系です。
月額と、買い切りの2種類の
ライセンスがあります。
PhotonServerは右図の通り。
（PhotonServerのHPより料金表を抜粋→）
＜要点＞
・1サーバ月額約3万円
・1サーバ買い切り約60万円
・使い放題約33万円/月

62
モノビットリアルタイム通信
エンジンは右図の通り。
（モノビットエンジンのHPより料金表を抜粋→）
＜要点＞
・1サーバ月額約3万円
・1サーバ買い切り約60万円
・使い放題約26万円/月
使い放題の場合、モノビットリアルタイム通信エンジンの方が約7万円/月ほど
お安くなっています。Photonさんと同じ値段にしたはずなんですが...円安で値上
がった？勘違いかも知れませんが、結果的にモノビットエンジンの方が
約25％も安くなってしまいました…
また、ほとんどのお客様が「大規模向けライセンス」を選択されています。

63
＜実績の数＞
PhotonServerのHPには、国内外合わせて21タイトルの実績が掲載されていま
す。
(PhotonServerのHPより→）
モノビットリアルタイム通信エンジンの実績は現在6タイトルで、すべて国内タイ
トルです。
（モノビットエンジンのHPより→）

64
最近の『PhotonServer』採用タイトル
最近の『モノビットリアルタイム通信エンジン』採用タイトル
両エンジンとも、続々と最新タイトルに採用されています。

65
＜開発環境＞
PhotonServerはWindowsサーバで動作するため、開発環境はVisualStudioを利
用します。（使用言語は主にC＃）
モノビットエンジンはLinuxサーバで動作するため、gccやemacs、eclipseなどの
OSS系の開発環境を利用します。（使用言語は主にC++で、C#も利用可能）

66
＜使いやすさ＞
PhotonServerは、Windowsサーバ上の.Net Frameworkで動作するため、C#を自
在に利用することができます。
また、TCPとUDPをシームレスに利用することが出来ます。
モノビットエンジンは、LinuxサーバでC++言語でTCP通信を利用する前提で開発
されました。その後、C#対応とUDP対応を後付けで行ったため、C#を使ったり、
UDP通信を使う場合に、サーバ設計が若干いびつになってしまう欠点があります
。（しかし、何か実現できない機能がある、という訳ではありません）
こちらは来年前半中にPhotonと同じくらい使いやすく改善する予定です。

67
＜カスタマイズ＞
PhotonServer、モノビットエンジンともに、本格的なオンラインゲームを開発する
ためのロビーやルーム、マッチング、ロードバランシングのサンプルなどが、ソースコ
ードごと提供されており、サーバのゲームロジックを自由に記述することが出来ま
す。
モノビットエンジンの場合は、VertialNetwork機能や、リレーサーバなども提供され
ます。PhotonServerでも同様の機能が提供されている可能性がありますが、両エ
ンジンとも、本格的なオンラインゲームの実績があるため、機能的に大きな差は
ないと思われます。
このあたりは今度Photonさんと一緒に掘り下げてみたいところです。

68
＜運用コスト＞
PhotonServerはWindowsサーバを利用する必要があるため、OSのライセンス費用がかかってきます。
モノビットエンジンはLinuxサーバで動作するため、OSのライセンス費用がかかりません。
１，AmazonEC2 東京リージョンのオンデマンドインスタンス価格で比較すると...
c4.large（2コア）の場合、Linuxは$0.14 /1 時間、Windowsは$0.24 /1 時間となり、インフラコストは1.7倍。
２，AmazonEC2 バージニア北部リージョンのオンデマンドインスタンス価格で比較すると...
m4.4xlarge（16コア）の場合、Linuxは$1.008 /1 時間、Windowsは$2.016 /1 時間となり、インフラコストは2倍。
AWSの場合、LinuxとWindowsのコスト差は、最小1.3倍から最大2倍になりました。
Azureでも、1コアの場合は同価格になるものの、8コア以上だとやはり約1.5倍ほどの差になります。
Linuxサーバの方が、インフラコスト的には圧倒的な優位性があります。

69
＜サポート体制＞
PhotonServerの場合、GMOクラウドの方が大変頑張って
サポートしてくれます！
技術的な質問も、開発元のドイツ本国に問い合わせてくれるようです。
モノビットエンジンは、エンジン本体も日本で開発を行っているため、
日本人のサポートスタッフが1営業日以内の返答を保証しています。
（ただし、利用申し込みをされた方か、サポート契約をされている方のみ）
※無料利用中の方は、facebookのモノビットエンジン助け合い助でサポートしています。
また、緊急の問題が発生した際に、エンジンの開発エンジニアが
お客様のオフィスに伺ってサポートを行うこともやっています。

70
＜モノビットエンジンのオンサイトサポートの実例＞
（お客様）
リリース後、リアルタイム通信を行っているサーバの負荷が
どうしても下がらないので、なんとか見てくれないか？
→緊急対応が必要な依頼だったため、モノビット社のエンジニアが
2週間にわたって先方オフィスへ常駐し、ゲームアプリ側の
プログラムも含めてデバッグと負荷対策を実施。
バグを取り除きつつ、エンジン本体内にもチューニングを施して、
高負荷問題を解決。

71
＜開発依頼＞
エンジンの機能とは関係ありませんが、モノビットには、ミドルウェア部門以外にも、ゲーム制作部門が
あり、数十名のエンジニアが在籍し、実際に自分たちでもリアルタイム通信を用いたゲームを開発して
います。
そのため、ただ単にエンジンを提供するだけでなく、
・リアルタイム通信エンジンに、こんな機能を追加してほしい
・リアルタイム通信サーバの設計開発の一部を手伝って欲しい。
などのニーズにも答えることが出来ます。
例１）チャットサーバに監視機能を追加して欲しい。
→開発案件として、チャットサーバ用GMツールを開発、納品しました。
例２）Webサーバとリアルタイム通信の連携プラグインを開発してほしい
→開発案件として、プラグインを開発、納品しました。
例３）リアルタイム通信サーバの詳細設計をすべて依頼したい
→開発案件として、通信サーバの詳細設計を行い、納品しました。

72
＜まとめ＞
■モノビットエンジンを選ぶ理由
１，Linuxサーバを使いたい
２，ライセンス料やインフラコストを抑えたい
３，日本人開発者による即日＆オンサイトの
サポートを受けられる安心感
４，サーバの設計や開発を発注したい
■PhotonServerを選ぶ理由
１，Windowsサーバを使いたい
２，VisualStudioでサーバを開発したい
３，実績が多いソリューションを使いたい
そのほか、実際に使ってみたり、担当者の話を聞いてみて、
気に入った方を選択されるのが良いかと思います。

73
■次回について
実は、今回のPhotonとモノビットエンジンの比較について、
GMOクラウドさんに「一緒にやりましょう！」とお声がけしたのですが、
「たまたま翌週にコロプラさんと勉強会やる予定なので、準備がちょっと...」
という理由で、残念ながら断られてしまいました。
ただ、「来年の春頃にはぜひ！」と話をしています。次回はPhotonさんと合同で
もう一歩踏み込んだ「リアルタイムサーバ勉強会」を開催したいと思っていますの
で、どうぞ楽しみにしていてください！
Photonさんも、来週コロプラさんと一緒に
サーバ勉強会を開催されるそうなので、
興味のある方は是非！→
（しかし既に満席のようです…）

74
＜おわび(T-T)＞
ATNDで下記のアジェンダを告知していましたが、
Photonとモノビットエンジンの比較だけで大ボリュームになってしまっ
たのと、下記アジェンダだけでも1時間くらい語れるボリュームになっ
てしまったので、今回は割愛して、後日それぞれ勉強会を開催させ
ていただきます。
・Unity、UnrealEngineなどのゲームエンジンと通信エンジンの組み
合わせ方
・自社でオリジナルの通信エンジンを作ってみる？
・通信エンジン界隈の今後の予想図
期待されていた方、大変申し訳ございませんでした… osz
■ 最後に

75
＜アンケートのお願い＞
よろしければ、次回の勉強会をより良くするため、
アンケートに答えて頂けると嬉しいです！
また、モノビットエンジンの話を個人的に詳しく聞きたい方は、
お名刺を席に置いていって頂くか、アンケートに連絡先を
ご記入ください。
後日、こちらよりご連絡させて頂きます。
本日はどうもありがとうございました！！
■ 最後に（その２）

年の瀬リアルタイム通信サーバ勉強会

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 年の瀬リアルタイム通信サーバ勉強会

Similar to 年の瀬リアルタイム通信サーバ勉強会 (20)

More from モノビットエンジン

More from モノビットエンジン (15)