gRPCとは
gRPC(Google Remote Procedure Call)は、Googleが2015年にオープンソースとして公開した高性能なRPC(Remote Procedure Call)フレームワークです。あたかもローカルの関数を呼び出すかのように、ネットワーク越しに別のサーバー上の関数を実行できる仕組みを提供します。
gRPCは、Protocol Buffers(protobuf)によるバイナリシリアライゼーションとHTTP/2プロトコルによる多重化・ストリーミングを基盤としており、JSON/HTTPベースのREST APIと比較して5〜10倍の通信速度を実現します。Google社内では「Stubby」という名前で10年以上運用されていた技術がベースとなっており、毎秒数十億回のRPCコールを処理する実績があります。
Protocol Buffers(protobuf)
Protocol Buffersは、Googleが開発した言語中立・プラットフォーム中立なデータシリアライゼーション形式です。.protoファイルでデータ構造とサービスインターフェースを定義し、protoc コンパイラで各プログラミング言語向けのコードを自動生成します。
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (User);
rpc ListUsers (ListUsersRequest) returns (stream User);
}
message User {
int32 id = 1;
string name = 2;
string email = 3;
}
message GetUserRequest {
int32 id = 1;
}
Protocol Buffersのバイナリ形式は、JSONと比較してデータサイズが約60-80%小さく、シリアライゼーション/デシリアライゼーションの速度も数倍高速です。また、スキーマの前方互換性・後方互換性が保証されており、APIの段階的な進化が可能です。
gRPCの4つの通信パターン
gRPCはHTTP/2のストリーミング機能を活用して、4つの通信パターンを提供します。
- Unary RPC:クライアントが1つのリクエストを送り、サーバーが1つのレスポンスを返す最もシンプルなパターン。通常のREST APIコールに相当します。
- Server Streaming RPC:クライアントが1つのリクエストを送ると、サーバーがストリームで複数のレスポンスを返します。リアルタイムデータフィード、ログストリーミングに適しています。
- Client Streaming RPC:クライアントがストリームで複数のリクエストを送り、サーバーが1つのレスポンスを返します。ファイルアップロードやセンサーデータの一括送信に適しています。
- Bidirectional Streaming RPC:クライアントとサーバーが独立してストリームでデータを送受信します。チャットシステムやリアルタイム協調編集に適しています。
gRPCとREST APIの比較
| 観点 | gRPC | REST API |
|---|---|---|
| シリアライゼーション | Protocol Buffers(バイナリ) | JSON(テキスト) |
| トランスポート | HTTP/2 | HTTP/1.1 or HTTP/2 |
| ストリーミング | 双方向対応 | なし(別途WebSocket等) |
| コード生成 | 自動(多言語対応) | OpenAPIから生成可能 |
| ブラウザ対応 | gRPC-Web経由 | ネイティブ対応 |
| デバッグ | バイナリのため専用ツール必要 | curlやブラウザで容易 |
grpcurlによる動作確認例
gRPCはバイナリプロトコルのためcurlで直接テストできませんが、grpcurlというCLIツールを使うことでREST APIをcurlで叩くのと同じ感覚で動作確認ができます。サーバー側でReflection APIを有効にしておけば.protoファイルなしでもメソッド一覧の取得やリクエスト送信が可能です。
# 提供されているサービス・メソッド一覧を取得
grpcurl -plaintext localhost:50051 list
# UserServiceのGetUserメソッドを呼び出す
grpcurl -plaintext -d '{"id": 123}' \
localhost:50051 UserService/GetUser
gRPCのメリット・デメリット
メリット
- 高速な通信:バイナリ形式のProtocol BuffersとHTTP/2の多重化により、JSON/HTTP1.1ベースのREST APIより大幅に高速です。
- 型安全なインターフェース:
.protoファイルからクライアント・サーバー双方のコードを自動生成でき、インターフェースの不整合をコンパイル時に検出できます。 - 双方向ストリーミング:長時間接続を維持しながらリアルタイムにデータをやり取りできます。
- 多言語対応:Go、Java、Python、C++、Node.jsなど主要言語向けのコード生成をサポートします。
デメリット
- ブラウザからの直接利用が困難:ブラウザはHTTP/2のトレーラーフレームを扱えないため、gRPC-Webやproxyを経由する必要があります。
- 可読性・デバッグの難しさ:バイナリ形式のためブラウザの開発者ツールやcurlでは中身を確認できず、grpcurlやWiresharkのプラグインなど専用ツールが必要です。
- キャッシュが効きにくい:POSTベースかつバイナリのため、HTTPキャッシュやCDNキャッシュの活用が難しくなります。
- 学習コスト:Protocol Buffersのスキーマ設計やストリーミングの概念など、REST APIに比べて学習コストが高くなります。
実務での活用シーンと導入時の注意点
活用シーン
gRPCは公開Web APIよりも、社内・クラウド内で完結するサービス間通信(サーバー間通信)に特に向いています。マイクロサービスアーキテクチャでのサービスメッシュ内通信、モバイルアプリのバックエンド通信、AI推論サーバーへの高頻度リクエストなどが典型的な適用先です。
導入時の注意点
- ロードバランシング設計:HTTP/2の永続的なコネクションを使うため、L4ロードバランサーでは特定サーバーへの偏りが発生しやすく、gRPC対応のL7ロードバランサー(Envoy等)やクライアントサイドLBの検討が必要です。
- スキーマ管理:複数チームで
.protoファイルを共有する場合、Bufなどのスキーマレジストリでバージョン管理・後方互換性チェックを行う運用が推奨されます。 - 外部公開する場合の設計:一般公開のWeb APIとして提供する場合は、gRPC-GatewayでRESTfulなJSON APIへ変換するか、Connect RPCの採用を検討すると相互運用性が高まります。
gRPCの活用事例
- マイクロサービス間通信:Kubernetes上のサービス間の高速通信。Netflix、Dropbox、Slackが採用
- モバイルアプリ通信:帯域幅が制限されるモバイル環境での効率的なデータ転送
- IoTデバイス通信:センサーデータの高速収集とデバイス制御
- 分散データベース:CockroachDB、TiDBなどの内部通信プロトコル
- AI/MLインフラ:TensorFlow Servingのモデル推論API、KubeflowのMLパイプライン
gRPCのエコシステム
- gRPC-Web:ブラウザからgRPCサービスを呼び出すためのプロキシ。Envoy Proxyを介して変換
- gRPC-Gateway:gRPCサービスにRESTful JSONインターフェースを自動生成するリバースプロキシ
- Buf:Protocol Buffersのリンター、ブレイキングチェンジ検出、スキーマレジストリ
- Connect:gRPC互換プロトコル。ブラウザからgRPC-Webなしで直接呼び出し可能
2025-2026年の最新動向
Connect RPC(旧Connect-Go/Connect-Web)が急速に普及しています。gRPC互換でありながらHTTP/1.1でも動作し、curlで直接テスト可能なシンプルさを持ちます。gRPC-Webのプロキシ不要でブラウザから直接呼び出せるため、フルスタック開発での採用が増加しています。
gRPC over QUICの実験的サポートが進み、HTTP/3ベースのgRPC通信が実現しつつあります。特にモバイルネットワークでの接続切り替え時のレジリエンスが向上します。
また、AI推論サービスでのgRPC活用が加速しており、NVIDIA Triton Inference Server、vLLM、TGI(Text Generation Inference)などのLLMサービングフレームワークがgRPCインターフェースを標準提供しています。
関連技術と用語
- API - ソフトウェア間通信の基本概念
- REST - JSONベースのAPI設計パターン
- GraphQL - 柔軟なクエリが可能なAPI技術
- HTTP/2 - gRPCの基盤プロトコル
- HTTP/3 - QUICベースの次世代プロトコル
外部リンク
よくある質問(FAQ)
Q. gRPCとは何ですか?
gRPCはGoogleが開発した高性能RPCフレームワークです。Protocol Buffersによるバイナリ通信とHTTP/2のストリーミングを特徴とし、マイクロサービス間の高速通信に広く利用されています。
Q. gRPCとREST APIの違いは?
gRPCはProtocol Buffersのバイナリ形式で5-10倍高速、双方向ストリーミング対応ですが、ブラウザからの直接利用にはgRPC-Webが必要です。REST APIはJSON/テキストベースでデバッグが容易です。
Q. Protocol Buffersとは?
Googleが開発した言語中立のデータシリアライゼーション形式です。.protoファイルでスキーマを定義し、各言語向けのコードを自動生成します。JSONより小さく高速なバイナリ形式が特徴です。
Q. gRPCの4つの通信パターンは?
Unary RPC(1対1)、Server Streaming(1対多)、Client Streaming(多対1)、Bidirectional Streaming(双方向)の4パターンがあります。
Q. gRPCの動作をcurlのように手軽にテストする方法はありますか?
grpcurlというCLIツールを使うと、curlのようなコマンド一発でgRPCサービスのメソッド一覧取得やリクエスト送信ができます。サーバーがReflection APIを有効化していれば.protoファイルなしでも呼び出し可能です。
