gRPCは2015年、Googleが社内利用のRPC基盤Stubbyをベースに公開したオープンソースの高性能RPC（Remote Procedure Call）フレームワークです。Protocol Buffers（Protobuf）でAPIを宣言し、HTTP/2上で効率的なバイナリ通信を行います。現在はCNCFのプロジェクトとして、マイクロサービス間通信、IoT、モバイル↔サーバの効率通信などで広く採用されています。
この記事の目次
- gRPCの基本
- gRPCとREST/GraphQLの比較
- gRPC のエコシステム
- gRPCの落とし穴
- まとめ
gRPCの基本
gRPCはProtocol Buffers（Protobuf）でサービス定義・メッセージ定義を書きます。.proto ファイルに型と RPCメソッドを宣言し、protoc でGo/Java/Python/C++/JS など各言語のクライアント＆サーバスタブを自動生成。
通信路はHTTP/2を使い、同一接続で多数のRPCを多重化できます。ストリーム双方向通信（unary、server streaming、client streaming、bidirectional streaming）もネイティブ対応で、リアルタイム通信も書けます。
gRPCとREST/GraphQLの比較
gRPCはREST/GraphQLと比べて「サーバ間通信に強い・速い」が、ブラウザからは直接使えないという特徴があります。ブラウザJavaScriptから呼ぶには gRPC-Web 経由でプロキシ（Envoyなど）が必要です。
公開APIにはRESTかGraphQL、社内マイクロサービス間にはgRPC、という棲み分けが現代の典型構成。Google Cloud / AWS / Azureの内部APIや、Netflix・Squareなど大手のマイクロサービス基盤で広く使われています。
gRPC のエコシステム
gRPC生態系には便利なツールが多数あります。gRPC-WebはブラウザからのgRPC呼び出し、gRPC-GatewayはgRPCをREST/JSONとして公開、ConnectはBuf社が開発したよりモダンなgRPC互換実装で、近年人気が高まっています。
Proto管理にはBuf CLIが定番で、リント・破壊的変更検出・コード生成を一元化できます。本番運用にはOpenTelemetryによる分散トレースの組み込みが推奨され、マイクロサービス間の可視化が容易になります。
gRPCの落とし穴
gRPCの最大の難しさはデバッグです。JSONなら curl で気軽に叩けますが、gRPCはバイナリなので grpcurl 等の専用ツールが必要。Protoが破壊的に変わるとクライアントが動かなくなる事故も起きやすく、Buf 等での厳密管理が不可欠です。
また、.proto の生成物をモノレポで共有するか、Buf Schema Registryで配布するかなど、「スキーマの配布・バージョン管理」の運用設計はgRPCで考えるべき重要トピック。「型契約が強い」のは利点でもあり、運用の手間でもあります。
まとめ
gRPCはマイクロサービス間通信のスタンダードとして、現代の大規模Webサービスを支えています。REST/GraphQLとは用途が異なる「サーバ間通信専用の道具」と捉えて、適切に使い分けるのがコツです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント