河合 宜文 / Kawai Yoshifumi / @neuecc
Cysharp, Inc.
Cygames
C#大統一理論
C#

Slido
https://www.sli.do/

Usage of MagicOnion

Unified Realtime/API Engine for .NET Core and Unity
https://github.com/Cysharp/MagicOnion/
・2017/06 - Ver.1, 「黒騎士と白の魔王(iOS/Android)」
・2018/12 - Ver.2, StreamingHub, Hosting
gRPC(HTTP/2)ベースの統合型ネットワークエンジン
サーバーを通したRPCの提供(のみ)
C#特化、C#フレンドリーなAPIの実現に力を注いだ
ビルトインの超高速で柔軟性の高いシリアライザ(MessagePack for C#)
を、（シリアライザの作者なので)100%活かしきった設計

Remote
Procedure
Call
ネットワーク越しの
メソッドを
呼ぶ
public class TestService : ITestService
{
public async UnaryResult<int> Sum(int x, int y)
{
return x + y;
}
}
var client = MagicOnionClient.Create<ITestService>(channel);
var result = await client.Sum(100, 200);

Unity Editor
MagicOnion
(Local Machine)
Testing
Logic on Server

Unity Editor
MagicOnion
(Local Machine) Unity Editor
Share Workspace

MagicOnion
(Local Machine)
Unity Editor
Concurrent Bake, Build
Control Many Headless Unity
Unity Editor
Unity Editor
Unity Editor

Unity Editor
MagicOnion
(Local Machine) Windows(Mac)
Sync Parameters

Unity Editor
MagicOnion
(Local Machine) External Tools
Send External Data
Sync from DCC Tools

MagicOnion
(Local Network)
iOS
Android
Windows(Mac)
Unity Editor
Sync Parameters
View Debug Info

MagicOnion
(Local Network)
iOS
Android Unity Editor
Windows(Mac)
Mutiplayer(Local Network)
for LAN VS, VR Exhibition

MagicOnion
(Local Network)
iOS
Android Unity Editor
Windows(Mac)
External Tools
Edit Server Data(Debug)

MagicOnion
(Internet)
iOS
Android Unity Editor
Windows(Mac)
Multiplayer(Planet Scale)

MagicOnion
(Internet)
MagicOnion(CUI) MagicOnion(CUI)
MagicOnion(CUI) MagicOnion(CUI)
Load Testing

MagicOnion
Not Only for Unity
Microservices
MagicOnion

MagicOnion
Good Old Legacy Model
Replacement of SOAP/WCF
GUI Tool

MagicOnion
GUI Tool
iOS
Android Unity Editor
Windows(Mac)
CUI Tool
MagicOnion
MagicOnion

究極の土管
ネットワーク通信における究極の抽象化で最小公倍数
Client <-> Server RPCさえあれば、なんでも実装できる
Unityに依存しないことであらゆる使い方ができるように
一つのSimpleなやり方で、どこまでも応用が効く
サーバープログラムを透明にしない
サーバーもクライアントもどちらも大事
適切な場所に適切なコードが書けることを最重要視する
（クライアントだけの比重を高めてデータを左から右に流すだけの土管は違う）
そのうえで、余計なものがついてないシンプルさを土管とする

究極の土管
ネットワーク通信における究極の抽象化で最小公倍数
Client <-> Server RPCさえあれば、なんでも実装できる
Unityに依存しないことであらゆる使い方ができるように
一つのSimpleなやり方で、どこまでも応用が効く
サーバープログラムを透明にしない
サーバーもクライアントもどちらも大事
適切な場所に適切なコードが書けることを最重要視する
（クライアントだけの比重を高めてデータを左から右に流すだけの土管は違う）
そのうえで、余計なものがついてないシンプルさを土管とする
世の中のウェブサイトはWordPressだけじゃないでしょ！
WordPressは大事で重宝されるけど、普通に開発だったら誰も
がRailsとか使って書くでしょ！

究極の土管
ネットワーク通信における究極の抽象化で最小公倍数
Client <-> Server RPCさえあれば、なんでも実装できる
Unityに依存しないことであらゆる使い方ができるように
一つのSimpleなやり方で、どこまでも応用が効く
サーバープログラムを透明にしない
サーバーもクライアントもどちらも大事
適切な場所に適切なコードが書けることを最重要視する
（クライアントだけの比重を高めてデータを左から右に流すだけの土管は違う）
そのうえで、余計なものがついてないシンプルさを土管とする
コンポーネント貼っつけてTransform同期みたいなEasyさはいらな
い（どうせそれ以外の要件やパフォーマンス問題で、アプリケー
ション要件に沿った機構を作る）
クライアント-サーバー間RPCをC#としてどれだけ書き味を高め
られるか（要件にあったカスタマイズがしやすいか）を究極的に
追求しているのがMagicOnion

Dedicated Server is Good
ってみんな（？）言ってる
P2Pは繋がらない場合リレーサーバー経由で動かす
などなど、実は複雑
「サーバーを通して通信する」で統一して考えるだけで
めっちゃSimpleにすっきりしたりする（応用例もずっと広がる）
インフラ知識やサーバー代に関する話は、後述しますが、世の中ど
んどん良くなっていってるので意外と大丈夫（になるといいなぁ）

MagicOnion Patterns

LinkBase
https://github.com/Cysharp/MagicOnion/tree/master/samples
(sample includes how to code-share, code-generate, setup resolver, cleanup,
register disconnect action)
<ItemGroup>
<Compile Include="..¥ChatApp.Unity¥Assets¥Scripts¥ServerShared¥**¥*.cs"
LinkBase="LinkFromUnity" />
</ItemGroup>
サーバー側のcsprojのほうが融通の効いた記述が
可能なので、Unity側にコード実体を置いて、サー
バー側ではリンク参照にする

MagicOnion.Hosting
基本的にはこのパッケージを使って動かすことを推奨
コンフィグ/ロギング/DIやコンテナ上での動作などをサポート
static async Task Main(string[] args)
{
await MagicOnionHost.CreateDefaultBuilder()
.UseMagicOnion(
new MagicOnionOptions(isReturnExceptionStackTraceInErrorDetail: true),
new ServerPort("localhost", 12345, ServerCredentials.Insecure))
.RunConsoleAsync();
}
Server上で動かす場合は0.0.0.0に変更する
本番ではfalseにする
ASP.NET CoreなどC#標準のウェブフレーム
ワークと同じ仕組みに乗っかっています
（のでノウハウが共有できる)

use Docker
サーバーでの実行はコンテナ化を推奨しています
よくわかんなくても、Cloud NativeでKubernetesでContainerizeで
Serverlessでイケてるらしいんで、そういうことにしましょう！
FROM mcr.microsoft.com/dotnet/core/sdk:2.2 AS sdk
WORKDIR /workspace
COPY . .
RUN dotnet publish ./SampleServer/SampleServer.csproj -c Release -o /app
FROM mcr.microsoft.com/dotnet/core/runtime:2.2
COPY --from=sdk /app .
ENTRYPOINT ["dotnet", "SampleServer.dll"] よくわかんなくてもこれをDockerfileとして置いて
おけばOK(csprojへのパスやDLL名は変える)

use CircleCI with AWS ECS(or Azure or GCP)
CIはCircleCIをお薦めしています（無料でも使えますよ！）
version: 2.1
orbs:
aws-ecr: circleci/aws-ecr@3.1.0
aws-ecs: circleci/aws-ecs@0.0.7
workflows:
build-push:
jobs:
# see: https://circleci.com/orbs/registry/orb/circleci/aws-ecr
# AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION, AWS_ECR_ACCOUNT_URL
- aws-ecr/build_and_push_image:
repo: magiconionsample
# see: https://circleci.com/orbs/registry/orb/circleci/aws-ecs
# AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION
- aws-ecs/deploy-service-update:
requires:
- aws-ecr/build_and_push_image
family: magiconionsample
cluster-name: magiconionsample-cluster
service-name: magiconionsample-service
container-image-name-updates: 'container=magiconion,tag=latest'
とりあえずこれを置いておけばビルドとデ
プロイが自動化される
AWS_ACCESS_KEY_IDなどを自分のものに設
定してもらうのと、作ったクラスタ名など
を置き換えてもらえればOK

Microser
vices
Realtime
Server
Unity
Native App
Browser
API
Server

Unary API
リクエスト/レスポンス型
public class TestService : ITestService
{
public async UnaryResult<int> Sum(int x, int y)
{
return x + y;
}
}
var client = MagicOnionClient.Create<ITestService>(channel);
var result = await client.Sum(100, 200);

iOS
Android
MagicOnion MagicOnion
MagicOnion MagicOnion
Windows(Mac)
クライアント-サーバーが1:1で繋がりっぱになりますが、
クライアントのほうがサーバー郡よりも圧倒的多数なの
で、サーバーの増減があってもすぐバランシングされる
ので、ただのTCPロードバランサーでOK

StreamingHub
グループ管理とブロードキャスト受信

Matching Service
MagicOnion MagicOnion
MagicOnion MagicOnion
Game Client

Matching Service
MagicOnion MagicOnion
MagicOnion MagicOnion
Game Client
APIサーバーとして自前管理 or Open Match
https://github.com/GoogleCloudPlatform/open-match
（今の所のOpen Matchの完成度的には自前管理のほうがいいかも)

Matching Service
MagicOnion MagicOnion
MagicOnion MagicOnion
Game Client
サーバーのオートスケーリングの管理はKubernetes + Agones
https://github.com/GoogleCloudPlatform/agones
というのがある（AgonesはUBI製で実績あり）

iOS
Android
MagicOnion
MagicOnion
MagicOnion
Windows(Mac)

iOS
Android
MagicOnion
MagicOnion
MagicOnion
Windows(Mac)
RedisのPub/SubでMagicOnionクラスタを繋ぐことにより、
特定のサーバーへのメッセージを全サーバーに伝達して、
別のサーバーに繋がっているクライアントにメッセージを
届ける
MagicOnion.Redis

public class AuthenticationFilter : MagicOnionFilterAttribute
{
public override ValueTask Invoke(ServiceContext context)
{
var token = context.CallContext.RequestHeaders
.FirstOrDefault(x => !x.IsBinary && x.Key == "auth-token");
if (token != null)
{
var decoder = context.ServiceLocator.GetService<LitJWT.JwtDecoder>();
if (decoder.TryDecode(token.Value,
x => JsonSerializer.Deserialize<int>(x.ToArray()), out var id)
== LitJWT.DecodeResult.Success)
{
context.Items["UserId"] = id;
return Next(context);
}
}
throw new Exception("not found authentication key");
}
}
Headerに埋め込んでサーバー側では
Filterで取り出す
ServiceContext.Itemsに格納
LitJWT
https://github.com/Cysharp/LitJWT

Matching(Authenticate) Service
MagicOnion MagicOnion
MagicOnion MagicOnion
Game Client
Create JWT
Auth Serviceで得られたJWT
をそのままヘッダに入れる
Realtime Serverではバックエンド
に認証DBを持たなくてもJWTの検
証でユーザー認証できる

Create Dashboard
Datadog, Prometheus, CloudWatch, ApplicationInsights, etc...

public class TelemetryFilter : MagicOnionFilterAttribute
{
public override ValueTask Invoke(ServiceContext context)
{
try
{
// リクエスト開始の記録
return Next(context);
}
catch
{
// Errorの伝達
throw;
}
finally
{
// リクエスト終了の記録
}
}
}
public class TelemetryLogger : IMagicOnionLogger
{
void BeginBuildServiceDefinition();
void EndBuildServiceDefinition(double elapsed);
void BeginInvokeMethod(ServiceContext context, by
void EndInvokeMethod(ServiceContext context, byte
void BeginInvokeHubMethod(StreamingHubContext con
void EndInvokeHubMethod(StreamingHubContext conte
void InvokeHubBroadcast(string groupName, int res
void WriteToStream(ServiceContext context, byte[]
void ReadFromStream(ServiceContext context, byte[
}
FilterとLoggerを使って自分で使っているダッ
シュボードサービス用のAPIに向かって投げる

Roadmap

Native gRPC(C Core) is Dead
C Coreは別にいいんだけど標準C#バインディング実装がダメ
性能的に不満しかない(あとUnityではフリーズしやすい)
サーバー側はMicrosoftがMS実装のハイパフォーマンスなウェブ
サーバー(Kestrel)の拡張としてPure C#実装を準備中
Unityで使うクライアント実装を独自に作る
StreamingHubのゼロアロケーションの達成とECSとの親和性の追求
RUDP/QUIC
UNIX domain socketが許されるなら転送方式はなんでもよくね？
Server/Clientが両方Pure C#なら自由に拡張できるのでやりたい放題

New Code Generator
IL2CPP環境向けに最大のパフォーマンスを引き出すためにコード
ジェネレーターは必須（リフレクションベースは絶対やらない）
MessagePack Compiler(mpc)
MagicOnion Compiler(moc)
どちらも挙動がめっちゃ不安定で苛立たしい(離脱ポイント)
安定したコードジェネレーターの作成が急務

while(true) { await tick; }
現在のStreamingHubはクライアントのメソッド呼び出し起因でし
か、ブロードキャストイベントを呼べない。
サーバー側でも一定間隔でグループへのアクセスを可能にすること
で、AIがルーム管理したり、コマンドをキューイングしてから処理
するなどが可能になる。
（MagicOnionの実例である「黒騎士と白の魔王」もこの方式）
ゲーム作成に必須と考えていて、今日リリース！したいと思ってた
んですが間に合わなかったのでまだですが近日中には……！

テレメトリの仕様共通化
https://opentelemetry.io/
今年11月ぐらいに策定完了（予定）
MagicOnion
標準実装(MagicOnion.Telemetry(予))を一つ用意するだけで、
あらゆる監視サービスに対応できるようになるので、ユー
ザーが自分でFilter/Loggerを書く必要がなくなる

Google CloudRun
未来はServerless(Not FaaS, mBaaS)。
インフラ構築大変だし、お高いんでしょ、に対する答え。
接続がある間だけ起動し、接続がなくなったら自動終了
使った分だけ課金
無料Tierあり
まだgRPC対応していないのでただの理想？
でも(Googleだし)近い内に実装されそう
MagicOnionがgRPC(HTTP/2)という標
準プロトコルに乗っかっている強
みの一つ

Conclusion

流行るための要素の追求
gRPC(HTTP/2)に乗っかっている、などスタンダードへの意識
オープン(ソース)な開発姿勢
スタンドアロンでの動作やUnity以外でも動くなど間口を広げる
その上でUnityやC#に対する親和性を高める工夫の追加
知識の連続性
UniRxが他の言語でも使える概念、であったように
MagicOnionに含まれるgRPCやコンテナの知識は無駄にならない
学習コストを未来で確実に償却できるようなデザイン

今は時代の変わり目
リアルタイム通信がほぼ必須だったり、5Gが迫っていたり
サーバーはコンテナ化が主流になりUnityはECSで大変革
旧来の手法から大きく変わるタイミング
一歩先の理想形を描く
ただの旧来のXXの置き換えなどではなく、
誰も見たことのない究極的な理想の形に近づけていく
MagicOnionはC#を主軸にして理想を具現化したフレームワーク
新しい世界を一緒に追求しましょう！

もし不安があるのならお問い合わせフォームへ
https://cysharp.co.jp/contact/
サーバーサイドC#実現の「離陸のお手伝い」をします
本気でC#をやりたい、というチームに対して、最大限のアドバ
イスとノウハウの提供をすることで、初めての不安を払拭し、
安心してコンテンツの開発に集中できるように
開発の全面請負はしません
C#の開発会社が増えることをミッションにしています
（リサーチやSDK開発、負荷テスト協力などは要相談）