gRPCとは？詳しく解説します

TOP
コラム
gRPCとは？詳しく解説します

概要

gRPCはGoogleによって、RPC基盤であるStubbyの次世代版として2015年に開発されたRPCフレームワークです。あらゆる環境で実行できる最新のオープンソースの高性能リモートで、RPCフレームワークとして機能する点が最大のポイントです。
RPCフレームワークについて簡単に触れておきます。 RPCはRemote Procedure Callの略で、別の場所にある関数を別のコンテキストで実行できるものを指します。ユーザーは、実行するリモートプロシージャを選択し、必要なパラメーターをシリアル化し、追加情報をメッセージに追加します。これはサーバーに送信され、サーバーは他のアプリケーションとやり取りして、メッセージをデコードし、操作を実行します。その後、結果が最初のユーザーに返されます。このフレームワークは、リモートシステムと対話する必要があるアプリケーションを作成するために使用されます。

クライアントとサーバー間のインターフェースを定義する簡単な方法を提供します。 RPCフレームワークは、次の4つのコンポーネントで構成されています。クライアントプロトコルインターフェイス (CPI)、サーバープロトコルインターフェイス (SPI)、クライアントプロトコルの実装 (CPI)、サーバープロトコルの実装 (SPI)です。
gRPCはロードバランシング、トレース、ヘルスチェック、および認証のプラグイン可能なサポートにより、データセンター内およびデータセンター間でサービスを効率的に接続できます。また、デバイス、モバイルアプリケーション、ブラウザをバックエンドサービスに接続する分散コンピューティングのラストマイルにも適用できます。 gRPCの利用シナリオとしては、マイクロサービス型のアーキテクチャーにおけるサービス間の接続や、モバイルデバイスのクライアントとバックエンドサービスとの接続などが一般的となっております。

背景

Googleは10年以上にわたり、Stubbyと呼ばれる単一の汎用RPCインフラストラクチャを使用して、データセンター内およびデータセンター全体で実行されている多数のマイクロサービスを接続してきました。
統一されたクロスプラットフォームのRPCインフラストラクチャを持つことで、効率、セキュリティ、信頼性、行動分析の改善をフリート全体に展開することができます。
Stubbyには多くの優れた機能がありますが、標準に基づいておらず、内部インフラストラクチャと密接に結合されているため公開に適しているとは見なされません。 SPDY、HTTP/2、QUICの出現により、これらの同じ機能の多くが、Stubbyが提供しない他の機能とともに、パブリックスタンダードに登場しました。この標準化を活用し、その適用範囲をモバイル、IoT、およびクラウドのユースケースに拡張するために、Stubbyを作り直す時が来たことが明らかになりました。以上がgRPCの背景です。

概念と設計

これらは以下のような概念によって設計されております。
一点目が、オブジェクトではなくサービス、参照ではなくメッセージとなる点です。 gRPCでは分散オブジェクトの落とし穴を回避しながら、システム間で大まかなメッセージ交換を行うというマイクロサービスの設計哲学を実行します。
二点目が、カバレッジとシンプルさを実現することです。 gRPCでは選択したプラットフォーム用に誰かが簡単に構築できる必要があると考え設計されております。
三点目が、フリーかつオープンであることです。 gRPCでは基本的な機能をすべての人が無料で使用できるようにします。すべてのアーティファクトをオープンソースの取り組みとしてリリースし、採用を促進し、妨げないようにするライセンスを使用します。
四点目が、相互運用性とリーチです。 gRPCにおけるワイヤプロトコルは、一般的なインターネットインフラストラクチャを介したトラバーサルに耐えられる必要があります。
五点目が、汎用かつ高性能である点です。 gRPCのスタックは、ユースケース固有のスタックと比較してパフォーマンスをほとんど犠牲にせずに、幅広いクラスのユースケースに適用できる必要があります。
六点目が、レイヤードです。 gRPCのスタックの主要なファセットは、独立して進化できる必要があります。ワイヤ形式の改訂によって、アプリケーション層のバインディングが中断されてはなりません。
七点目が、ペイロードに依存しないことです。異なるサービスでは、プロトコルバッファ、JSON、XML、Thriftなどの異なるメッセージタイプとエンコーディングを使用する必要があります。
八点目が、ストリーミングです。ストレージシステムは、ストリーミングとフロー制御に依存して大規模なデータセットを表現します。音声からテキストへの変換や株価表示などの他のサービスは、ストリーミングに依存して、時間的に関連するメッセージシーケンスを表します。

特徴

次にgRPCの特徴をいくつか説明させていただきます。
一点目がシンプルなサービス定義です。 gRPCでは強力なバイナリシリアル化ツールセットおよび言語であるProtocol Buffersを使用してサービスを定義します。
二点目が素早い開始と拡張です。
gRPCでは迅速に開始して拡張し、ランタイム環境と開発環境を1行でインストールし、フレームワークを使用して1秒あたり数百万のRPCにスケーリングすることが可能です。
三点目がさまざまな言語とプラットフォームで動作することです。 gRPCは複数の言語とプラットフォームで動作し、さまざまな言語とプラットフォームで、サービスの慣用的なクライアントとサーバーのスタブを自動的に生成します。
四点目が双方向ストリーミングと統合認証機能のアイコンです。 gRPCは双方向ストリーミングと統合認証を行い、HTTP/2ベースのトランスポートによる双方向ストリーミングと完全に統合されたプラガブル認証を実施します。

長所と短所

gRPCの長所について説明します。 gRPCの長所は、単純であるためAPIの強力な形式として機能することです。 GETを使用して情報をフェッチし、POSTを使用してその他すべてを取得するという簡単な作業で実施できます。さらに、これは関数を簡単に追加できることを意味し、軽量のペイロードの場合、全体的に優れたパフォーマンスが得られます。任意のタイプの関数を定義できるため、無限に構成可能です。
典型的なユースケースには、リモートシステムに単純なリクエストを送信するコマンドAPI や、内部マイクロサービスを大規模かつ高速に管理するのに役立つ顧客固有のAPIが含まれます。複雑なリモート呼び出しを簡素化することで、gRPCはDockerベースのアプリケーションの世界の定番となり、実行するリモート呼び出しが大量にある場合にその価値を証明しています。

では、gRPCの短所について説明します。 gRPCが不十分な点は、基盤となるシステムと密接に結合されているため、多くの場合、再利用性が制限されていることです。さらに、APIと実際のシステム機能の間に抽象化レイヤーがないため、セキュリティ上の懸念が生じる可能性があります。

プロトコルバッファ

gRPCプロトコルバッファについて紹介します。gRPCは、プロトコルバッファをインターフェイス定義言語 ( IDL) としても、基になるメッセージ交換形式としても使用することが可能です。最初にgRPCの動作を確認したいだけの場合は、言語を選択してそのクイックスタートを試すことで挙動が確認できます。
gRPCでは、クライアントアプリケーションは別のマシン上のサーバーアプリケーションのメソッドをローカルオブジェクトであるかのように直接呼び出すことができるため、分散アプリケーションやサービスを簡単に作成できます。多くのRPCシステムと同様に、gRPCはサービスを定義するという考え方に基づいており、パラメーターと戻り値の型を使用してリモートで呼び出すことができるメソッドを指定します。サーバー側では、サーバーがこのインターフェイスを実装し、gRPCサーバーを実行してクライアント呼び出しを処理します。クライアント側では、クライアントはサーバーと同じメソッドを提供するスタブを持っています。デフォルトでは、gRPCはプロトコルバッファを使用します、構造化データをシリアル化するためのGoogleの成熟したオープンソースメカニズムです。これがどのように機能するかを簡単に紹介します。プロトコルバッファを操作する際の最初のステップは、シリアル化するデータの構造をprotoファイルに定義することです。
プロトコルバッファデータはメッセージとして構造化されます。各メッセージはフィールドと呼ばれる一連の名前と値のペアを含む情報の小さな論理レコードです。

API

gRPCは、ファイル内のサービス定義から開始して、クライアント側とサーバー側のコードを生成するプロトコルバッファーコンパイラプラグインを提供します。
gRPCユーザーは通常、クライアント側でこれらのAPIを呼び出し、サーバー側で対応するAPIを実装します。サーバー側では、サーバーはサービスによって宣言されたメソッドを実装し、gRPCサーバーを実行してクライアント呼び出しを処理します。 gRPCインフラストラクチャは、受信リクエストをデコードし、サービスメソッドを実行し、サービスレスポンスをエンコードします。クライアント側では、クライアントは、サービスと同じメソッドを実装するスタブと呼ばれるローカルオブジェクトを持ちます。その後クライアントはローカルオブジェクトでこれらのメソッドを呼び出すだけで、呼び出しのパラメーターを適切なプロトコルバッファーメッセージタイプにラップできます。
gRPCは、要求をサーバーに送信し、サーバーのプロトコルバッファー応答を返します。サーバーから応答が到着するまでブロックする同期RPC呼び出しは、RPCが目指しているプロシージャ呼び出しの抽象化に最も近いものです。
一方、ネットワークは本質的に非同期であり、多くのシナリオでは現在のスレッドをブロックせずにRPCを開始できるので便利です。ほとんどの言語のgRPCプログラミングAPIには、同期と非同期の両方のフレーバーがあります。

ライフサイクル

ライフサイクルについて説明させていただきます。
実装方法はそれぞれの言語に依存しますが、概要を理解していく必要があります。
一点目が最もシンプルなRPCのタイプです。このタイプではクライアントがスタブメソッドを呼び出すと、この呼び出しに対するクライアントのメタデータ、メソッド名、指定された期限を使用してRPCが呼び出されたことがサーバーに通知されます。その後、サーバーは独自の初期メタデータをすぐに送り返すか、クライアントの要求メッセージを待つことができます。
どちらが最初に発生するかは、アプリケーション固有となります。サーバーは、クライアントの要求メッセージを受け取ると、応答を作成して入力するために必要なすべての作業を行います。次に、応答がステータスの詳細 (ステータスコードとオプションのステータスメッセージ) およびオプションの末尾のメタデータと共にクライアントに返されます。
応答ステータスがOKの場合、クライアントは応答を受け取り、クライアント側で呼び出しを完了します。

二点目がサーバーストリーミングRPCです。サーバーストリーミングRPCはすでに説明したシンプルなRPCに似ていますが、サーバーがクライアントの要求に応答してメッセージのストリームを返す点が異なります。
すべてのメッセージを送信した後、サーバーのステータスの詳細 (ステータスコードとオプションのステータスメッセージ) とオプションの末尾のメタデータがクライアントに送信されます。
これでサーバー側の処理は完了です。サーバーのすべてのメッセージを受信すると、クライアントは完了します。

三点目がクライアントストリーミング RPCです。クライアントストリーミングは、クライアントが単一のメッセージではなくメッセージのストリームをサーバーに送信する点が異なります。サーバーは、単一のメッセージ (ステータスの詳細とオプションの後続メタデータを含む) で応答します。これは通常、クライアントのすべてのメッセージを受信した後であるとは限りません。

四点目が双方向ストリーミングRPCです。双方向ストリーミングRPCでは、メソッドを呼び出すクライアントと、クライアントのメタデータ、メソッド名、および期限を受信するサーバーによって呼び出しが開始されます。サーバーは、初期メタデータを送り返すか、クライアントがメッセージのストリーミングを開始するのを待つかを選択できます。クライアント側とサーバー側のストリーム処理はアプリケーション固有です。 2つのストリームは独立しているため、クライアントとサーバーは任意の順序でメッセージを読み書きできます。たとえば、サーバーはメッセージを書き込む前にクライアントのメッセージをすべて受信するまで待つことができます。または、サーバーとクライアントが応答を行うことができます。
つまり、サーバーが要求を受け取り、応答を返し、クライアントが送信します。応答に基づく別の要求などが可能となります。

タイムアウト

gRPCを使用すると、クライアントは、RPCがDEADLINE_EXCEEDEDエラーで終了する前に、RPCの完了を待機する時間を指定できます。
サーバー側では、特定のRPCがタイムアウトしたかどうか、またはRPCを完了するまでにどれくらいの時間が残っているかを確認するために、サーバーがクエリを実行できます。 期限またはタイムアウトの指定は言語固有です。一部の言語APIはタイムアウトに関して機能し、一部の言語APIは期限に関して機能し、デフォルトの期限がある場合とない場合があります。

RPC終了

gRPCでは、クライアントとサーバーの両方が呼び出しの成功について独立したローカルな判断を行い、その結論が一致しない場合があります。これは、たとえば、サーバー側では正常に終了しても、クライアント側では失敗するRPCを持つ可能性があることを意味します。クライアントがすべての要求を送信する前に、サーバーが完了を決定することもできます。

メタデータ

メタデータは、特定のRPC呼び出しに関する情報で、キーと値のペアのリスト形式です。キーは文字列で、値は通常は文字列ですが、バイナリデータの場合もあります。バイナリ値のキーは終了しますが-bin、ASCII値のキーは終了しません。メタデータはgRPC自体に対して不透明です。これにより、クライアントはサーバーへの呼び出しに関連する情報を提供でき、その逆も可能です。メタデータへのアクセスは言語に依存します。

まとめ

いかがでしたでしょうか？ gRPCについて説明させていただきますので、参考にしていただけましたら幸いです。