SlideShare a Scribd company logo
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
河合 宜文 / Kawai Yoshifumi / @neuecc
C#
Unity
株式会社グラニ
http://grani.jp/
gRPC + AWS
gRPC Application - API Service/Realtime Server
Monitoring and Tools
gRPC + AWS
gRPC Application - API Service/Realtime Server
Monitoring and Tools
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
iOS/Android用のモバイルRPG
リアルタイムバトル
C#
gRPC
What
Why
How
gRPCはHTTP/2ベースのRPC
GoogleによるオープンソースRPC実装
2種のフレームワークの統合
Unity用リアルタイム通信のスタンダード
勿論、パフォーマンスへの期待
C#版のgRPCはある、Unity版はない
移植 + 高レベルフレームワークを作成
https://github.com/grani/gRPC
https://github.com/neuecc/MagicOnion
C#版のgRPCはある、Unity版はない
移植 + 高レベルフレームワークを作成
https://github.com/grani/gRPC
https://github.com/neuecc/MagicOnion
リリース!
プロジェクト始動!
当時はWebSocket(C#)
でリアルタイム通信
gRPCプロジェクト始動!
Unity用のgRPCは存在しないので
Unity + iOS/Androidで動くよう移植から
スタート(つまり動くかも未検証)
この辺でWeb APIも含めて
完全移行完了(ギリギリ
某ネットワークミドルウェアに
リアルタイム通信を載せかえる、
Web APIはHTTP/1で継続
with AWS
Service2
BattleEngine
Service2
BattleEngine
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
Service2 - ELB(TCP)
BattleEngine - Lambda
デプロイでリクエストぷちっと切れる問題
Draining and Client Disconnect
Make gRPC Application
using
ようはConsole Application(not IIS)
with HTTP/1
ようはConsole Application(not IIS)
with HTTP/1
gRPC based HTTP/2 RPC Streaming Framework
https://github.com/neuecc/MagicOnion
https://github.com/neuecc/MessagePack-CSharp/
gRPC based HTTP/2 RPC Streaming Framework
https://github.com/neuecc/MagicOnion
https://github.com/neuecc/MessagePack-CSharp/
言語の違うREST
Response型を別々
に書く
APIクライアント
を手書きする
(ザ・マイクロ
サービスみたいな
構成)
中間IDLを書く
そこからクライア
ント・レスポンス
型自動生成
(←を嫌う時によ
くある構成、一番
メジャー)
サービスを普通に
書く、そこからク
ライアントを自動
生成、リクエス
ト・レスポンス型
はC#のDLLとして
共有
サービスを普通に
書く、クライアン
トはそのプロジェ
クト参照から実行
時動的生成
public class TestService : ITestService
{
// パブリックメソッドがそのままgRPC定義
public async UnaryResult<int> Sum(int x, int y)
{
// async/awaitにも自然に対応
// マジカル技術によりasync Task<T>じゃなくてもawait可能
await Task.Yield();
return x + y;
}
}
// 普通のgRPCの接続を作る(MagicOnion用の特別なことはない)
var channel = new Channel("127.0.0.1:12345");
// 自然な書き味で、タイプセーフにRPC通信を実現
// C#のasync/await構文により、非同期通信も自然に見える
var client = MagicOnionClient.Create<ITestService>(channel);
var result = await client.Sum(100, 200);
struct DynamicTuple
{
public int item1;
public int item2;
}
gRPC IN(byte[])
gRPC OUT(byte[])
RPC Method
MagicOnion Filters
IDL Less HandlerSelector
MessagePack(with LZ4) Deserialize
MessagePack(with LZ4) Serialize
// filter can attach per global/class/method
public class SampleFilterAttribute : MagicOnionFilterAttribute
{
public override async Task Invoke(ServiceContext context)
{
try
{
/* before invoke next */
await Next.Invoke(context);
/* after invoke next */
}
catch (Exception ex)
{
/* when exception */
}
finally
{
/* finalize */
}
}
}
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
開発環境用API実行機
InMemory BattleEngine
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
var thread = GameLoopThreadPool.GetThread();
while (true)
{
var shouldContinue = frameAction(this);
if (!shouldContinue) break;
await thread.NextFrame();
}
Monitoring and Tools
https://www.datadoghq.com/
SaaS形式のモニタリングサービス
「黒騎士と白の魔王」ではアプリケーション/インフラ双方とも、
全てのモニタリングをDatadogのみに集約
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
全モニタリングをDatadogに集約
DevもOpsも、同じダッシュボードをみて多角的な指標で監視
インフラ指標だけではなく、アプリケーション指標も送ることで、
DevやOpsを問わず同じ画面で状況を把握できる
「ヴァルハラゲート」の時と比べて、世代が一つ上がった
手でアプリケーション側から埋める
自動プロファイリングは便利だけど、大���の情報に限られる
最も可視化したいアプリケーション固有データをDatadogへ
より高速に、より柔軟に仕込むためDatadogクライアントを作成
https://github.com/neuecc/DatadogSharp
全モニタリングをDatadogに集約
DevもOpsも、同じダッシュボードをみて多角的な指標で監視
インフラ指標だけではなく、アプリケーション指標も送ることで、
DevやOpsを問わず同じ画面で状況を把握できる
「ヴァルハラゲート」の時と比べて、世代が一つ上がった
手でアプリケーション側から埋める
自動プロファイリングは便利だけど、大枠の情報に限られる
最も可視化したいアプリケーション固有データをDatadogへ
より高速に、より柔軟に仕込むためDatadogクライアントを作成
https://github.com/neuecc/DatadogSharp
http://engineering.grani.jp/entry/2017/05/29/173141
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践
Conclusion
「最高の」単一テクノロジに集約する
Microservices的ではあるが、分散しすぎない工夫を目指している
単一であることの複雑さの上昇と、分散による複雑さの上昇
その最適なバランスをC#とgRPCによって見つけていく
gRPCもHTTP/2も発展途上
特にHTTP/2はツール類がまだまだ途上
しかし、それは数年で解消されるだろう
HTTP/2もgRPCも「使われていくこと」によるコミュニティの知見
の蓄積、ツールの成熟が将来的に大きなメリットになっていく
グラニも積極的に知見をシェアし、盛り上がりに貢献していきたい
Hiring
http://recruit.grani.jp/
「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践

More Related Content

「黒騎士と白の魔王」gRPCによるHTTP/2 - API, Streamingの実践