Google リモート プロシージャ コール（gRPC）は、HTTP/2 経由で API を実装するための高性能なオープンソース フレームワークです。 これは、特にコードが異なるマシン上で実行される可能性がある場合に、開発者が分散アプリケーションを簡単に構築できるように設計されています。
gRPCは当初、リモート プロシージャ コール (RPC) を実装するためのテクノロジーとして Google によって開発されました。 現在、gRPC はCloud Native Computing Foundationのインキュベートされたプロジェクトであり、実稼働環境で使用されており、多数の貢献者によってサポートされています。
Google が gRPC を開発した理由を理解するために、 API設計のタイムラインを簡単に見てみましょう。
RPC は、API を設計および構築する最も古い方法の 1 つです。RPC を使用すると、実際には別のマシン (通常はローカル ネットワーク上) で実行されているサービスを呼び出す場合でも、ローカル コンピューターで実行されるかのようにコードを記述できます。
実際には、これにより、開発者はネットワークの詳細を考慮することなく、直接アクション（SendUserMessages、addEntry など）を使用できるようになります。 RPC メッセージは軽量かつ効率的ですが、基盤となるシステムと密接に結合されています。 これにより、統合や変更が困難になり、システムの詳細が漏洩する可能性が高くなります。
REST APIアーキテクチャが導入されたとき、GET、POST、PUT、DELETE などの汎用HTTPメソッドを使用してデータやリソースにアクセスする統一された方法が提供され、これらの課題の一部が解決されました。 REST はデータ アクセスを簡素化しますが、API は必要以上のメタデータを返すことがよくあります。 REST API では、ネットワークに関する詳細な情報 (リクエストの送信先など) も必要となるため、RPC ほど軽量で効率的ではありません。
gRPC は、新しいテクノロジーを採用することで、古い RPC 方式を更新し、相互運用性と効率性を高めます。 現在、これはマイクロサービスアーキテクチャ用の API を開発する際の魅力的な選択肢です。
gRPC の利点は次のとおりです。
全体として、gRPC は、高度に分散されたマイクロサービス アーキテクチャにおけるサービス間通信に最適な、高性能で柔軟なフレームワークを提供します。
gRPC の利点とメリットは、主に次の 2 つのテクノロジーの採用から生まれます。
gRPC は、XML や JSON の代わりにプロトコル バッファー(またはProtobufs ) を使用してサービスとメッセージを定義します。 これは、サービスが相互に送信する構造化メッセージをシリアル化するための、言語に依存しないメカニズムです。
REST API のOpenAPI 仕様の概念と同様に、gRPC の API 契約は .proto テキスト ファイルに実装され、開発者はデータの構造化方法を定義します。 次に、protoc コンパイラが .proto テキスト ファイルをサポートされている言語に自動的にコンパイルします。 実行時に、メッセージは圧縮され、バイナリ形式で送信されます。
これには 2 つの重要な利点があります。
従来、REST API はトランスポート層として HTTP/1.1 を使用していました。 REST API は HTTP/2 経由でも配信できますが、gRPC が HTTP/2 のみを使用することで、いくつかの重要な利点がもたらされます。 これらの利点の 1 つは、バイナリを使用して通信を送信できることです。 さらに、HTTP/2 は、一度に 1 つのリクエストを処理するのではなく、複数のリクエストを並列に処理する機能をサポートしています。 通信も双方向であるため、単一の接続で要求と応答の両方を同時に送信できます。
全体的に、これによりパフォーマンスが向上し、ネットワークの使用率が削減されます。これは、忙しいマイクロサービス アーキテクチャでは特に価値があります。 ただし、いくつか制限があります。 HTTP/2 は一般に最新の Web ブラウザーではサポートされていないため、アプリケーションを配信するには NGINX などのリバース プロキシを使用する必要がある場合があります。
現在、REST は最も支配的な API 設計スタイルであるため、gRPC と比較するための便利な参照ポイントとなります。REST と gRPC はどちらも、Web アプリケーションとマイクロサービスの API を構築するための有効なアプローチであり、どちらかが他方より優れているとは限りません。 そうは言っても、仕事に最適なツールを選択するには、それらの主な違いを理解しておくことが役立ちます。
gRPC と REST の主な違いは、次のカテゴリに分類されます。
REST API は HTTP/2 を利用できますが、RESTful サービスは従来、トランスポート層としてテキストベースの HTTP/1.1 を使用しています。gRPC は、より効率的で、ヘッダー圧縮や単一の TCP 接続での多重化などの機能を可能にするバイナリ プロトコルである HTTP/2 のみを使用します。
REST API は通常、データの送受信のデータ形式として JSON を使用します。 JSON はテキストベースで、読み書きが簡単で、幅広くサポートされています。gRPC API は、ペイロードが小さく、対話が高速になるバイナリ形式の Protobuf を使用します。 ただし、Protobuf は単独では簡単に読み取ることができません。
REST API は、ストリーミングのサポートが限定されている要求応答モデルをサポートします。 対照的に、gRPC API は HTTP/2 経由で配信され、Unary (要求応答)、サーバー ストリーミング、クライアント ストリーミング、双方向ストリーミングなどの複数の通信パターンをサポートします。
REST は、GET、POST、PUT、DELETE などの標準 HTTP メソッドをサポートするリソース中心のモデルです。 すべてのリクエストには、処理に必要なすべての情報が含まれている必要があります。 さらに、API 契約は通常、OpenAPI 仕様を使用して記述され、クライアントとサーバーのコーディングは別のステップとして扱われます。 対照的に、gRPC は、メッセージとサービスが .proto ファイルで定義されるサービス中心のモデルです。 このファイルを使用して、API クライアントとサーバーの両方のコードを生成することができます。
REST は、HTTP/1.1 を介したテキストベースのデータ転送のため、速度が遅くなる可能性があります。 各リクエストには TCP ハンドシェイクが必要であり、これにより遅延が発生する可能性があります。gRPC は HTTP/2 経由の複数のストリームをサポートしているため、複数のクライアントが新しい TCP 接続を確立せずに同時に複数のリクエストを送信できます。 また、ヘッダー圧縮などの HTTP/2 機能も活用します。
REST はエラー処理に標準の HTTP ステータス コードを使用します。 対照的に、gRPC は、エラー ステータス コードを定義し、それらの一貫性を確保するためのより詳細な情報を提供します。 デフォルトでは、gRPC モデルは非常に制限されていますが、 Google が開発したより豊富なエラー モデルを使用して拡張されるのが最も一般的です。
REST はほぼすべての言語で広くサポートされていますが、組み込みのコード生成機能は提供されていません。 実装は完全に開発者に任されます。 gRPC は、protoc コンパイラを使用して、複数のプログラミング言語のネイティブ コード生成を提供します。
要約すると、gRPC と REST のどちらを選択するかは、達成したい目標によって異なります。gRPC は、分散アプリケーションでサービスが通信するための効率的で高性能な方法を提供します。 ただし、Web ブラウザーやその他のクライアントでは直接読み取ることはできず、フロントエンド クライアントと対話するには、NGINX などのAPI ゲートウェイまたはリバース プロキシが必要です。 これは、イベント駆動型マイクロサービス アーキテクチャの一部である内部 API に最適なオプションです。
一方、REST は広く採用されており、事実上あらゆる言語でサポートされています。 データは JSON または XML を使用して交換されるため、人間と機械が読み取り可能です。 さらに、使い始めるための学習曲線がはるかに低く、多くの Web ブラウザーでサポートされているため、公開 API に最適です。
gRPC は、マイクロサービス アーキテクチャでの通信に最適なオプションの 1 つです。 これは部分的にはパフォーマンスによるものですが、言語サポートの柔軟性によるものでもあります。 開発者は、好みの言語で実行される gRPC クライアントとサーバーを簡単に構築および生成できます。 gRPC は API 契約をバイナリ形式で記述するため、マイクロサービスは構築に使用される言語に依存せずに通信できます。
最も一般的な gRPC ベースのマイクロサービス アーキテクチャの 1 つは、マイクロサービスの前に API ゲートウェイを配置し、すべての内部通信を gRPC 経由で処理することです。API ゲートウェイは、HTTP/1.1 からの受信リクエストを処理し、HTTP/2 経由の gRPC リクエストとしてマイクロサービスにプロキシします。
gRPC の採用が拡大するにつれて、開発者とセキュリティ運用チームは効果的なセキュリティ ソリューションが導入されていることを確認する必要があります。 gRPC メッセージはバイナリ形式であるため、ASCII ベースの通信を想定するデバイスやツールでは問題が発生する可能性があります。
gRPC API は、最も一般的な API セキュリティ脅威の多くに対しても脆弱です。 アクセス制御、暗号化、ランタイム保護などの標準的な API セキュリティ プラクティスは、gRPC ベースのアーキテクチャでも同様に重要です。
gRPC アプリケーションと API には、セキュリティに対する総合的なアプローチが必要です。 gRPC を保護するためのベスト プラクティスには次のようなものがあります。
最終的には、 API ゲートウェイ、 Web アプリケーション ファイアウォール(WAF)、その他の API 管理およびセキュリティ ツールが、運用環境で gRPC アプリケーションと API を保護するのに十分な能力があることを確認する必要があります。 各サービスの .proto ファイルをインポートし、それを使用して gRPC アプリケーションと API にセキュリティ保護を適用できる必要があります。
gRPC は、開発者やNetflixやLyftなどの大企業がマイクロサービス アーキテクチャで使用するための人気のある代替手段として、大きな注目を集めています。 とはいえ、gRPC は REST API の代替ではなく、API を構築するための本質的に優れた方法でもありません。gRPC は、主に内部マイクロサービス環境用の API を構築しており、効率的なリアルタイム通信が必要な場合に検討すべき代替手段にすぎません。
今後、gRPC はパフォーマンス上の利点と開発の容易さにより、クラウド ネイティブ アプリケーションで引き続き普及していくと思われます。 一方、API を公開する必要がある開発者は、アプリケーションで REST を引き続き使用します。 REST は、下位互換性と既存の API インフラストラクチャおよび操作との緊密な統合により、クラウド ネイティブ環境でも引き続き存在します。
NGINX は、gRPC のあらゆる段階に対応できるさまざまな無料リソースを提供しています。