gRPC とは何か？意味、アーキテクチャ、利点

gRPC の意味

gRPC は、拡張性と高速性に優れた API を構築するために利用される、堅牢なオープンソース RPC (Remote Procedure Call) フレームワークです。クライアントとサーバー間で透過的な通信を実現し、連携したシステムの構築が可能となります。Google、Netflix、Square、IBM、Cisco、Dropbox など、多くの有名技術企業が gRPC を採用しています。このフレームワークは、HTTP/2、プロトコルバッファ、その他最新技術を活用し、最高レベルの API セキュリティ、パフォーマンス、拡張性を実現しています。

gRPC の歴史

2015年、Google は異なる技術で構築された多数のマイクロサービスを連携させるため、従来の RPC フレームワークを拡張する形で gRPC を開発しました。当初は Google 内部のインフラと密接に連携していましたが、その後オープンソース化され、コミュニティで標準として利用されるようになりました。リリース初年度から、マイクロサービス、ウェブ、モバイル、IoT など多様なユースケースにおいて主要組織に活用され、2017年には普及の勢いから Cloud Native Computing Foundation (CNCF) のインキュベーションプロジェクトとなりました。

‍

基本的な gRPC の概念

gRPC の開発と成功は、JSON や XML よりも高い性能を発揮し、API セキュリティを強化する先進技術の活用にあります。gRPC の利点は、主に以下の概念に由来します:

プロトコルバッファ

プロトコルバッファ（Protobuf）は、Google が開発したシリアライズ／デシリアライズプロトコルで、サービス定義やクライアントライブラリの自動生成を容易にします。gRPC はこのプロトコルをインターフェース定義言語（IDL）およびシリアライズツールとして使用しています。現在のバージョンは proto3 で、最新機能を備え使いやすくなっています。

クライアントとサーバー間の gRPC サービスやメッセージは proto ファイルで定義されます。Protobuf コンパイラの protoc が、.proto ファイルを実行時にメモリへ読み込み、メモリ上のスキーマを使用してバイナリメッセージのシリアライズ／デシリアライズを実行するコードを生成します。コード生成後、各メッセージはクライアントとリモートサービス間で交換されます。

この流れから、Protobuf は JSON や XML に比べて大きな利点があることがわかります。データがバイナリ形式に変換されるため、パースに必要な CPU リソースが少なく、エンコードされたメッセージも軽量です。そのため、低速な CPU を持つモバイル端末でも、メッセージの交換が速く行われます。

‍

ストリーミング

ストリーミングは gRPC のもう一つの重要な概念です。ひとつのリクエストで複数の処理を実行できるようになっています。これは、HTTP/2 の多重化機能（単一 TCP 接続で複数のレスポンスやリクエストを同時に送受信できる機能）によって可能となります。以下は主なストリーミングの種類です:

• サーバーストリーミング RPC：クライアントがサーバーに単一のリクエストを送り、連続したデータを受信します。順序が保持され、サーバー側からメッセージが送り続けられ、すべて送信されるまで続きます。
• クライアントストリーミング RPC：クライアントが連続してデータを送信し、サーバーがそれを処理して単一のレスポンスを返します。各 RPC 呼び出し内でメッセージの順序が保証されます。
• 双方向ストリーミング RPC：クライアントとサーバーが互いに独立してメッセージをやり取りします。各ストリームでは順序が保持されますが、相互の送信順序は自由です。

HTTP/2

gRPC は、HTTP/1.1 の限界を克服するため 2015年に発表された HTTP/2 を基盤に開発されています。HTTP/1.1 との互換性は保ちつつ、以下のような先進的機能を備えています:

• バイナリフレーミング層 – HTTP/1.1 と異なり、HTTP/2 のリクエスト／レスポンスは小さなメッセージに分割され、バイナリ形式でフレーム化されるため、効率的に送信されます。これにより、リクエスト／レスポンスの多重化がネットワークリソースをブロックせずに可能となります。
• ストリーミング – クライアントのリクエストとサーバーのレスポンスを同時に行う双方向のフルデュプレックスストリーミングが実現します。
• フロー制御 – 進行中のメッセージ用のバッファメモリを詳細に制御できるフロー制御機構が組み込まれています。
• ヘッダー圧縮 – ヘッダーを含む全ての情報が送信前にエンコードされ、HPACK 圧縮方式により前回との差分のみが共有されることで、全体のパフォーマンスが向上します。
• 処理 – 同期および非同期の両処理が可能となり、様々なインタラクションやストリーミング RPC を実現できます。

HTTP/2 のこれらの機能により、gRPC は必要なリソースを削減し、クラウド上のアプリ間やサービス間での応答時間を短縮するとともに、モバイル端末のバッテリー寿命延長にも寄与します。

チャネル

チャネルは gRPC の基本概念です。HTTP/2 のストリームは、単一の接続で複数の通信を可能にしますが、チャネルは複数の同時接続上でのストリームをサポートします。これにより、指定のアドレスとポートで gRPC サーバーへ接続し、クライアントスタブの作成に活用されます。

‍

gRPC のアーキテクチャ

下記の gRPC アーキテクチャ図は、クライアント側とサーバー側の構成を示しています。各クライアントサービスには、現在のリモートプロシージャを表すスタブ（自動生成ファイル）が含まれており、クライアントはスタブへパラメータを渡してローカルな手続きを呼び出します。スタブは Protobuf を用いてパラメータをシリアライズし、ローカルマシンのクライアントタイムライブラリへリクエストを転送します。

OS は HTTP/2 プロトコルを介してリモートサーバーに通信を行います。サーバーの OS がパケットを受け取り、サーバースタブの手続きを呼び出すと、受信したパラメータがデコードされ、Protobuf を用いて該当する処理が実行されます。サーバースタブはエンコードされたレスポンスをクライアントのトランスポート層へ返し、クライアントスタブが結果メッセージを受け取りパラメータを展開、処理結果が呼び出し元へ返されます。

‍

gRPC の利点

gRPC は従来の RPC 設計に新たな視点を加え、いくつかの面で優れた利点を提供します。gRPC の採用が進む理由は、以下の通りです:

1. パフォーマンス

各種評価により、gRPC は Protobuf と HTTP/2 を活用することで、REST+JSON 通信に比べ最大10倍の高速なパフォーマンスと向上した API セキュリティを実現していることが示されています。Protobuf はサーバー側とクライアント側で迅速にメッセージをシリアライズし、コンパクトなペイロードを生成します。HTTP/2 はサーバープッシュ、多重化、ヘッダー圧縮などにより、さらなる性能向上を実現しています。サーバープッシュは、クライアントの要求を待たずにサーバー側からコンテンツを送信し、多重化は先頭ブロッキングを解消します。また、先進的な圧縮方式でメッセージサイズを削減し、読み込み速度を高めます。

2. ストリーミング

gRPC では、クライアント側またはサーバー側のストリーミングがサービス定義に含まれており、ストリーミングサービスやクライアントの構築が容易です。HTTP/2 を介して、以下のストリーミング方式がサポートされます:

• 単一（ストリーミングなし）
• クライアントからサーバーへのストリーミング
• サーバーからクライアントへのストリーミング
• 双方向ストリーミング

3. コード生成

gRPC の大きな特徴は、クライアント／サーバー向けのコードが自動生成される点です。gRPC フレームワークは protoc コンパイラを用いて、.proto ファイルからコードを生成します。これにより、メッセージフォーマットやサービスエンドポイントが定義され、サーバー用のスケルトンやクライアント用のネットワークスタブが自動生成されるため、開発時間が大幅に削減されます。

4. 相互運用性

gRPC のツールやライブラリは、Java、JavaScript、Ruby、Python、Go、Dart、Objective-C、C# など、複数のプラットフォームや言語に対応しています。Protobuf のバイナリ形式と効率的なコード生成により、各プラットフォームで高性能なアプリケーションが構築可能です。

5. セキュリティ

gRPC は、TLS による エンドツーエンド暗号化された HTTP/2 接続を利用することで、API のセキュリティを確保しています。SSL/TLS を用いた認証と通信の暗号化が推奨されます。

6. 使いやすさと生産性

gRPC はオールインワン型の RPC ソリューションであり、様々な言語やプラットフォームでシームレスに動作します。必要な定型コードが自動生成されるため、開発者はビジネスロジックに集中できます。

7. 組み込み機能

gRPC には、メタデータ交換、暗号化、認証、タイムアウト／キャンセル、インターセプター、ロードバランシング、サービスディスカバリなどの機能が最初から備わっています。

‍

gRPC の欠点

他の技術と同様、gRPC には以下のような注意点もあります:

1. ブラウザ対応の制限

gRPC は HTTP/2 を多用するため、ウェブブラウザから直接 gRPC サービスを呼び出すことはできません。最新のブラウザは、gRPC クライアントに必要なリクエスト制御を提供していないため、HTTP/1.1 と HTTP/2 の変換にはプロキシレイヤーや gRPC-web が必要となります。

2. 人が読めない形式

Protobuf により gRPC のメッセージは、人が直接読めない形式に圧縮されます。正しくデシリアライズするためには、ファイル内にメッセージのインターフェース記述が必要となり、開発者は gRPC 用のコマンドラインツールなど、追加のツールを利用してペイロードの解析やデバッグを行う必要があります。

3. エッジキャッシュの非対応

HTTP はエッジキャッシュをサポートしていますが、gRPC は POST メソッドを使用するため、API セキュリティ上の懸念があり、仲介者を介したレスポンスのキャッシュができません。さらに、gRPC の仕様ではキャッシュに関する規定がなく、サーバーとクライアント間でキャッシュのセマンティクスを取り入れる余地が示されています。

4. 学習曲線が急

多くのチームが gRPC や Protobufの習得、さらには HTTP/2 の取扱いに苦労しており、そのため可能な限り REST に依存する傾向があります。

gRPC と REST の比較

gRPC は、API 分野で確固たる実績を築いている有望な技術ですが、REST の代替や API 開発の唯一の選択肢というわけではありません。大規模なマイクロサービス連携、即時性が求められる通信、低電力・低帯域システム、多言語環境など、特定の用途に適した代替手段といえます。

REST とは異なり、gRPC は HTTP/2 の多重化ストリーミングやバイナリプロトコルフレーミングを最大限に活用しています。さらに、Protobuf によるメッセージ構造と組み込みのコード生成機能により、複数言語環境での高いパフォーマンスを実現しています。これらの機能は gRPC を優れた API アーキテクチャスタイルにしていますが、主な欠点としてブラウザ対応が限定されるため、内部システム向けとなる点が挙げられます。

一方、REST は全てのブラウザでサポートされ、広く採用されているため、実績あるフォーマットとして安心して利用できます。最終的な API フォーマットの選定は、ユースケースの要求に大きく依存します。

関連する記事を読む: 

• gRPC と REST の比較
• REST と SOAP の違い
• gRPC と WebSocket

結論

gRPC は、特にマイクロサービスアーキテクチャにおいて、その高速かつ効率的な通信性能から注目を集めています。しかし、バイナリ形式のメッセージは内容の検証、認証、認可などのセキュリティ対策を行う上で、新たな課題も生み出します。こうしたリスクに対処するため、OWASP API Security Top-10 を活用し、gRPC アプリの脆弱性やセキュリティリスクの検出および軽減策を講じることが求められます。また、gRPC 固有の状況に対応できる即時の API セキュリティ層の導入も重要です。