このページでは、Cloud Run で信頼できないコードをホストするためのマルチテナント アーキテクチャを作成する際のベスト プラクティスについて説明します。お客様の場合、 Google Cloud 「テナント」とはお客様の顧客の 1 つを指し、 「信頼できないコード」とは、これらのテナントから提供され、お客様のプラットフォームで実行されるコードを指します。
ユースケース
このようなアーキテクチャのユースケースには、次のようなものがあります。
- アプリ ホスティング プラットフォーム: お客様が顧客にコードを デプロイするプラットフォームを提供します。たとえば、ウェブ ホスティング プラットフォーム（顧客がウェブ サーバー） や Functions-as-a-Service プラットフォーム（顧客が関数を提供する）などです。
- エージェント ホスティング プラットフォーム: 顧客が SDK を使用して AI エージェントを構築し、 プラットフォームがバックグラウンドで実行します。
- ファインチューニングされたモデル プラットフォーム: 顧客ごとに AI モデルをカスタマイズできます。 プラットフォームは、GPU を活用してオンデマンドで実行します。
- ユーザー定義関数: ソフトウェアを使用すると、顧客はコードを使用してカスタム ロジックを定義できます。たとえば、分析エンジンを提供し、顧客がカスタム関数を作成できるようにする場合や、API ゲートウェイを提供し、顧客が独自のカスタム ロジックに基づいてリクエストをフィルタリングまたは変更できるようにする場合などです。
- Software-as-a-Service（SaaS）の拡張性: SaaS を提供していて、顧客が拡張機能を使用して機能を拡張できるようにしたい場合があります。これらの拡張機能は、顧客またはパートナーによって作成される可能性があります。
Google Cloud のお客様は、これらのユースケースで Cloud Run を本番環境で正常に使用しています。
マルチテナント プラットフォームの課題
このようなアーキテクチャの作成における一般的な課題は次のとおりです。
- セキュリティ: 提供されたコードをスキャンまたはサニタイズすることはできません。信頼できないコードには、悪意のあるアクションや脆弱な依存関係が含まれている可能性があります。適切に分離されていない場合、信頼できないコードが他のテナントのセンシティブ データにアクセスする可能性があります。コードをコンテナにパッケージ化するだけでは、十分なセキュリティ境界にはなりません。また、最小権限の原則を適用して、コードの実行内容を制限する必要があります。
- 費用対効果: 各テナントがプラットフォームの 固定費用を負担する場合、このようなアーキテクチャは高額になる可能性があります。
- テナント管理: 数十万のテナントを管理することは 困難です。特にデータの削除は困難です。
Cloud Run のメリット
Cloud Run ベースのアーキテクチャは、セキュリティ、費用対効果、テナント管理など、一般的な課題に対するソリューションを提供します。
セキュリティ
Cloud Run には、このアーキテクチャに関連するすぐに使えるセキュリティ機能が用意されています。
- コンピューティングの分離: Cloud Run は、同じサービス、または異なるプロジェクトの異なるサービスのコンテナ インスタンス間の厳格な分離を保証します。コンテナのセキュリティと実行環境の詳細については、セキュリティ設計の概要をご覧ください。
- セキュリティ アップデート: ベースイメージの自動セキュリティ アップデートを 有効 にすると、大規模な再デプロイを行わずに、デプロイされたワークロードのオペレーティング システムとランタイムを 最新の状態に保ち、パッチを適用できます。
- ネットワーク分離: Cloud Run は、コンテナをサンドボックス化するだけでなく、マルチテナント ネットワーク スタックも 提供します。
- サービス ID: Cloud Run ワークロードは、制限付き権限を持つ 専用の ID を持つように構成できます。
費用対効果
- ゼロへのスケーリングと従量課金制: Cloud Run インスタンスは 使用されていない場合は自動的にゼロにスケーリングされるため、ホストされているワークロードは 実行する必要がある場合にのみ課金されます。これにより、「常時オン」の仮想マシンを活用するアーキテクチャと比較して、リソースの使用率が非常に高くなります。
- リクエストごとの課金: ゼロへのスケーリングに加えて、リクエストが処理された場合にのみ課金される、より詳細な課金モデルを利用できるため、費用対効果がさらに高まります。
- オンデマンドと高速起動: スケールダウンすると、Cloud Run サービスは 迅速にスケールアップできるため、デプロイされたアプリケーションの エンドユーザーが認識するレイテンシはほとんどありません。
- 自動コスト ラベル付け: Cloud Run によって報告されるすべての費用にはラベルが付けられるため、 テナントの費用帰属と追跡を自動化できます。
- 総コスト削減のコミットメント: 請求先アカウント レベルでは、 柔軟な確約利用割引を使用して、ベースラインの Cloud Run 使用量の費用を最適化できます。
テナント管理
Cloud Run はオンデマンドであるため、 複数の Google Cloud プロジェクトを使用しても費用が高くなることはありません。 プロジェクトの整理 Google Cloud で説明されているように、テナントを管理できます。
マルチテナント プラットフォームのターゲット アーキテクチャ
推奨されるアーキテクチャの概要は次のとおりです。
プロジェクトの Google Cloud 整理
組織、オフライン課金を設定し、Google のアカウント担当者 に連絡して、リセラー アカウントとして行動していることを伝えます。は、不正使用の軽減のための適切なコミュニケーション チャネルが確立されるように協力します。 Google Cloud Google Cloud
フォルダを使用してプロジェクトを整理する必要があります。特に、ファースト パーティのコードを実行するプロジェクトと、テナントの信頼できないコードを実行するプロジェクトを別のフォルダに配置することが重要です。 Google Cloud テナントのプロジェクトとリソースの作成に人が介在しないように、テナントのオンボーディングを自動化する必要があります。
Google では、テナントごとに 1 つのプロジェクトを使用することをおすすめします。 Google Cloud 同じプロジェクトで複数のテナントをホストすることもできますが、次のような追加の制限があります。
プロジェクトごとに 1 つのテナント（推奨） Google Cloud
このアーキテクチャでは、プラットフォームの各テナントが専用の Google Cloud プロジェクトでホストされます。これには多くのメリットがあります。
- シンプルなセキュリティ: Google Cloud プロジェクトは、含まれるすべての リソースの厳格な境界です。つまり、テナントが複数の Google Cloud Cloud Run サービスや Cloud Storage バケットなどの複数のリソースにアクセスする必要がある場合は、プロジェクトを安全な境界として使用できます。
- 制限が少ない:
- 特定のプロジェクトのリソース数には上限があります。たとえば、Cloud Run では、プロジェクト内のリージョンごとに 1,000 個のサービスしか作成できません。 サービス アカウントやその他の関連リソースの数にも同様の制限があります。
- プロジェクトの数自体が割り当てであり、増やすことができます。組織の数に 制限はありません。 Google Cloud 請求先アカウントあたりのプロジェクト数の上限は 100,000 ですが、Google に連絡することで増やすことができます。組織は、多くのお支払いアカウントを作成し、「アカウント グループ」（現在プライベート プレビュー）にグループ化することもできます。
- シンプルなモニタリングと管理:
- テナントごとにプロジェクトを使用すると、データ削除プロセスが簡単になります。テナントのデータを削除するには、対応するプロジェクトを削除します。
- Google Cloud モニタリングとロギングはプロジェクト間で機能し、フリート全体をモニタリングできます。
- プロジェクト レベルの割り当てを使用すると、特定のテナントの Cloud Run リソースの使用量を制限できます。これにより、制限を独自の料金階層に合わせることができます。
- カスタム組織のポリシーを使用すると、フォルダのすべてのプロジェクトに、使用可能なリージョンや最大 CPU/メモリ割り当てなどの特定の制限を適用できます。
プロジェクトの作成と Google Cloud API とリソースの初期化にはレイテンシが発生する可能性があるため、 必要に応じて テナントに割り当てる事前作成されたプロジェクトのプールを使用することをおすすめします。
プロジェクトごとに複数のテナント（非推奨） Google Cloud
同じプロジェクトで複数のテナントをホストすることもできますが、このアーキテクチャはおすすめしません。 Google Cloud
多くの Google Cloud サービスには、プロジェクトごとのリソース上限があります。たとえば、Cloud Run では、プロジェクト内のリージョンごとに 1,000 個の Cloud Run サービスという調整不可能な上限があります。そのため、プロジェクトごとに複数のテナントをホストする場合でも、プロジェクトのフリートを管理する必要があります。これにより、テナント管理の複雑さが増します。 Google Cloud セキュリティの観点から、 Google Cloud プロジェクトはセキュリティ境界として設計されています。同じプロジェクトで 2 つの 異なるテナントをホストする場合は、セキュリティに 注意する必要があります。たとえば、専用のサービス アカウントと詳細な権限を使用して行います。
多くのリージョンへのデプロイ
信頼性とスケーラビリティの両方を実現するため、テナント のデプロイを複数のGoogle Cloud リージョンに分散することをおすすめします。 各テナント アプリケーションは単一のリージョンにデプロイされますが、テナントごとに異なるリージョンを使用できます。リージョンの選択はランダムにすることも、テナントのロケーションを考慮してレイテンシを最適化することもできます。
リクエスト ルーティングとカスタム ドメイン
テナントの Cloud Run サービスをエンドユーザーに公開する場合は、独自のドメインを追加して独自のルーティング ロジックを使用します。たとえば、 サブドメインを Google Cloud テナントのサービスをホストするプロジェクトにマッピングします。
カスタム ルーティング サービスを実装できますが、ルーティング ロジックには Service Extensions を使用した グローバル外部アプリケーション ロードバランサを使用することをおすすめします。Service Extensions は、プラグイン（リクエスト処理とインラインでロジックが 実行される）またはコールアウト（ルーティング ロジックが別の Cloud Run サービスに 委任され、 Google Cloud's スケーラブルなマルチリージョン データベース（ Spannerなど）の 1 つを呼び出すことができる）として実装できます。
アプリケーション ロードバランサを使用すると、 Cloud CDN を活用してキャッシュ レイヤを追加し、 Cloud Armor を使用してプラットフォームに追加の分散型サービス拒否攻撃（DDoS）保護を追加することもできます。
評判と不正使用
信頼できないコードの実行を許可するホスティング プラットフォームは、不正使用の対象となります。
提供する評判階層ごとに異なる Cloud 請求先アカウントを使用することをおすすめします。たとえば、無料階層のテナントは、高額な顧客と同じ請求先アカウントに接続しないでください。Google は、これらの請求先アカウントを異なる評判レベルで考慮できます。
プロジェクトの整理で説明したように、請求先アカウントごとに分離するだけでなく、フォルダを使用してプロジェクトを整理する必要があります。 Google Cloud Google は、フォルダ内のすべてのリソースが設定された最大値を超えないように、フォルダレベルの割り当てを設定できます。これにより、プラットフォームの費用をより適切に管理できます。
デフォルトでは、Google は利用規約に従って不正使用のワークロードを自動的に停止します。また、不正使用の検出イベントを Cloud Logging に記録することもできます。これに基づいて対応できます。Google Cloud