このドキュメントでは、ベクトル検索を使用して、検索拡張生成（RAG）対応の生成 AI アプリケーションのインフラストラクチャを設計するために使用できるリファレンス アーキテクチャについて説明します。ベクトル検索は、非常に大規模なベクトル類似性マッチング用に最適化されたサービング インフラストラクチャを提供する、フルマネージド Google Cloud サービスです。
このドキュメントは、生成 AI アプリケーションのアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI、ML、大規模言語モデル（LLM）のコンセプトに関する基本的な知識があることを前提としています。このドキュメントでは、生成 AI アプリケーションの設計と開発の方法については説明しません。
アーキテクチャ
次の図は、このドキュメントで説明するアーキテクチャの概要を示しています。
上の図のアーキテクチャには、データの取り込みとサービングの 2 つのサブシステムがあります。
- データ取り込みサブシステムは、外部ソースからアップロードされたデータを取り込みます。このサブシステムは、RAG 用のデータの準備を行い、Vertex AI とやり取りして取り込まれたデータのエンベディングを生成し、ベクトル インデックスを構築して更新します。
- サービング サブシステムには、生成 AI アプリケーションのフロントエンド サービスとバックエンド サービスが含まれています。
- フロントエンド サービスは、アプリケーション ユーザーとのクエリ / レスポンス フローを処理し、クエリをバックエンド サービスに転送します。
- バックエンド サービスは Vertex AI を使用してクエリ エンベディングを生成し、ベクトル類似性検索を実行し、責任ある AI の安全フィルタとシステム インストラクションを適用します。
次の図は、アーキテクチャの詳細を示しています。
以降のセクションでは、上のアーキテクチャ図の各サブシステム内のデータフローについて説明します。
データ取り込みサブシステム
データ取り込みサブシステムは、外部ソースからデータを取り込み、RAG 用にデータを準備します。データの取り込みと準備のフローは次のとおりです。
- データは外部ソースから Cloud Storage バケットにアップロードされます。外部ソースには、アプリケーション、データベース、ストリーミング サービスなどがあります。
- データが Cloud Storage にアップロードされると、メッセージが Pub/Sub トピックにパブリッシュされます。
- Pub/Sub トピックがメッセージを受信すると、Cloud Run ジョブがトリガーされます。
- Cloud Run ジョブは、元データを解析し、必要な形式にフォーマットしてチャンクに分割します。
- Cloud Run ジョブは、 Vertex AI Embeddings API を使用して、指定したエンベディング モデルを使用してチャンクのエンベディングを作成します。Vertex AI は、テキストとマルチモーダルのエンベディング モデルをサポートしています。
- Cloud Run ジョブは、エンベディングのベクトル検索インデックスをビルドし、インデックスをデプロイします。
新しいデータが取り込まれると、新しいデータに対して上記の手順が実行され、ストリーミング アップデートを使用してインデックスが更新されます。
サービング サブシステムは、ユーザー リクエストを処理するときに、ベクトル類似度検索にベクトル検索インデックスを使用します。次のセクションでは、サービング フローについて説明します。
サービング サブシステム
サービング サブシステムは、生成 AI アプリケーションとユーザー間のクエリ / レスポンス フローを処理します。サービング フローの手順は次のとおりです。
- ユーザーが、生成 AI アプリケーションのフロントエンド インターフェース（chatbot など）を提供する Cloud Run サービスに自然言語クエリを送信します。
- フロントエンド サービスは、ユーザーのクエリをバックエンドの Cloud Run サービスに転送します。
- バックエンド サービスは、次のようにクエリを処理します。
- データ取り込みサブシステムが取り込まれたデータのエンベディングの生成に使用するエンベディング モデルとパラメータを使用して、クエリをエンベディングに変換します。
- ベクトル検索インデックスでクエリ エンベディングのベクトル類似性検索を実行して、関連するグラウンディング データを取得します。
- 元のクエリとグラウンディング データを組み合わせて、拡張プロンプトを作成します。
- 拡張プロンプトを Vertex AI にデプロイされた LLM に送信します。
- LLM がレスポンスを生成します。
- プロンプトごとに、Vertex AI は構成した責任ある AI の安全フィルタを適用し、フィルタされたレスポンスと AI 安全性スコアを Cloud Run バックエンド サービスに送信します。
- アプリケーションは、Cloud Run フロントエンド サービス経由でレスポンスをユーザーに送信します。
Cloud Logging では、クエリ / レスポンスのアクティビティのログを保存して表示できます。また、Cloud Monitoring を使用してログベースのモニタリングを設定できます。生成されたレスポンスを BigQuery に読み込んで、オフライン分析を行うこともできます。
Vertex AI プロンプト オプティマイザーは、最初のプロンプト設計時とプロンプトの継続的なチューニングの両方で、プロンプトを大規模に改善するのに役立ちます。プロンプト オプティマイザーは、ML エンジニアが提供する一連のサンプル プロンプトに対するモデルのレスポンスを評価します。評価の出力には、サンプル プロンプトに対するモデルのレスポンス、ML エンジニアが指定した指標のスコア、使用を検討できる最適化されたシステム指示のセットが含まれます。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Vertex AI: ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する LLM をカスタマイズできる ML プラットフォーム。
- ベクトル検索: 意味的に類似または関連するデータを保存、インデックス化、検索できるベクトル類似性マッチング サービス。
- Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
- Pub/Sub: メッセージを処理するサービスとメッセージを生成するサービスを切り離す、非同期でスケーラブルなメッセージング サービス。
- Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
- Cloud Monitoring: アプリケーションとインフラストラクチャのパフォーマンス、可用性、動作状況を可視化するサービス。
- BigQuery: ML、地理空間分析、ビジネス インテリジェンスなどの組み込み機能を使用してデータの管理と分析を支援する、Google Cloud のフルマネージド エンタープライズ データ ウェアハウス。
ユースケース
RAG は、LLM から生成される出力の品質を高める効果的な手法です。このセクションでは、RAG 対応の生成 AI アプリケーションを使用するユースケースの例を示します。
個人に特化したおすすめの商品情報
オンライン ショッピング サイトで、LLM を利用した chatbot を使用して、買い物客が商品を見つけたり、ショッピング関連のサポートを利用できるようにします。ユーザーからの質問を、ユーザーの購入行動やウェブサイトのインタラクション パターンに関する過去のデータに基づいて拡張します。データには、非構造化データストアに保存されているユーザー レビューやフィードバック、ウェブ分析データ ウェアハウスに保存されている検索関連の指標などがあります。拡張された質問を LLM で処理することで、より魅力的で説得力のあるパーソナライズされた回答を生成できます。
臨床支援システム
医師は、適切な治療方法や処方薬を判断するために、患者の健康状態を迅速に分析し、診断する必要があります。この臨床診断プロセスを支援するために、Med-PaLM などの医療 LLM を使用する生成 AI アプリケーションを使用できます。病院の電子医療記録（EHR）データベースや、PubMed などの外部のナレッジベースから取得したデータで医師のプロンプトをコンテキスト化することで、過去の患者記録に裏付けられたレスポンスを生成できます。
効率的な法律調査
生成 AI を活用した法的調査により、弁護士は大量の法令と判例法をすばやく照会し、関連する判例を特定したり、複雑な法的概念を要約できます。法律事務所独自の契約書コーパス、過去の法的コミュニケーション、内部の訴訟記録から取得したデータで弁護士のプロンプトを補強することで、このような調査の出力精度を高めることができます。こうした設計アプローチにより、弁護士が専門とする法的領域に関連するレスポンスを生成することが可能になります。
代替案を設計する
このセクションでは、 Google Cloudの RAG 対応生成 AI アプリケーションで検討できる代替の設計アプローチについて説明します。
AI インフラストラクチャの代替手段
RAG アプリケーションで AlloyDB for PostgreSQL や Cloud SQL などのフルマネージド Google Cloud データベースのベクトルストア機能を利用する場合は、Vertex AI と AlloyDB for PostgreSQL を使用した RAG 対応の生成 AI アプリケーションのインフラストラクチャをご覧ください。
オープンソースのツールとモデルである Ray、Hugging Face、LangChain を使用して、RAG 対応の生成 AI アプリケーションを迅速に構築してデプロイする場合は、Google Kubernetes Engine（GKE）を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャをご覧ください。
アプリケーション ホスティングのオプション
このドキュメントで説明するアーキテクチャでは、Cloud Run が生成 AI アプリケーション サービスとデータ処理ジョブのホストです。Cloud Run は、デベロッパー重視のフルマネージド アプリケーション プラットフォームです。コンピューティング インフラストラクチャの構成の柔軟性と制御を強化する必要がある場合は、アプリケーションを GKE クラスタまたは Compute Engine VM にデプロイできます。
アプリケーション ホストとして Cloud Run、GKE、Compute Engine のいずれを使用するかを決定する際には、構成の柔軟性と管理上の労力とのトレードオフを考慮する必要があります。サーバーレス Cloud Run オプションを使用すると、管理作業が最小限に抑えられる事前構成済みの環境にアプリケーションをデプロイできます。Compute Engine VM と GKE コンテナでは、基盤となるコンピューティング リソースの管理はユーザーの責任となりますが、構成の柔軟性と制御性が向上します。適切なアプリケーション ホスティング サービスの選択の詳細については、次のドキュメントをご覧ください。
その他のオプション
Google Cloudで生成 AI アプリケーションに使用できるその他のインフラストラクチャ オプション、サポートされているモデル、グラウンドング手法については、生成 AI アプリケーションのモデルとインフラストラクチャを選択するをご覧ください。
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。
このセクションのガイダンスはすべてを網羅しているわけではありません。アプリケーションの特定の要件と、使用する Google Cloud とサードパーティのプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。
セキュリティ、コンプライアンス、プライバシー
このセクションでは、ワークロードのセキュリティとコンプライアンスの要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| プロダクト | 設計に関する考慮事項と推奨事項 |
|---|---|
| Vertex AI |
セキュリティ管理: Vertex AI は、 Google Cloud セキュリティ管理をサポートしています。これにより、データ所在地、データ暗号化、ネットワーク セキュリティ、アクセスの透明性の要件を満たすことができます。詳細については、Vertex AI のセキュリティ管理と生成 AI のセキュリティ管理をご覧ください。 モデル アクセス: 組織のポリシーを設定して、 Google Cloud プロジェクトで使用できる LLM のタイプとバージョンを制限できます。詳細については、Model Garden モデルへのアクセスを制御するをご覧ください。 共有責任: Vertex AI は基盤となるインフラストラクチャを保護し、データ、コード、モデルを保護するためのツールとセキュリティ制御を提供します。詳細については、Vertex AI の共有責任をご覧ください。 データ保護: Cloud Data Loss Prevention API を使用して、プロンプトとレスポンス、ログデータ内の個人情報（PII）などの機密データを検出して匿名化します。詳細については、AI アプリでの機密データの保護をご覧ください。 |
| Cloud Run |
上り（内向き）セキュリティ（フロントエンド サービス）: アプリケーションへの外部アクセスを制御するには、フロントエンド Cloud Run サービスのデフォルトの run.app URL を無効にして、リージョン外部アプリケーション ロードバランサを設定します。ロードバランサは、アプリケーションへの受信トラフィックのロード バランシングとともに、SSL 証明書の管理も処理します。保護を強化するために、Google Cloud Armor セキュリティ ポリシーを使用して、サービスにリクエスト フィルタリング、DDoS 保護、レート制限を提供できます。
上り（内向き）セキュリティ（バックエンド サービス）: このアーキテクチャのアプリケーションのバックエンド用の Cloud Run サービスには、インターネットからのアクセスは必要ありません。内部クライアントのみがサービスにアクセスできるようにするには、 データの暗号化: デフォルトでは、Cloud Run は Google が所有し Google が管理する 暗号鍵を使用してデータを暗号化します。お客様が管理する鍵を使用してコンテナを保護するには、顧客管理の暗号鍵（CMEK）を使用します。詳細については、顧客管理の暗号鍵の使用をご覧ください。 コンテナ イメージのセキュリティ: 承認済みのコンテナ イメージのみが Cloud Run ジョブとサービスにデプロイされるようにするには、Binary Authorization を使用します。 データ所在地: Cloud Run は、データ所在地の要件を満たすのに役立ちます。Cloud Run コンテナ インスタンスは、選択したリージョン内で実行されます。 コンテナ セキュリティの詳細については、Cloud Run の一般的な開発のヒントをご覧ください。 |
| Cloud Storage |
データの暗号化: デフォルトでは、Cloud Storage に保存されるデータは、 Google が所有し、Google が管理する 暗号鍵を使用して暗号化されます。必要に応じて、CMEK を使用するか、顧客指定の暗号鍵（CSEK）などの外部の管理方法で管理する独自の鍵を使用できます。詳細については、データ暗号化オプションをご覧ください。 アクセス制御: Cloud Storage は、バケットとオブジェクトに対するユーザーのアクセスを制御するための 2 つの方法をサポートしています。これらの方法の 1 つは Identity and Access Management（IAM）、もう 1 つはアクセス制御リスト（ACL）です。ほとんどの場合は IAM の使用をおすすめします。これにより、バケットレベルとプロジェクト レベルで権限を付与できます。詳細については、アクセス制御の概要をご覧ください。 データ保護: Cloud Storage を介してデータ取り込みサブシステムに読み込むデータには、機密データが含まれる場合があります。このようなデータを保護するには、Sensitive Data Protection を使用してデータを検出、分類、匿名化します。詳細については、Cloud Storage での Sensitive Data Protection の使用をご覧ください。 ネットワーク制御: Cloud Storage からデータが漏洩するリスクを軽減するには、VPC Service Controls を使用してサービス境界を作成します。 データ所在地: Cloud Storage は、データ所在地の要件を満たすのに役立ちます。データは、指定したリージョン内で保存または複製されます。 |
| Pub/Sub |
データ暗号化: Pub/Sub はデフォルトで、 Google が所有し、Google が管理する 暗号鍵を使用して、保存時と転送時の両方ですべてのメッセージを暗号化します。Pub/Sub は、アプリケーション レイヤでのメッセージ暗号化に CMEK の使用をサポートしています。詳細については、メッセージ暗号化を構成するをご覧ください。 データ所在地: データ所在地の要件がある場合、メッセージ データが特定のロケーションに保存されるように、メッセージ ストレージ ポリシーを構成できます。 |
| Cloud Logging |
管理アクティビティの監査: このリファレンス アーキテクチャで使用されるすべての Google Cloud サービスで、管理アクティビティのロギングがデフォルトで有効になっています。Cloud Logging からログにアクセスし、そのログを使用して Google Cloud リソースの構成やメタデータを変更する API 呼び出しなどのアクションをモニタリングできます。 データアクセス監査: BigQuery では、データアクセス イベントのロギングがデフォルトで有効になっています。このアーキテクチャで使用される他のサービスでは、データアクセス監査ログを有効にできます。これらのログを使用して、以下の対象をモニタリングできます。
ログデータのセキュリティ: Google が Cloud Logging のデータにアクセスする、またはデータを使用することはありません。 データ所在地: データ所在地の要件を満たすために、指定したリージョンにログデータを保存するように Cloud Logging を構成できます。詳細については、ログをリージョン化するをご覧ください。 |
| アーキテクチャ内のすべてのプロダクト |
データ漏洩のリスクを軽減する: データ漏洩のリスクを軽減するには、インフラストラクチャの周囲に VPC Service Controls 境界を作成します。VPC Service Controls は、このリファレンス アーキテクチャで使用されるすべてのサービスをサポートしています。 デプロイ後の最適化: Google Cloudにアプリケーションをデプロイしたら、Active Assist サービスを使用して、クラウド リソースのセキュリティをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を探すをご覧ください。 アクセス制御: すべてのクラウド サービスで最小権限の原則に従います。 |
Google Cloudでの AI と ML のデプロイのセキュリティに関する一般的なガイダンスについては、次のリソースをご覧ください。
- （ブログ） Google のセキュア AI フレームワークの紹介
- （ドキュメント） Google Cloud アーキテクチャ フレームワークのAI と ML のセキュリティの観点
- （ドキュメント） Vertex AI の共有責任
- （ホワイトペーパー）生成 AI、プライバシー、 Google Cloud
- （動画）AI アプリでの機密データの保護
信頼性
このセクションでは、 Google Cloudでデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。
| プロダクト | 設計に関する考慮事項と推奨事項 |
|---|---|
| ベクトル検索 |
クエリのスケーリング: ベクトル検索インデックスがクエリ負荷の増加に対応できるように、インデックス エンドポイントの自動スケーリングを構成できます。クエリ負荷が増加すると、指定した最大数までノード数が自動的に増加します。詳細については、自動スケーリングを有効にするをご覧ください。 |
| Cloud Run |
インフラストラクチャの停止に対する堅牢性: Cloud Run はリージョン サービスです。データはリージョン内の複数のゾーンに同期的に保存されます。トラフィックは、ゾーン間で自動的にロードバランスされます。ゾーンが停止しても、Cloud Run は引き続き実行され、データは失われません。リージョンが停止した場合、Google が問題を解決するまで Cloud Run は実行を停止します。 障害処理: 個々の Cloud Run ジョブまたはタスクが失敗する可能性があります。このような障害に対処するには、タスクの再試行とチェックポイントを使用します。詳細については、ジョブの再試行とチェックポイントに関するベスト プラクティスをご覧ください。 |
| Cloud Storage | データの可用性: Cloud Storage バケットは、リージョン、デュアルリージョン、マルチリージョンの 3 つのロケーション タイプのいずれかに作成できます。リージョン バケットに保存されるデータは、リージョン内の複数のゾーン間で同期をとって複製されます。高可用性を実現するには、デュアルリージョンまたはマルチリージョン バケットを使用します。この場合、データはリージョン間で非同期で複製されます。 |
| Pub/Sub |
レート制御: メッセージ トラフィックの一時的な急増中にエラーが発生しないようにするには、パブリッシャーの設定でフロー制御を構成して、パブリッシュ リクエストのレートを制限します。 エラー処理: 失敗したパブリッシュの試行を処理するには、必要に応じて再試行リクエスト変数を調整します。詳細については、リクエストを再試行するをご覧ください。 |
| BigQuery | インフラストラクチャの停止に対する堅牢性: BigQuery に読み込むデータは、指定したリージョン内の 2 つのゾーンに同期的に保存されます。この冗長性により、ゾーン停止時のデータ消失を防ぐことができます。BigQuery の信頼性に関する機能の詳細については、信頼性についてをご覧ください。 |
| アーキテクチャ内のすべてのプロダクト | デプロイ後の最適化: Google Cloudにアプリケーションをデプロイしたら、Active Assist サービスを使用して、クラウド リソースの信頼性をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を探すをご覧ください。 |
AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、アーキテクチャ フレームワークの AI と ML の視点: 信頼性をご覧ください。
費用の最適化
このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。
| プロダクト | 設計に関する考慮事項と推奨事項 |
|---|---|
| ベクトル検索 |
ベクトル検索の課金は、インデックスのサイズ、秒間クエリ数（QPS）、インデックス エンドポイントに使用するノードの数とマシンタイプによって異なります。QPS の高いワークロードでは、クエリをバッチ処理すると費用を削減できます。ベクトル検索の費用を見積もる方法については、ベクトル検索の料金の例をご覧ください。 ベクトル検索インデックスがデプロイされているコンピューティング ノードの使用率を改善するには、インデックス エンドポイントの自動スケーリングを構成します。需要が少ない場合は、指定した最小数にノード数が自動的に減らされます。詳細については、自動スケーリングを有効にするをご覧ください。 |
| Cloud Run |
Cloud Run のジョブとサービスを作成するときに、コンテナ インスタンスに割り当てるメモリと CPU の量を指定します。費用を抑えるには、デフォルトの（最小）CPU とメモリの割り当てから始めます。パフォーマンスを向上させるには、CPU の上限とメモリ上限を構成して割り当てを増やします。詳細については、次のドキュメントをご覧ください。 Cloud Run のジョブとサービスの CPU とメモリの要件を予測できる場合は、確約利用の割引を受けることで費用を節約できます。詳細については、Cloud Run の確約利用割引をご覧ください。 |
| Cloud Storage | データ取り込みサブシステムへのデータの読み込みに使用する Cloud Storage バケットには、適切なストレージ クラスを選択します。ストレージ クラスを選択する場合は、ワークロードのデータ保持とアクセス頻度の要件を考慮してください。たとえば、ストレージ費用を管理するには、Standard クラスを選択して オブジェクトのライフサイクル管理を使用します。これにより、設定した条件に基づいて、オブジェクトの低コスト ストレージ クラスへのダウングレードやオブジェクトの削除を自動的に行うことができます。 |
| Cloud Logging |
ログの保存費用を管理するには、次の操作を行います。
|
| BigQuery | BigQuery では、クエリを実行する前に費用を見積もることができます。クエリ費用を最適化するには、ストレージとクエリ計算を最適化する必要があります。詳細については、費用の見積もりと管理をご覧ください。 |
| アーキテクチャ内のすべてのプロダクト | Google Cloudにアプリケーションをデプロイしたら、Active Assist サービスを使用して、クラウド リソースの費用をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を探すをご覧ください。 |
Google Cloud リソースの費用を見積もるには、Google Cloud 料金計算ツールを使用します。
AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、アーキテクチャ フレームワークの AI と ML の視点: 費用最適化をご覧ください。
パフォーマンスの最適化
このセクションでは、ワークロードのパフォーマンス要件を満たす Google Cloud でトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| プロダクト | 設計に関する考慮事項と推奨事項 |
|---|---|
| ベクトル検索 |
インデックスを作成するときに、パフォーマンス要件に基づいて、シャードのサイズ、距離測定タイプ、各リーフノードのエンベディング数を設定します。たとえば、アプリケーションがレイテンシの変動に極めて敏感な場合は、大きなシャードサイズをおすすめします。詳細については、パフォーマンスに影響する構成パラメータをご覧ください。 ベクトル検索インデックスがデプロイされるノードのコンピューティング容量を構成する場合は、パフォーマンスの要件を考慮してください。適切なマシンタイプを選択し、予想されるクエリ負荷に基づいてノードの最大数を設定します。詳細については、パフォーマンスに影響するデプロイ設定をご覧ください。
クエリのパフォーマンス、可用性、コストの要件に基づいて、Vertex Search インデックスのクエリ パラメータを構成します。たとえば、 最新のインデックスを使用すると、生成される回答の精度が向上します。ベクトル検索インデックスは、バッチ アップデートまたはストリーミング アップデートを使用して更新できます。ストリーミング更新を使用すると、更新されたデータに対してニア リアルタイムのクエリを実行できます。詳細については、アクティブ インデックスの更新と再ビルドをご覧ください。 |
| Cloud Run |
デフォルトでは、各 Cloud Run コンテナ インスタンスに 1 つの CPU と 512 MiB のメモリが割り当てられます。パフォーマンス要件に応じて、CPU の上限とメモリ上限を構成できます。詳細については、次のドキュメントをご覧ください。 トラフィックがない期間があっても最適なレイテンシを確保するには、インスタンスの最小数を構成します。このようなインスタンスがアイドル状態の場合、インスタンスに割り当てられた CPU とメモリは低価格で課金されます。 パフォーマンスの最適化に関するガイダンスについては、Cloud Run の一般的な開発のヒントをご覧ください。 |
| Cloud Storage | 大きなファイルをアップロードするには、並列複合アップロードと呼ばれる方法を使用できます。この方法では、サイズの大きいファイルがチャンクに分割されます。チャンクは Cloud Storage に並行してアップロードされ、その後、クラウドでデータが再構成されます。ネットワーク帯域幅とディスク速度が制限要因になっていない場合は、並列複合アップロードが通常のアップロード オペレーションよりも高速になる可能性があります。ただし、この方法にはいくつかの制限事項があり、費用にも影響が及びます。詳細については、並列複合アップロードをご覧ください。 |
| BigQuery |
BigQuery では、クエリ実行グラフを使用してクエリのパフォーマンスを分析し、スロット競合やシャッフル割り当ての不足などの問題に関するパフォーマンス分析情報を取得できます。詳細については、クエリのパフォーマンス分析情報を取得するをご覧ください。 クエリのパフォーマンス分析情報で特定した問題に対処したら、入力データと出力データの量を減らすなどの手法でクエリをさらに最適化できます。詳細については、クエリ計算を最適化するをご覧ください。 |
| アーキテクチャ内のすべてのプロダクト | Google Cloudにアプリケーションをデプロイしたら、Active Assist サービスを使用して、クラウド リソースのパフォーマンスをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を探すをご覧ください。 |
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、アーキテクチャ フレームワークの AI と ML の視点: パフォーマンス最適化をご覧ください。
次のステップ
- 生成 AI アプリケーションのモデルとインフラストラクチャを選択する
- Vertex AI と AlloyDB for PostgreSQL を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ
- GKE を使用した RAG 対応生成 AI アプリケーション用インフラストラクチャ
- Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要については、アーキテクチャ フレームワークの AI と ML の視点をご覧ください。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー
その他の寄稿者:
- Assaf Namer | プリンシパル クラウド セキュリティ アーキテクト
- Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
- Divam Anand | プロダクト ストラテジー＆オペレーション リード
- Eran Lewis | シニア プロダクト マネージャー
- プロダクト マネジメント担当ディレクター | Jerome Simms
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Nicholas McNamara | プロダクトと商用化戦略担当プリンシパル
- Preston Holmes | アウトバウンド プロダクト マネージャー - アプリ アクセラレーション
- Rob Edwards | DevOps 担当テクノロジー プラクティス リード
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Wietse Venema | デベロッパーリレーションズ エンジニア