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

AWS Summit Tokyo 2017

Transcript

3. 河合 宜文 / Kawai Yoshifumi / @neuecc C# Unity 株式会社グラニ http://grani.jp/
4. gRPC + AWS gRPC Application - API Service/Realtime Server Monitoring and Tools
5. gRPC + AWS gRPC Application - API Service/Realtime Server Monitoring and Tools
7. iOS/Android用のモバイルRPG リアルタイムバトル C#
8. gRPC What Why How
9. gRPCはHTTP/2ベースのRPC
10. GoogleによるオープンソースRPC実装
11. 2種のフレームワークの統合 Unity用リアルタイム通信のスタンダード 勿論、パフォーマンスへの期待
12. C#版のgRPCはある、Unity版はない 移植 + 高レベルフレームワークを作成 https://github.com/grani/gRPC https://github.com/neuecc/MagicOnion
13. C#版のgRPCはある、Unity版はない 移植 + 高レベルフレームワークを作成 https://github.com/grani/gRPC https://github.com/neuecc/MagicOnion
14. リリース! プロジェクト始動！ 当時はWebSocket(C#) でリアルタイム通信 gRPCプロジェクト始動！ Unity用のgRPCは存在しないので Unity + iOS/Androidで動くよう移植から スタート（つまり動くかも未検証） この辺でWeb APIも含めて 完全移行完了(ｷﾞﾘｷﾞﾘ 某ネットワークミドルウェアに リアルタイム通信を載せかえる、 Web APIはHTTP/1で継続
15. with AWS
16. Service2 BattleEngine
17. Service2 BattleEngine
24. Service2 - ELB(TCP) BattleEngine - Lambda
25. デプロイでリクエストぷちっと切れる問題 Draining and Client Disconnect
26. Make gRPC Application
27. using
28. ようはConsole Application(not IIS) with HTTP/1
29. ようはConsole Application(not IIS) with HTTP/1
30. gRPC based HTTP/2 RPC Streaming Framework https://github.com/neuecc/MagicOnion https://github.com/neuecc/MessagePack-CSharp/
31. gRPC based HTTP/2 RPC Streaming Framework https://github.com/neuecc/MagicOnion https://github.com/neuecc/MessagePack-CSharp/
32. 言語の違うREST Response型を別々 に書く APIクライアント を手書きする (ザ・マイクロ サービスみたいな 構成） 中間IDLを書く そこからクライア ント・レスポンス 型自動生成 （←を嫌う時によ くある構成、一番 メジャー） サービスを普通に 書く、そこからク ライアントを自動 生成、リクエス ト・レスポンス型 はC#のDLLとして 共有 サービスを普通に 書く、クライアン トはそのプロジェ クト参照から実行 時動的生成
33. 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; }
34. gRPC IN(byte[]) gRPC OUT(byte[]) RPC Method MagicOnion Filters IDL Less HandlerSelector MessagePack(with LZ4) Deserialize MessagePack(with LZ4) Serialize
35. // 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 */ } } }
37. 開発環境用API実行機
38. InMemory BattleEngine
41. var thread = GameLoopThreadPool.GetThread(); while (true) { var shouldContinue = frameAction(this); if (!shouldContinue) break; await thread.NextFrame(); }
42. Monitoring and Tools
43. https://www.datadoghq.com/ SaaS形式のモニタリングサービス 「黒騎士と白の魔王」ではアプリケーション/インフラ双方とも、 全てのモニタリングをDatadogのみに集約
47. 全モニタリングをDatadogに集約 DevもOpsも、同じダッシュボードをみて多角的な指標で監視 インフラ指標だけではなく、アプリケーション指標も送ることで、 DevやOpsを問わず同じ画面で状況を把握できる 「ヴァルハラゲート」の時と比べて、世代が一つ上がった 手でアプリケーション側から埋める 自動プロファイリングは便利だけど、大枠の情報に限られる 最も可視化したいアプリケーション固有データをDatadogへ より高速に、より柔軟に仕込むためDatadogクライアントを作成 https://github.com/neuecc/DatadogSharp
48. 全モニタリングをDatadogに集約 DevもOpsも、同じダッシュボードをみて多角的な指標で監視 インフラ指標だけではなく、アプリケーション指標も送ることで、 DevやOpsを問わず同じ画面で状況を把握できる 「ヴァルハラゲート」の時と比べて、世代が一つ上がった 手でアプリケーション側から埋める 自動プロファイリングは便利だけど、大枠の情報に限られる 最も可視化したいアプリケーション固有データをDatadogへ より高速に、より柔軟に仕込むためDatadogクライアントを作成 https://github.com/neuecc/DatadogSharp http://engineering.grani.jp/entry/2017/05/29/173141
50. Conclusion
51. 「最高の」単一テクノロジに集約する Microservices的ではあるが、分散しすぎない工夫を目指している 単一であることの複雑さの上昇と、分散による複雑さの上昇 その最適なバランスをC#とgRPCによって見つけていく gRPCもHTTP/2も発展途上 特にHTTP/2はツール類がまだまだ途上 しかし、それは数年で解消されるだろう HTTP/2もgRPCも「使われていくこと」によるコミュニティの知見 の蓄積、ツールの成熟が将来的に大きなメリットになっていく グラニも積極的に知見をシェアし、盛り上がりに貢献していきたい
52. Hiring http://recruit.grani.jp/