このドキュメントでは、検索拡張生成（RAG）対応のアプリケーションのネットワーク インフラストラクチャの保護に役立つリファレンス アーキテクチャについて説明します。通常、RAG アーキテクチャには、データ処理とコンテンツ取得のフローを処理する個別のサブシステムが含まれています。このリファレンス アーキテクチャは、共有 VPC を使用して次の操作を行う方法を示しています。
- Identity and Access Management（IAM）の権限を使用して、サブシステム間の分離を作成します。
- プライベート IP アドレスを使用してアプリケーション コンポーネントを接続します。
このドキュメントは、アーキテクト、デベロッパー、ネットワーキング管理者、セキュリティ管理者を対象としています。このドキュメントは、ネットワーキングに関する基本的な知識があることを前提としています。このドキュメントでは、RAG ベースのアプリケーションの作成については説明しません。
アーキテクチャ
次の図は、このドキュメントで説明するネットワーキング アーキテクチャを示しています。
上記の図のアーキテクチャには、次のコンポーネントが示されています。
| コンポーネント | 目的 |
|---|---|
| 外部ネットワーク（オンプレミスまたは別のクラウド） |
|
| ルーティング プロジェクト |
|
| RAG 共有 VPC ホスト プロジェクト | フロントエンド サービス ロードバランサと、VPC ネットワークを必要とするその他のサービスをホストする共有 VPC ネットワークをホストします。すべてのサービス プロジェクトがその共有 VPC ネットワークにアクセスできます。 |
| データ取り込みサービス プロジェクト |
元データの入力用の Cloud Storage バケットが含まれています。データ取り込みサブシステムが含まれます。これには次のコンポーネントが含まれます。
|
| サービング サービス プロジェクト |
サービング サブシステムが含まれています。これには、推論とインタラクションのサービスと機能を提供する次のコンポーネントが含まれています。
|
| フロントエンド サービス プロジェクト |
Cloud Run または Google Kubernetes Engine（GKE）で実行されるユーザー インタラクション サービスの前に配置されたロードバランサであるサービング サブシステムが含まれています。 このプロジェクトには Google Cloud Armor も含まれており、サービスへのアクセスを制限するのに役立ちます。インターネットからアクセスできるようにする場合は、リージョン外部アプリケーション ロードバランサを追加できます。 |
| VPC Service Controls の境界 | データの引き出しから保護します。Cloud Storage バケットに保存されているデータは、境界外にコピーできません。また、コントロール プレーン オペレーションは保護されます。 |
以降のセクションでは、アーキテクチャ内の接続とトラフィック フローについて説明します。
コンポーネント間の接続
このセクションでは、このアーキテクチャのコンポーネントとネットワーク間の接続について説明します。
外部ネットワークからルーティング VPC ネットワーク
外部ネットワークは、Cloud Interconnect または HA VPN を介して Google Cloud ルーティング VPC ネットワークに接続します。これらは、Network Connectivity Center ハブのハイブリッド スポークです。
ルーティング VPC ネットワーク内の Cloud Router と外部ネットワーク内の外部ルーターは、Border Gateway Protocol（BGP）ルートを交換します。
- 外部ネットワーク内のルーターは、外部サブネットのルートをルーティング VPC Cloud Router に通知します。ルートの優先度は、BGP 指標と属性を使用して表現できます。
- ルーティング VPC ネットワーク内の Cloud Router は、 Google Cloudの VPC 内のプレフィックスのルートを外部ネットワークにアドバタイズします。
VPC ネットワークから共有 VPC ネットワークへのルーティング
Network Connectivity Center ハブの Network Connectivity Center VPC スポークを使用して、ルーティング VPC ネットワークと RAG VPC ネットワークを接続します。ハブは、外部ネットワークへのハイブリッド スポークもホストします。
共有 VPC ネットワーク内のリソース間
この設計では、Cloud Storage バケットが外部ネットワークからデータを受信します。推論リクエストは、リージョン内部アプリケーション ロードバランサを通過します。システムの残りの部分については、次のオプションがあります。
- Cloud Storage バケット、Vertex AI、Cloud Run、Pub/Sub など、Google SaaS インフラストラクチャにすべてをホストします。この場合、コンポーネントは限定公開の Google インフラストラクチャを介して通信します。
- Compute Engine VM、GKE クラスタ、Cloud SQL データベース、または VPC ネットワークで実行されるその他のコンポーネントで実行されるワークロードにすべてをホストします。この場合、システムは、Network Connectivity Center または VPC ネットワーク ピアリングを介してリンクするネットワーク間でプライベート IP アドレスを使用して通信します。
- フルマネージド サービス、プラットフォーム サービス、インフラストラクチャ サービスを組み合わせて使用します。この場合、次の方法で VPC ネットワークとフルマネージド サービス間の接続を確立できます。
- 限定公開の Google アクセス: この方法では、外部 IP アドレスを持たず、VPC ネットワークで実行されているワークロードが Google API にアクセスできます。このアクセスは Google インフラストラクチャを介して内部的に行われ、このプロセスでは、このようなトラフィックがインターネットに公開されることはありません。
- Private Service Connect: この方法では、マネージド VPC ネットワークでホストされている AlloyDB for PostgreSQL などのサービス用に、サービス プロジェクトにエンドポイントを作成できます。
外部ネットワークからフロントエンド サービス ロードバランサへ
リージョン内部アプリケーション ロードバランサのエンドポイントは、RAG ネットワーク内の IP アドレスです。RAG ネットワーク、ルーティング ネットワーク、外部ネットワークへのハイブリッド接続はすべて、同じ Network Connectivity Center ハブのスポークです。したがって、Network Connectivity Center にすべてのスポーク サブレンジをハブにエクスポートするように指示できます。ハブは、これらのサブレンジを他のスポーク ネットワークに再エクスポートします。これにより、システムのエンドユーザーは外部ネットワークからロード バランシングされたサービスにアクセスできます。
トラフィック フロー
このリファレンス アーキテクチャのトラフィック フローには、RAG データフローと推論フローが含まれます。
RAG の人口フロー
このフローでは、データ エンジニアからベクトル ストレージまで、RAG データがシステムをどのように流れるかについて説明します。
- 外部ネットワークから、データ エンジニアは Cloud Interconnect 接続または Cloud VPN 接続を介して生データをアップロードします。データは、ルーティング VPC ネットワークの Private Service Connect エンドポイントにアップロードされます。
- データは Google の内部インフラストラクチャを介して、データ取り込みサービス プロジェクトの Cloud Storage バケットに転送されます。
データ取り込みサービス プロジェクト内では、次のいずれかの方法でシステム間でデータが移動します。
- 限定公開の Google アクセス
- Private Service Connect エンドポイント
- Google のインフラストラクチャを直接使用する
この方法は、システムがGoogle Cloud VPC ネットワークでホストされているか、Google Cloudで直接ホストされているかによって異なります。このフローの一環として、データ取り込みサブシステムはチャンク化された RAG データをモデルにフィードし、モデルは各チャンクのベクトルを生成します。
データ取り込みサブシステムは、ベクトルデータとチャンク化されたデータを適切なデータストアに書き込みます。
推論フロー
このフローは、お客様からのリクエストについて説明しています。
- 外部ネットワークから、顧客がサービスの IP アドレスにリクエストを送信します。
- リクエストは、Cloud Interconnect 接続または Cloud VPN 接続を介してルーティング VPC ネットワークに転送されます。
- リクエストは、VPC スポーク接続を介して RAG VPC ネットワークに転送されます。
- お客様のリクエストはロードバランサに届き、ロードバランサはリクエストをフロントエンド サブシステムに渡します。
- フロントエンド サブシステムは、リクエストをサービング サブシステムに転送します。
- サービング サブシステムは、データストアから関連するコンテキスト データを使用してリクエストを拡張します。
- サービング サブシステムは、拡張プロンプトを AI モデルに送信します。AI モデルはレスポンスを生成します。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
- 共有 VPC: Virtual Private Cloud の機能。このネットワークの内部 IP アドレスを使用して、複数のプロジェクトのリソースを共通の VPC ネットワークに接続できます。
- Private Service Connect: コンシューマーが VPC ネットワーク内からマネージド サービスにプライベート接続でアクセスできるようにする機能。
- 限定公開の Google アクセス: 外部 IP アドレスを持たない VM インスタンスが Google API とサービスの外部 IP アドレスにアクセスできるようにする機能。
- Cloud Interconnect: 高可用性で低レイテンシの接続を通じて、外部ネットワークを Google ネットワークに拡張するサービス。
- Cloud VPN: IPsec VPN トンネルを介してピア ネットワークを Google のネットワークに安全に拡張するサービス。
- Cloud Router: Border Gateway Protocol（BGP）のスピーカー機能とレスポンダー機能を提供する、分散型のフルマネージド サービスです。Cloud Router は、Cloud Interconnect、Cloud VPN、Router アプライアンスと連携して、BGP で受信したルートやカスタム学習ルートに基づいて VPC ネットワークに動的ルートを作成します。
- Network Connectivity Center: ハブと呼ばれる一元管理リソースに接続されているスポーク リソース間のネットワーク接続を簡素化するオーケストレーション フレームワーク。
- VPC Service Controls: Google Cloud リソースのデータ引き出しのリスクを最小限に抑えるマネージド ネットワーキング機能。
- Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
- Model Armor: プロンプト インジェクション、センシティブ データの漏洩、有害なコンテンツから生成 AI とエージェント AI のリソースを保護するサービス。
- Google Cloud Armor: ウェブ アプリケーション ファイアウォール（WAF）ルールを提供し、DDoS 攻撃やアプリケーション攻撃から保護するネットワーク セキュリティ サービス。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
ユースケース
このアーキテクチャは、システム全体の入力、出力、内部通信でプライベート IP アドレスを使用し、インターネットを通過しないようにする必要があるエンタープライズ シナリオ向けに設計されています。
- 非公開入力: アップロードされたデータはインターネット経由で送信されません。代わりに、Cloud Storage バケットを Google Cloudルーティング VPC ネットワークの Private Service Connect エンドポイントの背後にホストします。プライベート IP アドレスのみを使用して、Cloud Interconnect または Cloud VPN 接続経由で RAG データをコピーします。
- プライベート サービス間接続: サービスは、Google の内部インターフェースまたは VPC ネットワークの内部にあるプライベート アドレスを介して相互に通信します。
- プライベート出力: そのアクセスを設定しない限り、推論結果はインターネット経由でアクセスできません。デフォルトでは、指定された外部ネットワーク内のユーザーのみがサービスのプライベート エンドポイントにアクセスできます。
代替案を設計する
このセクションでは、 Google Cloudの RAG 対応アプリケーションで検討できる代替のネットワーク設計アプローチについて説明します。
サービスを一般公開する
このドキュメントに示すアーキテクチャでは、内部ネットワークのユーザーのみがアプリケーションにクエリを送信できます。アプリケーションがインターネット上のクライアントからアクセスできるようにする必要がある場合は、リージョン外部アプリケーション ロードバランサを使用します。
GKE Inference Gateway を使用する
フロントエンド サブシステムが GKE で実行されている場合は、アプリケーション ロードバランサの代わりに Inference Gateway を使用できます。
設計上の考慮事項
このセクションでは、RAG 対応アーキテクチャのプライベート接続をサポートするネットワーキングをデプロイする際に役立つ追加のガイダンスを提供します。このガイダンスは、セキュリティとコンプライアンス、信頼性、費用、パフォーマンスに関する特定の要件を満たすのに役立ちます。このセクションのガイダンスはすべてを網羅しているわけではありません。特定のデプロイでは、このセクションで説明されていない追加の設計要素を考慮する必要がある場合があります。
セキュリティ、プライバシー、コンプライアンス
ほとんどの場合、AI モデルの前に Model Armor をデプロイして、インバウンド プロンプトとアウトバウンド結果の両方を評価します。Model Armor は、潜在的なリスクを防ぎ、責任ある AI の実践を確保するのに役立ちます。
不適切なリクエストがサービング サブシステムに到達する前に拒否するには、Model Armor をロードバランサに接続します。
このアーキテクチャでは、不正なデータ漏洩を防ぐ VPC Service Controls を使用します。
この設計では、確立されたセキュリティ原則を使用して、RAG ワークロードの保護に役立てます。AI ワークロードと ML ワークロードに固有のセキュリティの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: セキュリティをご覧ください。
費用の最適化
AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。
パフォーマンスの最適化
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。
デプロイ
このセクションでは、アプリケーションを作成する手順について説明します。
- ワークロードのリージョンを特定します。
- Google Cloud プロジェクトと VPC ネットワークを作成する。
- 外部ネットワークをルーティング VPC ネットワークに接続します。
- Network Connectivity Center を使用してネットワークをリンクする。
- RAG デプロイのコンポーネントを特定してサービス アカウントを作成する。
- VPC Service Controls を構成する。
- データ取り込みサブシステムを構築する。
- サービング サブシステムを構築する。
- フロントエンド サブシステムをビルドします。
- アプリケーションをインターネットからアクセスできるようにする。
ワークロードのリージョンを特定する
一般に、接続、VPC サブネット、ワークロードは、オンプレミス ネットワークまたは他のクラウド クライアントの近くに配置します。 Google Cloudワークロードのリージョンを選択する方法の詳細については、Google Cloud リージョン選択ツールと Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
Google Cloud プロジェクトと VPC ネットワークを作成する
組織で分散アプリケーション用の Cross-Cloud Network がすでに設定されている場合、ルーティング プロジェクトとルーティング VPC ネットワークはすでに存在しているはずです。
次の順序で Google Cloud プロジェクトと VPC ネットワークを作成します。
- ルーティング プロジェクトを作成します。
- 限定公開の Google アクセスが有効になっているルーティング VPC ネットワークを作成します。
- RAG プロジェクトを作成します。
- RAG プロジェクトを共有 VPC ホスト プロジェクトに昇格させます。
- データ取り込みサービス プロジェクトを作成します。
- サービング サービス プロジェクトを作成します。
- フロントエンド サービス プロジェクトを作成します。
- プライベート Google アクセスが有効になっている共有 VPC RAG ネットワークを作成します。
- RAG ネットワークを使用する権限をサービス プロジェクトに付与します。
外部ネットワークをルーティング VPC ネットワークに接続する
分散型アプリケーション向けの Cross-Cloud Network をすでに設定している場合は、この手順をスキップできます。
外部ネットワークとルーティング ネットワーク間の接続を設定します。関連するテクノロジーについては、外部接続とハイブリッド接続をご覧ください。接続プロダクトの選択方法については、ネットワーク接続プロダクトの選択をご覧ください。
Network Connectivity Center を使用してネットワークをリンクする
- ルーティング プロジェクトで、Network Connectivity Center ハブを作成します。
- Cloud Interconnect 接続を VLAN アタッチメント スポークとして追加するか、Cloud VPN 接続を VPN スポークとして追加します。
- RAG VPC ネットワークとルーティング VPC ネットワークを VPC スポークとしてハブに追加します。
RAG デプロイのコンポーネントを特定してサービス アカウントを作成する
- RAG デプロイを選択し、必要なコンポーネントのリストを作成します。
- 各コンポーネントに必要なアクセス権を特定します。
- コンポーネントごとに、適切な権限を持つサービス アカウントを作成します。場合によっては、コンポーネントに別のサービス プロジェクトからの読み取りまたは書き込みの権限を付与することになります。
この設計では、Cloud Storage バケットをデータ入力コンポーネントとして使用し、推論フロントエンドでロードバランサを使用することを前提としています。残りの設計は必要に応じて変更できます。
理想的には、各コンポーネントは独自のサービス アカウントとして実行されます。各コンポーネントに、必要な機能を実行するために必要な最小限の IAM 権限のみが付与されていることを確認します。たとえば、データ取り込みサブシステムの Cloud Run ジョブは、入力 Cloud Storage バケットから読み取る必要がありますが、バケットに書き込む必要はありません。この例では、Cloud Run ジョブを実行するサービス プロジェクトには、バケットからの読み取りのみを行う権限が必要です。書き込み権限は必要ありません。
VPC Service Controls を構成する
- デプロイの周囲に VPC Service Controls の境界を作成します。
- アクセスルールを構成する。
データ取り込みサブシステムを構築する
データ取り込みサブシステムは、データ エンジニアから未加工のデータを取得し、サービング サブシステムで使用できるように処理します。
- データ取り込みサービス プロジェクトで、Cloud Storage バケットを作成します。
- ルーティング VPC ネットワークで、リージョン Private Service Connect エンドポイントを作成し、エンドポイントをバケットに接続します。
- 外部ネットワークで、前の手順で生成された IP アドレスと URL を使用して、エンドポイントの DNS エントリを追加します。
- エンドポイントの IP アドレスへのアクセスを許可するように、外部ネットワークのファイアウォール ルールを更新します。
- データ取り込みサービス プロジェクトで、選択した RAG アーキテクチャに従って取り込みパイプラインの残りの部分を構築します。
- 取り込みパイプライン内の関連リソースがベクトルを生成するモデルにアクセスできるように、IAM 権限を付与します。
- 取り込みパイプライン内の関連リソースがベクトル データストアに書き込めるように、IAM 権限を付与します。
サービング サブシステムをビルドする
- サービング サービス プロジェクトで、サービング パイプラインを構築します。
- フロントエンド システムのサービス アカウントがサービング サブシステムの出力にアクセスできるように、IAM 権限を付与します。
フロントエンド サブシステムをビルドする
このセクションでは、Cloud Run の前にサーバーレス NEG を使用するリージョン内部アプリケーション ロードバランサを使用することを前提としています。ただし、別のロードバランサとバックエンドを使用することはできます。
- フロントエンド システムのコードを作成します。
- フロントエンド サービス プロジェクトで、ロードバランスされたフロントエンド システムをデプロイします。これには、Cloud Armor セキュリティ ポリシーを構成するオプションの手順が含まれます。
- ルーティング VPC ネットワークで Cloud Router を構成して、RAG VPC ネットワークからオンプレミス ルーターにルートを転送します。この構成により、クライアントはロードバランサにアクセスできます。
- 外部ネットワークで、ロードバランサのフロントエンドが外部ネットワークから到達できるようにファイアウォール ルールを構成します。
- 外部ネットワークで、ロードバランサの転送ルールを指すように DNS を更新します。
アプリケーションをインターネットからアクセスできるようにする
このセクションは省略可能です。
この設計では、サービスが外部ネットワークからのみアクセス可能であることを前提としていますが、インターネットからサービスにアクセスできるようにすることもできます。
インターネットからサービスにアクセスできるようにする手順は次のとおりです。
- 内部ロードバランサが指すバックエンドと同じバックエンドを指すリージョン外部アプリケーション ロードバランサを作成します。省略可能な手順を完了して、Cloud Armor セキュリティ ポリシーを構成します。
- サービスのお客様がバックエンド サービスにアクセスできるように、VPC Service Controls を更新します。
次のステップ
- 分散型アプリケーション向けのクロスクラウド ネットワークについて学習する。
- Cloud Run で AI アプリとエージェントをホストする方法を学習する。
- 責任ある AI のベスト プラクティスと Vertex AI の安全フィルタについて学習する。
- 大規模言語モデル（LLM）のベスト プラクティスについて学習する。
- Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要について、Well-Architected Framework の AI と ML の視点を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
その他の寄稿者:
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Samantha He | テクニカル ライター
- Ammett Williams | デベロッパー リレーションズ エンジニア
- Aspen Sherrill | クラウド セキュリティ アーキテクト