【CEDEC2017】新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！
•
5 gefällt mir•8,089 views
2017年に完全新作、超高性能に生まれ変わったモノビットエンジンの製品群を用いて、 10万人規模の大規模同時接続を行うMO型、MOBA型、MMORPGなどのネットワークゲームについて、 どのようにプログラムとサーバを構築し、安全に運用することが出来るようになったのか、 実際にコーディング実例やサーバ構成図、運用管理画面を表示しつつ、ご説明いたします。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (13)
Ähnlich wie 【CEDEC2017】新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！
Ähnlich wie 【CEDEC2017】新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！ (20)
Mehr von モノビット エンジン
Mehr von モノビット エンジン (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
【CEDEC2017】新しくなったモノビットエンジンを使って10万人規模のサーバを構築するノウハウを公開！
- 1. 本城 嘉太郎（代表取締役） 中嶋 謙互（取締役CTO） 安⽥ 京⼈（ミドルウェア事業部部⻑） 新しくなったモノビットエンジンを使って 10万人規模のサーバを構築するノウハウを公開！ CEDEC2017 株式会社モノビット
- 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年9月 2017年10月 2017年秋 2017年冬 送受信制限機能 の実装 シーケンス 最適化 内部データベース 再構築 差分データ 送信制御 Websocket対応Unity+WebGL NET CORE対応 - 19 -
- 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からの⾔語バインディング を理解しているのであれば、お客様の環境であらゆる⾔語に対応することもできます。
- 47. 新製品「MRSクラスタ」 2017/08/30 CEDEC 2017 株式会社モノビット 取締役CTO 中嶋謙互 https://github.com/kengonakajima
- 49. ⾃⼰紹介 • ゲームプログラマ、ネットワークプログラマ • これまでにやったこと • 1994年ごろ〜 多数のMMORPGの設計とプログラミング • 2000年ごろ〜 MMOG/MOG⽤のネットワークミドルウェア • 2011年 「オンラインゲームを⽀える技術」著 • 2013年ごろ〜 クラウドゲーム企業のアーキテクトとして参画。 フリーランスでインディーゲームを製作、Steamで現在も販売中 • 2016年〜 (株)モノビットのCTOとして参画、エンジンの刷新を担当する 過去20年以上にわたり、ソケットAPIを⽤いたマルチプレイゲームの実装をやリ続けてきた。
- 51. モノビットでの担当分野 • モノビットエンジン • 特にリアルタイム通信 • 各開発プロジェクトでの技術ディレクション
- 52. 基盤ライブラリ”MRS”
- 53. オンラインゲームのカテゴリ • リアルタイムゲーム • 空間共有の⼈数が多いMMO • 空間共有の⼈数が少ないMO • チートできるリレー型 • チートできないサーバーロジック型 • WebAPIサーバだけで実現できるもの
- 54. オンラインゲームのカテゴリ • リアルタイムゲーム • 空間共有の⼈数が多いMMO : MRSが最適 • 空間共有の⼈数が少ないMO : UnityではMUN、それ以外は MRS • チートできるリレー型 • チートできないサーバーロジック型 • WebAPIサーバだけで実現できるもの
- 55. MUNはMRSの上に • Monobit Unity Network • Monobit Revolution Server • MUNは、MRSを⽤いてUnityのシンプルなゲーム向けに作られたミドル ウェア
- 56. 基盤ライブラリとしてのMRS • ソケットAPIをラップし、バイナリデータを 送受信するだけ •TCP, UDP, RUDP, WebSocket •OSごとの違いを吸収する •C⾔語API •最⼩限の機能に絞ることで軽量かつ⾼速に 動作
- 58. MRS関連のプログラム群 • mrs_room 対戦部屋(Room)の概念を実装したゲーム同期サーバーのサンプルコード。 • mrs_pusher リアルタイム通信とWebAPI通信を連携するためのブリッジツール • mrs_mmo C++とC#による、MRSを⽤いたMMOGのサンプルコード • mrs_bench MRSのベンチマークプログラム • mrs_gen(開発中) MRSに最適化された⾼速なRPCスタブコードジェネレータ • mrs_mon MRSのUDPパケットを追跡するデバッグツール 必要なものを組み合わせて使う
- 59. MRSの次のマイルストーン • ⾃動スケーリング • 負荷にあわせたVMインスタンスやサーバプロセス の⾃動起動・停⽌ • UE4 • P2P • MRSの外部ライブラリとして実装し、必要な場合だ け組み合わせて使う • MMOボイスチャット • ⼤⼈数でも破綻のない⾃然なボイス処理 めんどくさいことから⾃動化してゆき、 ゲーム内容の制作に集中できるように！！
- 61. MRSクラスタ • MRSアプリケーションの⾃動スケーリングツール。 • Rubyによるシンプルなスクリプト • Linuxサーバ向け • VMインスタンスの増減、プロセスの増減の両⽅を⾏う • リレー型ゲームではパッケージそのままで使える • MMOやサーバロジック型ゲームにも対応可能 • どの部分もスケールアウト/イン可能 • AWSなど特定のクラウドに依存しない • AWSとIDCFから。 AWSやGoogleについてはSDKを使⽤、 SDKがない環境ではhttpsを直接叩く • オンプレのシステムでも適⽤可能 • 異なる性能のインスタンスを混在使⽤可能 (現在開発中)
- 62. VM2 VM3 MRSクラスタのマシンとプロセス mrsctl VM1 ・・・ VM起動・停⽌ App1⽤サーバプロセス群 room room match status VM2 VM3VM1 ・・・ App2⽤サーバプロセス群 room room room match room プロセス起動・停⽌ ・ ・ ・
- 63. MRSクラスタに含まれるサービス • mrs_room データリレーサーバ。独⾃のゲームロジックを持たせる場合はここに 追加実装する • mrs_match マッチングサーバ。どのプレイヤーがどのmrs_roomに居るかを検索 ・ソートできる。 • mrs_status ステータスサーバ。mrs_roomやmrs_matchなどのサーバの稼働状況 をクライアントに送る。 • mrs_auth 認証の中継サーバ。外部の認証サーバーへのブリッジ機能を実装。 上記はすべて⾃動スケールアウト・カスタマイズ可能
- 64. MRSクラスタの標準プロセス構成 auth x N Client x N Internet match x N DB x 1 将来N status x Nroom x N Bridgeとか LINEとか 外部サービス 空きroom検索 HTTP(S) リアルタイム同期 TCP/UDP room検索 HTTP(S) HTTPS 状態送信 認証 必要な部分だけ選んで利⽤可能。 既存システムと重複する部分を無くせる
- 65. MRSクラスタの最⼩構成 auth x N Client x N Internet match x N DB x 1 将来N status x Nroom x N Bridgeとか LINEとか 外部サービス 空きroom検索 HTTP(S) リアルタイム同期 TCP/UDP room検索 HTTP(S) HTTPS 状態送信 認証 例えば、roomを固定数だけ常時起動しておき、 ゲームのWebサーバーからクライアントにアドレスを渡すだけ。 ⾃動スケールアウト・インを⾏わず、⾃動再起動やロギングの機能のみを使う
- 66. MRSクラスタの設計指針 • 複雑さはできるだけクライアントに集める。 • サーバ同⼠の連携を無くし疎結合とする。 • 上記の結果・・・ • 同時接続規模の上限がなくなる • サーバの機能ごとにばらばらにスケールアウトできるように なる • ばらばらに⽌めたり起動したりできる • SPOFがなくなる • 特定のクラウドに依存せず、オンプレでも動作可能になる
- 67. ⾃動スケーリングのカスタマイズ • mrsctlの動作ステップ • mrsctl statusコマンドで各マシンから負荷状況を収集 • mrsctl planコマンドでマシンとプロセスの修正案を提⽰(シ ェルコマンドラインまたはJSON) • 実際にコマンドを実⾏(⾃動または⼈間) • カスタマイズ⽅法 • mrsctl planの内容を変更し、実際に発⾏するコマンドの内容 をアプリケーション側で⾃在に決定できる。典型的にはログ したり他システムとの連携などを想定 • ゲームのリアルタイム同期データ以外はすべてWeb標準の技 術を使⽤。既存ツールが使える
- 68. オンプレシステムにおけるMRSクラスタ • Fixed: マシン構成が固定のパターン • 利⽤可能なLinuxマシンが固定されている場合はプロセス構 成のみmrsctlで変更可能。容量を⼤きめにしておいて変更 しない運⽤も可能。 • Manual: マシン構成が⼿動で変更されるパターン • ⼿動でマシンを追加したり削減したりする。増減したマシ ンのアドレスをmrsctlに教えることでクラスタに追加した り外したりする
- 69. ⾃動スケーリングの今後 • より緻密な負荷減少への対応 • ⼩さいインスタンスを適切に使う • AWSのスポットインスタンスのような⼀時的だが安 いサーバの活⽤