マルチテナント ソリューションでの Container Apps の使用に関する考慮事項
Azure Container Apps を使用すると、サーバーレス プラットフォームでマイクロサービスとコンテナー化されたアプリケーションを実行できます。 この記事では、マルチテナント ソリューションに役立つ Container Apps のいくつかの機能について説明します。 また、計画フェーズ中に役立つガイダンスへのリンクも提供します。
分離モデル
Container Apps を使用するマルチテナント システムを操作する場合、必要な分離レベルを判断することが求められます。 Container Apps では、さまざまなマルチテナント モデルをサポートしています。
- 共有環境を使用して、"信頼できるマルチテナント" を実装できます。 たとえば、テナントがすべて組織内からのものである場合は、このモデルが適していると考えられます。
- テナントごとに個別の環境をデプロイして、"敵対的なマルチテナント" を実装できます。 たとえば、テナントによって実行されているコードを信頼しない場合は、このモデルが適していると考えられます。
次の表に、Container Apps の主なテナント分離モデル間の相違点を要約します。 モデルの説明は、この記事の後半にあります。
| 考慮事項 | テナントごとに 1 つの環境 | テナント固有のコンテナー アプリ | 共有コンテナー アプリ |
|---|---|---|---|
| データの分離 | 高 | 低 | 低 |
| パフォーマンスの分離 | 高 | 中。 ネットワークの分離なし。 | 低 |
| 配置の複雑性 | Medium | 低から中 | 低 |
| 操作の複雑さ | Medium | 低 | 低 |
| リソース コスト | 高 | 低 | 低 |
| シナリオ例 | セキュリティとコンプライアンスを確保するために、分離された環境で敵対的なマルチテナント ワークロードを実行する | 信頼できるマルチテナント アプリケーションのコスト、ネットワーク リソース、運用を最適化する | ビジネス ロジック レベルでマルチテナント ソリューションを実装する |
共有コンテナー アプリ
すべてのテナントで使用される 1 つの Container Apps 環境に共有コンテナー アプリをデプロイすることを検討できます。
この方法は一般にコスト効果が高く、管理するリソースが少なくなるため、必要な運用オーバーヘッドが最小になります。
ただし、この分離モデルを使用する場合、アプリケーション コードがマルチテナント対応であることが求められます。 この分離モデルの場合、ネットワーク、コンピューティング、監視、またはデータのレベルでの分離は保証されません。 テナントの分離はアプリケーション コードで行う必要があります。 このモデルは、実行されているコードを信頼しない敵対的なマルチテナント ワークロードには適していません。
また、このモデルは、うるさい隣人の問題 (あるテナントのワークロードが別のテナントのワークロードのパフォーマンスに影響を与えることがある) の対象になる可能性があります。 この問題を軽減するために専用のスループットを用意する必要がある場合は、共有コンテナー アプリ モデルは適していないと考えられます。
Note
デプロイ スタンプ パターンは、テナントがそれぞれ異なるコスト モデルにある場合に役立ちます。 たとえば、テナントは、その価格レベルに応じて、共有または専用の Container Apps 環境に割り当てられます。 このデプロイ戦略を使用すると、リージョンあたり 1 つのサブスクリプションの場合の Container Apps の制限を超えることができ、テナントの数が増えるにつれて直線的にスケーリングできます。
テナント固有のコンテナー アプリ
検討できるもう 1 つの方法は、共有環境内でテナント固有のコンテナー アプリをデプロイしてテナントを分離することです。
この分離モデルでは、各テナント間を論理的に分離します。 これには以下のような利点があります。
- 費用効率。 Container Apps 環境、仮想ネットワーク、接続されたその他のリソース (Log Analytics ワークスペースなど) を共有することで、一般に、テナントごとの全体的なコストと管理の複雑さを軽減できます。
- アップグレードとデプロイの分離。 各テナントのアプリケーション バイナリを、同じ環境の他のコンテナー アプリのものとは別にデプロイおよびアップグレードできます。 この方法は、異なるテナントを異なるタイミングでコードの特定のバージョンにアップグレードする必要がある場合に役立ちます。
- リソースの分離。 環境内の各コンテナー アプリには、独自の CPU とメモリのリソースが割り当てられます。 特定のテナントでより多くのリソースが必要になった場合、そのテナントの特定のコンテナー アプリに追加の CPU とメモリを割り当てることができます。 コンテナー アプリの CPU とメモリの割り当ての合計には制限があるので注意してください。
ただし、この方法では、テナント間のハードウェアまたはネットワークの分離は行われません。 1 つの環境内のすべてのコンテナー アプリで同じ仮想ネットワークが共有されます。 アプリにデプロイされたワークロードで共有リソースが誤った使われ方をしないようにすることが必要です。
また、1 つの環境にデプロイできるコンテナー アプリの数にも制限があります。 この分離モデルを実装する前に、見込まれるテナント数の増加を考慮してください。
Container Apps には Dapr のサポートが組み込まれています。これは、モジュール設計を使用して機能をコンポーネントとして提供します。 Container Apps では、Dapr コンポーネントは環境レベルのリソースです。 複数のテナント間で 1 つの環境を共有する場合は、Dapr コンポーネントを正しいテナント固有のコンテナー アプリに適切にスコープ設定して、確実に分離し、データ漏えいのリスクを回避します。
Note
リビジョンを使用して、テナントごとに異なるバージョンのアプリを作成しないでください。 リビジョンによってリソースは分離されません。 これらは、ブルーグリーン デプロイや A/B テストのような、更新プログラムのロールアウト プロセスの一環として複数のバージョンのアプリを実行する必要があるデプロイ シナリオ向けに設計されています。
テナントごとに 1 つの環境
テナントごとに 1 つの Container Apps 環境をデプロイすることを検討できます。 Containers Apps 環境は、コンテナー アプリのグループを囲む分離境界です。 環境によって、データ プレーン上でコンピューティングとネットワークの分離が実現します。 各環境は独自の仮想ネットワークにデプロイされ、それが環境内のすべてのアプリで共有されます。 環境ごとに、独自の Dapr と監視の構成があります。
この方法では、各テナントのデータとトラフィックが特定の環境に分離されるため、最強レベルのデータとパフォーマンスの分離が実現します。 また、このモデルを使用する場合、アプリケーションはマルチテナント対応でなくてもかまいません。 この方法を使用すると、環境内のコンテナー アプリにリソースをどのように割り当てるかをより細かく制御できます。 割り当ては、テナントの要件に基づいて決定できます。 たとえば、一部のテナントでは、他より多くの CPU とメモリのリソースが必要な場合があるため、それらのテナントのアプリケーションにより多くのリソースを提供でき、一方で、テナント固有の環境で実現する分離の恩恵を受けることができます。
ただし、リージョンごとにサブスクリプション内にデプロイできる環境の数の制限は低くなっています。 状況によっては、Azure サポート チケットを作成してそれらのクォータを増やすことができます。
この分離モデルを実装する前に、見込まれるテナント数の増加を把握しておいてください。 この方法ではデプロイと管理が必要なリソースが増えるため、多くの場合、総保有コストが高くなり、デプロイと運用の複雑さのレベルが高くなることに注意してください。
マルチテナントをサポートする Container Apps の機能
カスタム ドメイン名
Container Apps を使用すると、ワイルドカード DNS の使用と、独自のワイルドカード TLS 証明書の追加が可能になります。 テナント固有のサブドメインを使用しているときに、ワイルドカード DNS と TLS 証明書を使用すると、多数のテナントに簡単にソリューションをスケーリングできます。このとき、それぞれの新しいテナントを手動で再構成する必要はありません。
Container Apps では、環境レベルで証明書を管理します。 カスタム ドメインをバインドするには、事前にコンテナー アプリに対してイングレスも有効にする必要があります。
認証と承認を要求する
Container Apps では、アプリの代理として認証トークンを検証できます。 要求にトークンが含まれていない、トークンが無効である、または要求が承認されない場合は、要求をブロックするか、またはユーザーがサインインできるようにそれを ID プロバイダーにリダイレクトするよう、Container Apps を構成できます。
テナントが ID プロバイダーとして Microsoft Entra ID を使って場合は、/common エンドポイントを使ってユーザー トークンを検証するように Container Apps を構成できます。 こうすると、ユーザーの Microsoft Entra テナントとは関係なく、それらのトークンが検証され、承認されます。
Container Apps を Azure Active Directory B2C と統合して、パートナー ID プロバイダーを介したユーザー認証を行うこともできます。
詳細については、次のリソースを参照してください。
Note
Container Apps の認証と承認の機能は、Azure App Service のものと似ています。 ただし、いくつかの違いがあります。 詳細については、「組み込みの認証の使用に関する考慮事項」を参照してください。
マネージド ID
Microsoft Entra ID のマネージド ID を使うと、コンテナー アプリから、Microsoft Entra ID によって認証された他のリソースにアクセスできます。 マネージド ID を使用する場合、コンテナー アプリでサービス間通信の資格情報を管理する必要はありません。 ロールベースのアクセス制御で、コンテナー アプリの ID に特定のアクセス許可を付与できます。
マネージド ID を使用する場合は、選択した分離モデルを念頭に置いてください。 たとえば、すべてのテナント間でコンテナー アプリを共有し、テナント固有のデータベースをデプロイするとします。 1 つのテナントのアプリケーションから別のテナントのデータベースにアクセスできないようにすることが必要です。
詳細については、「Azure Container Apps のマネージド ID」を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Daniel Larsen | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Will Velida | カスタマー エンジニア 2、FastTrack for Azure
その他の共同作成者:
- John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Chad Kittel | プリンシパル ソフトウェア エンジニア、Microsoft
- Xuhong Liu | シニア サービス エンジニア、FastTrack for Azure
- Aarthi Murugan | シニア プログラム マネージャー、CS Tech Strategy App Innovation
- Kendall Roden | シニア プログラム マネージャー、Azure Container Apps
- Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
関連リソース
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示