// シス担のミカタ
API・メッセージング

gRPC じーあーるぴーしー

Protocol BuffersRPCHTTP/2マイクロサービスストリーミングIDL
gRPCについて教えて

簡単に言うとこんな感じ！

gRPCはGoogleが作った「超高速な関数呼び出し通信」の仕組みだよ！　普通のWeb APIより速くてデータも軽い。特にマイクロサービスみたいに複数のサーバーが互いに話しかけ合う場面で大活躍なんだ！

gRPCとは

gRPC（ジーアールピーシー）は、Googleが2015年に公開したオープンソースのRPC（Remote Procedure Call＝遠隔手続き呼び出し）フレームワークです。RPCとは「別のサーバー上にある関数を、あたかも手元で呼び出すように実行する」仕組みのことで、gRPCはそれをモダンな技術スタックで実現しています。

通信プロトコルにはHTTP/2を採用し、データのシリアライズ（変換）にはProtocol Buffers（Protobuf）という高効率な形式を使います。REST APIがテキスト（JSON）でやりとりするのに対し、gRPCはバイナリ（0と1の羅列）でやりとりするため、データが小さくなり通信速度が大幅に向上します。

マイクロサービスアーキテクチャの普及とともに「サービス間通信をいかに速く・安全に・型安全に行うか」が課題になり、gRPCはその解答として急速に普及しました。GoogleやNetflix、Squareなど大規模システムで採用実績があります。

gRPCの仕組みと構造

gRPCの全体像は「定義ファイルを書く→コードを自動生成→呼び出す」というシンプルな流れです。

ステップ内容
① .protoファイルを書くサービスとメッセージの定義（IDL）
② protocでコード生成クライアント・サーバーのスタブを自動生成
③ サーバー側を実装生成されたインターフェースに処理を書く
④ クライアントから呼び出すまるでローカル関数のように呼び出せる

4つの通信パターン

gRPCには用途に応じた4つの通信モードがあります。

パターン説明使いどころ
Unary RPC1リクエスト→1レスポンス通常のAPIと同じ
Server Streaming1リクエスト→複数レスポンス株価・ログのリアルタイム配信
Client Streaming複数リクエスト→1レスポンスファイルアップロード
Bidirectional Streaming双方向に複数送受信チャット・リアルタイム通信

Protocol Buffers（Protobuf）の.protoファイル例

syntax = "proto3";

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int32 user_id = 1;
}

message UserResponse {
  int32  user_id = 1;
  string name    = 2;
  string email   = 3;
}

このファイル1つから、10以上のプログラミング言語向けのコードが自動生成されます。

歴史と背景

  • 2000年代〜 Googleは社内で「Stubby」と呼ばれる独自のRPCフレームワークを使い、膨大なサービス間通信を処理していた
  • 2015年2月 Stubbyをベースにオープンソース化したgRPC 1.0を公開。HTTP/2とProtobufを採用
  • 2016年〜 CNCF（Cloud Native Computing Foundation）に寄贈され、Kubernetes・Envoyなどクラウドネイティブ技術との親和性が高まる
  • 2017〜2018年 マイクロサービスブームとともに採用企業が急増。Netflix、Cisco、Juniperなどが導入
  • 2020年〜 gRPC-Webの登場でブラウザからの直接呼び出しも可能に。Envoyプロキシ経由での利用が広がる
  • 現在 gRPC is a CNCF Graduated Projectとして成熟したエコシステムを持ち、サービスメッシュ・Kubernetes環境での標準的な選択肢に

REST APIとgRPCの比較

システム発注・選定の際に「REST APIとgRPC、どちらを使うべき？」と問われることがよくあります。

比較項目REST APIgRPC
データ形式JSON（テキスト）Protocol Buffers（バイナリ）
通信プロトコルHTTP/1.1（主流）HTTP/2
速度・効率普通高速・軽量（2〜10倍程度）
型の安全性弱い（実行時エラー）強い（コンパイル時検出）
ブラウザ対応◎ ネイティブ対応△ gRPC-Web経由が必要
学習コスト低いやや高い
向いている用途外部公開API・Webアプリサービス間通信・IoT・リアルタイム
ツールの充実度◎ 豊富○ 充実してきた
REST API vs gRPC — アーキテクチャ比較 REST API クライアント（ブラウザ/アプリ） HTTP/1.1 JSON テキスト {"name":"Alice","age":25} サーバー（REST エンドポイント） gRPC クライアント（自動生成スタブ） .proto → コード自動生成 HTTP/2（多重化・ヘッダ圧縮） Protocol Buffers バイナリ 0A 05 41 6C 69 63 65 10 19 サーバー（自動生成インターフェース） vs 速度・効率 普通 高速・軽量

関連する規格・RFC

規格・RFC番号内容
RFC 9113HTTP/2の仕様（gRPCが採用する通信プロトコル）
RFC 7541HPACK — HTTP/2のヘッダー圧縮アルゴリズム
Protocol Buffers v3Googleが定めるgRPCのデータ直列化フォーマット仕様
gRPC Core SpecgRPC公式の通信仕様（grpc.io/docs/guides/）
gRPC-WebブラウザからgRPCを利用するためのプロキシ仕様

関連用語

  • REST API — HTTPベースの標準的なWeb API設計スタイル。gRPCと比較・選定されることが多い
  • Protocol Buffers — gRPCが採用するGoogleのバイナリシリアライズ形式
  • HTTP/2 — gRPCが採用する高速通信プロトコル。多重化・ヘッダ圧縮が特徴
  • マイクロサービス — gRPCが最も活躍するアーキテクチャパターン
  • API Gateway — 外部クライアントとgRPCサービス群の間に置く中継コンポーネント
  • サービスメッシュ — Istio・EnvoyなどgRPCと組み合わせて使うサービス間通信管理基盤