Protocol Buffers（プロトコルバッファ）とは？

Protocol Buffers（protobuf）は、Googleが開発した軽量で効率的なデータシリアライズフォーマット。JSONやXML のようなフォーマットと同様に、データの構造を定義し、異なるシステム間でのデータ交換を効率化することを目的としている。

特徴

• バイナリ形式なのでJSONやXMLよりも高速・コンパクト
• 型安全でデータ構造を厳密に定義できる
• 言語非依存で、C++, Java, Python, Go, Rust などさまざまな言語で使用可能
• .protoファイルを使ってデータ構造を定義する

gRPC とは？

gRPCは、Googleが開発した高性能なRPC（Remote Procedure Call）フレームワーク。gRPCは、データシリアライズにProtocol Buffers（protobuf）を使用し、クライアントとサーバー間で高速・効率的に通信するために最適化されている。

特徴

• HTTP/2を使用し、並列リクエスト・ストリーミングが可能
• protobufをデフォルトのデータフォーマットとして使用（JSONも利用可能）
• 多言語対応（C++, Python, Go, Java, C#, Rust など）
• ストリーミング対応（クライアント/サーバー/双方向ストリーミング）
• 認証・ロードバランシングをサポート

Protocol BuffersとgRPCの関係

protobufはgRPCのデータフォーマットとして利用され、gRPCはその上にRPCの仕組みを提供するという関係

なぜgRPCはHTTP/2を使うのか？

gRPCの特徴である以下は、HTTP/2でなければ実現できないため

• 双方向ストリーミング
• 同時に複数のリクエスト処理（多重化）
• ヘッダー圧縮による高速化

gRPCはHTTP/2の能力をフルに活かして、API通信を簡単・高速・型安全にするライブラリといえる

HTTP/2

• 通信プロトコル
• gRPCに限らず、WebサーバーやREST APIでも使える汎用的な輸送手段

gRPC

• HTTP/2の上に構築されたアプリケーション層の通信ライブラリ
• RPC（Remote Procedure Call）という「関数呼び出し」のモデルで通信を抽象化

なぜgRPCはREST APIのようなスタイルではなく、RPCを採用したのか？

マイクロサービス時代の内部通信に最適な形を追求した結果、RPCスタイルが最も効率的

• HTTP/2 + Protocol Buffers による高速・軽量な通信
• IDLによる強い型安全と自動コード生成
• RESTのような汎用性ではなく、密結合でも効率重視の設計
• 関数を呼び出すようにサービスを使うニーズに最適

RESTとRPCの違い

なぜマイクロサービスではRPCが有利か？

関数呼び出しのように扱える（開発しやすい）

• サーバーの処理を、クライアントから client.AddUser(user) みたいに呼び出せる
• RESTのようにURLやHTTPメソッドを設計する必要がない

自動コード生成で手間がない

• .proto を書くだけで、クライアントとサーバーのスタブが多言語で自動生成
• RESTだとOpenAPI（Swagger）などを使っても、完全自動化は難しい

通信が軽い・速い（バイナリ・圧縮）

• JSONより数倍小さい Protocol Buffers
• HTTP/2の多重化・ヘッダー圧縮で高スループット

型安全・構造化されたAPI定義ができる

• IDL（インターフェース定義言語）により、コンパイル時にエラー検出が可能

RESTが向いている場面との違い

gRPCは外部通信にも使えるか？

可能ではあるが制約がある

• ブラウザからは直接使えない（gRPC-Webが必要）
• HTTP/2に対応していないプロキシ／ロードバランサが問題になることも
• 外部向けAPIとしてはRESTのほうが一般的で互換性も高い