gRPC とは？高性能 RPC の解説

gRPC は、HTTP/2 とバイナリの protocol buffers を使い、サービス同士がローカル関数のように呼び出し合えるようにする、高性能な remote procedure call フレームワークです。

REST や GraphQL が HTTP 上の人間が読める JSON を好むのに対し、gRPC は速度と厳格な契約を好みます。サービスとメッセージを .proto ファイルで定義し、クライアントとサーバーのコードを生成すると、呼び出しはコンパクトなバイナリフレームとして HTTP/2 上を移動します。これは、パイプラインが build およびデプロイする内部の microservice トラフィックでよく見られます。

protocol buffers による契約

.proto ファイルは、サービスのメソッドとメッセージの形状を宣言します。tooling が多くの言語で強く型付けされたクライアントとサーバーを生成するため、契約は慣習ではなくコンパイル時に強制されます。

HTTP/2 上に構築

gRPC は HTTP/2 上を通り、多くの呼び出しを 1 つの接続で多重化し、streaming をサポートします。これにより、リクエストごとに接続を開く場合と比べて、頻繁なサービス間トラフィックのレイテンシが低減します。

streaming モード

Unary：1 リクエスト、1 レスポンス。
Server streaming：1 リクエスト、多数のレスポンス。
Client streaming：多数のリクエスト、1 レスポンス。
双方向 streaming：両側がストリーミングします。

status code、ただし独自のセット

gRPC は、HTTP コードとは別の、OK、UNAVAILABLE、DEADLINE_EXCEEDED などの独自の status code を持ちます。UNAVAILABLE は通常、リトライする価値のある一時的な問題を示し、INVALID_ARGUMENT は恒久的なクライアントエラーです。

CI/CD における gRPC

パイプラインは .proto ファイルをコンパイルし、契約チェックを実行し、内部で gRPC を話すサービスをデプロイします。メッセージの形状を互換性のない形で変更するデプロイは caller を壊す可能性があり、そのため proto の契約テストが CI で実行されます。

一時的な gRPC 障害

一瞬のネットワーク切断は UNAVAILABLE または deadline exceeded として現れ、どちらも一般にリトライ可能です。Latchkey の runner では、サービス呼び出し中の一時的なトランスポート障害は自動的にリトライされ、恒久的な引数や認証のエラーは本物の失敗として表面化されます。

重要なポイント

gRPC は、契約を protocol buffers で定義する、HTTP/2 上のバイナリ RPC フレームワークです。
独自の status code を持ち、UNAVAILABLE は通常リトライ可能です。
互換性のないメッセージ変更は caller を壊すため、CI は proto の契約チェックを実行します。