HTTP API を使用した gRPC サービスの比較

[アーティクル]
11/30/2023

この記事では、gRPC サービスと、JSON を使用する HTTP API (ASP.NET Core Web API を含む) を比較して説明します。アプリに API を提供するために使用するテクノロジは重要な選択であり、gRPC は、HTTP API と比較して特有の利点を備えています。この記事では、gRPC の長所と短所について説明し、他のテクノロジよりも gRPC を使用するのが推奨されるシナリオを示します。

比較の概要

次の表は、gRPC の機能と、JSON を使用する HTTP API の機能の比較の概要を示しています。

機能	gRPC	JSON を使用する HTTP API
コントラクト	必須 (`.proto`)	オプション (OpenAPI)
プロトコル	HTTP/2	HTTP
Payload	Protobuf (小、バイナリ)	JSON (大、人が判読できる)
規範的性質	厳密な仕様	制約が緩い。どのような HTTP でも有効です。
ストリーム	クライアント、サーバー、双方向	クライアント、サーバー
ブラウザーのサポート	いいえ (grpc-web が必要)	はい
セキュリティ	トランスポート (TLS)	トランスポート (TLS)
クライアントコード生成	はい	OpenAPI とサードパーティ製ツール

gRPC の長所

パフォーマンス

gRPC メッセージは、効率的なバイナリメッセージ形式である Protobuf を使用してシリアル化されます。 Protobuf はサーバーおよびクライアント上で、非常に高速にシリアル化を行います。 Protobuf のシリアル化では、メッセージペイロードが小さくなります。これはモバイルアプリのように帯域幅が限られるシナリオでは重要です。

gRPC は、HTTP のメジャーリビジョンである HTTP/2 向けに設計されており、パフォーマンスは HTTP 1.x よりも大幅に向上します。

バイナリフレームと圧縮。 HTTP/2 プロトコルは、送信と受信の両方においてコンパクトかつ効率的です。
単一 TCP 接続での複数の HTTP/2 呼び出しの多重化。多重化により、ヘッドオブラインブロッキングが解消されます。

HTTP/2 は gRPC に限定されません。 JSON を使用する HTTP API を含め、要求の種類の多くでは、HTTP/2 を使用することができ、パフォーマンスの向上による恩恵を受けることができます。

コード生成

すべての gRPC フレームワークで、コード生成は最高レベルでサポートされています。 gRPC 開発の中核となるファイルは .proto ファイルであり、そこで gRPC のサービスとメッセージのコントラクトが定義されます。このファイルから、gRPC フレームワークによって、サービス基本クラス、メッセージ、および完全なクライアントが生成されます。

サーバーとクライアントの間で .proto ファイルを共有すれば、端から端までメッセージとクライアントコードを生成できます。クライアントのコード生成によって、クライアントとサーバー上でメッセージが重複しなくなり、厳密に型指定されたクライアントが自動的に作成されます。クライアントを記述する必要がないので、多くのサービスを持つアプリケーションの開発時間が大幅に節約されます。

厳密な仕様

JSON を使用する HTTP API の公式仕様は存在しません。 URL、HTTP 動詞、および応答コードの最適な形式については、開発者が議論します。

gRPC 仕様では、gRPC サービスが従う必要がある形式の規範が示されています。 gRPC はプラットフォームや実装の全体にわたって一貫性があるため、議論は不要であり、開発者の時間が節約されます。

ストリーム

HTTP/2 では、有効期間が長いリアルタイム通信ストリームの基盤が提供されます。 gRPC では、HTTP/2 を介したストリーミングが最高レベルでサポートされています。

gRPC サービスでは、ストリーミングのすべての組み合わせがサポートされます。

Unary (ストリーミングなし)
サーバーからクライアントへのストリーミング
クライアントからサーバーへのストリーミング
双方向ストリーミング

期限/タイムアウトとキャンセル

gRPC を使用すると、クライアントが RPC の完了を待機する時間を指定できます。期限がサーバーに送信され、期限を越えた場合にどのようなアクションを実行するかをサーバーで決定できます。たとえば、タイムアウト時に、進行中の gRPC/HTTP/データベース要求をサーバーでキャンセルする場合があります。

子の gRPC 呼び出しを通して期限やキャンセルを伝達すると、リソース使用量の制限を適用する助けとなります。

gRPC での推奨されるシナリオ

gRPC は以下のシナリオに適しています。

マイクロサービス: gRPC は、待機時間が短く、スループットの高い通信のために設計されています。 gRPC は、効率が非常に重要となる軽量のマイクロサービスに適しています。
ポイントツーポイントのリアルタイム通信: gRPC での双方向ストリーミングのサポートは非常に優秀です。 gRPC サービスでは、ポーリングせずにメッセージをリアルタイムにプッシュできます。
多言語環境: gRPC ツールでは、一般的な開発言語がすべてサポートされているため、gRPC は多言語環境に適した選択肢となっています。
ネットワーク面の制約がある環境: gRPC メッセージは、軽量なメッセージ形式である Protobuf でシリアル化されます。 gRPC メッセージは常に、同等の JSON メッセージよりも小さくなります。
プロセス間通信 (IPC) :UNIX ドメインソケットや名前付きパイプなどの IPC トランスポートを gRPC と共に使用して、同じマシン上のアプリ間で通信を行うことができます。詳細については、「gRPC を使用したプロセス間通信」を参照してください。

gRPC の短所

ブラウザーのサポートが限定的

現在のところ、ブラウザーから gRPC サービスを直接呼び出すことはできません。 gRPC は HTTP/2 の機能を多用しており、gRPC クライアントをサポートするための Web 要求を通して必要とされるレベルの制御を提供するブラウザーがありません。たとえば、ブラウザーでは呼び出し元に、HTTP/2 を使用するよう求めたり、基になる HTTP/2 フレームへのアクセスを提供したりすることを許可していません。

ASP.NET Core での gRPC には、ブラウザーと互換性のある 2 つのソリューションが用意されています。

gRPC-Web を使うと、gRPC-Web クライアントと Protobuf を使用してブラウザーアプリで gRPC サービスを呼び出すことができます。 gRPC-Web では、ブラウザーアプリで gRPC クライアントを生成することが要求されます。 gRPC-Web を使用すると、ブラウザーアプリは gRPC の高パフォーマンスで低ネットワークの使用を活用できます。

.NET には、gRPC-Web のサポートが組み込まれています。詳細については、「ASP.NET Core gRPC アプリでの gRPC-Web」参照してください。
gRPC JSON コード変換を使用すると、JSON と RESTful API のように、ブラウザーアプリで gRPC サービスを呼び出すことができます。ブラウザーアプリで gRPC クライアントを生成する必要はありません。gRPC について知る必要もありません。 RESTful API は、HTTP メタデータを使用して .proto ファイルに注釈を付けることによって、gRPC サービスから自動的に作成できます。コード変換により、アプリで gRPC と JSON の両方の Web API をサポートできるため、両方に個別のサービスを構築する手間を省くことができます。

.NET には、gRPC サービスから JSON Web API を作成するためのサポートが組み込まれています。詳細については、「ASP.NET Core gRPC アプリでの gRPC JSON コード変換」を参照してください。

注意

gRPC JSON コード変換には .NET 7 以降が必要です。

人が判読できない

HTTP API 要求はテキストとして送信され、人が読み取りと作成を行えます。

gRPC メッセージは、既定では Protobuf でエンコードされます。 Protobuf での送受信は効率的ですが、そのバイナリ形式は人が判読できません。 Protobuf では、正しく逆シリアル化するために、.proto ファイルで指定されているメッセージのインターフェイスに関する説明を必要とします。ネットワーク上の Protobuf ペイロードを分析し、手動で要求を作成するには、追加のツールが必要です。

バイナリの Protobuf メッセージをサポートするため、サーバーリフレクションや gRPC コマンドラインツールなどの機能が存在します。また、Protobuf メッセージは、JSON との間の変換がサポートされています。組み込みの JSON 変換によって、デバッグ時に Protobuf メッセージを人が判読できる形式に変換する効率的な方法が提供されます。

他のフレームワークのシナリオ

以下のシナリオでは、gRPC よりも他のフレームワークが推奨されます。

ブラウザーでアクセスできる API: gRPC は、ブラウザーで完全にサポートされているわけではありません。 gRPC-Web でブラウザーのサポートを提供可能ですが、制限があり、サーバープロキシが必要になります。
ブロードキャストリアルタイム通信: gRPC ではストリーミングによるリアルタイム通信がサポートされますが、登録済みの接続にメッセージをブロードキャストするという概念がありません。たとえば、チャットルーム内のすべてのクライアントに新しいチャットメッセージを送信する必要があるチャットルームシナリオでは、クライアントに新しいチャットメッセージを個々にストリーミングするため、それぞれに gRPC 呼び出しが必要です。 SignalR は、このシナリオの場合に便利なフレームワークです。 SignalR には永続的な接続という概念があり、メッセージをブロードキャストするためのサポートが組み込まれています。