このページでは、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 インスタンスは 使用されていない場合は自動的にゼロにスケーリングされるため、ホストされているワークロードは 実行する必要がある場合にのみ課金されます。これにより、「常時オン」の仮想マシンを活用するアーキテクチャと比較して、リソースの使用率が非常に高くなります。