新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！2017年10月27日モノビットエンジン勉強会
•
2 likes•9,580 views
2017年に完全新作、超高性能に生まれ変わったモノビットエンジンの製品群を用いて、10万人規模の大規模同時接続を行うMO型、MOBA型、MMORPGなどのネットワークゲームについて、どのようにプログラムとサーバを構築し、安全に運用することが出来るようになったのか、実際にコーディング実例やサーバ構成図、運用管理画面を表示しつつ、ご説明いたしました。 また、「ネットワークゲームにおける TCPとUDPの使い分け」と称して中嶋謙互がTCP/UDPの性能を実際の計測値をもとに徹底比較しつつ、解説しました。 なお、今回はCEDEC2017に公開したセッションに加えて、これまでに頂いたご質問とその回答などを交えてお届けいたしました！
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to 新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！2017年10月27日モノビットエンジン勉強会
Similar to 新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！2017年10月27日モノビットエンジン勉強会 (20)
More from モノビット エンジン
More from モノビット エンジン (10)
Recently uploaded
Recently uploaded (14)
新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！2017年10月27日モノビットエンジン勉強会
- 3. スマホ/家庭用ゲームやVRコンテンツで、マルチプレイを簡単に実現できる、リアルタイム通信ミド ルウェアです。主に３つの製品ラインナップで展開しています。2017年にVer2.0に進化しました！ １，Monobit Revolution Server （略称：MRS） MMORPGや、多人数MOアクションゲームにも対応出来 る処理速度とレスポンスを追求した、高速ゲームサーバ です。シンプルなAPIで超高速通信かつ大規模同時接 続を実現します。 ■モノビットエンジンVer2.0シリーズとは？ ２，Monobit Unity Networking 2.0 (略称：MUN2.0) Unityに特化した通信ミドルウェアです。マッチング、ルー ム、通信リレーの機能が標準で用意されており、ネットワ ークの知識がなくてもマルチプレイを実装可能。RMSと連 携して、サーバにもC++/C#でコードが書けるように進化 しました。 ３，VR Voice Chat 2.0 Unityで簡単にボイスチャットを実現することができるUnity プラグインです。2.0になってレスポンス速度上昇！
- 4. - 3 - MRS(Monobit Revolution Server)のご紹介
- 5. ■ MRS(Monobit Revolution Server)とは これまでにない大規模オンラインゲーム開発が可能 低遅延が要求されるアクションゲームやVRなど リアルタイム通信コンテンツの開発に最適 - 4 -
- 6. ■ MRS(Monobit Revolution Server)の特徴 ●低遅延・高効率でのリアルタイム通信制御 - 通信シーケンスや内部プロセス、利用者に提供するAPI等を刷新 - リアルタイム通信機能として、より速く、よりシンプルな設計を実現 従来リリースしていた「リアルタイム通信エンジン」をゼロから見直して作成 ●TCP, UDP, WebSocket の通信プロトコルの利用 - ネットワーク高速化とサーバ側CPU負荷軽減を実現 - 1CPUあたり最大20,000クライアントの同時接続を実現 TCP 接続は従来の「リアルタイム通信エンジン」を大幅に強化 UDP 接続プロトコルのサポート - リアルタイム性の求められるデータの送受信に最適なUDP/RUDPを使用可能 WebSocket 接続プロトコルのサポート(ver.1.1.0 以降) - PhantomJS(http://phantomjs.org/)を利用した自動テストが可能 高速処理によるインフラコストの大幅低減を実現 - 5 -
- 7. ■ MRS(Monobit Revolution Server)の特徴 ●多種多様なプラットフォームに対応 ●ゲームエンジン、開発言語を多数サポート C/C++ JavaC# Java Script 家庭用ゲーム機やマルチプラットフォームも対応 PHP, Ruby Windows/VisualStudioでサーバ開発が可能に！ - 6 -
- 8. ■ MRS(Monobit Revolution Server)の特徴 ●堅牢な暗号化によりチート対策も万全 ・ 送信レコード単位で、暗号処理の適用可否を設定可能 - 暗号処理はCPU負荷を掛けやすい - 秘匿性が低い送信レコードには暗号処理させないなどの施策により 全体的なスループット向上が見込まれる ・ 暗号方式について - 暗号鍵方式には AES128 を採用 - 暗号鍵の交換方式には EDCH(楕円曲線ディフィー・ヘルマン) 鍵共有アルゴリズムを採用 ●拡張ライブラリによる機能の拡張が可能 ルームサーバの機能や、ゲームマッチング、チャットなどは 『MRS_ROOM』 や 『MUN』 などで実現可能 ルーム作成 マッチング チャット MRS_ROOM MUN 転送レコードごとの暗号化 - 7 -
- 9. ■ MRS(Monobit Revolution Server)の特徴 - mackerel_agent をインストールするだけで問題なく監視可能 - システムメトリック ロードアベレージ, CPU, メモリ, ディスクアクセス, ネットワーク帯域, ストレージ使用状況の監視 - カスタムメトリック 各サーバプロセスごとのモニタリング, 同時利用者数（CCU）の監視など ●直感型サーバ監視ツール 『Mackerel』 に対応 MRS の対応内容 Mackerelとは - サーバプロセスの監視状況をリアルタイムにグラフ化 - モニタリングはもちろん、ブラウザ対応UIやAPIが豊富 高機能な監視ツールにより運用をサポート - 8 -
- 10. ■ MRS(Monobit Revolution Server)の特徴 ●低遅延・高効率化のNiftyCloudでの実証実験 ・ TCP による最高性能試験の結果、 毎秒約540,000レコードのECHO送受信を実現させることが可能 ※ MRS_bench 計測結果（1秒間隔の計測ログ、暗号化なし） loop:試行数 s:総送信バイト数 r:総受信バイト数(総受信レコード数) c:接続数 d:切断数 e:エラー検知数 loop:1 s:0 r:0(0) c:0 d:0 e:0 loop:1302 s:940160 r:46678(32104) c:40 d:0 e:0 loop:2576 s:4679800 r:366276(143363) c:117 d:0 e:0 loop:3222 s:8596640 r:1443319(340764) c:193 d:0 e:0 loop:3627 s:12284680 r:3220253(495575) c:266 d:0 e:0 loop:3939 s:15922640 r:5375457(551009) c:300 d:0 e:0 loop:4240 s:19534640 r:7557718(543762) c:300 d:0 e:0 ・ UDP による最高性能試験の結果、 毎秒約350,000レコードのECHO送受信を実現させることが可能 ※ MRS_bench 計測結果（1秒間隔の計測ログ、暗号化なし） loop:試行数 s:総送信バイト数 r:総受信バイト数(総受信レコード数) c:接続数 d:切断数 e:エラー検知数 loop:1 s:0 r:0(0) c:0 d:0 e:0 loop:698 s:133020 r:132220(132220) c:20 d:0 e:400 loop:1624 s:770060 r:768440(346380) c:40 d:0 e:920 loop:2491 s:1463660 r:1461980(344720) c:40 d:0 e:920 loop:3373 s:2169260 r:2167640(353580) c:40 d:0 e:920 loop:4255 s:2874860 r:2873220(353560) c:40 d:0 e:920 - Server : Nifty-Cloud e-large8(¥37/h) x1 Intel Xeon 4Core CPU(E5-2697) 2.60GHz / 8GB RAM - Client : VMware 上の 仮想 Linux PC ※ MRS ver.1.0.0 リリース版での検証 ※ 計測ツールは弊社内製のベンチマークツール 『MRS_bench』 によるもの - 9 -
- 11. ・機能比較(MRS vs 従来品) 機能 新MRS 旧エンジン 対応プロトコル TCP/UDP/RUDP/WebSocket TCP 外部API設計 C言語風（シンプル化） C++風 遅延 マイクロ秒 ミリ秒 CPUスレッドあたりスループット 300同時接続時 毎秒54万レコード 300同時接続時 毎秒数万レコード クライアント開発言語 C++,C# C++,C# サーバ開発言語 C++,C# C++ サーバOS Linux,Windows,MacOSX Linux 10 ■ MRS(Monobit Revolution Server)の特徴
- 12. 対応 プラットフォーム ■ MRS(Monobit Revolution Server)の展望 ●MRSの今後の開発ロードマップとリリース予定 通信方式 実装方法 現行リリース 2017年8月 2017年9月 2017年10月 2017年冬 Linux Windows MacOSX Android iOS Unity Client/Server 通信方式 TCP/UDP/RUDP プロトコル WebSocket CのAPIを利用 通信結果を コールバック処理 他言語はバイン ディングで対応 Cocos2d-x Unity+WebGL UnrealEngine 4 P2P通信方式 コールバック処理 のRPC化 RPCスタブコードの ジェネレータを リリース - 11 -
- 13. MUN (Monobit Unity Networking)のご紹介 - 12 -
- 14. ■ MUN(Monobit Unity Networking)とは クライアントのみでも実装できる、Unity特化型の通信エンジン マルチプレイを簡単に実装できるアセットです - 13 - ●対応バージョン Unity4.x ： 4.3.4 以降の Pro 版に対応 Unity5.x ： Personal / Pro 両対応 Unity2017.x ： 対応中
- 15. ■ MUN(Monobit Unity Networking)の特徴 - サーバ接続/切断、オフラインモード - ロビーやルームに対する入室/退室制御、ロビーとルームの状態取得 - プレイヤー情報の取得（サーバ内検索, プレイヤーパラメータの設定と取得） - RPCによる、任意のクライアントに対する情報送信および受信 - シーン内オブジェクトの位置・姿勢・アニメーション等の同期 - 各種条件に応じた、マッチメイキング制御 - ノンプログラミング通信制御 etc... ※すべて単一のコンポーネントやAPIで実装可能 MUN で実装できる機能の一部 - 14 - ※各種家庭用ゲーム機はNDA締結により利用可能になります ●多彩な機能が多様なプラットフォームで利用可能 利用可能なプラットフォーム
- 16. ■ MUN(Monobit Unity Networking)の特徴 ●すべての通信ロジックを、クライアント側オンリーで実装可能 MUN リリース当初からの設計思想を実現 - 15 - - 『サーバサイドの構築なしでリアルタイム通信を実現したい』 というご要望に対応 - 通信ロジックも含め、 オンラインゲームのすべての制御をクライアント側でコーディング可能！ ※MUNサーバはbroadcastでリレー配信する役割を果たします - クライアントコードをそのままサーバに移植して、簡単にチート対策！ - MUN標準機能のサーバのソースコードを公開中。VisualStudioでカスタマイズ可能。 ●必要に応じて、サーバにコードを書くことも可能！ MUN2.0より、MRSと連携してC++/C#言語でサーバ開発が可能になりました！ サーバとクライアントでコードを自在に配置可能
- 17. ■ MUN(Monobit Unity Networking)の特徴 - MUNサーバ側は、TCP/UDPの通信ポート双方で待ち受けしている - 同一認証のMUNクライアントであれば、TCPの接続クライアントと UDPの接続クライアントを同一ルームに接続させることも可能 ●TCP, UDPの通信プロトコルの利用 MRSに基づき、TCP/UDPの通信プロトコルをサポート MUNにおける UDP/RUDP接続プロトコルについて - 16 - - MUNの内部処理で行われる送受信（ロビー/ルームの入退室など）の 通信をUDPで行なう場合、すべて RUDP で伝送される - RPC（リモートプロシージャコール）、およびオブジェクト同期通信のみ UDP/RUDP の個別設定が可能 速度を重視するか信頼性を重視するか、 場面によって最適な通信プロトコルを選択可能
- 18. ■ MUN(Monobit Unity Networking)の特徴 - クライアントサイドの改ざんに伴う、チートの横行を防ぐ術がほとんどない すべてのソースコードがクライアントに含まれるため - ホストの優位性が圧倒的に高い ノンプレイヤーの通信データについて、ホストは即時実行するが 他クライアントはホストからの通信を待たねばならないため - ゲーム進行が、ホストの性能に依存する ●オンプレミス版MUNサーバを用いたサーバサイド実装にも対応 - 17 - クライアント側オンリーでの実装における『問題点』 サーバサイド実装にすることの『メリット』 - サーバサイドに実装することにより、クライアント改ざんの隙を与えない ほとんどの処理はサーバ依存にし、クライアントはビューアとして機能させる - すべてのクライアントに対し、『平等なサービス』を提供できる ホストも他のクライアントで実行タイミングを完全に一致させることができる
- 19. 機能 MUN2.0 MUN1.0 プロトコル TCP/UDP/RUDP TCP サーバ開発 可能（C++/C#） 不可 自動スケール機能 新製品MRSクラスタ リリース予定 なし 負荷試験自動化ツール ○ ☓ カスタム認証機能 ○ ☓ 汎用ルームサーバー ○ ○ マッチメイキング ○ ○ プレイヤー検索 ○ ○ ルーム作成・入退室制御 ○ ○ ルーム名・人数取得 ○ ○ RPC同期通信 ○ ○ 再接続処理 ○ ○ 18 ■ MUN(Monobit Unity Networking)の特徴 ●従来製品との機能比較（MUN2.0 vs MUN）
- 20. 対応 プラットフォーム ■ MUN(Monobit Unity Networking)の展望 ●MUNの今後の開発ロードマップとリリース予定 クライアント プログラム サーバ プログラム 2017年8月 2017年9月 2017年10月 2017年秋 2017年冬 送受信制限機能 の実装 シーケンス 最適化 内部データベース 再構築 差分データ 送信制御 Unity+WebGL NET CORE対応 - 19 - 大量RPC送受信時 の処理負荷軽減
- 21. VR VoiceChat with MUN のご紹介 - 20 -
- 22. ■ VR VoiceChat with MUN とは MUNをベースに動作する『ボイスチャットエンジン』 コンポーネントを追加するだけで簡単に実装が可能！ 無音検知、マルチキャスト配信、遅延音声カット機能を搭載！ - 21 -
- 23. ■ VR VoiceChat with MUN の特徴 VoiceChat with MUN の機能を実装するには、Unityのオブジェクトに 『MonobitVoice』のコンポーネントを追加します ●コンポーネントを追加するだけで簡単に実装が可能 - 22 - 上記コンポーネントを追加した状態で、MUNによる通信同期を行なう シーンファイル上で動かすだけで、ボイスチャットが簡単に実現できます 簡単な手順でボイスチャットを実装可能
- 24. ■ VR VoiceChat with MUN の特徴 - キーボードのタイピング音や、周囲の環境騒音の同時伝送を防ぎます - 『一定量以下のdb値の音声を送信しないようにする』 という シンプルなソフトウェアノイズキャンセリングを実装しています - 無音検知機能によりデータ転送量を減らします 無音検知閾値を調整することで無音検知機能を無効化することも可能です ●無音検知機能（ノイズキャンセラ）を搭載 会話時の雑音などのノイズを除去し、クリーンな音声だけを送信 ハウリングを防止 - 特にスマートフォン端末など、スピーカー出力部とマイク入力部が 近い位置にあるデバイスで有効です - 23 -
- 25. ■ VR VoiceChat with MUN の特徴 - 例えば 『FPSのチーム戦』 などにおいて、 『戦闘前のブリーフィング中にはチーム関係なく全員と会話させたい』 『戦闘中は自分のチームだけで会話させ、相手に音声を伝えたくない』 という、条件付きのボイスチャット配信設定を行なう機能です ●マルチキャスト配信機能を搭載 ルーム内の特定プレイヤーに対して、自身の音声の送信可否を設定可能 - 24 - マルチキャスト配信機能のメリット - ゲームデザインに応じたボイスチャットの拡張性を高めます - 『特定プレイヤーとの会話』 によって、音声ストリーム情報による トラフィックの総量を抑えることができます ※マルチキャスト配信機能の設定にはAPIを使用する必要があります 全員に声が届く 仲間にだけ 声が届く 聞こえない
- 26. ■ VR VoiceChat with MUN の特徴 - 『相手の音声が数ミリ秒～数秒遅れて再生』 されるような 再生遅延の状態が著しく悪い状態のときに 『再生待ちレコード』 を削除し、 よりリアルタイムな音声を受信側で再生させる機能です ●遅延音声のカット機能を搭載 受信側の再生遅延が著しい場合に、再生の早回しを行なう機能 『ぶつ切り感』 をほとんど感じない音声遅延カット - 『音声のぶつ切り』 がイメージとして浮かぶかもしれませんが、 音声として聞き取れる僅かな時間をカットするだけなので、 ぶつ切り感をほとんど感じることはありません - 数ミリ秒単位で音声再生を補完することにより、送信側の音声をより瞬時に 受信側で再生できる 『リアルタイムさ』 を実感できます - コンポーネントの設定から 『遅延音声のカット機能』 を無効にすることもできます - 25 - 生の音声データを取り出して、ボイスチェンジャーも実装可能です
- 27. ■ VR VoiceChat with MUN の展望 - 26 - ●今後の開発ロードマップとリリース予定 ボイスチャット 専用サーバ P2P対応 未定2017年秋 2017年冬 ノンサーバによる ボイスチャットの実装 サーバミキシング機能の実装独立サーバでの運用
- 30. 29 ■ MRSゲームサーバ構成例 MRSサーバにおける最小構成 ・ mrs_room : MRSで提供している最小構成のルーム管理サーバ。 ルーム入退室制御と、ルーム内外でのデータ送信を可能にする。 Global Section Private Section MRS Server Machine MRS Server Process MRS Server mrs_room mrs_room がルームの管理、ルーム内外のデータ送信を 一括制御 Internet ・・・ MRS Client MRS Client ・・・ MRS Client Machine MRS Client Process MRS Client MRS Client MRS Client MRS Client MRS Client MRS Client MRS Client MRS Client mrs_room MRS Server mrs_room ・・・mrs_room ・・・ MRS Server mrs_room mrs_room ・・・ MRS Server mrs_room mrs_room ・・・ CネイティブのAPIを用意 言語バインディングで多言語対応 Frontend MRS Room Servers
- 31. 30 ■ MRSゲームサーバ構成例 特徴 ・リアルタイム処理を必要とされる部分について、簡単なデータ送受信とルーム管理機能を提供 ・簡単な通信対戦、小規模ネットワークゲームであれば実装可能 ・サーバ、クライアントともにCネイティブのAPIを用意しており、言語バインディングにより、多種多様な プログラミング言語に対応可能（弊社サンプルでは C, C++, C#, Java, JavaScript, PHP を用意） ・ルームを跨いだ通信ができないので注意が必要 リアルタイムサーバ間、サーバ⇔クライアントとの接続 ・TCP/UDP/WebSocketによるソケット接続が可能で、完全同期通信を実現。 なぜAPIがCネイティブである必要があるのか ・リアルタイム通信を行うゲームでは、サーバサイドで多くの処理を行う必要があるので、サーバプログラムの 実行速度が大変重要 ・そのため、例えWebブラウザで動かすようなゲームであっても、Web言語よりも数十倍の実行効率を持つ C++言語でサーバー側の処理を記述する事により、素早い通信を実現し、なおかつサーバー台数を大幅に 削減可能 ・かつ、C++言語で書かれたライブラリをCネイティブのAPIとしてWrapすることで、より多くの言語バイン ディングに対応することを可能にしている
- 32. 31 ■ MRSゲームサーバのコーディング例 簡単な送受信サンプルの実装例 ・MRSのコードは至ってシンプルで、簡単なECHO送受信のコードをCで記述すると以下のように書けます。 クライアント側 サーバ側 #include <mrs.hpp> bool g_Run = true; // ループフラグ // 接続後処理 void onConnect( MrsConnection _con, void* _data ) { // ECHO 送信 mrs_write_record( _con, MRS_RECORD_OPTION_NONE, 0x01, “Hello, MRS!”, strlen(“Hello, MRS!”) + 1 ); } // ECHO受信後処理 void onRead( MrsConnection _con, void* _data, uint32 _seq, int16 _option, uint16 _type, const void* _payload, uint32 _len ) { // 受信結果表示 printf(“data=%s, datalen=%d”, (const char *)_payload, _len); // ループ終了 g_Run = false; } //メイン処理 int main() { // 初期化 mrs_initialize(); // 接続処理 MrsConnection client = mrs_connect(MRS_CONNECTION_TYPE_TCP, “192.168.1.253”, 3456, 10000 ); // コールバック設定 mrs_set_connect_callback( client, OnConnect ); mrs_set_read_record_callback( client, OnRead ); // ループ処理 while(g_Run) { mrs_update(); mrs_sleep(1); } // 終了処理 mrs_close(client); mrs_finalize(); return 0; } #include <mrs.hpp> // 接続後処理 void onConnect( MrsServer _server, void* _data, MrsConnection _client ) { // コールバック設定 mrs_set_read_record_callback( _client, OnRead ); } // ECHO受信後処理 void onRead( MrsConnection _con, void* _data, uint32 _seq, int16 _option, uint16 _type, const void* _payload, uint32 _len ) { // ECHO返信 mrs_write_record( _con, _option, _type, _payload, _len); } //メイン処理 int main() { // 初期化 mrs_initialize(); // リスニング開始処理 MrsConnection server = mrs_server_create(MRS_CONNECTION_TYPE_TCP, “192.168.1.253”, 3456, 2000 ); // コールバック設定 mrs_set_new_connection_callback( server, OnConnect ); // ループ処理 while(true) { mrs_update(); mrs_sleep(1); } // 終了処理 mrs_close(server); mrs_finalize(); return 0; }
- 33. 32 ■ 10万人規模のサーバ構成 まず性能分析から ・サーバプロセス１つにつき、MRS単体で以下のレコード処理性能（ECHO送受信性能）を持ちます TCP では 54万レコード/秒 （約60Mbps） UDP では 35万レコード/秒 （約22.4Mbps） ・原則として、上記を基準にプロセス内の処理性能を考慮してサーバ構成を検討すれば問題ありません。 耐用しうる同時接続数について ・接続数の限界は、理論上「2の64乗」までは可能です。 ・上記の通信処理性能と合わせて考えれば、例えばMMOなど「同時接続10万接続」が要求される場合でも 余裕で捌けます。 ・なお、公式の無料頒布版では「同時接続者数制限 100CCU まで」の制約がありますが、弊社との契約により この上限を段階的に開放することができますので、別途ご相談ください。
- 34. 33 ■ 10万人規模のサーバ構成 サーバインスタンスの役割構成を設定する場合 ・MRS自体はサーバ構成情報を持っていないため、別途データベースサーバなどを設けて、サーバの役割構成の 情報を付与する必要があります。 ・付与されたインスタンス情報はWebサーバ（mrs_pusher）を介してクライアントに通知します。 ・手順は以下の通りです 1. あらかじめKVSやデータベース等のデータストアに接続サーバのアドレス情報を退避しておく 2. MRS クライアントから「最初に接続するサーバ」のアドレス情報を、下図 a → b → c の順に取得 3. 取得した情報により、「最初に接続するサーバ」との情報の送受信（下図 d） 4. MRS クライアントから「次に接続するサーバ」 のアドレス情報を、下図 a → b → c の順に取得 5. 取得した情報により、「次に接続するサーバ」との情報の送受信（下図 e） Web Server mrs_pusher Database database First Server mrs_room Second Server mrs_room MRS Client MRS Client a c d e b
- 35. 34 ■ 10万人規模のサーバ構成 サーバインスタンスの役割構成の実装例 ・MRSクライアントから、一般的なゲームサーバのサービス（ロビーサーバ, マッチングサーバ, バトルサーバ） などに接続する場合の構成例は以下の通りです。
- 36. 35 ■ 最小限のMUNゲームサーバ構成例 MUNサーバにおける最小構成 ・ mun_resolver : 接続する mun_proxy への接続アドレス通知 ・ mun_proxy : ルーム外における一連の通信制御（ルーム入退室, ルーム/プレイヤー検索, etc...） ・ mun_room : ルーム内における一連の通信制御（RPC, オブジェクト同期, etc...) ・ mun_master : mun_proxy, mun_room の情報を統制管理する、オンメモリ上のデータベース制御
- 37. 36 ■ 最小限のMUNゲームサーバ構成例 特徴 ・リアルタイム処理を必要とされる部分について、マッチング処理からゲームシーンの完全同期までを提供 簡単な小規模ネットワークゲーム、MOレベルのネットワークゲームなど運用可能 ・MUNを利用することにより、サーバサイドを一切コードを書かずに、クライアントサイドのみ実現可能 ・MRS同様、ルームを跨いだ通信ができないので注意が必要 リアルタイムサーバ間、サーバ⇔クライアントとの接続 ・内部エンジンで MRS を利用しているので、特性は MRS に準じる ・MUN では MRS-API を Unity 向けに C# でバインディングして、TCP/UDPによるソケット接続が可能 MUN ルームサーバの制限 ・1ルームに入室できるプレイヤー人数は 255 人まで、1サーバプロセスで十分に捌ける人数は３万クライアント程度 ・提供するゲームの規模に応じて、mun_room サーバのスケールアウトが必要
- 38. 37 ■ MUNのコーディング例 簡単な送受信サンプルの実装例 ・MUNのコードも至ってシンプルで、簡単なECHO送受信のコードを記述すると以下のように書けます。 クライアント側 using System; using MonobitEngine; namespace MUN_EchoSample { class EchoSample : MonobitEngine.MonoBehaviour { void Start() { MonobitNetwork.ConnectServer(“EchoSample”); // サーバ接続 } void Update() { if( !MonobitNetwork.isConnect ) return; if( !MonobitNetwork.inRoom ) { MonobitNetwork.JoinOrCreateRoom(“MyRoom”, new RoomSettings(), null); // ルーム入室 } } // ルーム入室時の処理 void OnJoinedRoom() { if( !MonobitNetwork.isHost ) { monobitView.RPC(“SendMsg”, MonobitTarget.Others, MonobitNetwork.player, “Hello, MUN!” ); // ECHO送信 } } // ECHO送信の受信 [MunRPC] void SendMsg(MonobitPlayer sender, string msg) { UnityEngine.Debug.Log(“SendMsg : “ + msg ); // 受信結果表示 monobitView.RPC(“EchoMsg”, sender, msg ); // ECHO返信 } // ECHO返信の受信 [MunRPC] void EchoMsg(string msg) { UnityEngine.Debug.Log(“EchoMsg : “ + msg ); // 返信結果表示 MonobitNetwork.DisconnectServer(); // サーバ切断 } } }
- 39. 38 ■ MUNによる10万人大規模サービスの構成 MUNサーバで「同時接続者数10万」を実現するには ・MUNは原則として、以下の用途におけるネットワークゲームに適しています。 a) オンライン対戦型のターン制カードゲーム、パズルゲームなど b) MO（中小規模の、参加人数限定型マルチプレイヤーオンラインゲーム） c) MOBA（参加人数限定型の戦略対戦型オンラインゲーム） ・１つの MUN サーバセットあたりで、同時接続、およびルーム内各種メッセージを捌けるのは おおよそ３万人程度です（弊社調べ：１ルームあたり、秒間平均200メッセージの送受信を想定）。 ・10万人規模の同時接続者数を捌くためには、MUNサーバの横展開（スケール）が必要になりますが、MUN の サーバセットは密結合のサーバプロセスで構成されているため、スケールする場合、このサーバセットを１組として 複数のサーバセットを並列配置することになります。 ・サーバセットをスケールすることにより、実質的に無限数のMUN クライアントに対し、同時接続処理を捌けます。 ・次ページで、具体的なサーバ構成例を示します。 MUN Room MUN Proxy mun_proxy ・・・mun_resolver MUN Master mun_master MUN Resolver mun_proxy mun_room ・・・mun_room 「MUN サーバセット」のこの１組を単位として、 複数サーバセットを並列配置する
- 40. 39 ■ MUNによる10万人大規模サービスの構成 複数の MUN サーバセットによる 10万人同時接続の実現（概略） ・複数の MUN サーバセットによる、 10万人同時接続を実現するためのサーバ構成例として、以下に示します。 ・１つの MUN サーバセットに対して同時に捌くことのできるクライアント数は３万クライアントまでですが、若干 余裕を持たせて、サーバセットを５セット程度用意します。 ・どの MUN サーバセットに接続するかを管理し、クライアントを誘引するための、Webサーバを複数台用意します。 Global Section MUN Server Machine MUN Server Process Internet MUN Client MUN Client ・・・ MUN Client Machine MUN Client Process Web Server mrs_pusherdatabase MUN Client MUN Client MUN Client MUN Client MUN Client MUN Client MUN Client MUN Client MUN Resolver mun_resolver MUN Master mun_master MUN Proxy ・・・ mun_proxy mun_room MUN Room ・・・ ・・・ mun_proxy mun_room ・・・ MUN Resolver mun_resolver MUN Master mun_master MUN Proxy ・・・ mun_proxy mun_room mun_proxy mun_room ・・・ MUN Room Private Section MUN Server Set 1 MUN Server Set 2 ・・・
- 41. 40 ■ MUNによる10万人大規模サービスの構成 複数の MUN サーバセットによる 10万人同時接続の実現（詳細） ・Webサーバでは、複数の MUN サーバセット内に含まれる mun_resolver のクライアント接続アドレス情報を 事前にデータベース情報として、複数台で同一の内容を保持します。 かつ、MUNクライアントは mun_resolver に接続する前にこの Web サーバに接続し、MUN サーバセットのうち 「最も既存クライアントの接続数の少ない」 mun_resolver のアドレス情報を mrs_pusher で返します。 ※ MUN では MRS が内包されていますので、MRSでの情報のやり取りも可能です。 ・MUN サーバセットでは、MO/MOBAをはじめとする、中小規模の人数が参加するゲームルームを設置し、そこで ルーム内プレイヤー同士で、RPCによるデータの送受信、キャラクタなどのオブジェクト位置情報の同期などを 行います。 MUN Resolver に接続するためのアドレス情報を退避したデータベースを持つWebサーバ。 MUNクライアントとのやり取りのためにmrs_pusherを利用し、かつ最もクライアント接続数が 少ない、MUNサーバセットへの誘導を行なう Web Server mrs_pusherdatabase MUN サーバセット自体は通常の MUN サーバとして運用する サーバのスケールアウトは、原則このサーバセットを1単位として、全体をスケールする形をとる 接続するクライアントは、適宜必要に応じたルームに入室させ、 その中に所属するプレイヤー同士で、メッセージのやり取り、キャラクタの位置情報の同期、 各種パラメータの共有などを行なう。 比較的セキュリティ性を求められない通信対戦/MOであればクライアントベースで開発し、 セキュリティ性の高い通信対戦/MOや、複雑なロジックを必要とするMOBAなどであれば サーバサイドでのプログラムを実装し、なるべく保守性・安定性に優れたシステムを構築する
- 46. 45 ■ まとめ お手軽に開発するのであれば「MUN」がおすすめです！ ・何よりクライアントベースで開発できます。 ・ネットワークゲームのモック、プロット開発、小規模なゲームであれば、機能として十分です。 ・Unity のクライアント負荷を軽減するために実装した一部のロジックについてサーバサイドに移植したり、アプリ 利用者側の操作に依存しないゲームロジックをサーバサイドに記述することも可能です。 ・有償プランをお使いの場合、原則１つのサーバセットで捌けるクライアントの上限は３万程度ですが、Webサーバを 伴った並列制御が可能で、同時接続者数制限は実質ほぼありません。ぜひご検討ください。 最初から本格的・大規模なネットワークゲームを作るのであれば 「MRS」一択です！ ・低遅延かつ高レイテンシの、最高級のネットワーク環境でゲームを実装できます。 ・CベースのAPIを覚える必要がありますが、数あるネットワークライブラリの中でもかなり平易です。 ・加えて、MRSの同梱サンプルや、大規模なものだと「MUNサーバ」など、有効なサンプルは揃っています。 ・C/C++ 対応はもちろん、C#, JavaScript のバインディングコードも同梱しています。Cからの言語バインディング を理解しているのであれば、お客様の環境であらゆる言語に対応することもできます。
- 50. ぐぐると • UDPはとにかく遅延が小さい • だから対戦格闘みたいな速い反応速度が必要なゲームはUDP • MMOはTCP (でもUDPのもある) • できるだけUDPのほうがいいだろ • TCPはデバッグしやすいよ • UDPは面倒なことが多いからTCP • でも、あのゲームもこのゲームもUDPを使ってる • しかし、あのゲームもこのゲームもTCPを使ってる • 同じジャンルでもいろいろ違う • 両方使ってるゲームもあるよ 結論ができない・・！ 49
- 57. IPアドレスとルータ 11.22.33.44 ルータ ルータ ルータ ルータ ルータ ルータ ルータ ルータ 55.44.33.22 IPアドレスをたよりにルータからルータへ転送されていく 56
- 59. パケットヘッダの積み重なり Ethernetヘッダ IPヘッダ UDP/TCPヘッダ アプリケーションヘッダ アプリケーションデータ IPヘッダ UDP/TCPヘッダ アプリケーションヘッダ アプリケーションデータ UDP/TCPヘッダ アプリケーションヘッダ アプリケーションデータ アプリケーションヘッダ アプリケーションデータ アプリケーションデータ データリンク層 ネットワーク層 トランスポート層 セッション層・アプリケーション層 物理層 {“x”:10,”y”:20} データタイプ、関数ID ポート番号、順序番号etc 宛先IPアドレス 宛先マシンアドレス 58
- 60. IP : ルーターを使ってデータを転送 無線LAN 利用者 サーバー 端末 ルータ ルータ ルータ ルータ 銅線 光 光 光 銅線電波 信号 ルータは高速なコンピューター 入力 信号 バッファ メモリ信号 入力 入力 出力 信号 信号 信号 出力 出力 インターネットの巨大な住所録をメモリに載せ、 11.22.33.44がどの光ケーブルの先にあるかを判定 55.44.33.22 11.22.33.44 59
- 63. 問題 : 光は速いけど遅い • 真空中 : 1秒間に30万km • 光ファイバの中 : 1秒間に20万km • 1ミリ秒(ms)では200km • 東京 <-> 大阪 400km = 片道2ms 東京<->サンフランシスコ 片道40ms 62
- 64. 問題 : 短い経路ではなく安い経路が使われる • 富山から東京にパケットを投げたら、金沢>大阪>東 京 と伝達される • NTT西日本と東日本の取引がそうなっている tracerouteの結果 63
- 65. 問題 : ルータは遅い • 富山から大阪は300kmしかないので1.5msで済 むはずが、10ms以上かかっている • ルータがやっていること • ケーブルの信号を読み取ってバッファに積む • パケットを解析して送り先IPアドレスを調べる • IPアドレスの住所録(数十万〜数百万件)を検索してどのケーブルに出力するか決定 • 送信バッファに出力 • ケーブルに送信する • パケットの断片化や暗号化、アタック防止やファイアウォール、NATの変換、統計 データ取得など膨大な量のタスクを同時進行させている 64
- 67. 問題: ルータの出口が細いと捨てる 入力 バッファ メモリ 入力 入力 出力 出力 出力 高速回線 低速回線 BA C C 入力が速すぎたので AとBは捨てる 66
- 68. 問題:小さい単位でしか送れない • 物理層の制限 (MTU) • できるだけ多くの人が1本のケーブルを共有する ために、 時間を短く切りきざむ必要がある。 • WiFiやEthernetでは1500Bytes ~ 9KBytes (数マイクロ 秒以下) • モバイルだと1000Bytes以下のこともある • それ以外でもだいたい1KB~5KB以下 • それ以上のパケットは「断片化」して送る 67
- 69. 4KBを送るとき(成功) WiFi ルータ 4KBのデータ 1500B 1500B 1000B 1500B 1500B ルータ 1500B 3個に分かれた。 パケットを分割する動作を「IP断片化」と呼ぶ 1000B 1500B 1000B 68
- 70. 4KBを送るとき(成功:パケット順) WiFi ルータ 4KBのデータ 1500B 1500B 1000B 1500B1500B ルータ 1500B 順番が入れ替わったら 受信したサーバー(エンドポイント)が 並べ替えて元に戻す 1000B 1500B 1000B 69
- 71. 4KBを送るとき(失敗:パケットロス) WiFi ルータ 4KBのデータ 1500B 1500B 1000B 1500B1500B ルータ IPのパケットが2個、消えた。 元に戻すことができない! 1500B x x 70
- 72. 50KBを送るとき 50KBのデータ 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 1500B 500B x どれか1個がロスしたら全体が復元できなくなる! IPパケットは最大64KBまで。 断片の数が多いほど全ロスの確率が指数的に高まる 71
- 74. iperf3コマンドでもロス率を見る • Linux,Windows,Mac,Androidなど各OSで使えるベンチマークツール • TCPもUDPも測れる • pingコマンドよりも、ゲームの送信パターンにより近くすることができ る 73
- 75. 参考データ • 無線LAN • 電波最強で0.01~0.1%程度、電波弱いと5%〜100%ロス • モバイルキャリア • 電波最強でも0.1%以上ロスあり 電波弱いと10%以上ロス。 • 有線LAN • 0.00000001%〜ケーブルクオリティ低いと0.01%ロス • ルータが混んでたらいくらでもロス • データセンター内部 • スループット制限を超えた分は全部ロス 74
- 80. TCP : 正確な受信順序 • パケットに「シーケンス番号」が付いているので、受信 側のメモリに貯めておいて順番を入れ替えることができ る • これで何十MBでも何GBでも正しく送れるようになった 21 23 25 26 受信 受信バッファ アプリケーション 22 24 79
- 81. TCP : 送りすぎの防止 (輻輳制御) • スライディングウインドウ(窓枠ずらし)方式 • 一度に送信するパケットの量に上限を設定する。 これを「窓 枠」「ウインドウ」と呼ぶ。 • 窓の大きさは「ウインドウサイズ」と呼ばれる • 速く送るにはウインドウサイズを大きくする必要がある。 • この窓枠の大きさを状況によって動的に変更し、性能を調整す る https://www.youtube.com/watch?v=lk27yiITOvU 80
- 82. TCP : スロースタート • 遅く始めてだんだん加速する。つまり、窓枠をだんだん大きくする 。 • パケットがロスしない間は、ウインドウサイズをだんだん大きくし て加速していく • パケロスしたらリセット=窓枠を最小にする http://www.net.c.dendai.ac.jp/~yutaro/ 81
- 85. TCPの時代分け • 1980年代 : TCP登場、telnetでマシンを遠隔操作 • 1990年代 : メールやHTTPなどで大ブレイク • 2000年代 : モバイルで長時間のストールを防ぎたい！ • 2010年代 : 動画や音声を高速送信したい! 84
- 87. TCPの今後の発展 • より多くの観測情報を統計的に使う • 2016 Google BBR (Bottleneck Bandwidth and Round-trip propagation time)アルゴリズム登場 • 途中のルータと通信してより正確な状況を把握する • 宇宙空間やIoTなど極端な状況への対応 • 異なる経路の複数のセッションを同時に活用(MPTCP) • … • スループットの向上とストールの回避をどこまでも追 求している • 現在も早く進化中で、今後もどんどん改善されていく • GoogleやMSなどの巨大企業による莫大な量の投資 86
- 90. mrs_benchのTCPモードで実験 • サーバ : Centos7 + cubic • クライアント : MacOS X + newreno • 意図的なパケロスなし • 富山>東京 mrs_benchはモノビットエンジン製品”MRS”の TCP/UDPベンチマークツール だいたい50ms以下なので 快適にゲームできる 89
- 91. mrs_benchのTCPモードで実験 • サーバ : Centos7 + cubic • クライアント : MacOS X + newreno • 意図的なパケロス : 5% (モバイルやWiFiではまああ る状態) • 富山>東京 これではゲームにならない 90
- 92. LinuxでのTCPアルゴリズムの調整 • CentOS7で使えるTCPモジュールの確認 • bic,cubic,westwood,htcp,hstcp,hybla,vegas,scalable,lp,veno,yeah,illinois,dctcp が標 準インストールされているとわかる • westwoodはパケットロスが多く遅延が大きいモバイル環境向け • dctcpはデータセンター向けで、高速スイッチ機器と連携できる • などなど 91
- 93. Linuxにwestwood TCPを導入 • rootになり • modprobe tcp_westwood • echo “westwood” > /proc/sys/net/ipv4/tcp_congestion_control • 再起動は不要 92
- 94. mrs_benchでwestwoodを測定 • サーバ : Centos7 + westwood • クライアント : MacOS X + newreno • 意図的なパケロス : 5% (モバイルやWiFiではまああ る状態) • 富山>東京 最初少し悪化するが、統計データが集まると回復し安定化 これなら問題なくゲームできる 93
- 95. CentOS以外でもアルゴリズムを確認 • Android • 4.4.2 Xperia ZR • adb shellにおいて sysctl -a | grep conges • net.ipv4.tcp_allowed_congestion_control = cubic reno • net.ipv4.tcp_available_congestion_control = cubic reno • net.ipv4.tcp_congestion_control = cubic • MacOS Xと iOS • sysctl -a | grep sockets • net.inet.tcp.newreno_sockets: 0 • net.inet.tcp.cubic_sockets: 74 • Windows • デフォルトはCTCP • コマンドラインで netsh int tcp show global で細かな設 定を確認できる 94
- 97. TCPとUDPの比較 • UDPが即必要になる要件 • WiFiアドホックネットワークやNATトラバーサルが必要な場合 • それでもTCPとの併用は選択肢になる • UDPの明白なデメリット • 数%ある「UDPブロックド」タイプのファイアウォールを全く 越えられない。 • 特に企業や学校の「ウェブ検索専用のゲーム禁止ネットワーク 」でよく見られる • 比較検討のポイント • 通信遅延 • サーバのCPU消費 • RUDPの性能 • プログラミングコスト(デバッグ効率) NATトラバーサルについては話が非常に長くなるので、ここでは割愛 96
- 99. TCPとUDPの比較 : 通信遅延 • UDPにはストールがなく、ただ単にパケットが消えるだけ • TCPのストールについては前述。 • ここではパケットの到達までにかかる時間の長さだけを考え る • サーバ: Centos7 + westwood • 富山>東京 UDP速い 通信距離が長くなるほど明らかにUDPが速くなるのは、 途中のルータすべての処理負荷の蓄積が無いため。 開発中のゲームで、20〜30msの遅延は問題になるか？ 98
- 100. TCPとUDPの比較 : サーバのCPU消費 • libuv_bench でTCPとUDPのエコーサーバーで比較(top) • TCP: Centos7 + westwood • IDCFクラウドのデータセンター内通信を使用 • 600Mbpsを送信 libuv_benchは弊社が独自に実装した libuvを用いたベンチマークプログラム TCP 合計10.4% UDP 合計6.2% UDPのほうがユーザー時間もシステム時間も小さい TCPはOSが接続状態(コネクション)を管理しているため 99
- 101. TCPとUDPの比較 : RUDPの性能 • RUDP : Reliable(信頼できる) UDP • UDPにTCPの機能の一部を追加したプロトコルの総称 • モノビットエンジン製品では、再送機能と順序保証を単 純なスライディングウインドウ式で実装したRUDPであ るENetの独自修正版を使用。 • 富山>東京 パケットロス10%、遅延100ms追加で比較 mrs_bench RUDP ENetTCP westwood ACKパケットも連続ロスした場合はどちらも1000ms以上遅れることもある。 ENetは少し平均遅延が長いが健闘している 100
- 102. TCPとUDPの比較 : RUDPのサーバCPU • 100Mbps送受信のMRSサーバで比較(top) TCP 合計2.3% RUDP 合計8.3% これが、30年近くかけて大規模環境で叩かれてきたLinuxのTCPと 主にゲームで使われてきた10年選手のENetの差・・！ しかし100Mbpsで1ヶ月通信すると、 通信費がAWSなら50万円以上だがCPU費用は1000円以下。 CPUコストは誤差といえる。 モノビットエンジンMRSでは、パケットごとに信頼性のあり・なしを設定可能 RUDP 合計6% (信頼性なしモード) 101
- 103. TCPとUDPの比較 : RUDPの使い方 • 信頼性(再送、順序)が必要なパケットは再送をさせる が、そうではないパケットは再送させない • モノビットエンジンではパケットごとにon/offできる • 信頼性ありパケットの用途 • ログイン・ログアウト、ショップ、マッチング、ア イテム取得など • 信頼性なしパケットの用途 • キャラクターの位置更新、エフェクト、ボイスチャ ット、映像データなど • 以下はMRSでのコード例 102
- 104. TCPとUDPの比較 : プログラミングコスト • UDPとTCPの違いはミドルウェアが自動的に吸収、プログラ ミングの作業自体は簡単 • 以下はモノビットエンジン製品”MRS”におけるコード例 切り替えはライブラリのフラグ一発なので、 TCPで開発を始めてから、随時UDPにきりかえてテストをしていくことができる。 また、”UDPブロックドNAT"環境でもスイッチ一発で切り替えることができ、問題を解 消できる。 103
- 105. TCPとUDPの比較 : プログラミングコスト • トラブルシューティングはUDPが一手間多く必要 • TCPではOSがコネクションの状態を管理しているため、 netstatやss, nethogsなどの標準ツールを用いて通信状態の確認 がやりやすい • UDPではコネクションをアプリケーションが管理しているた め、tcpdumpやwiresharkを用いた確認作業が必要 • モノビットエンジン用のパケット解析スクリプト”mrsdump” を準備中 104
- 106. TCPとUDPの使い分け 質問 答え UDPは速いか？ 遠いとかなり速い UDPはサーバが軽いか？ UDPは軽いがRUDPは重い。ただし誤差 の範囲 UDPはプログラミングが面倒か ？ 実装は変わらないが トラブルシュートが面倒 結論: ゲームでは、UDPとTCPの切り替えが可能な通信ミドルウェアを使えば、 「UDPブロックドNAT」の問題も解消できるので、UDPが第一選択肢となる。 では、開発中のゲームではどうすればよいか？ 105
- 107. ゲームで必要な低遅延と帯域幅 ゲームジャンル 遅延 帯域 プロトコル FPS(PvP公式戦) 5~15ms 500Kbps~1Mbps UDP+RUDP FPS(PvP一般) 10~30ms 200~300Kbps UDP+RUDP 対戦格闘(1vs1) 5~30ms 50~200Kbps UDP+RUDP レースゲーム(PvP) 10~50ms 100~200Kbps UDP+RUDP スマブラ系PvP 10~50ms 100~300Kbps UDP+RUDP VR空間共有 10~100ms 100K~1Mbps UDP+RUDP/TCP FPS(PvE) 30~100ms 200Kbps UDP+RUDP/TCP RTS/MOBA 20~100ms 200~500Kbps UDP+RUDP/TCP TPS 50~100ms 100~300Kbps RUDP/TCP スマホアクション 50~200ms 50~100Kbps RUDP/TCP ボイスチャット 50~200ms 50K~300Kbps RUDP/TCP 超多人数戦争 100~300ms 300Kbps~1Mbps RUDP/TCP MMORPG 100~500ms 50~200Kbps RUDP/TCP スマホターン制 200~1000ms 20~100Kbps TCP 上記は一人 あたり必要な帯域幅 106
- 108. モノビットのミドルウェア製品 • MRS “Monobit Revolution Server” • UDP/RUDP/TCP/WebSocketに対応した全プラッ トフォーム向け通信ミドルウェア • http://www.monobitengine.com/mrs/ • MUN “Monobit Unity Network” • Unity向けの導入が非常に簡単なMRSベースの ミドルウェア • http://www.monobitengine.com/mun/ 107
- 109. モノビットの調査ツール • 社内で調査やお客さまサポートに使う独自ツール群 • mrs_bench : MRSのベンチマークツール • enet-benchmark : ENetのベンチマークツール • libuv_bench : libuvのベンチマークツール • node_bench : node.jsのベンチマークツール • MRSだけではなく下位レイヤー単体の調査を綿密に 行って、 問題の切り分けを行っています。 • ネットワークゲーム実装で困ったり、何か工夫した いときは遠慮なくお声掛けください! 108