RAG 対応生成 AI アプリケーションのプライベート接続

Last reviewed 2026-11-03 UTC

このドキュメントでは、検索拡張生成(RAG)対応のアプリケーションのネットワーク インフラストラクチャを保護する際に役立つリファレンス アーキテクチャについて説明します。RAG アーキテクチャには通常、データ処理フローとコンテンツ取得フローを処理する個別のサブシステムが含まれています。このリファレンス アーキテクチャでは、共有 VPC を使用して次のことを行う方法について説明します。

  • Identity and Access Management(IAM)権限を使用して、サブシステムを分離します。
  • プライベート IP アドレスを使用してアプリケーション コンポーネントを接続する。

このドキュメントは、アーキテクト、デベロッパー、ネットワーク管理者、セキュリティ管理者を対象としています。このドキュメントは、ネットワーキングに関する基本的な知識があることを前提としています。このドキュメントでは、RAG ベースのアプリケーションの作成については説明しません。

アーキテクチャ

次の図は、このドキュメントで説明するネットワーキング アーキテクチャを示しています。

RAG を使用するアプリケーションのネットワーキング アーキテクチャ。

ネットワーク アーキテクチャの接続とトラフィック フロー。

上記の図のアーキテクチャには、次のコンポーネントが含まれています。

外部ネットワーク(オンプレミスまたは別のクラウド)

次の機能を実行する外部ネットワーク。

  • 未加工の RAG データをアップロードするデータ エンジニアにネットワーク接続を提供します。
  • 外部ネットワーク接続を終端します。
  • 外部ルーターをホストします。
  • Google Cloud ルーティング Virtual Private Cloud(VPC)ネットワークの Private Service Connect エンドポイントへの接続を提供します。
  • Private Service Connect エンドポイントを指す DNS サーバーが含まれています。
ルーティング プロジェクト

次の機能を実行する Google Cloud プロジェクト。

  • ルーティング VPC ネットワークをホストします。このネットワークは、Cloud Interconnect または Cloud VPN 接続を介して外部ネットワークに接続します。
  • 外部ネットワーク、ルーティング VPC ネットワーク、共有 VPC ネットワークを接続する Network Connectivity Center(NCC)ハブをホストします。
  • リージョン Cloud Storage エンドポイントに接続する Private Service Connect エンドポイントをホストします。このエンドポイントを使用すると、データ エンジニアは RAG データを Cloud Storage バケットにアップロードできます。
RAG 共有 VPC ホスト プロジェクト

フロントエンド サービスの内部アプリケーション ロードバランサと、VPC ネットワークを必要とするその他のサービスをホストする共有 VPC ネットワークをホストします。すべてのサービス プロジェクトがその共有 VPC ネットワークにアクセスできます。

データの取り込みサービス プロジェクト

元データの入力用の Cloud Storage バケットが含まれています。データ取り込みサブシステムが含まれています。これには次のコンポーネントが含まれます。

  • 取り込み処理: 元データを読み取り、処理します。
  • 取り込み出力: 最終的なデータストアに書き込みます。
サービス提供プロジェクト

サービング サブシステムが含まれています。これには、推論とインタラクションのサービスと機能を提供する次のコンポーネントが含まれています。

  • データの取り込みサブシステムの出力を含む RAG データストア。
  • 推論クエリと RAG データストアのデータを組み合わせてモデルにフィードするサービング プロセス。
  • サービング サブシステムが、アップロードされた RAG データからベクトルを作成し、エンドユーザーのリクエストを処理するために使用するモデル。
フロントエンド サービス プロジェクト

フロントエンド サブシステムが含まれています。これは、Cloud Run または Google Kubernetes Engine(GKE)で実行されるユーザー インタラクション サービスの前に配置されたアプリケーション ロードバランサです。

このプロジェクトには、サービスへのアクセス方法を制限する Google Cloud Armor も含まれています。インターネットからのアクセスを可能にする場合は、リージョン外部アプリケーション ロードバランサを追加します。

VPC Service Controls の境界

データの引き出しから保護します。Cloud Storage バケットに保存されているデータは、境界外のどこにもコピーできません。また、コントロール プレーン オペレーションは保護されます。

以降のセクションでは、アーキテクチャ内の接続とトラフィック フローについて説明します。

コンポーネント間の接続

このセクションでは、このアーキテクチャのコンポーネントとネットワーク間の接続について説明します。

外部ネットワークからルーティング VPC ネットワーク

外部ネットワークは、NCC ハブのハイブリッド スポークである Cloud Interconnect または Cloud VPN を介して Google Cloud ルーティング VPC ネットワークに接続します。

ルーティング VPC ネットワークの Cloud Router と外部ネットワークの外部ルーターは、Border Gateway Protocol(BGP)ルートを交換します。

  • 外部ネットワークのルーターは、外部サブネットのルートをルーティング VPC の Cloud Router に通知します。ルートの優先度は、BGP の指標と属性を使用して表現できます。
  • ルーティング VPC ネットワーク内の Cloud Router は、 Google Cloudの VPC 内のプレフィックスのルートを外部ネットワークにアドバタイズします。

ルーティング VPC ネットワークから共有 VPC ネットワーク

ルーティング VPC ネットワークと RAG VPC ネットワークを、NCC ハブの NCC VPC スポークを使用して接続します。ハブは、外部ネットワークへのハイブリッド スポークもホストします。

共有 VPC ネットワーク内のリソース間

この設計では、Cloud Storage バケットが外部ネットワークからデータを受信します。推論リクエストは、リージョン内部アプリケーション ロードバランサを介して送信されます。システムの残りの部分については、次のオプションがあります。

  • Cloud Storage バケット、Gemini Enterprise Agent Platform、Cloud Run、Pub/Sub など、すべてを Google SaaS インフラストラクチャでホストします。この場合、コンポーネントは Google のプライベート インフラストラクチャを介して通信します。
  • Compute Engine VM、GKE クラスタ、Cloud SQL データベース、または VPC ネットワークで実行されるその他のコンポーネントで実行されるワークロードにすべてをホストします。この場合、システムは、NCC または VPC ネットワーク ピアリングを介してリンクするネットワーク間でプライベート IP アドレスを使用して通信します。
  • フルマネージド サービス、プラットフォーム サービス、インフラストラクチャ サービスを組み合わせて使用します。この場合、次の方法を使用して、VPC ネットワークとフルマネージド サービス間の接続を確立できます。
    • プライベート Google アクセス: この方法では、外部 IP アドレスを持たず、VPC ネットワークで実行されるワークロードが Google API にアクセスできます。このアクセスは Google インフラストラクチャを介して内部的に行われ、このプロセスによってこのようなトラフィックがインターネットに公開されることはありません。
    • Private Service Connect: この方法では、マネージド VPC ネットワークでホストされている AlloyDB for PostgreSQL などのサービス用のエンドポイントをサービス プロジェクトに作成できます。

外部ネットワークからフロントエンド サービス アプリケーション ロードバランサ

リージョン内部アプリケーション ロードバランサのエンドポイントは、RAG ネットワーク内の IP アドレスです。RAG ネットワーク、ルーティング ネットワーク、外部ネットワークへのハイブリッド接続はすべて、同じ NCC ハブのスポークです。したがって、NCC にすべてのスポーク サブ範囲をハブにエクスポートするように指示できます。ハブは、これらのサブ範囲を他のスポーク ネットワークに再エクスポートします。システムの最終ユーザーは、外部ネットワークからロード バランシングされたサービスにアクセスできます。

トラフィック フロー

このリファレンス アーキテクチャのトラフィック フローには、RAG データフローと推論フローが含まれます。

RAG の挿入フロー

このフローでは、RAG データがデータ エンジニアからベクトル ストレージにシステムを介して流れる仕組みについて説明します。

  1. 外部ネットワークから、データ エンジニアが Cloud Interconnect 接続または Cloud VPN 接続を介して元データをアップロードします。データは、ルーティング VPC ネットワークの Private Service Connect エンドポイントにアップロードされます。
  2. データは Google の内部インフラストラクチャを介して、データの取り込みサービス プロジェクトの Cloud Storage バケットに転送されます。
  3. データ取り込みサービス プロジェクト内では、次のいずれかの方法でシステム間でデータが移動します。

    • 限定公開の Google アクセス
    • Private Service Connect エンドポイント
    • 直接的な Google インフラストラクチャ

    この方法は、システムがGoogle Cloud VPC ネットワークでホストされているか、Google Cloudで直接ホストされているかによって異なります。このフローの一環として、データの取り込みサブシステムはチャンク化された RAG データをモデルにフィードし、モデルはチャンクごとにベクトルを生成します。

  4. データの取り込みサブシステムは、ベクトルデータとチャンク化されたデータを適切なデータストアに書き込みます。

推論フロー

このフローでは、お客様のリクエストについて説明します。

  1. 外部ネットワークから、お客様が Service の IP アドレスにリクエストを送信します。
  2. リクエストは、Cloud Interconnect 接続または Cloud VPN 接続を介してルーティング VPC ネットワークに送信されます。
  3. リクエストは、VPC スポーク接続を介して RAG VPC ネットワークに渡されます。
  4. お客様のリクエストがアプリケーション ロードバランサに到着し、リクエストがフロントエンド サブシステムに渡されます。
  5. フロントエンド サブシステムは、リクエストをサービング サブシステムに転送します。
  6. サービング サブシステムは、データストアから関連するコンテキスト データを使用してリクエストを拡張します。
  7. サービング サブシステムは、拡張プロンプトを 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、ルーター アプライアンスと連携して、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 アドレスを使用する必要があり、インターネットを通過してはならないエンタープライズ シナリオ向けに設計されています。

  • プライベート入力: アップロードされたデータはインターネット経由で送信されません。代わりに、 Google Cloudルーティング VPC ネットワークの Private Service Connect エンドポイントの背後で Cloud Storage バケットをホストします。プライベート IP アドレスのみを使用して、Cloud Interconnect または Cloud VPN 接続を介して RAG データをコピーします。
  • プライベートなサービス間接続: サービスは、Google の内部インターフェースを介して、または VPC ネットワークの内部にあるプライベート アドレスを介して相互に通信します。
  • プライベート出力: アクセスを設定しない限り、推論結果にインターネット経由でアクセスすることはできません。デフォルトでは、指定された外部ネットワーク内のユーザーのみがサービスのプライベート エンドポイントにアクセスできます。

代替案を設計する

このセクションでは、 Google Cloudの RAG 対応アプリケーションで検討できる代替のネットワーク設計アプローチについて説明します。

サービスを一般公開する

このドキュメントに示すアーキテクチャでは、内部ネットワークのユーザーのみがアプリケーションにクエリを送信できます。アプリケーションがインターネット上のクライアントにアクセスできるようにする必要がある場合は、リージョン外部アプリケーション ロードバランサを使用します。

GKE Inference Gateway を使用する

フロントエンド サブシステムが GKE で実行されている場合は、アプリケーション ロードバランサの代わりに GKE Inference Gateway を使用できます。

設計上の考慮事項

このセクションでは、RAG 対応アーキテクチャのプライベート接続をサポートするネットワーキングをデプロイする際の追加のガイダンスについて説明します。このガイダンスは、セキュリティ、プライバシー、コンプライアンス、信頼性、費用の最適化、運用効率、パフォーマンスの最適化に関する特定の要件を満たすのに役立ちます。このセクションのガイダンスはすべてを網羅しているわけではありません。特定のデプロイでは、このセクションで説明されていない追加の設計要素を考慮する必要がある場合があります。

セキュリティ、プライバシー、コンプライアンス

RAG 対応アーキテクチャを保護し、プライバシーとコンプライアンスの要件を満たすには、次の推奨事項を考慮してください。

  • プロンプトとレスポンスのスクリーニング: AI モデルの前に Model Armor をデプロイして、プロンプト インジェクション、ジェイルブレイクの試み、機密データの漏洩、責任ある AI ポリシー違反に対して、インバウンド プロンプトとアウトバウンド結果の両方を評価します。Model Armor を Gemini Enterprise Agent Platform と直接統合するか、Service Extensions のトラフィック拡張機能を使用して Model Armor をアプリケーション ロードバランサに接続することで、不適切なリクエストがサービング サブシステムに到達する前に拒否できます。プライベート Google アクセスまたは VPC Service Controls を使用しているときに、証明書エラーなしで VPC ネットワーク内から Model Armor リージョン エンドポイントにプライベートにアクセスするには、Model Armor API 用にリージョン Private Service Connect エンドポイントを作成します。
  • 境界とネットワークのマイクロセグメンテーション: このアーキテクチャでは、VPC Service Controls を使用して、サービス プロジェクト全体で不正なデータ引き出しを防止します。サービス境界に加えて、Cloud Next Generation Firewall の階層型ファイアウォール ポリシーとネットワーク ファイアウォール ポリシーを IAM で管理されるタグとともに使用して、共有 VPC ネットワーク内のデータの取り込み、サービング、フロントエンド ワークロード間の東西トラフィックを制限します。
  • ID とゼロトラスト アクセス: Identity-Aware Proxy(IAP)を有効にして、フロントエンドの内部アプリケーション ロードバランサまたはリージョン外部アプリケーション ロードバランサにゼロトラスト アクセス制御を適用します。これにより、認証および認可されたユーザーのみが RAG アプリケーションにクエリを実行できます。最小権限のサービス アカウントとプリンシパル アクセス境界ポリシーを組み合わせて、各サブシステム プリンシパルがアクセスできるリソースを制限します。サービング サブシステムがプライベート ネットワーク間で自律エージェントまたは Model Context Protocol(MCP)ツールをオーケストレートする場合は、Agent Identity と Agent Gateway を使用して、エージェントとツールの間のトラフィックを認証して管理します。
  • データのプライバシーと暗号化: データ取り込みサブシステムで Sensitive Data Protection を使用して、エンベディングを生成して RAG データストアに書き込む前に、Cloud Storage バケットにアップロードされた未加工ドキュメント内の個人情報(PII)を検査、分類、匿名化します。規制遵守のために暗号鍵を制御する必要がある場合は、Cloud Storage バケット、ベクトル データストア、モデル エンドポイントに Cloud Key Management Service(Cloud KMS)の顧客管理の暗号鍵(CMEK)を構成します。

この設計では、確立されたセキュリティ原則を使用して RAG ワークロードを保護します。AI ワークロードと ML ワークロードに固有のセキュリティの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: セキュリティをご覧ください。

信頼性

RAG 対応アプリケーション用の信頼性の高いネットワーキング インフラストラクチャを構築して運用するには、次の推奨事項を検討してください。

  • 冗長ハイブリッド接続: 複数のエッジ可用性ドメインとリージョンにまたがる冗長 Cloud Interconnect VLAN アタッチメントまたは HA VPN トンネルを構成し、冗長 Cloud Router とペアリングして、外部ネットワークとルーティング VPC ネットワーク間の動的 BGP フェイルオーバーを実現します。
  • マルチリージョン ロード バランシングとストレージ: リージョン間で高可用性を実現するには、クロスリージョン内部アプリケーション ロードバランサを使用して、複数のリージョンのフロントエンドとサービング バックエンドに推論トラフィックを分散し、複製されたベクトル データストアでデュアルリージョンまたはマルチリージョンの Cloud Storage バケットを使用します。
  • 非同期取り込みと割り当ての復元力: デッドレター トピックまたは Eventarc 再試行ポリシーで Pub/Sub を使用して、Cloud Storage バケットへの元データのアップロードを取り込み処理パイプラインから切り離します。これにより、一時的なエンベディングまたはインデックス作成の失敗を、データ損失なしで再試行できます。大量のエンベディング生成と推論中に予測可能なレイテンシと容量を確保するには、プロビジョンド スループットを予約し、HTTP 429 レスポンスに指数バックオフを実装します。

AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。

費用の最適化

RAG 対応アーキテクチャの構築と実行の費用を最適化するには、次の推奨事項を検討してください。

  • ネットワーク下り(外向き)とエンドポイントの選択: ルーティング VPC ネットワーク、Private Service Connect エンドポイント、Cloud Storage バケット、RAG データストア、モデル エンドポイントを同じリージョンに配置して、NCC スポークを介したリージョン間のデータ移転料金を回避します。ルーティング VPC ネットワークまたはホスト VPC ネットワークで共有 Private Service Connect エンドポイントを統合して、エンドポイントとデータ処理の 1 時間あたりの料金を削減します。
  • ストレージ ライフサイクル管理: 元データの取り込みバケットに Cloud Storage オブジェクトのライフサイクル管理または Autoclass を構成して、処理済みのソース ドキュメントをよりコールドなストレージ クラスに移行するか、ベクトルが RAG データストアに書き込まれた後にステージング ファイルを削除します。
  • バッチ エンベディングとコンテキスト キャッシュ: データ取り込みサブシステムで大規模で緊急性の低い RAG コーパスを更新する場合は、オンライン リクエストよりも低コストでエンベディングのバッチ予測またはバッチ推論を使用します。サービング サブシステムで、繰り返し使用されるシステム指示と頻繁に取得される参照ドキュメントのコンテキスト キャッシュ保存を有効にして、入力トークンのコストを削減します。

AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。

運用効率

ネットワーキングと RAG インフラストラクチャを効率的に運用して管理するには、次の推奨事項を検討してください。

  • Infrastructure as Code(IaC): エンタープライズ基盤ブループリントと Infrastructure Manager の Terraform モジュールを使用して、ルーティング プロジェクト、共有 VPC ホスト プロジェクトとサービス プロジェクト、NCC ハブとスポーク、Private Service Connect エンドポイント、VPC Service Controls の境界のプロビジョニングを自動化します。
  • 一元化されたプライベート DNS 解決: ルーティング VPC ネットワークで Cloud DNS 限定公開ゾーンとインバウンドまたはアウトバウンド転送ポリシーを使用して、外部ネットワークと VPC スポーク間の DNS 管理を簡素化します。これにより、オンプレミス クライアントとサービス プロジェクトは、Private Service Connect エンドポイントと内部アプリケーション ロードバランサの IP アドレスを自動的に解決します。
  • ネットワークと AI のオブザーバビリティ: Network Intelligence Center(接続テストと Flow Analyzer を含む)、Cloud Logging、Cloud Monitoring を使用して、ハイブリッド接続、NCC スポーク トラフィック、VPC Service Controls ポリシーの拒否をモニタリングします。Gen AI Evaluation Service を使用して、サービング サブシステムでの検索の関連性とグラウンディングを継続評価します。

AI ワークロードと ML ワークロードに固有のオペレーショナル エクセレンスの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 運用の卓越性をご覧ください。

パフォーマンスの最適化

ネットワーキング ワークロードと RAG ワークロードのパフォーマンスを最適化するには、次の推奨事項を検討してください。

  • ハイブリッド帯域幅とリージョン コロケーション: Cloud Interconnect VLAN アタッチメントまたは Cloud VPN トンネルのサイズを調整して、インタラクティブな推論リクエストと共有される帯域幅を飽和させることなく、外部ネットワークからの元データのアップロード量のピークを処理できるようにします。リージョンの Private Service Connect エンドポイント、Cloud Storage バケット、ベクトル データストア(ベクトル検索や AlloyDB for PostgreSQL など)、モデル エンドポイントを、ハイブリッド相互接続のポイント オブ プレゼンスに最も近いリージョンに配置して、ネットワークの往復レイテンシを最小限に抑えます。
  • コンピューティングのスケーリングと推論ルーティング: フロントエンドまたはサービング サブシステムが Cloud Run で実行されている場合は、最小インスタンス数を構成し、同時実行設定を調整して、トラフィックの急増時にコールド スタート レイテンシを排除します。GKE でオープンモデルをサービングする場合は、Inference Gateway を使用して、モデルサーバー間で KV キャッシュ対応ルーティングと負荷対応ルーティングを実行します。

AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。

デプロイ

このセクションでは、アプリケーションを作成する手順について説明します。

  1. ワークロードのリージョンを特定する。
  2. Google Cloud プロジェクトと VPC ネットワークを作成する。
  3. 外部ネットワークをルーティング VPC ネットワークに接続する。
  4. NCC を使用してネットワークをリンクする。
  5. RAG デプロイのコンポーネントを特定し、サービス アカウントを作成する。
  6. VPC Service Controls を構成する。
  7. データ取り込みサブシステムを構築する。
  8. サービス提供サブシステムを構築する。
  9. フロントエンド サブシステムをビルドする。
  10. インターネットからアプリケーションにアクセスできるようにする。

ワークロードのリージョンを特定する

一般に、接続、VPC サブネット、 Google Cloudワークロードは、オンプレミス ネットワークまたは他のクラウド クライアントの近くに配置する必要があります。ワークロードのリージョンを選択する方法については、Google Cloud リージョン選択ツールと Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。

Google Cloud プロジェクトと VPC ネットワークを作成する

組織で分散アプリケーション用のクロスクラウド ネットワーク がすでに設定されている場合は、ルーティング プロジェクトとルーティング VPC ネットワークがすでに存在しているはずです。

次の順序で Google Cloud プロジェクトと VPC ネットワークを作成します。

  1. ルーティング プロジェクトを作成します。
  2. プライベート Google アクセスを有効にして、ルーティング VPC ネットワークを作成します。
  3. RAG プロジェクトを作成します。
  4. RAG プロジェクトを共有 VPC ホスト プロジェクトに昇格させる。
  5. データの取り込みサービス プロジェクトを作成します。
  6. サービング サービス プロジェクトを作成します。
  7. フロントエンド サービス プロジェクトを作成します。
  8. 限定公開の Google アクセスを有効にして、共有 VPC RAG ネットワークを作成します。
  9. サービス プロジェクトに RAG ネットワークを使用する権限を付与します。

外部ネットワークをルーティング VPC ネットワークに接続する

分散型アプリケーション向けのクロスクラウド ネットワーク をすでに設定している場合は、この手順をスキップできます。

外部ネットワークとルーティング ネットワーク間の接続を設定します。関連するテクノロジーについては、外部接続とハイブリッド接続をご覧ください。接続プロダクトの選択方法については、Network Connectivity プロダクトの選択をご覧ください。

  1. ルーティング プロジェクトで、NCC ハブを作成します。
  2. Cloud Interconnect 接続を VLAN アタッチメント スポークとして追加するか、Cloud VPN 接続を VPN スポークとして追加します。
  3. RAG VPC ネットワークとルーティング VPC ネットワークを VPC スポークとしてハブに追加します。

RAG デプロイのコンポーネントを特定してサービス アカウントを作成する

  1. RAG デプロイを選択し、必要なコンポーネントのリストを作成します。
  2. 各コンポーネントに必要なアクセス権を特定します。
  3. コンポーネントごとに、適切な権限を持つサービス アカウントを作成します。場合によっては、コンポーネントに別のサービス プロジェクトの読み取りまたは書き込みの権限を付与することを意味します。

この設計では、データ入力コンポーネントとして Cloud Storage バケットを使用し、推論フロントエンドでアプリケーション ロードバランサを使用することを前提としています。設計の残りの部分は、必要に応じて変更できます。

理想的には、各コンポーネントは独自のサービス アカウントとして実行されます。各コンポーネントには、必要な機能を実行するために必要な最小限の IAM 権限のみが付与されていることを確認します。たとえば、データの取り込みサブシステムの Cloud Run ジョブは、入力 Cloud Storage バケットから読み取る必要がありますが、バケットに書き込む必要はありません。この例では、Cloud Run ジョブを実行するサービス プロジェクトに、バケットからの読み取り権限のみを付与し、書き込み権限は付与しないようにします。

VPC Service Controls を構成する

  1. デプロイの周囲に VPC Service Controls の境界を作成します。
  2. アクセスルールを構成する。

データ取り込みサブシステムを構築する

データの取り込みサブシステムは、データ エンジニアから元データを受け取り、サービング サブシステムで使用できるように処理します。

  1. データ取り込みサービス プロジェクトで、Cloud Storage バケットを作成します。
  2. ルーティング VPC ネットワークで、リージョン Private Service Connect エンドポイントを作成し、エンドポイントをバケットに接続します。
  3. 外部ネットワークで、前の手順で生成された IP アドレスと URL を使用して、エンドポイントの DNS エントリを追加します。
  4. エンドポイント IP アドレスへのアクセスを許可するように、外部ネットワーク ファイアウォール ルールを更新します。
  5. データの取り込みサービス プロジェクトで、選択した RAG アーキテクチャに従って、取り込みパイプラインの残りの部分を構築します。
  6. 取り込みパイプラインの関連リソースがベクトルを生成するモデルにアクセスできるように、IAM 権限を付与します。
  7. 取り込みパイプラインの関連リソースがベクトル データストアに書き込めるように、IAM 権限を付与します。

サービング サブシステムを構築する

  1. サービス提供プロジェクトで、サービス提供パイプラインを構築します。
  2. フロントエンド システムのサービス アカウントがサービング サブシステムの出力にアクセスできるように、IAM 権限を付与します。

フロントエンド サブシステムをビルドする

このセクションでは、Cloud Run の前にサーバーレス NEG を使用するリージョン内部アプリケーション ロードバランサを使用することを前提としています。ただし、別のロードバランサとバックエンドを使用することもできます。

  1. フロントエンド システムのコードを作成します。
  2. フロントエンド サービス プロジェクトで、ロードバランスされたフロントエンド システムをデプロイします。これには、Cloud Armor セキュリティ ポリシーを構成するオプションの手順が含まれます。
  3. RAG VPC ネットワークからオンプレミス ルーターにルートを転送するように、ルーティング VPC ネットワークで Cloud Router を構成します。この構成により、クライアントはアプリケーション ロードバランサにアクセスできます。
  4. 外部ネットワークで、外部ネットワークからロードバランサのフロントエンドにアクセスできるようにファイアウォール ルールを構成します。
  5. 外部ネットワークで、アプリケーション ロードバランサの転送ルールを参照するように DNS を更新します。

インターネットからアプリケーションにアクセスできるようにする

このセクションは省略可能です。

この設計では、サービスに外部ネットワークからのみアクセスできるようにすることを前提としていますが、インターネットからサービスにアクセスできるようにすることもできます。

インターネットからサービスにアクセスできるようにするには、次の操作を行います。

  1. 内部アプリケーション ロードバランサが参照するバックエンドを参照するリージョン外部アプリケーション ロードバランサを作成します。Cloud Armor セキュリティ ポリシーを構成するオプションの手順を完了します。
  2. VPC Service Controls を更新して、サービス ユーザーがバックエンド サービスにアクセスできるようにします。

次のステップ

寄稿者

著者:

  • Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
  • Mark Schlagenhauf | テクニカル ライター、ネットワーキング

その他の寄稿者:

  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
  • Samantha He | テクニカル ライター
  • Ammett Williams | デベロッパー リレーションズ エンジニア
  • Aspen Sherrill | クラウド セキュリティ アーキテクト