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の代わりにProtocol Buffers（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つのリクエストを処理するのではなく、複数のリクエストを並列処理する機能をサポートしています。また、通信は双方向なので、1つの接続でリクエストと応答の両方を同時に送信することができます。
全体的に見て、これによりパフォーマンスが向上し、ネットワーク使用率が減少します。これは、ビジー状態のマイクロサービス アーキテクチャでは特に重要となる可能性があります。ただし、いくつかの制限があります。HTTP/2は一般に最新のWebブラウザではサポートされていないため、NGINXなどのリバース プロキシを使用してアプリケーションを配信する必要がある場合があります。
現在、RESTは最も採用されているAPI設計スタイルであるため、gRPCと比較するための便利な参照ポイントとなります。RESTとgRPCはどちらも、Webアプリケーションおよびマイクロサービス向けAPIの構築において有効なアプローチであり、どちらか一方が他方より優れているとは限りません。とは言え、これらの主な違いを理解しておくと、業務に最適なツールを選択する際に役立ちます。
gRPCとRESTの主な違いは、次のカテゴリに分類できます。
REST APIでもHTTP/2を利用できますが、RESTfulサービスは従来、トランスポート レイヤとしてテキストベースのHTTP/1.1を使用しています。gRPCは、より効率的でヘッダー圧縮や1つのTCP接続を介した多重化などが可能なバイナリ プロトコルであるHTTP/2のみを使用します。
REST APIは、通常、データを送受信するためのデータ形式としてJSONを使用します。JSONはテキストベースで、簡単に読み書きができ、広くサポートされています。gRPC APIは、ペイロードが小さく、高速でやり取りできるバイナリ形式のProtobufを使用します。ただし、Protobufは簡単にそのまま読み取ることができません。
REST APIは、ストリーミングのサポートが制限されている要求応答モデルをサポートします。一方、gRPC APIはHTTP/2経由で配信され、単項（要求応答）、サーバ ストリーミング、クライアント ストリーミング、双方向ストリーミングなど、いくつかの通信パターンをサポートします。
RESTは、GET、POST、PUT、DELETEなどの標準HTTPメソッドをサポートするリソース中心のモデルです。すべてのリクエストには、その処理に必要なすべての情報を含める必要があります。また、APIコントラクトは通常、OpenAPI仕様を使用して記述され、クライアントのコードとサーバのコードは別のステップとして扱われます。これとは対照的に、gRPCはサービス中心のモデルで、メッセージとサービスを.protoファイルで定義します。このファイルを使用して、APIクライアントとAPIサーバ両方向けのコードを生成することができます。
RESTでは、HTTP/1.1経由のテキストベースのデータ転送のため、速度が下がる可能性があります。各リクエストにはTCPハンドシェイクが必要なため、遅延が発生する可能性があります。gRPCはHTTP/2経由の複数のストリームをサポートしているため、複数のクライアントが新しいTCP接続を確立しなくても複数のリクエストを同時に送信できます。また、ヘッダー圧縮などのHTTP/2機能も使用されます。
RESTは、エラー処理に標準のHTTPステータス コードを使用します。これに対し、gRPCは、エラー ステータス コードを非常に細かく定義し、一貫性を確保します。gRPCモデルは、デフォルトでは機能が限られていますが、Googleが開発した豊富なエラー モデルを使用して拡張することが一般的です。
RESTは、ほぼすべての言語で広くサポートされていますが、コード生成機能は組み込まれていません。実装は完全に開発者に任されています。gRPCでは、protocコンパイラを使用して、複数のプログラミング言語のコードをネイティブ生成できます。
結論を言うと、gRPCとRESTのどちらを選択するかは、何をする必要があるかによって異なります。gRPCは、分散アプリケーションでサービスが通信するための効率的で高性能な方法を提供します。ただし、Webブラウザやその他のクライアントから直接読み取ることはできず、フロントエンド クライアントとやり取りするには、APIゲートウェイまたはNGINXなどのリバース プロキシが必要です。これは、イベント駆動型マイクロサービス アーキテクチャの一部である内部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 Application Firewall（WAF）、その他のAPI管理およびセキュリティ ツールが、本番環境でgRPCアプリケーションおよびAPIを保護するために十分な能力を備えていることを確認する必要があります。これらのツールは、各サービスの.protoファイルをインポートし、それを使用してgRPCアプリケーションとAPIにセキュリティ保護を適用できる必要があります。
gRPCは、開発者およびNetflixやLyftなどの大企業がマイクロサービス アーキテクチャで使用するための人気の代替手段として、大きな支持を得ています。しかし、gRPCはREST APIの代替手段ではなく、APIを構築するための本質的に優れた方法でもありません。gRPCは、主に内部のマイクロサービス環境向けのAPIを構築していて、効率的なリアルタイム通信が必要な場合に検討する価値のある代替手段にすぎません。
gRPCは、パフォーマンス上の利点と開発のしやすさから、クラウドネイティブ アプリケーションで今後も引き続き普及していくと思われます。一方、APIを一般向けに公開する必要がある開発者は、アプリケーションで引き続きRESTを使用するでしょう。RESTは、その下位互換性や、既存のAPIインフラストラクチャおよび操作と緊密に統合できることから、クラウドネイティブ環境でも引き続き使用されるでしょう。
NGINXは、gRPC導入のあらゆる段階に対応できるさまざまな無料リソースを提供しています。