このページでは、Cloud Run で信頼できないコードをホストするマルチテナント アーキテクチャを作成するためのベスト プラクティスについて説明します。 Google Cloud のお客様の場合、「テナント」は自社のお客様の 1 つとして定義され、「信頼できないコード」は、これらのテナントから提供され、プラットフォームで実行されるコードです。
ユースケース
このようなアーキテクチャのユースケースには、次のようなものがあります。
- App Hosting プラットフォーム: 顧客がコードをデプロイするプラットフォームを提供します。たとえば、ウェブ ホスティング プラットフォーム（お客様がウェブサーバーを提供） や Functions-as-a-Service プラットフォーム（お客様が関数を提供）などです。
- エージェント ホスティング プラットフォーム: 顧客が SDK を使用して AI エージェントを構築し、プラットフォームがバックグラウンドで実行します。
- ファインチューニングされたモデル プラットフォーム: 顧客ごとに AI モデルをカスタマイズする機能を提供します。 プラットフォームは、GPU を活用してオンデマンドで実行します。
- ユーザー定義関数: ソフトウェアを使用すると、お客様はコードを使用してカスタム ロジックを定義できます。たとえば、分析エンジンを提供し、顧客がカスタム関数を作成できるようにする場合や、API Gateway を提供し、顧客が独自のカスタム ロジックに基づいてリクエストをフィルタリングまたは変更できるようにする場合などです。
- 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 Cloud 組織とオフライン請求を設定し、アカウント チームに連絡して、販売パートナー アカウントとして機能していることを伝える必要があります。Google Cloud は、不正行為の軽減のために適切な通信チャネルが設定されていることを確認するために、お客様と協力することがあります。
フォルダを使用して Google Cloud プロジェクトを整理する必要があります。特に、ファーストパーティ コードを実行するプロジェクトと、テナントの信頼できないコードを実行するプロジェクトを、異なるフォルダに配置することが重要です。テナントのプロジェクトとリソースの作成に人間参加型が必要ないように、テナントのオンボーディングを自動化する必要があります。
Google では、テナントごとに 1 つの Google Cloud プロジェクトを使用することをおすすめします。同じプロジェクトで複数のテナントをホストすることもできますが、これには追加の制限があります。
Google Cloud プロジェクトごとに 1 つのテナント（推奨）
このアーキテクチャでは、プラットフォームの各テナントが専用のGoogle Cloud プロジェクトでホストされます。これには、次のような多くのメリットがあります。
- セキュリティの簡素化: Google Cloud プロジェクトは、含まれるすべてのリソースの厳格な境界です。つまり、テナントが複数の Cloud Run サービス、Cloud Storage バケットなどの複数のGoogle Cloud リソースにアクセスする必要がある場合は、プロジェクトを安全な境界として使用できます。
- 制限が少ない:
- プロジェクト内のリソースの数には上限があります。たとえば、Cloud Run では、プロジェクトのリージョンごとに 1,000 個のサービスしか作成できません。サービス アカウントの数やその他の関連リソースにも同様の上限があります。
- プロジェクトの数自体が割り当てであり、増やすことができます。 Google Cloud 組織では、この数に上限はありません。請求先アカウントあたりのプロジェクト数には 100,000 というソフトリミットがありますが、Google に問い合わせることで、この数を増やすことができます。組織は、複数の請求先アカウントを作成して「アカウント グループ」（現在、限定公開プレビュー中）にグループ化することもできます。
- モニタリングと管理の簡素化:
- テナントごとにプロジェクトを使用すると、データ削除プロセスが簡単になります。テナントのデータを削除すると、それぞれのプロジェクトが削除されます。
- Google Cloud Monitoring と Logging はプロジェクト間で機能し、フリート全体をモニタリングできます。
- プロジェクト レベルの割り当てを使用すると、特定のテナントの Cloud Run リソース使用量に上限を設定できます。これにより、上限を独自の料金階層に合わせることができます。
- カスタムの組織ポリシーを使用すると、利用可能なリージョンや CPU/メモリの最大割り当てなど、フォルダの特定の制限をすべてのプロジェクトに適用できます。
Google Cloud プロジェクトの作成と API やリソースの初期化にはレイテンシが発生する可能性があるため、事前に作成したプロジェクトのプールを使用し、必要に応じてテナントに割り当てることをおすすめします。
Google Cloud プロジェクトごとに複数のテナント（非推奨）
同じ Google Cloudプロジェクトで複数のテナントをホストすることもできますが、Google はこのアーキテクチャをおすすめしません。
多くの 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 サービスに委任され、Spanner などのGoogle Cloudのスケーラブルなマルチリージョン データベースのいずれかを呼び出すことができる）として実装できます。
アプリケーション ロードバランサを使用すると、Cloud CDN を活用してキャッシュ レイヤを追加し、Cloud Armor を使用してプラットフォームに分散型サービス拒否（DDoS）攻撃に対する保護を追加することもできます。
評価と不正行為
信頼できないコードの実行を許可するホスティング プラットフォームは、不正使用の対象となります。
提供するレピュテーション ティアごとに異なる Cloud 請求先アカウントを使用することをおすすめします。たとえば、無料枠のテナントを、高額な料金を支払っているお客様と同じ請求先アカウントに関連付けるべきではありません。Google は、これらの請求先アカウントを異なる評価レベルで考慮できます。
Google Cloud プロジェクトの整理で説明されているように、請求先アカウントごとに分けるだけでなく、フォルダを使用してプロジェクトを整理する必要があります。Google では、フォルダレベルの割り当てを設定して、フォルダ内のすべてのリソースが設定された最大値を超えないようにすることで、プラットフォームの費用をより適切に管理できます。
デフォルトでは、Google は Google Cloud 利用規約に従って不正なワークロードを自動的に削除します。また、Google は不正行為検出イベントを Cloud Logging に記録することもできます。これにより、ユーザーは対応できます。