インターセプター
インターセプターを使用して、多くのRPCメソッドに適用される汎用的な動作を実装する方法について説明します。
インターセプター
概要
gRPCサービスを作成する中核はRPCメソッドの実装です。しかし、実行されるメソッドとは無関係であり、すべてのRPCまたはほとんどのRPCに適用すべき機能も存在します。インターセプターは、このタスクに適しています。
インターセプターを使用するタイミング
インターセプターという概念は、すでに知っているかもしれませんが、「フィルター」や「ミドルウェア」と呼んでいたかもしれません。インターセプターは、単一のRPCメソッドに固有ではないロジックを実装するのに非常に適しています。また、異なるクライアントまたはサーバー間で簡単に共有できます。インターセプターは、gRPCを拡張するための重要で頻繁に使用される方法です。gRPCエコシステム全体で、すでにインターセプターとして利用可能な機能が見つかるかもしれません。
インターセプターのユースケースの例をいくつか示します。
- メタデータの処理
- ロギング
- フォールトインジェクション
- キャッシング
- メトリクス
- ポリシー施行
- サーバーサイド認証
- サーバーサイド認可
注記
クライアントサイド認証はインターセプターで行うことも可能ですが、gRPCはより適した「コールクレデンシャル」APIを提供しています。クライアントサイド認証の詳細については、認証ガイドを参照してください。インターセプターの使用方法
インターセプターは、gRPCチャネルまたはサーバーを構築する際に追加できます。追加されたインターセプターは、そのチャネルまたはサーバー上のすべてのRPCに対して呼び出されます。インターセプターAPIはクライアントサイドとサーバーサイドで異なるため、インターセプターは「クライアントインターセプター」または「サーバーインターセプター」のいずれかになります。
インターセプターは本質的にコールごとであり、TCP接続の管理、TCPポートの設定、TLSの設定には有用ではありません。ほとんどのカスタマイズに適したツールですが、すべてに使用できるわけではありません。
インターセプターの順序
複数のインターセプターを使用する場合、それらの順序は重要です。gRPC実装でそれらが実行される順序を理解することが重要です。インターセプターをアプリケーションとネットワークの間に並んだ線のように考えると便利です。一部のインターセプターは「ネットワークに近い」位置にあり、送信されるものに対してより多くの制御を持ち、他のインターセプターは「アプリケーションに近い」位置にあり、アプリケーションの動作をよりよく把握できます。
2つのクライアントインターセプター(キャッシングインターセプターとロギングインターセプター)があると仮定します。それらはどのような順序で配置すべきでしょうか?アプリケーションの通信をよりよく監視し、キャッシュされたRPCを無視するために、ロギングインターセプターをネットワークに近い位置に配置したいかもしれません。
flowchart LR
APP(Application) --> INT1
INT1(Caching\nInterceptor) -->|Cache miss| INT2
INT2(Logging\nInterceptor) --> NET
NET(Network)
あるいは、アプリケーションの動作を理解し、ロードされている情報を確認するために、アプリケーションに近い位置に配置したいかもしれません。
flowchart LR
APP(Application) --> INT2
INT1(Caching\nInterceptor) -->|Cache miss| NET
INT2(Logging\nInterceptor) --> INT1
NET(Network)
インターセプターの順序を変更するだけで、これらのオプションを選択できます。
言語サポート
| 言語 | 例 |
|---|---|
| C++ | C++の例 |
| Go | Goの例 |
| Java | Javaの例 |
| Python | Pythonの例 |