Apigee Extension Processor（バージョン 1.0）の一般提供（GA）についてお知らせします。この強力な新機能により、Apigee のリーチと柔軟性が大幅に広がり、さまざまなバックエンド サービスやモダン アプリケーション アーキテクチャをこれまで以上に簡単に管理したり保護したりできるようになります。
最新のデプロイメント モデルを採用しているデベロッパーのために、Extension Processor で Cloud Run とのシームレスな連携機能を提供します。これにより、コンテナ化したスケーラブルなアプリケーションに Apigee ポリシーを適用できるようになります。
また、Extension Processor を使うと、強力な新しい通信パターンを利用できます。gRPC 双方向ストリーミングによる高度なリアルタイム インタラクションを簡単に管理できるので、高度にインタラクティブな低レイテンシ アプリケーションを実現できます。さらに、イベント駆動アーキテクチャを利用する場合は、サーバー送信イベント（SSE）の管理と保護が可能になるので、クライアントへのデータ ストリーミングを簡単に効率化できます。
この機能の利点は、アプリケーションのデプロイと通信プロトコルにとどまりません。Apigee Extension Processor と Google トークン インジェクション ポリシーを組み合わせると、Google Cloud インフラストラクチャのアクセス保護が劇的に簡単になります。Apigee の一貫したセキュリティ フレームワークを維持しながら、Bigtable などの強力なデータサービスにシームレスに接続してアクセスを制御し、機械学習ワークロードに Vertex AI のインテリジェンスを活用することができます。
加えて、Extension Processor と Google の Cloud Load Balancing のインテリジェントなトラフィック管理機能を連携させれば、多様なトラフィック フローのルーティングと管理に比類のない柔軟性をもたらすことができます。この強力な組み合わせにより、どんなに複雑な API 環境でも管理できるようになるため、無数の可能性が開かれます。
このブログでは、現在の高パフォーマンス リアルタイム アプリケーション環境における重要な課題に対処できる強力なソリューション、すなわち Apigee の gRPC ストリーミング管理の概要を説明します。gRPC は効率的なマイクロサービスの基盤ですが、ストリーミングであるがゆえに、Google Cloud の Apigee をインライン プロキシ（従来モード）として利用する組織に課題をもたらします。以降で説明しますが、Apigee Extension Processor を使うと、gRPC ストリーミングのトラフィックがアプリケーション ロードバランサ（ALB）を通過する際に、Apigee のデータプレーンがトラフィックにポリシーを適用できます。これは、サービス拡張機能（トラフィック拡張機能）によって実現しており、Apigee ゲートウェイを直接通過させることなく、gRPC ストリームを効果的に管理およびルーティングできます。
ここでは、このソリューションの中核的な要素やその利点について詳しく説明するとともに、Cloud Run バックエンドに関わる実際のユースケースの概要をお伝えします。
Apigee Extension Processor は強力なトラフィック拡張機能（サービス拡張機能の一種）です。Cloud Load Balancing を活用し、API 管理の一環として Apigee を呼び出すことができます。これにより、ALB がユーザー管理バックエンド サービスにリクエストを転送する前に API 管理ポリシーを適用できます。つまり、Cloud Load Balancing を通過するワークロードでも、実質的に Apigee の確かな API 管理機能を利用できるようになります。
次の図は、Apigee Extension Processor 構成に必要なコンポーネントの概要を示しています。
Apigee Extension Processor の構成には、ALB、Extension Processor を有効にした Apigee インスタンス、サービス拡張機能など、いくつかの重要なコンポーネントが含まれています。これらのコンポーネントの詳細については、Apigee Extension Processor の概要をご覧ください。
以降のステップに付いている番号は、一連のイベントを示し、フロー図の矢印の番号に対応しています。
1: クライアントが ALB にリクエストを送信します。
2: この ALB がポリシー適用ポイント（PEP）となり、トラフィックを処理します。この処理の一環として、設定されたサービス拡張機能（トラフィック拡張機能）を通じて Apigee を呼び出します。
3: Apigee Extension Processor は、ポリシー決定ポイント（PDP）となってリクエストを受信し、対象となる API 管理ポリシーをリクエストに適用したうえで、処理済みのリクエストを ALB（PEP）に返します。
4: ALB は処理を完了し、リクエストをバックエンド サービスに転送します。
バックエンド サービスは応答を開始し、ALB がそれを受信します。応答にポリシーを適用することもできます。その場合、ALB はサービス拡張機能を通して再度 Apigee を呼び出してから、クライアントに転送します。
多くの最新のアプリケーションはストリーミング gRPC の機能が必要で、それを利用しています。ただし、インライン プロキシとして使われる Apigee は、現時点でストリーミングをサポートしていません。Apigee Extension Processor が非常に重要になるのはそのためです。具体的には、ALB が PEP（ポリシー適用ポイント）として振る舞い、ストリーミング gRPC トラフィックを処理します。一方の Apigee ランタイムは、PDP（ポリシー決定ポイント）として振る舞います。
Apigee Extension Processor を使って gRPC ストリーミング パススルーを実現するには、次の重要な要素が必要になります。詳しい構成手順については、Apigee Extension Processor を使ってみるをご覧ください。
リアルタイム アプリケーション ログの提供など、gRPC ストリーミング機能に対応した高パフォーマンス バックエンド サービスをお客様が開発するシナリオを考えてみましょう。スケーラビリティを実現し、管理を簡単にするために、このバックエンド アプリケーションはプライマリの Google Cloud プロジェクトの Google Cloud Run にデプロイしています。現在、お客様は、この gRPC ストリーミング サービスを、適切に管理された安全な API ゲートウェイを通じてクライアントに公開したいと考えています。この目的のために Apigee を選択し、認証、認可、レート制限などのポリシーを含む堅牢な API 管理機能を活用しています。
前述のように、Apigee をインライン プロキシモードで使う場合、gRPC ストリーミングはネイティブにサポートされません。そのため、標準の Apigee 構成を通じて Cloud Run gRPC サービスを直接公開しても、クライアント、サーバー、双方向ストリーミングといったストリーミングのユースケースはサポートされません。
Apigee Extension Processor が必要なブリッジを提供してくれるので、同じ Google Cloud プロジェクトの Cloud Run にデプロイされたバックエンド アプリケーション宛ての gRPC ストリーミング トラフィックを管理できます。
簡単な手順は次のとおりです。
注: このシナリオの Apigee プロキシは、ターゲットのないプロキシです。つまり、ターゲット エンドポイントが設定されていません。最終的なルーティングは ALB に依存します。
応答処理は、リクエスト フローと同様のパターンで行います。バックエンドが応答を開始すると、ALB がそれを処理します。ALB は、サービス拡張機能（トラフィック拡張機能）を通じて Apigee を呼び出し、ポリシーを適用してから、応答をクライアントに転送することもできます。
このシンプルなユースケースでは、Apigee Extension Processor を使って、同じ Google Cloud プロジェクト内の Cloud Run にデプロイされたアプリケーション宛ての gRPC ストリーミング トラフィックに API 管理ポリシーを適用する方法を示しています。ALB は、主に NEG 構成に基づき、Cloud Run サービスへのルーティングを処理します。
Apigee Extension Processor を使ってバックエンドの gRPC ストリーミング サービスを管理することで、いくつかの重要な利点を得ることができます。それにより、プラットフォームで Apigee の中核的な強みを次のような新たな応用例に活用できます。
gRPC ストリーミングは、Apigee プラットフォームのコアプロキシでネイティブにサポートされていないストリーミング通信パターンですが、このアプローチによって、Apigee の堅牢な API 管理機能を利用できるようになります。
すでに RESTful API に Apigee を活用している組織がこのソリューションを使うと、gRPC ストリーミング サービスを Apigee 内で管理できるようになります。Extension Processor を使う必要はありますが、使い慣れた API 管理の考え方を活用できるので、別のツールを使う必要性が減少します。
Apigee は、API 管理ポリシーを一元的に定義して適用するためのプラットフォームです。Extension Processor を通して gRPC ストリーミングを扱えるようにすることで、すべての API エンドポイントで一貫したガバナンスとセキュリティを維持できます。
gRPC ストリーミング サービスをプロダクトとして公開する場合、Apigee の収益化機能を活用できます。Apigee で作成したカスタム API プロダクトに料金プランを追加すれば、gRPC ストリーミング API が使われるたびに収益を上げることができます。
パススルー シナリオでは、詳細な gRPC プロトコルレベルの分析が制限される場合があります。しかし Apigee なら、接続試行、エラー率、全体的な使用パターンなど、ストリーミング サービスのトラフィックに関する貴重な知見を提供できます。このオブザーバビリティは、モニタリングやトラブルシューティングに不可欠です。
Apigee の分散トレース システムは、gRPC ストリーミング サービスを含む分散システムのリクエストを追跡する際に役立ち、複数のアプリケーション、サービス、データベースにわたってエンドツーエンドの可視性を提供します。
Apigee API Analytics は、ロードバランサを通過する豊富な情報を収集し、UI でデータを視覚化したり、データをダウンロードしてオフライン分析したりする機能を提供します。このデータは、使用パターンの理解、パフォーマンスのボトルネックの特定、情報に基づくビジネスの意思決定に非常に役立ちます。
Apigee Extension Processor は、Google Cloud の gRPC ストリーミング サービスに欠かせない API 管理を実現します。以上の利点を考慮すれば、これが有用で実用的な方法であることは明らかです。
Apigee Extension Processor は、Apigee の機能を拡張する上で重要な前進となります。私たちが思い描くのは、どんなゲートウェイでも Apigee のポリシー適用機能を活用できる未来です。これは、ext-proc プロトコルを利用し、さまざまな Envoy ベースのロードバランサやゲートウェイと連携することで実現します。それにより、ロードバランサやゲートウェイがポリシー適用ポイント（PEP）として、Apigee ランタイムがポリシー決定ポイント（PDP）として振る舞えるようになります。この進化によって、ますます分散化が進む異機種混在環境でも、デジタル アセットを一貫して管理し、保護することができます。
