gRPC
gRPCとは
gRPC は、Google が開発した RPC(Remote Procedure Call — 遠隔にある関数をあたかも手元の関数のように呼び出す仕組み)のフレームワークです。「サーバーの GetUser() を呼ぶ」という関数呼び出しのスタイルで API を設計します。
通信には [[HTTP/2とHTTP/3]] で登場した HTTP/2 を使い、データは Protocol Buffers(バイナリ形式のシリアライズ方式。以下 protobuf)で送ります。
スキーマファーストという考え方
gRPC では、まず .proto ファイルにサービスの定義(関数名・引数・戻り値の型)を書きます。
service UserService {
rpc GetUser (GetUserRequest) returns (GetUserResponse);
}
message GetUserRequest {
int64 id = 1;
}
この定義から各言語のクライアント・サーバーのコードを自動生成できるため、言語が異なるサービス間でも型のズレが起きません。これがスキーマファーストの利点です。
REST APIとの比較
| [[REST API]] | gRPC | |
|---|---|---|
| データ形式 | JSON(テキスト) | protobuf(バイナリ) |
| 通信 | HTTP/1.1 中心 | HTTP/2 |
| 設計スタイル | リソース+HTTPメソッド | 関数呼び出し |
| 人間の読みやすさ | 高い | 低い(バイナリのため) |
| 性能 | 標準的 | 高速・小サイズ |
| ブラウザから直接 | 呼べる | 素では呼べない(gRPC-Web が必要) |
バイナリ形式と HTTP/2 の多重化により、gRPC はサービス間の大量・高頻度の通信で強みを発揮します。一方、ブラウザから直接呼びにくいため、外部公開 API には REST が使われることが多いです。
初学者向けポイント
- 使いどころの典型は [[マイクロサービス]] の内部通信です。「外向きは REST、内側は gRPC」という構成をよく見かけます
- HTTP/2 の特性を活かしたストリーミング(1つの接続で連続的にデータを送り合う)を4形態サポートしています
- curl でそのまま叩けないため、動作確認には grpcurl などの専用ツールを使います
関連技術とのつながり
- [[REST API]] — 外部公開に強い REST と内部通信に強い gRPC で使い分ける
- [[HTTP/2とHTTP/3]] — gRPC の高速さを支える通信層
- [[マイクロサービス]] — gRPC の主戦場。サービス間の型安全な通信を実現
Q: gRPCがデータのやり取りに使う形式はどれ?
- [ ] JSON(テキスト形式)
- [x] Protocol Buffers(バイナリ形式)
- [ ] HTML
解説: gRPC は protobuf というバイナリ形式を使うため、JSON よりデータが小さく高速です。
Q: gRPCの設計の進め方として正しいのはどれ?
- [x] .protoファイルにサービス定義を書き、各言語のコードを自動生成する
- [ ] まずHTMLの画面を作り、そこからAPIを推測する
- [ ] データベースのテーブルから直接APIが生成される
解説: gRPC はスキーマファーストで、.proto の定義からクライアント・サーバーのコードを自動生成します。
Q: gRPCの主な使いどころとして本文で挙げられているのはどれ?
- [ ] ブラウザから直接呼び出す外部公開API
- [ ] 静的なWebページの配信
- [x] マイクロサービスの内部通信
解説: gRPC はブラウザから直接呼びにくいため、サービス間の内部通信で強みを発揮します。