マルチテナントと Azure Resource Manager

Azure Resource Manager は、Azure 用のコア リソース管理サービスです。 Azure 内の各リソースの作成、管理、および最終的な削除は、Resource Manager を使用して行われます。 マルチテナント ソリューションを構築する場合、Resource Manager を頻繁に使用して、テナントごとにリソースを動的にプロビジョニングします。 このページでは、マルチテナント ソリューションに関連する Resource Manager の機能の一部について説明します。 また、Resource Manager の使用を計画している場合に役立つガイダンスへのリンクも提供しています。

マルチテナント機能をサポートする Resource Manager の機能

コードとしてのインフラストラクチャ

Resource Manager は、コードとしてのインフラストラクチャ (IaC とも呼ばれる) をサポートするツールを提供します。 クラウド内のすべてのソリューションについて、コードとしてのインフラストラクチャを定義することをお勧めしますが、マルチテナント ソリューションを使用する場合はその定義が特に重要になります。 マルチテナント ソリューションでは、新しいテナントをオンボードするときに、デプロイをスケーリングし、新しいリソースをプロビジョニングすることがしばしば必要になります。 リソースを手動で作成または構成する場合は、プロセスに余分のリスクが入り込み、時間も余計に必要になります。 手動によるアプローチでは、全体的なデプロイ プロセスの信頼性が低下します。

デプロイ パイプラインからコードとしてのインフラストラクチャをデプロイする場合は、Bicep を使用することをお勧めします。これは、宣言型の方法で Azure リソースをデプロイおよび管理するために特別に設計された言語です。 また、JSON Azure Resource Manager テンプレート (ARM テンプレート)、Terraform、基になる Resource Manager API にアクセスする他のサードパーティ製品を使用することもできます。

デプロイ スタックの場合、リソース グループ間またはサブスクリプション間で分散されている場合でも、リソースのセットを 1 つのユニットとして管理できます。 デプロイ スタックは、異なる場所に複数のテナント固有のリソースをプロビジョニングし、そのライフサイクルを 1 つの論理ユニットとして管理する必要がある場合に役立ちます。

テンプレート スペックは、適切にパラメーター化された単一のテンプレートから新しいリソース、デプロイ スタンプ、または環境をプロビジョニングする場合に便利です。 テンプレート スペックを使用すると、テナント固有のインフラストラクチャをデプロイするために使用するテンプレートの中央リポジトリを作成できます。 これらのテンプレートは、Azure 自体の内部に格納および管理されます。テンプレート スペックは、それらからデプロイする必要がある場合は常に再利用できます。

一部のソリューションでは、リソースを動的にプロビジョニングまたは構成したり、テンプレートのデプロイを開始したりするためのカスタム コードを記述することもできます。 Azure SDK は、Azure 環境を管理するために独自のコードから使用できます。 Resource Manager へのアプリケーションの認証管理に関する適切なプラクティスに従い、資格情報の格納と管理を回避するためにマネージド ID を使用してしてください。

ロールベースのアクセス制御

ロールベースのアクセス制御 (Azure RBAC) を使用すると、Azure リソースへのアクセスを細かく管理できます。 マルチテナント ソリューションでは、特定の Azure RBAC ポリシーを適用する必要があるリソースがあるかどうかを考慮します。 たとえば、特に機密性の高いデータを持つテナントがおり、組織内の他の人々を含めずに特定の個人にアクセス権を付与するために RBAC を適用する必要がある場合があります。 同様に、テナントは監査中などに、Azure リソースに対する直接のアクセスを要求する場合があります。 これを許可する場合は、細かくスコープ指定された RBAC アクセス許可を使用すると、別のテナントのデータへのアクセスを提供せずに、あるテナントのデータへのアクセス権を付与できます。

タグ

タグを使用すると、Azure リソース、リソース グループ、サブスクリプションにカスタム メタデータを追加できます。 Azure コストの追跡と割り当てを簡単にして、リソース管理を簡略化するため、テナント固有のリソースにテナントの識別子をタグ付けすることをご検討ください。

Azure リソース クォータ

Resource Manager は、制限とクォータを適用する Azure のポイントの 1 つです。 これらのクォータは、設計プロセス全体を通して考慮することが重要です。 すべての Azure リソースには、遵守する必要がある制限があります。これらの制限には、一定の時間内に Resource Manager に対して行える要求数が含まれます。 この制限を超えると、Resource Manager その要求をスロットルします。

自動デプロイを実行するマルチテナント ソリューションを構築すると、他の顧客よりも速くこれらの制限に達する可能性があります。 同様に、大量のインフラストラクチャをプロビジョニングするマルチテナント ソリューションもこの制限をトリガーする可能性があります。

各 Azure サービスは、リソース プロバイダーによって管理されます。リソース プロバイダーによって独自の制限が定義される場合もあります。 たとえば、Azure Compute リソース プロバイダーは仮想マシンのプロビジョニングを管理し、短期間に行える要求の数に対する制限を定義します。 その他のリソース プロバイダーの制限の一部については、「リソース プロバイダーの制限」に説明されています。

Resource Manager またはリソース プロバイダーによって定義された制限を超えるリスクがある場合は、次のような軽減策を検討してください。

• 複数の Azure サブスクリプション間にワークロードをシャード化する。
• サブスクリプション内の複数のリソース グループを使用する。
• さまざまな Microsoft Entra プリンシパルから要求を送信します。
• 追加のクォータ割り当てを要求する。 一般に、クォータ割り当て要求はサポート ケースを開いて送信します。ただし、一部のサービスでは、仮想マシンの予約インスタンスなど、これらの要求のための API が提供されています。

選択する軽減策は、発生した特定の制限に適している必要があります。

分離モデル

一部のマルチテナント ソリューションでは、テナントごとに個別または専用のリソースをデプロイする場合があります。 Resource Manager には、要件およびリソースを分離する理由に応じて、リソースを分離するために使用できるいくつかのモデルが用意されています。 Azure リソースを分離する方法のガイダンスについては、「マルチテナント ソリューションでの Azure リソースの編成」を参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

マルチテナント機能のデプロイおよび構成の方法を確認します。