Azure Container Apps を使用して、サーバーレス プラットフォームでマイクロサービスとコンテナー化されたアプリケーションを実行できます。 この記事では、マルチテナント ソリューションに役立つ Container Apps のいくつかの機能について説明します。 また、計画フェーズ中に役立つリソースも提供します。
分離モデル
Container Apps を使用するマルチテナント システムを使用する場合は、必要な分離レベルを決定する必要があります。 Container Apps では、マルチテナントのさまざまなモデルがサポートされています。
共有環境を使用して 、信頼できるマルチテナント を実装できます。 たとえば、このモデルは、テナントがすべて組織内から存在する場合に適している場合があります。
テナントごとに個別の環境をデプロイすることで 、敵対的なマルチテナント を実装できます。 たとえば、このモデルは、テナントが実行するコードを信頼しない場合に適している可能性があります。
次の表は、Container Apps の主なテナント分離モデルの違いをまとめたものです。 モデルについては、この記事の後半で説明します。
| 考慮事項 | テナントごとに 1 つの環境 | テナント固有のコンテナー アプリ | 共有コンテナー アプリ |
|---|---|---|---|
| データの分離 | 高 | 低 | 低 |
| パフォーマンスの分離 | 高 | 中、ネットワーク分離なし | 低 |
| 配置の複雑性 | ミディアム | 低から中程度 | 低 |
| 操作の複雑さ | ミディアム | 低 | 低 |
| リソース コスト | 高 | 低 | 低 |
| サンプル シナリオ | セキュリティとコンプライアンスのために、分離された環境で敵対的なマルチテナント ワークロードを実行します。 | 信頼できるマルチテナント アプリケーションのコスト、ネットワーク リソース、操作を最適化します。 | ビジネス ロジック レベルでマルチテナント ソリューションを実装します。 |
共有コンテナー アプリ
すべてのテナントが使用する 1 つの Container Apps 環境に共有コンテナー アプリをデプロイすることを検討してください。
通常、この方法はコスト効率が高く、管理するリソースが少ないため、運用上のオーバーヘッドが最小限に抑えられます。
ただし、この分離モデルを使用する場合は、アプリケーション コードがマルチテナント対応である必要があります。 この分離モデルでは、ネットワーク、コンピューティング、監視、またはデータ レベルでの分離は保証されません。 アプリケーション コードでテナントの分離を処理する必要があります。 このモデルは、実行中のコードを信頼しない、敵対的なマルチテナント ワークロードには適していません。
このモデルは、 ノイズの多い近隣の懸念の対象となる可能性があります。つまり、あるテナントのワークロードが、別のテナントのワークロードのパフォーマンスに影響を与える可能性があります。 この問題を軽減するために専用のスループットを提供する必要がある場合は、共有コンテナー アプリ モデルが適していない可能性があります。
注
デプロイ スタンプ パターンは、テナントが異なる価格モデルにある場合に便利です。 たとえば、テナントは、価格レベルに応じて、共有または専用の Container Apps 環境に割り当てられる場合があります。 このデプロイ戦略を使用すると、リージョンごとに 1 つのサブスクリプションに対する Container Apps の制限を超え、テナントの数が増えるにつれて直線的にスケーリングできます。
テナント固有のコンテナー アプリ
考えられるもう 1 つの方法は、テナント固有のコンテナー アプリを共有環境内にデプロイしてテナントを分離することです。
この分離モデルにより、テナント間の論理的な分離が保証される一方で、次のような利点があります。
コスト効率。 Container Apps 環境、仮想ネットワーク、Log Analytics ワークスペースなどの他のアタッチされたリソースを共有することで、通常、テナントごとの全体的なコストと管理の複雑さを軽減できます。
アップグレードとデプロイの分離。 各テナントのアプリケーション バイナリは、同じ環境内の他のコンテナー アプリのバイナリとは別にデプロイおよびアップグレードできます。 この方法は、異なる時間に異なるテナントを特定のバージョンのコードにアップグレードする必要がある場合に役立ちます。
リソースの分離。 環境内の各コンテナー アプリには、独自の CPU リソースとメモリ リソースが割り当てられます。 特定のテナントでより多くのリソースが必要な場合は、そのテナントの特定のコンテナー アプリにより多くの CPU とメモリを割り当てることができます。 コンテナー アプリの CPU とメモリの割り当ての合計には制限 があることに注意してください。
ただし、この方法では、テナント間のハードウェアまたはネットワークの分離は提供されません。 1 つの環境内のすべてのコンテナー アプリは、同じ仮想ネットワークを共有します。 アプリにデプロイされたワークロードが共有リソースを誤用しないことを信頼できる必要があります。
Container Apps には、モジュール設計を使用して 機能をコンポーネントとして提供する Dapr のサポートが組み込まれています。 Container Apps では、Dapr コンポーネントは環境レベルのリソースです。 複数のテナント間で 1 つの環境を共有する場合は、分離を保証し、データ漏洩を防ぐために、Dapr コンポーネントが適切なテナント固有のコンテナー アプリに適切にスコープ設定されていることを確認します。
注
リビジョンを使用して、異なるテナントに対して異なるバージョンのアプリを作成しないでください。 リビジョンによってリソースは分離されません。 これらは、更新プログラムのロールアウト中に複数のバージョンのアプリを実行する必要があるデプロイ シナリオ向けに設計されています。 このアプローチには、ブルーグリーンデプロイや A/B テストなどの戦略が含まれます。
テナントごとに 1 つの環境
テナントごとに 1 つの Container Apps 環境をデプロイすることを検討してください。 Container 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 と Microsoft Entra External ID を統合して、パートナー ID プロバイダーを介したユーザー認証を行うこともできます。
詳細については、次のリソースを参照してください。
注
Container Apps の認証と承認の機能は、Azure App Service の機能と似ています。 ただし、いくつかの違いがあります。 詳細については、 組み込み認証の使用に関する考慮事項を参照してください。
管理されたアイデンティティー
Microsoft Entra ID のマネージド ID を使用して、コンテナー アプリが Microsoft Entra ID で認証される他のリソースにアクセスできるようにします。 マネージド ID を使用する場合、コンテナー アプリはサービス間通信の資格情報を管理する必要はありません。 ロールベースのアクセス制御のために、コンテナー アプリの ID に特定のアクセス許可を付与できます。
マネージド ID を使用する場合は、分離モデルの選択に留意してください。 たとえば、すべてのテナント間でコンテナー アプリを共有し、テナント固有のデータベースをデプロイするとします。 1 つのテナントのアプリケーションが別のテナントのデータベースにアクセスできないようにする必要があります。
詳細については、「 Container Apps のマネージド ID」を参照してください。
専用コンピューティングのワークロード プロファイル
Container Apps には、テナントの専用リソースを予約できる専用プランが用意されています。 このプランは、テナントで使用できるリソースを制限する場合に役立ちます。これは、複数のコンテナー アプリ間で共有できます。 また、より高いメモリ対 CPU 比や GPU 可用性など、特定のテナント要件を満たすのに役立ちます。
詳細については、「 Container Apps のワークロード プロファイル」を参照してください。
ルールベースのルーティング
ルールベースのルーティングを使用すると、受信トラフィックを特定のコンテナー アプリまたはコンテナー アプリのリビジョンに転送できます。 要求は HTTP 要求パスに基づいてルーティングでき、URL 内のパスを書き換えることができます。 この機能は、要求のパスを使用するテナント固有のコンテナー アプリまたはリビジョンに 要求をマップ する必要があるマルチテナント システムに役立ちます。 通常、この機能は テナント固有のコンテナー アプリ 分離モデルで使用されます。
詳細については、「 Container Apps でルールベースのルーティングを使用する」を参照してください。
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要な著者:
- ダニエル・ラーセン |プリンシパル カスタマー エンジニア、FastTrack for Azure
- Will Velida | カスタマー エンジニア 2、FastTrack for Azure
その他の共同作成者:
- ジョン・ダウンズ |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
- チャド・キットテル |プリンシパル ソフトウェア エンジニア、Azure パターン & プラクティス
- 徐煥流 |Azure 用 FastTrack シニア サービス エンジニア
- アルティ・ムルガン |CS Tech Strategy App Innovation シニア プログラム マネージャー
- ケンドール・ローデン |Container Apps のシニア プログラム マネージャー
- Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
- ダニエル・スコット=レインズフォード |パートナー ソリューション アーキテクト、データおよび AI
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
関連リソース
- マルチテナント ソリューション のアーキテクトおよび開発者向けの
リソース - Azure でマルチテナント ソリューションを設計する
- Azure でマルチテナント ソリューションを設計および構築するためのチェックリスト