MagicOnionサーバーのパフォーマンス調査と.NET更新によるパフォーマンス改善

MagicOnionサーバー のパフォーマンス調査 と.NET更新によるパ フォーマンス改善 とうとう 1

自己紹介 ● とうとう( X :@__tou__tou ) ○ VRコミュニケーションを支えるエンジニア ○ 領域：インフラ・リアルタイムサーバー ● 上級バーチャルリアリティ技術者（日本バーチャルリアリティ学会） ● VRChat でよく遊んでいます 2

• https://twitter.com/__tou__tou

お題 ● ● ● ● ● 負荷試験の背景・目的 MagicOnionの概要 MagicOnionを利用したクラウドアーキテクチャ GKE・DFrameを利用した負荷試験環境の構築 負荷試験結果・考察 ○ ○ ○ ○ 限界性能と .NET更新によるパフォーマンス向上 インスタンスガチャの存在 dotTraceによるプロファイリング 同時接続人数 ● 負荷試験の費用 3

背景 ● メタバース等ではユーザーの位置情報を共有するために MagicOnion等のリアルタイムサーバーを利用 ● サーバー1台で運用可能なルーム数や同時接続人数を把握す ることは「安定したユーザー体験の提供」や「サーバー料金のコ スト効率を高める」ために重要 4

目的 ● 負荷試験により、MagicOnionサーバーの1台あたりの同時接 続人数を測定 ● .NET 更新によるパフォーマンス改善 5

MagicOnionの概要 6

MagicOnionの概要 ● .NETベースの 双方向 RPC フレームワークであり、リアルタイ ム通信を提供 ● サーバー・クライアントをともに C# で実装可能 ○ クライアントは Unity にも対応している ● 開発は Cysharp 社で MIT ライセンス ○ MagicOnion - GitHub 7

• https://github.com/Cysharp/MagicOnion

MagicOnionを利用した クラウドアーキテクチャ 8

シングルサーバー構成 構築は簡単だけど、サーバー数がス ケールしないので、トラフィックが増え るとボトルネックになる MagicOnionサーバーの1 プロセスは 複数の room（実装上はGroup）を持 つことができる room a room b https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide より 9

• https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide

サービスディスカバリ構成 room c に接続 したい room a room b サーバー台数がスケールした場 合でも、 接続したい room を持つ サーバーのネットワーク上の位 置を教えてくれる room c room d room e room f https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide より 10

• https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide

ロードバランサ + Pub/Sub 構成 LB room a あるMagicOnionサーバーから別の MagicOnionサーバーへメッセージを 転送 NATS の代わりに Redis Pub/Sub が 使われることもある room a room a room a https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide より 11

• https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide

負荷試験環境の構築 12

負荷試験対象：シングルサーバー構成 今回の負荷試験では、 MagicOnion サーバー 1 台あたりの性能 を評価 スケーリング性能は評価しない https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide より 13

• https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide

負荷試験環境 Google Kubernetes Engine : コンテナ化したアプリのデプロイ、管 理、スケーリングを担う, MagicOnionに接続するための Client を沢山用意するために利用 DFrame (Cysharp) : C# 製の負荷試験フレームワーク, C#で負荷シナリオを記述できるので 自由度が高い,Unityでも利用できる （が今回は通常の.NET版を利用） 14 Google Kubernetes Engine を使用したロード バランシング テスト を参考に構築

• https://cloud.google.com/kubernetes-engine/?hl=ja
• https://github.com/Cysharp/DFrame/
• https://cloud.google.com/architecture/distributed-load-testing-using-gke?hl=ja

負荷試験環境 WebUI を提供 相当 15

MagicOnionサーバーのデプロイフロー 16

負荷試験環境のデプロイフロー 17

負荷試験結果 18

ストレステスト サーバーの限界性能を評価 19

実験条件 ● Platform : .NET6.0, .NET8.0, .NET 9.0 ● Server Spec ○ ○ n1-standard-1（vCPU 1 個, Mem 3.75GB） CPU : Intel SkyLake ● MagicOnion6.1.5 のStremaingHub の HTPP/2 通信 (not https) ● csproj はほぼデフォルト設定 ○ 最適なパラメーターがあるはずだが今回は未検証 ● 1 room に 32 client が接続 ● 10分間、各 client が server に対して可能な限り高頻度で位置情報 をランダムに更新するリクエストを送信 ● 各 Platform において 5 回ずつ計測（合計 5×3=15 回計測） 20

結果の 一 例 1 client の結果 Latencyの統計値と RPS (Request Per Second) 32 client 合計の 秒間リクエスト数 21

.NET6,.NET8,.NET9 のパフォーマンス比較 .NET 8.0 .NET 6.0 5605 ± 192 RPS (平均±標準偏差) 15 % 向上 6430 ± 162 RPS (平均±標準偏差) 23 % 向上 .NET 9.0 7 % 向上 6896 ± 219 RPS (平均±標準偏差) 22

ストレステストにおける注意事項 ● worker（ client ）の計算リソースが十分であるか ○ 不足していると、サーバーに十分な負荷がかからない ● サーバーCPUに十分負荷がかかっているか ● インスタンスガチャ ○ CPUを指定しない場合、インスタンス性能バラつきが大きくな る ● メモリが十分か ● ネットワーク帯域が十分か 23

client の計算リソースが十分か VMインスタンス上で複数 の client が稼働 CPU 使用率 80% 未満な ので計算リソースは十分 ≒ サーバーに十分な負荷が かけられている 24

サーバー CPUに対する十分な負荷 CPU 使用率が 100 % に 張り付いている ≒ 十分な負荷 25

インスタンスガチャ ストレステストの結果 (MagicOnion on .NET 9.0) 同実験条件であるはずだ が、結果にバラつきがある ????? 6896 ± 219 RPS (平均±標準偏差) インスタンスの性能に バラつきがある？ → インスタンスガチャ 26

インスタンスガチャ ● 本実験で利用したマシンタイプは n1-standard-1 ● N1 はデフォルトで以下のいずれかの CPU が割り当てられる CPUの周波数が異なれば パフォーマンスに影響 ただし、本実験では CPUを 指定してインスタンスを作 成しているので CPU ガ チャの影響は小さい https://cloud.google.com/compute/docs/cpu-platforms?hl=ja より 27

• https://cloud.google.com/compute/docs/cpu-platforms?hl=ja

インスタンスガチャ ● そもそもクラウド上の仮想マシン（VM）は物理マシンがホスト ● n1-standard-1 における 1 は vCPU の数 である ● N1シリーズ(CPU : Skylake) を提供する物理マシンのCPU ○ インテル® Xeon® Platinum 8170M プロセッサー ○ 26コア52スレッド ● 1 個の vCPU は 1 スレッドで実現（ハイパースレッディング） ○ 1 個の物理コアで 2 個の vCPU を実現 ● つまり、物理マシン上のコアの稼働状況の影響を受けるはず ● これ以外にも、ネットワーク I/O や ネットワーク帯域、CPU、メモリの劣化 とかもありそう？？？ 28

• https://www.intel.co.jp/content/www/jp/ja/products/sku/120507/intel-xeon-platinum-8170m-processor-35-75m-cache-2-10-ghz/specifications.html

インスタンスガチャ 負荷試験において インスタンスガチャが発生するのは仕方がない！！！ → 複数回測定するべき どうしてもガチャが嫌ならベアメタルマシンを利用するといった 解決策もある（？） ベアメタルマシン：特定の物理サーバーをそのまま専用リソースとして利用す るコンピューティング環境 29

ルーム割り振り性能 30

client の room 割り振りで RPS が変化 32 room, 各 room に 1 client 接続 16 room, 各 room に 2 client 接続 8 room, 各 room に 4 client 接続 4 room, 各 room に 8 client 接続 1 room, 各 room に 32 client 接続 ● 同時接続人数が同じでも、room の割り振り方でRPSが変化 ○ ○ 1 room に 32 client 接続する場合は、[サーバーは1 client のリクエストを 32 client 転送] × 32 → N × N の処理なので重い 32 room で各 room 1 client 接続の場合は [サーバーは 1client のリクエス トをclientに送り返す] × 32 → N の処理なので軽い 31

dotTraceによるプロファイリング パフォーマンスのボトルネックや パフォーマンス向上の寄与原因を調査 32

プロファイリング（ .NET6 と .NET9） .NET 6.0 .NET 9.0 パフォーマンス向上の 寄与要因は 何だろうか？ 6896 ± 219 RPS (平均±標準偏差) 5605 ± 192 RPS (平均±標準偏差) 23 % 向上 33

プロファイリング ● dotTrace の Sampling Mode を利用 ○ https://www.jetbrains.com/help/profiler/dotTrace_Introduction.h tml ● .NET6と.NET9のプロファイルを比較 ● 単体のプロファイルでどのあたりがボトルネックかを確認 ○ csproj で最適なパラメータにあたりをつけて調整することが可能 34

• https://www.jetbrains.com/help/profiler/dotTrace_Introduction.html

プロファイリング結果 (.NET6と.NET9) 35

プロファイリング結果 (.NET6と.NET9) CPU スレッド時間：各スレッド がCPUを使って処理を実行し た合計時間 (.NET6) (.NET9) 例えば、負荷試験は 10分間 = 600,000 ms (CPU時間) で あるが、CPUスレッド時間は それ以上の値となる .NET9 の方が.NET6より CPU スレッド 時間が多い その分だけ多くの処理を行っている 36

プロファイリング結果 (.NET6と.NET9) System code : 主にThread 関係の処理、ソケット Read/Send のシステムコー ル File I/O : アプリケーションレ イヤでのストリーム読み書き Sleep : スレッドの待機時間 .NET9 の方が.NET6より ● System Code が増加 ● File I/O と Sleep が減少 つまり、Thread関係の処理や通信周り の処理が最適化された？ 37

プロファイリング結果 (.NET6と.NET9) System code の中で処理時間 が増加した関数を列挙 (.NET6) (.NET9) 38

.NET のリリースノート .NET 7.0 .NET 9.0 https://learn.microsoft.com/ja-jp/dotnet/core/whats-new/dotnet-9/overvie w ● ● https://learn.microsoft.com/ja-jp/dotnet/core/whats-new/dotnet-7 .NET6 -> .NET9 の間で様々なパフォーマンス向上（特 に.NET7） .NET 6 の LTS はサポート切れなので、次の LTS の .NET 8 への更新は手軽なパフォーマンス向上に繋がる 39

• https://learn.microsoft.com/ja-jp/dotnet/core/whats-new/dotnet-7
• https://learn.microsoft.com/ja-jp/dotnet/core/whats-new/dotnet-9/overview

同時接続人数を測定 40

実験条件 ● Platform : .NET 9.0 ● Server Spec ○ n1-standard-1, n1-highcpu-4, n1-highcpu-16 ○ CPU : Intel SkyLake ● MagicOnion6.1.5 のStremaingHub の HTPP/2 通信 (not https) ● csproj はほぼデフォルト設定 ● 10分間、各 client が server に対して約 14 ms 毎 (72 fps) で位置情報を ランダムに更新するリクエストを送信 ● CPU 使用率が 90-95 % となるまで 1 room の同時接続人数を増やす 41

n1-standard-1 同時接続 32 client で CPU 使用率 約95% 42

n1-higchcpu-4 同時接続 64 clientで CPU使用率が約95 % 43

n1-higchcpu-16 同時接続128 client で CPU使用率約90% 44

1 room の同時接続人数と必要な vCPU数 二次関数的に増加 32 人 -> vCPU 1 個 64 人 -> vCPU 4 個 128 人 -> vCPU 16個 1 インスタンスで実 現する 1 room の 同時接続数には限 界がありそうだ な..... 45

さらに同時接続人数を増やすには？ ● ハードウェアのスペックアップ ○ vCPU を増やす！ ■ お金の力で解決 ● ソフトウェアの工夫 ○ 自身から遠いユーザーの位置は同期しないor同期頻度を下げる ● クラウドアーキテクチャを見直す 46

ハードウェアのスペックアップ ● お金の力で vCPU を増やす！ ○ ただし、同時接続人数に対して二次関数的にvCPU数が必要になるの課 金額も二次関数的に増える (vCPU数と課金額は線形) https://cloud.google.com/compute/vm-in stance-pricing?hl=ja#compute-optimized _machine_types より 47

• https://cloud.google.com/compute/vm-instance-pricing?hl=ja#compute-optimized_machine_types

クラウドアーキテクチャの見直し：ロードバランサ + Pub/Sub 構成 LB room a 1 room を複数のインス タンスで構成する room a room a room a https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide より 48

• https://github.com/Cysharp/AlterNats?tab=readme-ov-file#architecture-guide

負荷試験の費用 49

費用 50

まとめ 51

MagicOnionパフォーマンスまとめ ● .NET6 -> NET9 の更新で 23 % パフォーマンス向上 ● n1-standard-1 (vCPU 1 個) のマシンで 最大 16369 RPS ○ 32 client が 1 client 1 room で接続し、各 client が可能 な限り高頻度でリクエストを送信 ● 1 room に 128 人の同時接続が可能 ○ n1-highcpu-16 (vCPU 16 個) のマシンを使った場合 ○ CPU 使用率が約90%基準 ○ 各 client が約 14 ms に1 回の頻度でリクエスト送信 52