リフレクション

概要

リフレクションは、プロトコルであり、gRPCサーバーはこれを利用して、リクエストとレスポンスメッセージによって参照されるすべての型を含む、標準化されたRPCサービスを介してエクスポートするprotobufで定義されたAPIを宣言できます。クライアントは、この情報を使用して、人間が読み取れる方法でリクエストをエンコードし、レスポンスをデコードできます。

リフレクションは、grpcurlやPostmanなどのデバッグツールで広く使用されています。RESTの世界から来た人は、gRPCリフレクションAPIを、記述されているREST APIを提供するHTTPサーバーでOpenAPIドキュメントを提供することと比較できるかもしれません。

透明性と解釈可能性

gRPCの優れたパフォーマンスに大きく貢献しているのは、シリアライゼーションにProtobufを使用していることです。これはバイナリの、人間が読み取れないプロトコルです。これはRPCを大幅に高速化しますが、サーバーと手動でやり取りすることを難しくする可能性もあります。仮に、curlを使用してHTTP/2を介してサーバーにgRPCリクエストを手動で送信するには、

1. サーバーが公開したRPCサービスを知る必要があります。
2. リクエストメッセージとその参照するすべての型のprotobuf定義を知る必要があります。
3. レスポンスメッセージとその参照するすべての型のprotobuf定義を知る必要があります。

その後、その知識を使用してリクエストメッセージをバイナリに手作業で作成し、レスポンスメッセージを丹念にデコードする必要があります。これは時間がかかり、イライラしやすく、エラーが発生しやすいでしょう。代わりに、リフレクションプロトコルにより、ツールはこのプロセス全体を自動化できるため、目に見えなくなります。

gRPC サーバーでのリフレクションの有効化

リフレクションは、gRPCサーバーでは自動的に有効になりません。サーバーの作者は、リフレクションサービスを追加するために、いくつかの追加関数を呼び出す必要があります。これらのAPI呼び出しは言語によってわずかに異なり、一部の言語では、grpc-reflectionのような名前の別のパッケージへの依存関係を追加する必要があります。

詳細については、以下のリンクを参照してください。

ヒント

リフレクションはgrpcurlなどのツールと非常にシームレスに連携するため、多くの場合、ユーザーはそれが裏で動作していることに気づいていません。ただし、リフレクションが公開されていない場合、シームレスに動作しません。代わりに、クライアントは厄介なエラーで失敗します。gRPCサービスのルーティング構成を作成するときに、この問題に遭遇することがよくあります。リフレクションサービスは、アプリケーションのメインRPCサービスと同様に、適切なバックエンドにもルーティングする必要があります。

gRPC APIが一般ユーザーからアクセスできる場合、セキュリティ上の問題と見なされる可能性があるため、リフレクションサービスを公開しない方が良い場合があります。最終的には、セキュリティと使いやすさのバランスを考慮して決定する必要があります。