概要

gRPCは、Googleが開発したRPCフレームワークである。マイクロサービス間の通信を中心に採用が広がっている。本記事では、gRPCの仕組みを採用判断に必要な範囲で整理し、どのような場面で選ぶべきか、どのようなトレードオフがあるかをまとめる。実装の詳細よりも、設計上の意思決定に焦点を当てる。

なお、Goによる実装入門は別記事gRPCとは？GoによるgRPCの実践入門で扱っている。本記事は採用判断と運用に絞る。

gRPCの特徴

採用を判断するうえで押さえておきたいのは、次の3点である。

RPCとして設計されている

gRPCは、リモートのメソッドをローカル関数のように呼び出すRPC（Remote Procedure Call）モデルを採る。RESTがリソース指向であるのに対し、gRPCは操作（手続き）を中心に考える。

HTTP/2を前提とする

gRPCはHTTP/2上で動作する。ヘッダー圧縮、多重化、双方向ストリーミングといった特性をそのまま活かせる。1本のコネクションで複数のリクエストを並行処理できるため、通信効率が高い。

Protocol Buffersで契約を定義する

APIの仕様は、Protocol Buffersというインターフェース定義言語で記述する。.protoファイルがサービス間の契約となり、そこからサーバーとクライアントのコードを生成する。バイナリ形式でシリアライズされるため、JSONより小さく速い。

通信方式には4種類ある。

• Unary（1リクエスト1レスポンス）
• Server streaming（1リクエスト複数レスポンス）
• Client streaming（複数リクエスト1レスポンス）
• Bidirectional streaming（双方向ストリーミング）

ストリーミングを言語に依存せず扱える点は、RESTにはない特徴である。

向いている場面・向かない場面

向いている場面

• マイクロサービス間の内部通信。低レイテンシかつ高スループットが求められる経路に適する
• 多言語環境。.protoから各言語のコードを生成でき、言語間で契約が揃う
• ストリーミングが必要な処理。リアルタイム更新や大量データの逐次転送など
• 強い型の契約を保ちたい場合。スキーマが先にあり、破壊的変更を検知しやすい

向かない場面

• ブラウザから直接呼び出すAPI。ブラウザはHTTP/2の機能を完全には扱えず、gRPC-WebやgRPC-Gatewayといった追加層が必要になる
• 公開API。外部の開発者が利用する場合、RESTやGraphQLのほうがツールやドキュメントの面で扱いやすい
• 通信内容をそのまま読みたい場面。バイナリ形式のため、curlでの確認やログの目視がしにくい

トレードオフ

採用の判断材料として、利点と難点を対にして整理する。

運用の勘所

採用後に効いてくる運用上の論点を挙げる。

• ロードバランシング: gRPCはコネクションを保持し続けるため、L4の分散では負荷が偏りやすい。L7での分散やクライアントサイドの分散を検討する
• スキーマの互換性: フィールド番号を変えない、既存フィールドを削除しないなど、後方互換を保つ運用ルールを決める
• 可観測性: バイナリ通信のため、メトリクスやトレーシングを設計段階から組み込む。OpenTelemetryなどの計装が前提になる
• デプロイ: HTTP/2を終端するプロキシやロードバランサーが対応しているかを確認する

RESTやGraphQLとの使い分け

• REST: 公開API、単純なCRUD、人間可読性やHTTPキャッシュを重視する場面に向く
• gRPC: 内部のサービス間通信、低レイテンシ、ストリーミング、多言語の契約共有に向く
• GraphQL: 多様なクライアントが必要なデータだけを取得したい場面や、複数APIの集約に向く

3つは排他ではない。外部公開はRESTやGraphQL、内部はgRPCというように、層によって使い分ける構成も一般的である。

まとめ

gRPCの採用判断は、次の問いに集約できる。

• その経路はブラウザから直接叩くか。叩くならRESTやgRPC-Gatewayを検討する
• 低レイテンシ・多言語・ストリーミングの要件があるか。あるならgRPCが活きる
• スキーマ管理と可観測性の運用コストを負担できるか

内部のサービス間通信で性能と契約を重視するなら、gRPCは強力な選択肢である。一方で、ブラウザ対応や可読性が要る場面では、RESTやGraphQLのほうが素直である。要件と運用体制に照らして選ぶことが重要である。

参考

• gRPC 公式サイト
• Protocol Buffers 公式ドキュメント