Azure には、リソースを編成するための多くの選択肢があります。 マルチテナント ソリューションでは、リソースの編成戦略を計画する際に、いくつかのトレードオフを検討する必要があります。 この記事では、Azure リソースの編成に関連する 2 つの主要な要素について説明します。テナントの分離と複数のリソースにまたがるスケールアウトです。 また、Azure リソースの制限とクォータへの対応方法と、これらの制限を超えてソリューションをスケーリングする方法についても説明します。
主な考慮事項と要件
テナントの分離の要件
Azure でマルチテナント ソリューションをデプロイする場合、リソースを各テナントの専用にするか、複数のテナント間でリソースを共有するかを決める必要があります。 このシリーズのマルチテナントの手法とサービス固有のガイダンスに関するセクションを通じて、多くのカテゴリのリソースに関連する選択肢とトレードオフについて説明します。 一般的に、"テナントの分離" にはさまざまなオプションがあります。 分離モデルを決定する方法については、「マルチテナント ソリューションに対して考慮すべきテナント モデル」を参照してください。
スケール
ほとんどの Azure リソースと、リソース グループやサブスクリプションには、スケーリング能力に影響を与える制限があります。 計画した数のテナントや計画したシステム負荷の要件を満たすには、"スケールアウト" や "ビン パッキング" を検討する必要があるかもしれません。
多くのテナントや高い負荷が必要になることはないという確信がある場合は、過剰なスケールアウトの計画を立てる必要はありません。 しかし、ソリューションを拡大していく計画があるなら、スケールアウトの計画を慎重に検討する必要があります。 この記事のガイダンスにしたがって、スケーリングできるように設計してください。
自動化されたデプロイ プロセスを使用していて、リソースをまたいでスケーリングする必要がある場合、複数のリソース インスタンス間でテナントのデプロイと割り当てを行う方法を決めます。 たとえば、特定のリソースに割り当て可能なテナントの数に到達しそうであることを、どのように検出できるでしょうか? 新しいリソースが必要になったときに、"ギリギリで" それらをデプロイしますか? それとも、必要になったときに使用できるように、リソースのプールを "前もって" デプロイしますか?
ヒント
設計と開発の初期段階では、自動化されたスケールアウト プロセスを選択しないことにするかもしれません。 それでも、拡大に応じてスケーリングするのに必要なプロセスを検討し、明確に文書化する必要があります。
コードと構成に推測を含めないようにすることも大切です。スケーリング能力が制限される恐れがあるからです。 たとえば、複数のストレージ アカウントにスケール アウトする必要があるかもしれません。 アプリケーション層が、すべてのテナントに対して単一のストレージ アカウントにのみ接続すると想定していないことを確認する必要があります。
考慮すべきアプローチとパターン
テナントの分離
Azure リソースは、階層を利用してデプロイおよび管理されます。 ほとんどの "リソース" は "リソース グループ" にデプロイされ、リソース グループは "サブスクリプション" に含まれます。 "管理グループ" は、サブスクリプションを論理的にグループ化します。 これらの階層レイヤーはすべて Microsoft Entra テナントに関連付けられています。
各テナントのリソースをデプロイする方法を決める際に、階層の異なるレベルで分離を行うことができます。 それぞれの選択肢はマルチテナント ソリューションの特定の種類で利用可能で、それぞれに利点とトレードオフがあります。 また、アプローチを組み合わせることも一般的で、ソリューションの異なるコンポーネントに対して別の分離モデルを使用することができます。
共有リソース内での分離
Azure リソースを複数のテナント間で共有して、すべてのワークロードを単一のインスタンスで実行することを選ぶこともできます。 使用している Azure サービスのサービス固有のガイダンスを参照して、特有の重要な検討事項や選択肢について確認してください。
リソースの単一インスタンスを実行する場合、スケーリングするにつれて到達する可能性がある、サービス制限、サブスクリプション制限、クォータを検討する必要があります。 たとえば、Azure Kubernetes Service (AKS) クラスターでサポートされているノードの数には最大値があり、ストレージ アカウントでサポートされている 1 秒あたりのトランザクション数には上限があります。 これらの制限に近づいたときに、どのように複数の共有リソースにスケーリングするかを検討してください。
またアプリケーション コードでは、マルチテナントであることを確実に認識して、特定のテナントのデータへのアクセスを制限するようにすることも必要です。
共有リソースのアプローチの例として、Contoso が、Web アプリケーション、データベース、ストレージ アカウントを含む、マルチテナントの SaaS アプリケーションを構築している状況を考えましょう。 共有リソースをデプロイして、これらのリソースを利用してすべての顧客にサービスを提供することにします。 次の図では、一組のリソースがすべての顧客によって共有されています。
リソース グループ内の別個のリソース
各テナントに対して専用のリソースをデプロイすることもできます。 ソリューション全体のコピーを単一のテナントにデプロイすることもできますし、 一部のコンポーネントをテナント間で共有し、他のコンポーネントを特定のテナント専用にデプロイすることもできます。
リソース グループを使用して、同じライフサイクルでリソースを管理することをお勧めします。 一部のマルチテナント システムでは、複数のテナントのリソースを 1 つのリソース グループまたは 1 セットのリソース グループにデプロイするのが合理的です。
テナント固有のリソースのデプロイを、デプロイ パイプラインとアプリケーションのどちらで開始するかを含めて、これらのリソースをデプロイして管理する方法を検討することが重要です。 また、特定のリソースが特定のテナントに関連していることをはっきりと識別する方法を決める必要もあります。 明確な名前付け規則の方策、リソース タグ、テナント カタログ データベースを使用することも検討してください。
複数のテナント間で共有するリソースと、個々のテナントにデプロイするリソースに対して、別個のリソース グループを使用することをお勧めします。 ただし、一部のリソースに関して、Azure にはリソース グループにデプロイできる単一の種類のリソースの数に制限があります。 この制限により、拡大するにつれて複数のリソース グループをまたいでスケーリングする必要が生じる場合があります。
Contoso には、Adventure Works、Fabrikam、Tailwind という 3 社の顧客がいるとします。 Contoso は、Web アプリケーションとストレージ アカウントを 3 社間で共有して、各テナントに対して個々のデータベースをデプロイすることに決めます。 次の図では、各顧客に、共有リソースを含むリソース グループと、データベースを含むリソース グループが割り当てられています。
サブスクリプション内の別個のリソース グループ
各テナントに一連のリソースをデプロイする場合、テナント固有の専用リソース グループを利用することを検討してください。 たとえば、「デプロイ スタンプ パターン」に従っている場合、各スタンプは、自身のリソース グループにデプロイされる必要があります。 複数のテナント固有のリソース グループを共有の Azure サブスクリプションにデプロイすることを検討できます。そうすると、ポリシーやアクセス制御の規則を簡単に構成できます。
各テナントに対して一連のリソース グループを作成し、さらに共有リソースに対して共有のリソース グループを作成することもできます。
テナント固有のリソース グループを共有サブスクリプションにデプロイする場合、各サブスクリプションのリソース グループの最大数や、デプロイするリソースに適用される、他のサブスクリプション レベルの制限にご注意ください。 これらの制限に近づいた場合は、複数のサブスクリプションをまたいだスケーリングが必要になる場合があります。
この例の場合、Contoso はそれぞれの顧客に対してスタンプをデプロイし、単一サブスクリプション内の専用のリソース グループにスタンプを配置することを選択するかもしれません。 次の図では、各顧客に対して 3 つのリソース グループを含むサブスクリプションが作成されます。
別個のサブスクリプション
テナント固有のサブスクリプションをデプロイすることで、テナント固有のリソースを完全に分離できます。 さらに、ほとんどのクォータと制限はサブスクリプション内で適用されるため、テナントごとに別個のサブスクリプションを使用することで、適用されるクォータを十分に活用できます。 一部の Azure 課金アカウントの種類では、プログラムを使用してサブスクリプションを作成できます。 サブスクリプション間で Azure の予約とコンピューティング用 Azure 節約プランを使用することもできます。
作成できるサブスクリプションの数にご注意ください。 サブスクリプションの最大数は、お客様と Microsoft または Microsoft パートナーとの取引関係によって異なる場合があります (エンタープライズ契約を交わしているかどうかなど)。
ただし、多くのサブスクリプションを使用している場合、クォータの増加をリクエストするのは簡単ではないことがあります。 クォータ API は、一部のリソースの種類に対してプログラマティック インターフェースを提供します。 とはいえ、多くのリソースの種類では、クォータの増加はサポート ケースを開始してリクエストする必要があります。 そして、多くのサブスクリプションを使用している場合、Azure サポート契約やサポート ケースを活用することは容易ではないことがあります。
テナント固有のサブスクリプションを管理グループにグループ化して、アクセス制御の規則やポリシーを簡単に管理できるようにすることを検討してください。
たとえば、次の図に示されているように、Contoso が 3 社の顧客それぞれに対して別個の Azure サブスクリプションを作成することに決めたとします。 各サブスクリプションには、その顧客のためのリソース一式を備えたリソース グループが含まれています。
各サブスクリプションには、その顧客のためのリソース一式を備えたリソース グループが含まれています。
Contoso では、管理グループを使用してサブスクリプションの管理を簡素化します。 管理グループの名称に Production ("運用") を含めることにより、運用テナントを非運用テナントやテスト用テナントから明確に区別することができます。 非運用テナントには、異なる Azure アクセス制御の規則とポリシーが適用される場合があります。
すべてのサブスクリプションは 1 つの Microsoft Entra テナントに関連付けられています。 Microsoft Entra テナントが単一であることは、ユーザーやサービス プリンシパルを含む Contoso チームの ID を、Azure 資産全体で使用できることを意味しています。
別の Microsoft Entra テナントにサブスクリプションを分離する
それぞれのテナントに対して、個々の Microsoft Entra テナントを手動で作成することや、リソースを顧客の Microsoft Entra テナント内のサブスクリプションにデプロイすることも可能です。 とはいえ、複数の Microsoft Entra テナントを使うと、認証、ロールの割り当ての管理、グローバル ポリシーの適用、その他の多くの管理操作を行うことが難しくなります。
警告
ほとんどのマルチテナント ソリューションに対しては、複数の Microsoft Entra テナントを作成しないようにお勧めします。 複数の Microsoft Entra テナントにまたがる作業は複雑さが増し、リソースのスケーリングと管理が行いにくくなります。 通常は、顧客の代理として Azure 環境を運用するマネージド サービス プロバイダー (MSP) だけがこの方法を採用します。
1 つの Microsoft Entra テナントを複数の個別のサブスクリプションや Azure リソースで使用できます。 複数の Microsoft Entra テナントをデプロイしようとする前に、その目的を実現できる別の方法がないかを検討してください。
複数の Microsoft Entra テナントに関連付けられているサブスクリプションの Azure リソースを管理する必要がある状況では、Azure Lighthouse を使って、Microsoft Entra テナントをまたいでリソースを管理することを検討してください。
たとえば、次の図に示されているように、Contoso は各顧客に対して別個の Microsoft Entra テナントと別個の Azure サブスクリプションを作成することができます。
Microsoft Entra テナントは、サブスクリプションと必要なリソースを含む Contoso の各テナントに対して構成されます。 Azure Lighthouse は各 Microsoft Entra テナントに接続されています。
ビン パッキング
リソース分離モデルに関わらず、ソリューションをいつどのように複数リソース間でスケール アウトするかを検討することは重要です。 システムの負荷が増加するにつれて、またはテナントの数が増えるにつれてリソースをスケーリングする必要があるかもしれません。 要件に最適な数のリソースをデプロイするには、"ビン パッキング" を検討してください。
ヒント
多くのソリューションでは、一連のリソース全体をまとめてスケーリングする方が、リソースを個別にスケーリングするよりも容易です。 「デプロイ スタンプ パターン」に従うことを検討してください。
リソース制限
Azure リソースには、ソリューションを計画する際に考慮に入れるべき制限とクォータがあります。 たとえば、リソースには、サポートされる同時リクエストの最大数やテナント固有の構成設定がある場合があります。
リソースをどのように構成して使用するかは、そのリソースのスケーラビリティにも影響を与えます。 たとえば、特定の量のコンピューティング リソースが割り当てられたアプリケーションは、定義された秒あたりのトランザクション数に正常に対応できます。 これを超える場合は、スケール アウトする必要があり、パフォーマンス テストは、リソースが要件を満たさなくなるポイントを特定するのに役立ちます。
Note
複数リソースへのスケーリングの原則は、複数のインスタンスをサポートするサービスを利用する場合でも適用されます。
たとえば、Azure App Service ではお使いのプランのインスタンス数のスケール アウトがサポートされていますが、単一プランをどの程度スケーリングできるかに関しては制限があります。 大規模なマルチテナント アプリの場合、これらの制限を超過し、拡大に対応するために追加の App Service リソースをデプロイする必要が生じるかもしれません。
テナント間でリソースの一部を共有する場合は、要件に基づいて構成する場合にリソースがサポートするテナントの数をまず決定する必要があります。 その後、テナントの合計数にサービスを提供するために必要なだけのリソースをデプロイします。
たとえば、マルチテナント SaaS ソリューションの一部として、Azure Application Gateway をデプロイするとします。 アプリケーション設計のレビュー、負荷がかかった状態のアプリケーション ゲートウェイのパフォーマンスのテスト、構成のレビューを行います。 そして、単一のアプリケーション ゲートウェイ リソースを、100 社の顧客間で共有できると判断します。 組織の拡大計画に基づき、最初の 1 年で 150 社の顧客のオンボードが見込まれるため、予想される負荷に対応するために複数のアプリケーション ゲートウェイをデプロイする計画する必要があります。
上の例では、2 つのアプリケーション ゲートウェイがあります。 1 つ目のゲートウェイは 1 から 100 番目の顧客専用で、2 つ目は 101 から 200 番目の顧客専用です。
リソース グループとサブスクリプションの制限
共有リソースと専用リソースのいずれを使用するにしても、制限を考慮に入れることは重要です。 Azure には、リソース グループと Azure サブスクリプションにデプロイできるリソース数に関して制限があります。 これらの制限に近づくにつれて、複数のリソース グループまたはサブスクリプションをまたいでスケーリングすることを計画する必要があります。
たとえば、各顧客に対して、専用のアプリケーション ゲートウェイを共有のリソース グループにデプロイするとします。 一部のリソースに関して、Azure では最大で 800 の同じ種類のリソースを単一のリソース グループにデプロイすることができます。 そのため、この制限に到達した場合は、新しいアプリケーション ゲートウェイを他のリソース グループにデプロイする必要があります。 次の図では、2 つのリソース グループがあります。 それぞれのリソース グループには 800 のアプリケーション ゲートウェイがあります。
リソース グループとサブスクリプションをまたぐテナントのビン パッキング
リソース、リソース グループ、サブスクリプションをまたいでビン パッキングの概念を適用することもできます。 たとえば、テナント数が少ない場合、単一のリソースをデプロイして、すべてのテナント間で共有することができます。 次の図は、単一リソースへのビン パッキングを示しています。
拡大するにつれて、容量の制限に近づき、複数 (R) 個のリソースにスケール アウトするかもしれません。 次の図は、複数リソース間のビン パッキングを示しています。
時間が経過するにつれて、単一リソース グループのリソース数の制限に到達し、複数 (R) 個のリソースを複数 (G) 個のリソース グループにデプロイするかもしれません。 次の図は、複数のリソース グループに含まれる複数のリソースをまたいだビン パッキングを示しています。
そしてさらに拡大する場合、それぞれが複数 (R) 個のリソースを持つ複数 (G) 個のリソース グループを含む、複数 (S) 個のサブスクリプションをまたいでデプロイすることができます。 次の図は、複数のリソース グループとサブスクリプションに含まれる複数のリソースをまたいだビン パッキングを示しています。
スケール アウト戦略を計画することにより、非常に多くのテナントにスケーリングして、大きな負荷を支えることができます。
タグ
リソース タグを使用すると、カスタムのメタデータを Azure リソースに追加することができます。これは、管理やコストの追跡に役立ちます。 詳細については、「リソース タグを使用したコストの割り当て」を参照してください。
回避すべきアンチパターン
- スケーリングの計画を立てない。 デプロイするリソースの制限について、また負荷やテナント数の増加に伴ってどの制限が重要になるかについて十分に理解していることを確認してください。 スケーリングに応じて追加のリソースをどのようにデプロイするか計画を立てて、その計画をテストします。
- ビン パッキングの計画を立てない。 すぐに拡張する必要がない場合でも、いずれは Azure リソースを複数のリソース、リソース グループ、サブスクリプションをまたいでスケーリングする計画を立ててください。 将来的に複数のリソースにスケーリングする必要が生じる可能性があるのに単一のリソースしか含めないなど、アプリケーション コードに憶測を含めることを避けてください。
- 多くの個々のリソースをスケーリングする。 リソース トポロジーが複雑である場合、個々のコンポーネントを 1 つ 1 つスケーリングするのは困難になる恐れがあります。 多くの場合は、「デプロイ スタンプ パターン」に従ってソリューションをまとめてスケーリングする方が簡単です。
- 必要がないのに、各テナントに分離されたリソースをデプロイする。 多くのソリューションでは、複数のテナントに共有リソースをデプロイする方が、コスト効率がよく、効果的です。
- 個別の Microsoft Entra テナントの使用。 一般に、複数の Microsoft Entra テナントをプロビジョニングすることはお勧めしません。 複数の Microsoft Entra テナントにまたがるリソースの管理は複雑です。 単一の Microsoft Entra テナントにリンクされたサブスクリプション間でスケーリングする方がシンプルです。
- スケーリングする必要がない場合の過度な設計。 ソリューションによっては、あるレベルを超えてスケーリングすることはないことが明確な場合があります。 そうした状況では、複雑なスケーリング ロジックを構築する必要はありません。 ただし、組織が拡大する計画を立てている場合は、(場合によっては急な) スケーリングに備える必要があります。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- John Downs | FastTrack for Azure のプリンシパル カスタマー エンジニア
その他の共同作成者:
- Jason Beck | FastTrack for Azure のシニア カスタマー エンジニア
- Bohdan Cherchyk | FastTrack for Azure のシニア カスタマー エンジニア
- Laura Nicolas | FastTrack for Azure のシニア カスタマー エンジニア
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Joshua Waddell | FastTrack for Azure のシニア カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
コストの管理と割り当て に関する手法を参照してください。