gRPCとは？
gRPCの概念について説明します。
gRPCとは？
gRPCはGoogleが開発した、高性能で汎用的なオープンソースRPC（Remote Procedure Call）フレームワークです。サービス間で高速かつ効率的に通信するために使用します。
ネットワーク上の関数を、自分のコード内の関数のように呼び出せます。リモート関数呼び出しを標準化し、高速で型安全な通信を実現します。
HTTP/1.1とJSONを主に使用する従来のREST通信とは異なり、gRPCはHTTP/2とバイナリシリアライズ形式のProtocol Buffers（ProtoBuf）を使用します。これにより、低レイテンシー、高スループット、小さいメッセージサイズを実現します。
サービスAPIは.protoファイルで定義します。サーバーとクライアントは同じインターフェース定義を共有し、複数のプログラミング言語向けにStubコードを自動生成できます。多言語環境での開発を容易にし、サービス境界を明確にします。
出典: https://appmaster.io/ko/blog/grpcneun-mueosibnigga
gRPCの主要要素
1. Protocol Buffersベース
gRPCはJSONの代わりに、バイナリ形式のProtocol Buffersを使用します。
- JSONより小さく高速
- protobufファイルによる明確なスキーマ
- 各言語向けのクライアントとサーバーのStubコードを自動生成
例: hello.proto
service HelloService {
rpc SayHello (HelloRequest) returns (HelloResponse);
}
message HelloRequest {
string name = 1;
}
message HelloResponse {
string message = 1;
}
2. HTTP/2通信
gRPCは内部でHTTP/2を使用するため、次の機能を利用できます。
- Multiplexing: 1つの接続で複数のリクエスト
- Server Push
- ヘッダー圧縮
- 双方向を含むストリーミング
適切な用途ではRESTより高速で効率的です。
gRPCの4つの通信方式
| 種類 | 説明 |
|---|---|
| Unary | 1リクエストと1レスポンス |
| Server Streaming | サーバーが複数のメッセージをストリームとして配信 |
| Client Streaming | クライアントが複数のメッセージを送り、サーバーが1回応答 |
| Bidirectional Streaming | クライアントとサーバーが複数のメッセージを同時に送受信 |
チャット、リアルタイムログ処理、ストリーミングデータ処理に適しています。
gRPCの長所と短所
長所
- Protocol BuffersとHTTP/2による高速で軽量な通信
- protoスキーマに基づくコンパイル時検証による強い型安全性
- Go、Java、Kotlin、Python、Rust、C#、Node、Rubyなどをサポート
- 双方向ストリーミングを標準サポート
- マイクロサービスの内部通信に適している
短所
- gRPC-WebやWebAssemblyなしではブラウザーから直接呼び出しにくい
- protoの作成とコンパイルへの理解が必要
- RESTよりデバッグが難しい
gRPCを使用するタイミング
適したケース
- マイクロサービスの内部通信
- 高性能が重要なトラフィック
- リアルタイムストリーミングサービス
- JavaサーバーとGoクライアントなどの多言語サービス
- IoT、ゲームサーバー、リアルタイムイベント処理
RESTが適したケース
- ブラウザーから直接呼び出すAPI
- シンプルな公開API
- JSONなど人間が読みやすい形式が必要な場合
gRPCとRESTの比較
| 項目 | gRPC | REST |
|---|---|---|
| 通信プロトコル | HTTP/2 | 通常はHTTP/1.1。HTTP/2も可能 |
| データ形式 | バイナリのProtocol Buffers | JSONやXMLなどのテキスト形式 |
| 速度 | 非常に高速で小さく、解析も効率的 | 比較的低速 |
| ストリーミング | 双方向を含め完全にサポート | 制限あり。SSEやWebSocketが別途必要 |
| インターフェース定義 | .protoファイルで型とスキーマを定義 |
必須スキーマなし。OpenAPIを推奨 |
| 型安全性 | コンパイル時に検証 | 実行時に検証される場合が多い |
| コード生成 | クライアントとサーバーのStubを自動生成 | Swagger/OpenAPIで文書化可能。Stubは任意 |
| 使いやすさ | ブラウザー呼び出しにはgRPC-Webが必要 | ブラウザーとJavaScriptから直接利用可能 |
| 人間の可読性 | バイナリ形式のため低い | JSONで高い |
| デバッグ | 難しい | curlやPostmanで容易 |
| セキュリティ | TLSとHTTP/2の強力な組み合わせ | 標準的なTLS |
| 適したサービス | 内部マイクロサービス、高性能、リアルタイムストリーミング | 公開API、外部連携、ブラウザー中心のサービス |
| 言語サポート | ほぼすべての主要言語を公式サポート | HTTPを扱えれば言語を問わない |
| 長所の要約 | 高速、効率的、型安全、強力なストリーミング | シンプル、デバッグ容易、高い互換性 |
| 短所の要約 | 複雑、ブラウザーから利用しにくい | 性能と型安全性で不利 |
まとめ
- gRPC: 内部通信、高性能、ストリーミングに最適です。
- REST: ブラウザー、公開API、デバッグのしやすさに最適です。