このページでは、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: 制限付き権限を持つ専用 ID を持つように Cloud Run ワークロードを構成できます。
費用対効果
- ゼロへのスケーリングと従量課金制: 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 プロジェクトごとに単一テナント（推奨）
このアーキテクチャでは、プラットフォームの各テナントが専用のGoogle Cloud プロジェクトでホストされます。これには次のようなメリットがあります。
- シンプルなセキュリティ: Google Cloud プロジェクトは、含まれるすべてのリソースの厳格な境界です。つまり、テナントが複数の Cloud Run サービスや Cloud Storage バケットなどの複数のGoogle Cloud リソースにアクセスする必要がある場合は、プロジェクトを安全な境界として使用できます。
- 制限が少ない:
- 特定のプロジェクトのリソース数には上限があります。たとえば、Cloud Run では、プロジェクト内のリージョンごとに 1,000 個のサービスしか作成できません。サービス アカウントやその他の関連リソースの数にも同様の上限があります。
- プロジェクトの数は割り当て自体であり、増やすことができます。 Google Cloud 組織のこの数に制限はありません。請求先アカウントあたりのプロジェクト数の上限は 100,000 ですが、Google にお問い合わせいただければ、この上限を引き上げることができます。組織は、複数の請求先アカウントを作成して、「アカウント グループ」（現在プライベート プレビュー版）にグループ化することもできます。
- モニタリングと管理の簡素化:
- テナントごとにプロジェクトを使用すると、データ削除プロセスが容易になります。テナントのデータ削除は、対応するプロジェクトの削除に帰着します。
- Google Cloud のモニタリングとロギングはプロジェクト間で機能し、フリート全体をモニタリングできます。
- プロジェクト レベルの割り当てを使用すると、特定のテナントの Cloud Run リソース使用量に上限を設定し、上限を独自の料金プランに合わせることができます。
- カスタム組織ポリシーを使用すると、フォルダのすべてのプロジェクトに、使用可能なリージョンや CPU/メモリの最大割り当てなどの特定の制限を適用できます。
Google Cloud プロジェクトの作成と API およびリソースの初期化にはレイテンシが発生する可能性があります。Google では、必要に応じてテナントに割り当てる事前作成されたプロジェクトのプールを使用することをおすすめします。
Google Cloud プロジェクトごとに複数のテナント（非推奨）
同じ Google Cloudプロジェクトで複数のテナントをホストすることは可能ですが、Google はこのアーキテクチャを推奨していません。
多くの Google Cloud サービスには、プロジェクトごとのリソース上限があります。たとえば、Cloud Run には、プロジェクト内のリージョンごとに 1,000 個の Cloud Run サービスという調整不可能な上限があります。したがって、プロジェクトごとに複数のテナントをホストする場合でも、 Google Cloud プロジェクトのフリートを管理する必要があり、テナント管理の複雑さが増します。セキュリティの観点から、Google Cloud プロジェクトはセキュリティ境界として設計されています。同じプロジェクトで 2 つの異なるテナントをホストする場合は、セキュリティに関してより慎重になる必要があります。たとえば、専用のサービス アカウントときめ細かい権限を確保します。
リクエストのルーティングとカスタム ドメイン
テナントの Cloud Run サービスをエンドユーザーに公開する場合は、独自のドメインを追加して独自のルーティング ロジックを使用する必要があります。たとえば、サブドメインをテナントのサービスをホストする Google Cloud プロジェクトにマッピングします。
カスタム ルーティング サービスを実装できますが、ルーティング ロジックには Service Extensions を使用したグローバル外部アプリケーション ロードバランサを使用することをおすすめします。Service Extensions は、プラグイン（ロジックがリクエスト処理とともにインラインで実行される）またはコールアウト（ルーティング ロジックが別の Cloud Run サービスに委任され、Google Cloudのスケーラブルなマルチリージョン データベース（Spanner など）のいずれかを呼び出すことができる）として実装できます。
アプリケーション ロードバランサを使用すると、Cloud CDN を活用してキャッシュ保存レイヤを追加し、Cloud Armor を使用してプラットフォームに分散型サービス拒否攻撃（DDoS）に対する追加の保護を追加することもできます。
評判と不正使用
信頼できないコードの実行を許可するホスティング プラットフォームは、不正使用の対象となります。
提供する評判レベルごとに異なる Cloud 請求先アカウントを使用することをおすすめします。たとえば、無料枠のテナントは、高額な顧客と同じ請求先アカウントに関連付けないでください。Google は、これらの請求先アカウントを異なる評判レベルで考慮できます。
Google Cloud プロジェクトの整理で説明したように、請求先アカウントごとに分離するだけでなく、フォルダを使用してプロジェクトを整理する必要があります。Google は、フォルダ内のすべてのリソースが設定された上限を超えないように、フォルダレベルの割り当てを設定するお手伝いをします。これにより、プラットフォームの費用をより適切に管理できます。
デフォルトでは、Google は Google Cloud 利用規約に従って不正使用のワークロードを自動的に削除します。また、Google は不正使用の検出イベントを Cloud Logging に記録することもできます。このイベントに基づいて、ユーザーが対応することも可能です。