gRPCとは #Go

RPCとは

RPCはRemoteProcedureCallの略で、逐語的に訳すと「遠隔手続き呼び出し」となります。
すなわち、「あるプログラムがネットワーク上の異なる場所に配置されたプログラムを呼び出して実行すること」を指します。
あるサービスから別のサービスのアプリケーションの処理（サブルーチン/クラス/関数など）を呼び出すことができ、RPCを使うことで、違うアプリケーションのロジックを、あたかも自分のアプリケーションの中に実装されているかのように扱うことができます。
gRPC以外にも「JSON-RPC」や「SOAP」なども。

gRPC

Googleが2004年に作ったはGoogleの各マイクロサービス間のRPC、「Stubby」を起源とし、http/2などの規格登場に合わせて汎用的に作り直したオープンソースのプロダクト。

REST-APIと比べた時のgRPCの利点

HTTP/2による通信の高パフォーマンス

HTTP/2では通信時にデータがテキストではなくバイナリにシリアライズされて送られます。そのため、小さな容量で転送でき、ネットワーク内のリソースをより効率的に使用することができます。また、HTTP/2ではストリームを使い、ひとつのコネクションで複数のリクエスト/レスポンスをやり取りできます。つまり、リクエスト/レスポンスの度にデータを接続、切断を繰り返す必要がなく、その都度ヘッダーを送らなくて済むので、高速で効率的な通信が可能となります。特にマイクロサービスでは通信の回数が多くなり、応答速度の遅延がサービス全体のボトルネックになりがちなので、これを解決できます。

Protcol Buffersでのスキーマファーストの開発により生産性が高い

gRPCではProtocolBuffersのフォーマットにシリアライズ/でシリアライズしてリクエストレスポンスでデータをやり取りします。.protoファイルにスキーマを書いて、コンパイラを実行すると任意の言語のサーバー/クライアント用コードを自動生成してくれます。この.protoファイルを見ると、APIの仕様が分かるので、API側、クライアント側で担当が違うような状況でも開発ができて便利だし、間違いが起きにくいです。

柔軟なストリーミング方式

シンプルなRPC
- クライアントから送られたひとつのリクエストに対して、レスポンスを一度返すもっとも基本的な形式
サーバーストリーミングRPC
- クライアントから送られたリクエストに対して、レスポンスを複数回に分けて返します。時間のかかる処理について、非同期的にレスポンスを返すことができます。クライアントからのリクエスト後、クライアントは待機状態とし、サーバーの状態変更に応じて、情報を随時プッシュしていくこともできます。通知やタイムラインのリアルタイム更新などに有効。こういった場合仮にストリーミング機能使えない場合、クライアント側から定期的にポーリングで情報を引っ張らねばならず無駄な通信が発生してしまうのに比べ、サーバストリーミングPRCは、サーバから直接情報をプッシュできるのでネットワーク負荷を最小化できます。
クライアントストリーミングRPC
- クライアントからリクエストを分割して送り、サーバーは全てのリクエストを受け取る前に処理を逐次開始できる方式。
双方向ストリーミングRPC
- クライアントから初めのリクエストが送られた後、サーバー・クライアントどちらも任意のタイミングでリクエスト・レスポンスを送ることができます。チャットやゲームなどに有用です。RESTAPIではストリーミングが行えないので、WebSocketサーバーを別途立てる必要などがありました。gRPCの場合、単一のサーバーで双方向通信のAPIとしても使えます。

REST-APIと比べた時のgRPCの欠点

HTTP/2非対応である危険性

例えばAWSのALB（ApplicationLoadBalancer）はgRPCに対応していません15。フロントでHTTP/2のリクエストを受け付けることはできますが、バックエンドのサーバーへの転送をHTTP/1で行うためです。同様に通信経路上でHTTP/2に非対応なサービスがある場合に、gRPCを使う上で問題が生じる場合があります。

ブラウザの対応状況が不十分

gRPCWebなどはあるものの、Envoyなどを使ってProxyサーバーを立てる必要があったり、双方向あるいはクライアントストリーミングRPCに非対応であるなど、まだまだ十分な対応状況とはいえないようです18。フロントエンドのアプリケーションとの通信に使うには少し工夫が必要です。SPAとの通信にはRESTAPIの方が、JSONとの親和性の高さもあり良いかもしれません。

バイナリにシリアライズすると人間が読めない

JSONの場合は出力を人間が直接読めますが、gRPCの場合は専用のクライアントをインストールする必要があります。

RESTでも通信速度が十分な場合も

基本的にgRPCは　RESTよりもミニマムで高速な通信が可能ですが、RESTもそれなりに早く、ボトルネックが通信以外にある場合はそもそも通信速度の優位性は役に立ちません。