Download as PDF, PPTX
![動作例
クライアントA
サーバ
クライアントCが既存のPlayerの状態⼀覧を
サーバから取得して状態を再現する
クライアントB A: (1, 0 ,0 )
B: (0, 0, 2 )
C: (0, 0, 0)
クライアントC Task<PlayerStatus[]>
FetchCurrentAsync()
A: (1, 0 ,0 )
B: (0, 0, 2 )
C: (0, 0, 0)](https://image.slidesharecdn.com/magiconion-191027042746/85/MagicOnion-C-90-320.jpg)
![Broadcastの種類
• Broadcast(IGroup)
• 指定Group内の、クライアント全員に送信
• BroadcastToSelf(IGroup) / BroadcastExceptSelf(IGRoup)
• ⾃分に対してのみ送信 / ⾃分以外の全員に送信
• BroadcastExcept(IGRoup, Guid / Guid[])
• 指定Group内の、指定のクライアントを除く全員に送信
• BroadcastTo(IGRoup, Guid / Guid[])
• 指定Group内の、指定のクライアントのみへ送信](https://image.slidesharecdn.com/magiconion-191027042746/85/MagicOnion-C-114-320.jpg)
Uploaded bytorisoup
MagicOnion～C#でゲームサーバを開発しよう～
https://vsuc.connpass.com/event/146588/
![[CEDEC 2021] 運用中タイトルでも怖くない！ 『メルクストーリア』におけるハイパフォーマンス・ローコストなリアルタイム通信技術の導入事例](https://cdn.slidesharecdn.com/ss_thumbnails/cedec2021-210825103749-thumbnail.jpg?width=640&height=640&fit=bounds)
MagicOnion～C#でゲームサーバを開発しよう～
- 1. MagicOnion 〜C#でゲームサーバを開発しよう〜 .NET Conf inTokyo 2019 #dotnetconfunity 2019/10/27 とりすーぷ
- 2. ⾃⼰紹介 • 「とりすーぷ」 • @toRisouP •株式会社バーチャルキャスト 開発 • xR開発 • 最近はサーバ開発 • Microsoft MVP for Developer Technologies 2018〜2020
- 3. 今回の話 • MagicOnionについて解説 • 何のためのフレームワークか •どんな機能があるのか • 環境構築 • 実装例の紹介 • 実装時の注意点 • デプロイ
- 4.
- 5. MagicOnion is 何 •ネットワーク通信のためのフレームワーク • Unityでのゲーム開発を中⼼に使えるネットワーク通信フレームワーク • サーバサイド：.NET Core • クライアントサイド：Unity / .NET Core • 開発はCysharp社 • MITライセンス
- 6. MagicOnionのバックエンド • C# +.NET Core / Unity • 通信プロトコル: gRPC • データフォーマット: MessagePack for C# • 定義したC#ファイルがそのままDSLになる • C#インタフェースがAPIのエンドポイント • C#オブジェクトが通信データ構造（MessagePackObject)
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. MagicOnion 最⼤の特徴 • 通信レイヤを意識せずにサーバコードを呼び出せる •サーバとクライアントでC#インタフェースを共有すればOK • 通信のデータ構造もC#で定義すればOK • async/awaitでメソッド呼び出しするだけでサーバの処理を実⾏できる • ただし、gRPCのコネクション管理だけは⾃前で管理しないとダメ（しょうがない）
- 18.
- 19. 機能⼀覧 • 実装できるAPIの種類 • Service、StreamingHub •Filter機能 • Filter • その他便利な機能 • Swagger、Telemetry
- 20. APIの実装 • ⼤きく2つのAPI実装パターンがある • Service •StreamingHub
- 21. Service • Service • シンプルな単発のAPIを作成するのに使う •1Request ‒ 1Response通信（中⾝はUnary RPC) • リクエストを投げた本⼈にのみレスポンスを返せる
- 22.
- 23. StreamingHub • StreamingHub • リアルタイム通信向け •中⾝はBidirectional Streaming RPC • 仮想的なコネクションを貼ったままずっと維持する • クライアントとサーバが⾃由にメッセージを送受信できる • 全体へブロードキャストも可能
- 24.
- 25. 機能⼀覧 • 実装できるAPIの種類 • Service、StreamingHub •Filter機能 • Filter • その他便利な機能 • Swagger、Telemetry
- 26. Filter • 通信の前後に処理を追加する機能 • サーバ側フィルタ •Service、StreamingHubに適⽤可能 • クライアント側フィルタ • Serviceのみ対応
- 27.
- 28.
- 29. Filterの⽤途 • 使⽤例 • 認証⽤のヘッダーを追加 •メッセージの暗号化/復号化 • 通信ログ出⼒ • 通信をせずにダミーのレスポンスの差し替え • エラーメッセージのハンドリング • リトライ処理
- 30. 機能⼀覧 • 実装できるAPIの種類 • Service、StreamingHub •Filter機能 • Filter • その他便利な機能 • Swagger、Telemetry
- 31. 便利な機能 • Swagger対応 • 「Service」で実装したメソッドをRESTAPIとして実⾏できる • Webブラウザ上でAPIの動作確認ができる • デバッグに便利 • Telemetry対応 • MagicOnionの監視 • メトリクス
- 32. 今回の話 • MagicOnionについて解説 • 何のためのフレームワークか •どんな機能があるのか • 環境構築 • 実装例の紹介 • 実装時の注意点 • デプロイ
- 33.
- 34. 環境構築 • MagicOnionは環境構築がちょっとたいへん • クライアント側(Unity)は⼿動でライブラリ追加が必要 •コード共有 • コードジェネレート
- 35. クライアント ライブラリ導⼊ • これらのライブラリを⼿動でUnityに導⼊する必要がある •MagicOnion.Client.Unity.unitypackage • https://github.com/Cysharp/MagicOnion/releases • MessagePack.Unity.x.x.x.x.unitypackage • https://github.com/neuecc/MessagePack-CSharp/releases • gRPC Unity plugin • https://packages.grpc.io/
- 36. Player Settingsも設定が必要 • ScriptingDefine Symbols • ENABLE_UNSAFE_MSGPACK を書き⾜す • Allow ʻunsafeʼ Code • Enable
- 37. ついでに導⼊するとよさげ • UniRx • ReactiveExtensions for Unity • イベント処理の整理に便利 • UniTask • ValueTask for Unity • Unity向けのAwaiter実装の提供 • ⾮同期周りにはコレ
- 38. 環境構築 • MagicOnionは環境構築がちょっとたいへん • クライアント側(Unity)は⼿動でライブラリ追加が必要 •コード共有 • コードジェネレート
- 39.
- 40.
- 41.
- 42.
- 43.
- 44.
- 45.
- 46. この⽅法のメリット • 設定が簡単 • csprojに数⾏書き⾜すだけで設定が終わる •リポジトリをチェックアウトしてくればそのまま動く • 環境に依存しない • シンボリックリンクとかそういう⾯倒な作業もいらない • 相対パスさえ維持されていれば動く
- 47. デメリット • リポジトリが1個にまとまってしまう • サーバのビルドにクライアントコードのcheckoutも必要になる •クライアントの容量が⼤きくなってくるとCI/CDがツライことになる • 開発フローの整理が難しくなる • クライアント開発とサーバ開発が同じリポジトリで管理される • GitHubのissue/pr 欄が混ざる
- 48.
- 49. 折半案 サーバ側 ここのUnityプロジェクトは、 Headlessなクライアント + DebugScene が置かれる Git Repository Git Repository
- 50.
- 51.
- 52. 補⾜：UnityPackageはどう管理する？ • Unity PackageManagerで管理できる • Unity標準のパッケージマネージャ機能 • まだ発展途上 • ⾃前でレジストリを⽴てればオレオレライブラリも管理可能 • 余⼒があるならコレで管理すると良さそう
- 53. 環境構築 • MagicOnionは環境構築がちょっとたいへん • クライアント側(Unity)は⼿動でライブラリ追加が必要 •コード共有 • コードジェネレート
- 54. コードジェネレートの話 • MagicOnionの動作にはコードジェネレートが2回必要 • MagicOnionのインタフェース定義 •MessagePackのオブジェクト定義 • ただし、ジェネレートが必要なのはUnity側のみ（サーバ側は不要） • ジェネレートしたコードはUnityプロジェクトに配置する
- 55.
- 56.
- 57.
- 58.
- 59.
- 60. コマンド例 ./moc/win-x64/moc.exe ‒i ./Server/ServerSample.Interfaces/ServerSample.Interfaces.csproj ‒o ./Unity/Assets/Scripts/Generated/MagicOnion.Generated.cs •MagicOnionのジェネレート例 • ServerSample.Interfaces.csprojをもとに、Unity/Assets/以下に⽣成
- 61.
- 62.
- 63. 環境構築 まとめ • 環境構築がちょっと⼤変 •csprojを編集する必要がある • コードジェネレートの整備が⼿間 • 開発フローはよく考えよう • Unity側とサーバ側、2つのプロジェクト管理を同時にやる必要 • gitリポジトリをどうわけるか、どういうフローで開発をすすめるのか • CI/CDとの相性
- 64. 今回の話 • MagicOnionについて解説 • 何のためのフレームワークか •どんな機能があるのか • 環境構築 • 実装例の紹介 • 実装時の注意点 • デプロイ
- 65.
- 66. 実装例 • それぞれの実装例を紹介 • Service •StreamingHub
- 67.
- 68. Serviceの実装例 • 実装⼿順 1. 共有するインタフェース/オブジェクトを定義 2.サーバに実装を書く 3. サーバにコネクションする 4. Unity側で呼び出す
- 69. Serviceの実装例 • 実装⼿順 1. 共有するインタフェース/オブジェクトを定義 2.サーバに実装を書く 3. サーバにコネクションする 4. Unity側で呼び出す
- 70.
- 71.
- 72. Serviceの実装例 • 実装⼿順 1. 共有するインタフェース/オブジェクトを定義 2.サーバに実装を書く 3. サーバにコネクションする 4. Unity側で呼び出す
- 73.
- 74.
- 75. Serviceの実装例 • 実装⼿順 1. 共有するインタフェース/オブジェクトを定義 2.サーバに実装を書く 3. サーバにコネクションする 4. Unity側で呼び出す
- 76.
- 77.
- 78.
- 79.
- 80. Serviceの実装は簡単 • リクエストに対して、処理を書いて、結果を返すだけ • かんたん •クライアント側は普通にasync/awaitでメソッドを呼ぶだけ • サーバ側はインタフェースを実装するだけ
- 81.
- 82. StreamingHubはムズカシイ • StreamingHubはリアルタイム通信を実現する機構 • クライアントとサーバが相互にメソッドを呼び出し合える •Serviceの実装と⽐べて複雑になりやすい • 「状態」がクライアントとサーバの両⽅で管理することになる • どのタイミングで何の処理が実⾏されるか、を整理しないとヤバイことになる
- 83. StreamingHubの実装例 • サーバサイドでPlayerとその座標を管理する • Playerは移動量をサーバに送って、移動先を更新する •Playerが移動したら全員に通知する • ⼊室時に既存のPlayer⼀覧を返す • Playerが⼊室/退室したら通知する • 単⼀のプロセスでのみ動く（プロセス間での協調は考えない）
- 84.
- 85. 動作例 クライアントA サーバ サーバ側で座標⼀覧を管理 クライアントB A: (1,0 ,0 ) B: (0, 0, 2 )
- 86. 動作例 クライアントA サーバ MoveAsync()をクライアントがコールすると サーバ上の状態が書き換わり クライアントB A: (1+1, 0 +0 ,0 +0 ) B: (0, 0, 2 ) MoveAsync( +1, +0, +0)
- 87. 動作例 クライアントA サーバ 新しい座標を全員に通知する クライアントB A: (1,0 ,0 ) B: (0, 0, 2 ) OnPlayerMoved( id: A, position: (1,0,0) ) OnPlayerMoved( id: A, position: (1,0,0) )
- 88. 動作例 クライアントA サーバ 新しいクライアントが接続してきたら サーバ側で新しいPlayerIdを発⾏して返す クライアントB A: (1,0 ,0 ) B: (0, 0, 2 ) C: (0, 0, 0) クライアントC Task<int> JoinAsync() => id: 12345
- 89. 動作例 クライアントA サーバ 既存のクライアントにPlayer⼊室イベントを送信する クライアントB A: (1,0 ,0 ) B: (0, 0, 2 ) C: (0, 0, 0) クライアントC OnPlayerJoined( id: 12345, position: (0,0,0) ) OnPlayerJoined( id: 12345, position: (0,0,0) )
- 90. 動作例 クライアントA サーバ クライアントCが既存のPlayerの状態⼀覧を サーバから取得して状態を再現する クライアントB A: (1,0 ,0 ) B: (0, 0, 2 ) C: (0, 0, 0) クライアントC Task<PlayerStatus[]> FetchCurrentAsync() A: (1, 0 ,0 ) B: (0, 0, 2 ) C: (0, 0, 0)
- 91.
- 92. 実装順序 • 実装順序 1. インタフェース定義 2.通信のオブジェクト定義 3. サーバ側実装 4. クライアント側実装
- 93. 例:座標管理 1. インタフェース定義 • 定義するインタフェースは2つある •サーバ → クライアント(Receiver) • クライアント → サーバ(Hub)
- 94.
- 95.
- 96. 2.通信のオブジェクト定義 • 通信に利⽤するデータ構造を定義する • MessagePackObjectとして定義する •（定義したあとはMessagePackのコードジェネレートが必要）
- 97.
- 98.
- 99. 3.サーバ側の実装 • StreamingHubの特性を覚えよう • １コネクションごとに新しいインスタンスが⽣成して割り当てられる •コネクションが維持されている限り同じインスタンスが使われる （インメモリで状態が保持され続ける）
- 100.
- 101.
- 102.
- 103. 3.サーバ側の実装 • PlayerManager • Playerの状態をインメモリで管理するシングルトンなオブジェクト •各Hubのインスタンスが同時にアクセスするオブジェクトなので、 中⾝の実装はThread Safeにつくる必要がある
- 104. 3.サーバ側の実装 • PlayerHub 1/5 •コンストラクタ
- 105. 3.サーバ側の実装 • PlayerHub 1/5 •コンストラクタ インメモリで状態を保持できる
- 106. 3.サーバ側の実装 • PlayerHub 1/5 •コンストラクタ PlayerManagerはDIで渡される
- 107. 3.サーバ側の実装 • PlayerHub 2/5 •新規参加処理「JoinAsync()」
- 108. 3.サーバ側の実装 • PlayerHub 2/4 •新規参加処理「JoinAsync()」 1. 新しいPlayerをPlayerManagerに作ってもらう 2. このHubをGroupに登録 3. 既存のクライアントにメッセージ発⾏ & My IDをreturn
- 109. 3.サーバ側の実装 • PlayerHub 2/4 •新規参加処理「JoinAsync()」 1. 新しいPlayerをPlayerManagerに作ってもらう 2. このHubをGroupに登録 3. 既存のクライアントにメッセージ発⾏ & My IDをreturn
- 110. 3.サーバ側の実装 • PlayerHub 2/4 •新規参加処理「JoinAsync()」 1. 新しいPlayerをPlayerManagerに作ってもらう 2. このHubをGroupに登録 3. 既存のクライアントにメッセージ発⾏ & My IDをreturn
- 111. 3.サーバ側の実装 • PlayerHub 2/4 •新規参加処理「JoinAsync()」 1. 新しいPlayerをPlayerManagerに作ってもらう 2. このHubをGroupに登録 3. 既存のクライアントにメッセージ発⾏ & My IDをreturn めっちゃ⼤事！！！
- 112. Group • Hub同⼠を束ねる機能 • マッチングに合わせてHubをグルーピングする機能 •⽂字列を指定してGroupに参加できる • 同じGroup内にメッセージをまとめて発⾏（Broadcast）できる
- 113. StreamingHubの「Group」 サーバプロセス PlayerHub PlayerHub PlayerHub クライアント メッセージのBroadcastは 同⼀GroupのHubにつないだクライアントに対して送ることができる Group “A” Group “A” Group“B” 同じGroup内なら メッセージが送れる Groupはまたげない Broadcast()
- 114. Broadcastの種類 • Broadcast(IGroup) • 指定Group内の、クライアント全員に送信 •BroadcastToSelf(IGroup) / BroadcastExceptSelf(IGRoup) • ⾃分に対してのみ送信 / ⾃分以外の全員に送信 • BroadcastExcept(IGRoup, Guid / Guid[]) • 指定Group内の、指定のクライアントを除く全員に送信 • BroadcastTo(IGRoup, Guid / Guid[]) • 指定Group内の、指定のクライアントのみへ送信
- 115. 3.サーバ側の実装 • PlayerHub 2/5 •新規参加処理「JoinAsync()」 今回はGroupは1つに固定 （参加したクライアントが全員同じ部屋にマッチングする）
- 116. 3.サーバ側の実装 • PlayerHub 3/5 •既存のPlayer情報を取得して返す
- 117. 3.サーバ側の実装 • PlayerHub 4/5 •移動処理 • 座標更新をしたあと、OnPlayerMovedメッセージをBroadcast
- 118.
- 119. 実装順序 • 実装順序 1. インタフェース定義 2.通信のオブジェクト定義 3. サーバ側実装 4. クライアント側実装
- 120.
- 121.
- 122.
- 123. 4.クライアント側 • 移動コールバック • サーバからPlayerの座標更新通知がくる •メッセージをもとに、そのIDのPlayerの座標を更新（描画）
- 124.
- 125. StreamingHubの実装 • Serviceより実装が複雑になりやすい • どの状態を、誰が保持して、どこまで再現するのか？の管理が⼤変 •StreamingHubのインスタンスがステートフルである • 後から接続したクライアントと既存のクライアントの同期をどこまで担保するか • クライアントとサーバの実装が密結合化する • データフロー、ロジックの流れを精査しないとグチャグチャになる • ドメインイベントを起因にしてメッセージを発⾏するスタイルがゴチャらなさそう
- 126. 「実装例の紹介」のまとめ • Serviceの実装は、かんたん • RESTAPIのControllerを作るのと⼤差ない • Filterと合わせると便利 • StreamingHubは、表現⼒が⾼いがムズカシイ • なんでもできそうな代わりに、整えるのが難しい • バックエンド側のアーキテクチャをかなり考える必要あり
- 127. 今回の話 • MagicOnionについて解説 • 何のためのフレームワークか •どんな機能があるのか • 環境構築 • 実装例の紹介 • 実装時の注意点 • デプロイ
- 128.
- 129. 覚えておくといいテクニックとか • クライアント側 • gRPCのコネクション管理ちゃんとやろう •サーバ側 • Server GC使おう • ThreadPoolのサイズを増やそう • Generic Host使おう
- 130.
- 131. gRPCのコネクション管理 • C#のgRPC Client（Channel）はUnmanaged •Channelを利⽤している部分のDisposeを忘れるとすぐリークする • Dispose漏れがある状態でコネクションを閉じようとすると、やばい • Unity Editorごと巻き込んでフリーズしたり、アプリが正しく終了できなかったり MagicOnionの場合は、MagicOnion ClientのDisposeを必ず呼ぶこと
- 132.
- 133. 希望の光 • マネージドgRPCクライアント「grpc-dotnet」 • .NETCore 3.0向け • Unityではまだ使えない • 今後に期待
- 134. サーバ側 • Server GCを使おう •ThreadPoolのサイズを増やそう • Generic Hostを使おう
- 135. Server GC • C#のGCモードを「Server」に切り替えよう •Background garbage collectionが有効になる • CPUリソースの消費量が増える代わりに、Stop-the-worldが短くなる
- 136.
- 137. 覚えておくといいこと（サーバ） • Server GCを使おう •ThreadPoolのサイズを増やそう • Generic Hostを使おう
- 138.
- 139. 覚えておくといいこと（サーバ） • Server GCを使おう •ThreadPoolのサイズを増やそう • Generic Hostを使おう
- 140. Generic Host • ASP.NETから汎⽤機能を分離した公式フレームワーク •メッセージング • バックグラウンドサービスの起動 • 依存関係の注⼊（DI） • ロギング • 設定ファイル(config)の読み込み • サーバアプリケーションで必須な機能をまとめた便利パッケージ
- 141. MagicOnion on GenericHost •「MagicOnion.Hosting」パッケージを追加すればOK • あとは起動処理をGenericHost⾵にすればOK
- 143.
- 144.
- 145.
- 146.
- 147.
- 148.
- 149.
- 150. 実装の注意点 まとめ • gPRCのコネクション管理はマジで気をつけよう •切断時の処理とか再接続とか考えると頭痛いけどガンバッテ… • Generic Hostを使おう • コレいれておけば雑務な部分は全部やってくれる • 既存のASP.NETの資産がそのまま流⽤できて便利
- 151. 今回の話 • MagicOnionについて解説 • 何のためのフレームワークか •どんな機能があるのか • 環境構築 • 実装例の紹介 • 実装時の注意点 • デプロイ
- 152.
- 153. デプロイ • どういう構成で、どこで、どうやって動かす？ • どこでビルドするの •どこでどう動かすの • MagicOnionのサーバ構成
- 154. デプロイ • どういう構成で、どこで、どうやって動かす？ • どこでビルドするの •どこでどう動かすの • MagicOnionのサーバ構成
- 155. どうするの • サーバで動かすならDockerビルドしよう • ビルドするならCircleCIが便利 • Kubernetesでコンテナ管理がよさ • もちろんコレ以外のやり⽅でもできるけど、多分コレが⼀番無難な選択だと思う
- 156. Kubernetes • Dockerコンテナのオーケストレーションツール • インフラ構成をyamlファイルで管理できる便利システム •yamlにどのマシン(Node)に、何のコンテナをどう起動するか(Pod)を書いて applyすればそのとおりにコンテナが起動してくれる • 開発元はGoogle • 現状、Dockerのデファクトスタンダード • AWS、GCP、Azureももちろん対応している
- 157. デプロイ • どういう構成で、どこで、どうやって動かす？ • どこでビルドするの •どこでどう動かすの • MagicOnionのサーバ構成
- 158. MagicOnionのサーバ構成 • ⼤きく分けて2つの構成が選べる • ステートフル構成 •ステートレス構成 • それぞれ⼀⻑⼀短ある
- 159. ステートフル構成 • プロセス側で状態を保持する構成 • 簡単にいうと「インメモリでデータを保持する」実装 •あるGroupに参加したいならそのGroupの状態を持っている インスタンスを選んで接続する必要がある
- 160. ステートフル構成 MagicOnionインスタンス（サーバプロセス） StreamingHub クライアント 各インスタンスに対応するGroupが決まっている Group “A” StreamingHub StreamingHub StreamingHub StreamingHub Group “B” Group“C” 状態(インメモリ) インスタンス X AとBを担当 インスタンス Y Cを担当
- 161.
- 162. ステートフル構成 • メリット • リアルタイム通信に向く •⼤量のメッセージのBroadcastがプロセス内で完結する • データの保持もインメモリで済む • 外部ストレージへのトランザクション処理が省略できる • インメモリで済む限りにおいて、外部ストレージを使わないので⾼速に処理可能
- 163. ステートフル構成 • デメリット • オートスケールしにくい、LBが使えない、停⽌メンテが必要になるかも •ステートフルなのでプロセスをいきなり落とすと死ぬ • LBの代わりに、サービスディスカバリの⽤意が必要 • Kubernetesと相性が悪い • External IP / Node Portの設定をがんばる必要がある • Agonesが使えたらマシになりそう
- 164. サービスディスカバリ • 「ホスト」と「インスタンス」の割当を管理するシステム インスタンス Xインスタンス Y Service Discovery インスタンスが保持する Groupの情報を同期 10.0.0.5:12345 10.0.0.6:12345
- 165. サービスディスカバリ • 「ホスト」と「インスタンス」の割当を管理するシステム インスタンス Xインスタンス Y Service Discovery 10.0.0.5:12345 10.0.0.6:12345 「 に繋ぎたい」 「10.0.0.5:12345につないでね」
- 166. Agones • GoogleとUbisoftが共同で開発している マルチプレイヤーゲーム向けのサーバ管理システム • Kubernetesと協調して動く •マッチングに合わせてコンテナの起動、接続、停⽌を管理してくれる • OSS • 2019年9⽉にv1.0.0が出たばかり • Ubisoftが使っていた実績はあるが、巷に知⾒があまりない • 興味がある⼈は⼿を出すとよさそう
- 167. ステートレス構成 • プロセス上に状態を持たない構成 • MagicOnionのプロセス同⼠がバックエンドで協調して動く •どのインスタンスにつないでも好きなGroupに参加できる
- 168. ステートレス構成 MagicOnionクライアント クライアントはMagicOnionのホストがどうなっているかを 意識せずにすきなGroupに参加できる Group “A” Group “B” Group“C” RedisGroup “B” Group “A” Group “A” Group “C” Load Balancer MagicOnionのメッセージは Redis pub/sub経由でBroadcast
- 169. ステートレス構成にするには • バックエンドにRedisが必要 • RedisClusterをバックエンドに組む必要がある • MagicOnionに追加のパッケージが必要 • 「MagicOnion.Redis」を追加
- 170. ステートレス構成 • メリット • オートスケーリングができる •Load Balancerで負荷分散できる • ローリングアップデートしやすい • Kubernetesもニッコリ
- 171. ステートレス構成 • デメリット • リアルタイム通信に向いてない •メッセージのBroadcastにプロセスをまたぐ必要がある • データストレージへのトランザクション管理 • パフォーマンスがRedis依存 • MagicOnionがバックエンドにRedis pub/subを利⽤するため • Redis Clusterを組んでてもpub/subの性能はさほど向上しない • ⼤規模になるとここが⼀番ツライことになる
- 172. 構成についてのまとめ • リアルタイム通信なら「ステートフル」のほうがオススメ • ただしKubernetes周りが結構キビシイ •Agonesなんとかしてくれー！！！ • サービスディスカバリは⾃前で作るのがヨサソウ
- 173.
- 174. MagicOnionについてのまとめ • サーバサイドもC#で「いい感じ」にサーバが作れる • ゲーム向けのリアルタイム通信⽤途にも耐えうる •クライアントとサーバをC#で統⼀できる • クライアントエンジニアをそのままサーバ開発に回せる • 最新のC#を使える！楽しい！
- 175. ただし… • 開発フローの整備が課題 • クライアントとサーバがかなり密結合する •プロジェクト全体でフローを決めないと混乱しそう • サーバサイドの開発知識はある程度必要 • クライアントエンジニアを即⽇でサーバ開発に回すのはキビシイ • ある程度のスイッチングコストは⾒越しておくべき
- 176. 総評 • 「MagicOnioは、いいぞ。」 • サーバサイドもC#で書けるのは、結構気持ちいい（個⼈の感想） •クライアントとサーバの開発の境⽬がなくなる • MagicOnionというか、Kubernetesの運⽤の⽅がムズい • Agonesに期待