C# Tokyoでの登壇資料

1. ASP.NET Coreで
gRPCプログラミングを
始めよう
2019/10/24 #csharptokyo
@tanaka_733

2. 自己紹介
Senior Technical Support Engineer @ New Relic K.K.
◦ アプリケーションプラットフォーム監視（APM)のSaaSです
◦ 日本語サポート開始しました
◦ New Relicに関する勉強会の要望も受けます
Microsoft MVP for Azure
◦ .NET Core on Linux, Kubernetes, Azureなどのお仕事してました
◦ Visual StudioやQ#などにも興味があります
ソーシャル活動
◦ Twitter: @tanaka_733
◦ Blog: 銀の光と碧い空

3. gRPCのメリット
gRPCはHTTP/2を利用した言語に依存しない高性能なRPC
◦ 契約優先のAPI開発。言語非依存
◦ 型指定したサーバーとクライアントを生成可能
◦ クライアント、サーバー、双方向ストリーミングをサポート
◦ Protobufバイナリシリアル化
REST API + OpenAPIなどでできる部分もあるが、
RPCの方が便利では？という流れ

4. gRPC + ASP.NET Coreの
主なターゲット
新規でRPCスタイルのサーバーサイドを開発したい
• 新規でASP.NET Coreでサーバー作るなら、
通常のREST API、SignalRとともに検討したい
WCFからの移行
• .NET Frameworkの一部であるWCFは基本的に新機能はもうこない
• のでMicrosoftとしてはgRPC + ASP.NET Coreに移行してほしい雰囲気を感じる
• MSからeBookも出ています
• https://docs.microsoft.com/ja-jp/dotnet/architecture/grpc-for-wcf-
developers/?WT.mc_id=DT-MVP-5000211
• 個人的にはサポートなくなるわけじゃないし、WCFのままでいいという人もいると思いますが…

5. gRPCサポートって前からなかった？
という人へ
https://grpc.io/blog/grpc-on-dotnetcore/

6. はじめての
gRPC for ASP.NET Core
DEMO

7. gRPC サービスの作成

8. まず、ここから
公式ドキュメント
https://docs.microsoft.com/ja-jp/aspnet/core/grpc/?WT.mc_id=DT-MVP-
5000211&view=aspnetcore-3.0
リポジトリ
https://github.com/grpc/grpc-dotnet/
サンプルコードリポジトリ
https://github.com/grpc/grpc-dotnet/tree/master/examples

9. .proto から C# クラスの自動生成
サーバーサイド
◦ テンプレートを使う場合は設定済み。それ以外の場合はGrpｃServicesをServerに指定する
クライアントサイド
◦ ServicesをClientに指定して、手動でプロジェクトに設定。
WPFのみ既知の問題で動作しないため、クラスライブラリ経由。
Grpc.Tools をNuGetから参照に追加
Protobug アイテムをcsprojファイルに追加
◦ GrpcServicesはServer, Client, Both(デフォルト), Noneを指定可能
<ItemGroup>
<Protobuf Include="Protos¥greet.proto" GrpcServices="Server" />
</ItemGroup>

10. 各種パッケージの依存関係
https://grpc.io/blog/grpc-on-dotnetcore/

11. 自動生成されたクラス
ビルドによりC#コードが自動生成される
生成されたクラスは obj 配下にあるため、通常編集不可 ＆ バージョン管理不可

12. さまざまな呼出し方とユースケース
まずはこのサンプルを見てみましょう
https://github.com/grpc/grpc-dotnet/tree/master/examples
◦ Unary call
◦ Server streaming call
◦ Client streaming call
◦ Bi-directional streaming call
さらに、Cancelやinterceptor、認証などのサンプルがそろっています

13. gRPC for
ASP.NET Coreの課題

14. .protoを定義するのが面倒では？
.protoを使うことで複数のプログラミング言語間で
共通のインターフェースを定義できる。けれども…
◦ C#だけ使う環境だと、そもそも面倒では？
◦ サーバー、クライアントともC#だけどgRPCを使いたい場面もあるのでは？
MagicOnionという選択肢も検討しましょう
https://github.com/Cysharp/MagicOnion
サーバーもC#で書きたいUnityエンジニアで話題ですが、
普通のWebアプリでも使えます。

15. どこで動かすか？
Windows、Linuxなどのホスト上で直接動かす
•サービス（Windows Service）として
•セルフホスト(Kestrel）として
Docker
•Dockerコンテナ化して動かす
•Linux、Windowsコンテナ両方可能だが、Windowsコンテナ化するうまみはなさそう…
•ECSなどで動かせるようになる (Azure App Serviceは不可）
Kubernetes
•Dockerコンテナ化してkubernetesとの連携
•EnvoyなどService Mesh(後述)との連携も期待できる

16. 負荷分散とTLS
TLSによるセキュリティ保護が推奨
➔どこで終端させるかと負荷分散が要検討に
負荷分散
◦ L4負荷分散するかL7負荷分散するか
◦ gRPCは１つのコネクションを使いまわすことで効率化するため、
L4 Load Balancerでは常に同じバックエンドインスタンスにルーティングされる可能性がある
➔適切な負荷分散にならない可能性がある
◦ L７ Load Balancerはリクエストを解釈して適切なバックエンドにルーティングするので適切
TLS終端の処理も対応できる
◦ Kubernetes上の場合、Service Meshの利用も検討できる。が…
◦ Service Mesh: マイクロサービスな環境で負荷分散だけではなくサービス発見性や耐障害性も含めて高機能なもの。負荷分散
のためだけだと複雑すぎるのでは？
まだ、ベストプラクティスといえる構成はないのでは？（見つけていく必要あり）
https://docs.microsoft.com/ja-jp/dotnet/architecture/grpc-for-wcf-
developers/load-balancing?WT.mc_id=DT-MVP-5000211

17. そのほか考慮が必要そうなこと
さまざまな設定(チューニングなど）
• 開発環境ではエラー詳細をクライアント側に見えるなどの追加設定
• メッセージサイズ制限など
認証と認可
• TLSを使う場合はKestrel側で設定
• クライアント認証が必要な場合はASP.NET Coreパッケージでの対応が必要
Observability(ログ、メトリクス、トレース）
• ログは展開先の性質に応じて選択
• gRPC/.NET Coreでのメトリクス、トレースはツールによって対応状況が異なる

18. 分散トレーシング
gRPCをマイクロサービスに
展開しようという場合は必須（でしょう）

19. まとめ
ASP.NET Core 3でgRPCがサポートされました！
• C#で公式パッケージでgRPCサービス、クライアントが開発できます
• .protoをがりがり書いていく ＋ C#のクラス自動生成
ただ動かすだけならすぐできるけど…
• 運用を想定すると考慮していないといけないことたくさん
• ASP.NET CoreがというよりgRPCを使う場合に言えそう
• どこで動かすかが、なにをフロントのLBとするかが一番の課題？
• C#同士なら、MagicOnionでgRPCではなくC#で記述も検討