アーキテクチャとそれを実装するために使用するコンポーネントに関係なく、ソリューションのコンポーネントをデプロイして構成する必要があります。 マルチテナント環境では、特にテナントごとに専用リソースをデプロイする場合、またはシステム内のテナントの数に基づいてリソースを再構成する場合に、Azure リソースをデプロイする方法を検討することが重要です。 このページでは、マルチテナント ソリューションのデプロイに関するガイダンスをソリューション アーキテクトに提供し、デプロイ戦略を計画する際に考慮すべきいくつかのアプローチを示します。
主な考慮事項と要件
デプロイ戦略を計画する前に、要件を明確に知る必要があります。 具体的な考慮事項は次のとおりです。
- 予想されるスケール: 少ない数のテナント (5 つ以下など) をサポートすることが想定されますか、それとも多数のテナントに成長する見込みですか?
- 自動またはサポートされているオンボード: テナントをオンボードする準備ができたら、自動化された手順に従ってプロセス自体を完了できますか? または、新しいテナントが要求を開始し、その要求を受け取った後に手動でオンボードしますか? サービスの不正使用を防ぐなどのために、チームに手動で承認する手順が必要ですか?
- プロビジョニング時間: テナントをオンボードする準備ができたら、オンボード プロセスをどのくらい迅速に完了する必要がありますか? 明確な回答がない場合は、これを秒、分、時間、または日で測定する必要があるかどうかを検討してください。
- Azure Marketplace: デプロイを開始するために Azure Marketplace を使用する予定ですか? そうする場合は、 新しいテナントを追加するために満たす 必要がある要件があります。
また、オンボードとプロビジョニングの手順、自動化、およびリソース管理の責任も考慮する必要があります。
オンボードとプロビジョニングの手順
テナントをオンボードするときに行う必要があるすべてのことを考慮し、手動で実行されている場合でも、この一覧とワークフローをドキュメント化します。 オンボード ワークフローには、通常、次が含まれます。
- 商業契約への同意。
- 新しいテナント用にシステムを構成するために必要な情報の収集。
- サービスの不正行為や不正使用を防ぐなどのための手動承認手順。
- Azure でのリソースのプロビジョニング。
- ドメイン名の作成または構成。
- テナントの最初のユーザー アカウントの作成し、その資格情報をテナントに安全に送信するなど、デプロイ後の構成タスクを実行します。
- DNS レコードの変更など、手動での構成変更。
新しいテナントをオンボードするために必要なワークフローを明確にドキュメント化します。
さらに、テナントにプロビジョニングする必要がある特定の Azure リソースを検討します。 テナントごとに専用リソースをプロビジョニングしない場合でも、新しいテナントのオンボード時にリソースのデプロイが必要な場合があるかどうかを検討してください。 これは、テナントが特定のリージョンにデータを保存する必要がある場合、またはソリューション内のスタンプまたはコンポーネントの制限に近づいて、テナントの次のバッチ用に別のインスタンスを作成する必要がある場合に発生する可能性があります。
オンボード プロセスが、他のテナント (特に同じインフラストラクチャを共有するテナント) に破壊的な影響を及ぼしそうかどうかを検討します。 たとえば、共有データベースを変更する必要がある場合、このプロセスによって、他のテナントが認識する可能性のあるパフォーマンスへの影響を与えるおそれがありますか。 これらの影響を回避できるかどうかを検討するか、通常の運用時間外にオンボード プロセスを実行して軽減します。
Automation
自動デプロイは、クラウドでホストされるソリューションに対して常に推奨されます。 マルチテナント ソリューションを使用する場合、デプロイの自動化は次の理由でさらに重要になります。
- スケール: テナントの数が増えるほど、手動のデプロイ プロセスはますます複雑になり、時間がかかります。 自動デプロイ アプローチは、テナント数の増加に合わせて容易にスケーリングできます。
- 再現: マルチテナント環境では、すべてのテナントにわたるデプロイに一貫したプロセスを使用します。 手動プロセスでは、エラーが発生する可能性や、テナントに応じて実行される手順が発生する可能性があります。 これらの手動プロセスによって、環境が一貫性のない状態になり、チームがソリューションを管理することが困難になります。
- 障害の影響: 手動デプロイは、自動化されたデプロイよりも大幅にリスクが高く、障害が発生しやすくなっています。 マルチテナント環境では、すべてのテナントが影響を受ける可能性があるので、システム全体の障害 (デプロイ エラーによる) の影響が大きくなる可能性があります。
マルチテナント環境にデプロイする場合は、デプロイ パイプラインを使用し、 Bicep、JSON ARM テンプレート、Terraform、Azure SDK などのコードとしてのインフラストラクチャ (IaC) テクノロジを使用する必要があります。
Azure Marketplace を通じてソリューションを提供する場合、新しいテナントに対して完全に自動化されたオンボード プロセスを提供する必要があります。 このプロセスについては、 SaaS Fulfillment API のドキュメントを参照してください。
最大リソース容量
共有リソースにテナント リソースをプログラムでデプロイする場合は、各リソースの容量制限を検討してください。 この制限に近づくと、さらにスケールをサポートするために、リソースの別のインスタンスを作成する必要がある場合があります。 デプロイする各リソースの制限と、別のインスタンスのデプロイをトリガーする条件を検討します。
たとえば、ソリューションに Azure SQL 論理サーバーが含まれるとします。ソリューションでは、テナントごとにそのサーバーに専用データベースがプロビジョニングされます。 論理サーバーがサポートするデータベースの最大数などの 制限が 1 つの論理サーバーにあります。 これらの制限に近づくと、テナントのオンボードを続行できるよう、新しいサーバーのプロビジョニングが必要になる場合があります。 このプロセスを自動化するか、増加を手動で監視するか検討してください。
リソース管理責任
一部のマルチテナント ソリューションでは、テナントごとに専用の Azure リソース (たとえばテナントごとにデータベース) をデプロイします。 または、リソースの 1 つのインスタンスに配置するテナントのセット数を決定することができ、テナント数によって Azure にデプロイするリソースのセットが決まります。 他のソリューションでは、共有リソースのセットを 1 つデプロイし、新しいテナントをオンボードするときにリソースを再構成します。
これらの各モデルでは、さまざまな方法でリソースをデプロイおよび管理する必要があります。また、プロビジョニングするリソースのライフサイクルをデプロイおよび管理する方法を検討する必要があります。 一般的なアプローチ 2 つは次のとおりです。
- デプロイするリソースの 構成 としてテナントを扱い、デプロイ パイプラインを使用してそれらのリソースをデプロイおよび構成します。
- テナントを "データ" として扱い、 コントロール プレーン を用意してテナントのインフラストラクチャをプロビジョニングおよび構成します。
これらのアプローチの詳細については、後述します。
テスト
デプロイ中とデプロイ後に、ソリューションを徹底的にテストする計画を立ててください。 自動テストを使用して、ソリューションの機能的および非機能的動作を検証できます。 テナント分離モデルをテストします。また、 Azure Chaos Studio などのツールを使用して、実際の停止をシミュレートする障害を意図的に導入し、コンポーネントが使用できない場合や誤動作している場合でもソリューションが機能することを確認します。
考慮すべきアプローチとパターン
Azure アーキテクチャ センターおよび広範なコミュニティからの設計パターンのいくつかは、マルチテナント ソリューションのデプロイと構成に関連しています。
デプロイ スタンプ パターン
デプロイ スタンプ パターン によってデプロイされるのは、テナントまたはテナント グループ専用のインフラストラクチャです。 1 つのスタンプに複数のテナントが含まれていることも、シングル テナント専用のスタンプであることもあります。 1 つのスタンプをデプロイすることも、複数のスタンプ間でデプロイを調整することもできます。 テナントごとに専用スタンプをデプロイする場合は、プログラムでスタンプ全体をデプロイすることも検討できます。
デプロイ リング
デプロイ リング を使用すると、異なる時間の異なるインフラストラクチャ グループに更新をロールアウトできます。 このアプローチは、一般的に デプロイ スタンプ パターンで使用され、スタンプのグループは、テナントの基本設定、ワークロードの種類、その他の考慮事項に基づいて個別のリングに割り当てることができます。 詳しくは、「デプロイ リング」を参照してください。
機能フラグ
機能フラグ を使用すると、1 つのコードベースを維持しながら、ソリューションの新機能またはバージョンを異なるテナントに段階的に公開できます。 Azure App Configuration を使用して機能フラグを管理することを検討します。 詳しくは、「機能フラグ」をご覧ください。
場合によっては、特定の顧客に対して特定の機能を選択的に有効にする必要があります。 たとえば、特定の機能へのアクセスを許可する異なる 価格レベル がある場合があります。 通常、機能フラグは、このようなシナリオに最適な選択肢ではありません。 代わりに、各顧客が持つ ライセンス エンタイトルメント を追跡して適用するプロセスを構築することを検討します。
回避すべきアンチパターン
マルチテナント ソリューションをデプロイして構成する場合は、スケーリング能力を禁止する状況を回避することが重要です。 デモには次のものが含まれます。
- 手動デプロイとテスト。 前述のように、手動デプロイ プロセスではリスクが高く、デプロイ機能が遅くなります。 自動デプロイにパイプラインを使用するか、ソリューションのコードからプログラムでリソースを作成するか、またはその両方を組み合わせることを検討してください。
- テナントに特化したカスタマイズ。 1 つのテナントにのみ適用される機能または構成をデプロイしないようにします。 このアプローチでは、デプロイとテストのプロセスが複雑になります。 代わりに、テナントごとに同じリソースの種類とコードベースを使用し、一時的な変更や段階的に展開される機能の 機能フラグ のような戦略を使用するか、ライセンス エンタイトルメントで 異なる価格レベル を使用してそれらを必要とするテナントの機能を選択的に有効にします。 分離されたまたは専用のリソースを持つテナントでも、一貫性のある自動化されたデプロイ プロセスを使用します。
構成またはデータとしてのテナント リスト
マルチテナント ソリューションにリソースをデプロイする場合は、次の 2 つの方法を検討できます。
- 自動化されたデプロイ パイプラインを使用して、すべてのリソースをデプロイします。 新しいテナントが追加された後、各テナントのリソースをプロビジョニングするためにパイプラインを再構成します。
- 自動化されたデプロイ パイプラインを使用して、テナントの数に依存しない共有リソースをデプロイします。 テナントごとにデプロイされるリソースについては、アプリケーション内に作成します。
2 つのアプローチを検討する場合は、テナント リストを 構成 としてまたは データとして扱うのかを区別する必要があります。 この区別は、システムの コントロール プレーン を構築する方法を検討する場合にも重要です。
構成としてのテナント リスト
テナント リストを構成として扱う場合は、一元化されたデプロイ パイプラインからすべてのリソースをデプロイします。 新しいテナントがオンボードされる場合は、パイプラインまたはそのパラメーターを再構成します。 通常、再構成は、次の図に示す手動の変更によって行います。
新しいテナントをオンボードするプロセスは、次のようになります。
- テナント リストを更新します。 これは通常、パイプライン自体を構成するか、パイプラインの構成に含まれているパラメーター ファイルを変更することで、手動で行います。
- 実行するパイプラインをトリガーします。
- パイプラインは、新しいテナント固有のリソースを含む Azure リソースの完全なセットを再デプロイします。
このアプローチは、テナントの数が少ない場合や、すべてのリソースが共有されるアーキテクチャの場合に、うまく機能する傾向があります。 すべての Azure リソースを 1 つのプロセスを使用してデプロイおよび構成することができるため、これは単純なアプローチです。
ただし、5 から 10 以上などテナント数が多くなると、テナントを追加するときにパイプラインを再構成するのが煩雑になります。 多くの場合、デプロイ パイプラインの実行にかかる時間も大幅に増加します。 このアプローチでは、セルフサービス テナントの作成も簡単にはサポートされません。また、パイプラインの実行をトリガーする必要があるため、テナントがオンボードされる前のリード タイムが長くなる可能性があります。
データとしてのテナント リスト
テナント リストをデータとして扱う場合でも、パイプラインを使用して共有コンポーネントをデプロイします。 ただし、テナントごとにデプロイする必要があるリソースと構成設定については、リソースを強制的にデプロイまたは構成する必要があります。 たとえば、コントロール プレーンは、 Azure SDK を使用して、特定のリソースを作成したり、パラメーター化されたテンプレートのデプロイを開始したりできます。
新しいテナントをオンボードするプロセスは次のようになります。これは非同期的に行います。
- システムのコントロール プレーンへの API 要求を開始するなどの方法で、テナントのオンボードを要求します。
- ワークフロー コンポーネントは作成要求を受け取り、残りの手順を調整します。
- ワークフローは、テナント固有のリソースの Azure へのデプロイを開始します。 これは、Azure SDK を使用するなどの命令型プログラミング モデルを使用するか、Bicep または Terraform テンプレートのデプロイを強制的にトリガーすることで実現できます。
- デプロイが完了すると、ワークフローによって新しいテナントの詳細が中央テナント カタログに保存されます。 テナントごとの格納データには、ワークフローによって作成されたテナント固有のすべてのリソースのテナント ID とリソース ID が含まれる場合があります。
これを行うことにより、ソリューション全体を再デプロイすることなく、新しいテナントのリソースをプロビジョニングできます。 デプロイする必要があるのはこれらのリソースのみであるため、各テナントの新しいリソースのプロビジョニングに必要な時間は短くなる可能性があります。
ただし、このアプローチは多くの場合、ビルドにはるかに時間がかかるので、満たす必要があるテナントの数またはプロビジョニング期間によって、費やす労力が正当化される必要があります。
このアプローチの詳細については、「マルチテナント コントロール プレーンに関する考慮事項」を参照してください。
注意
Azure のデプロイと構成の操作は、多くの場合、完了に時間がかかります。 このような実行時間の長い操作を開始および監視するには、適切なプロセスを使用してください。 たとえば、 非同期要求-応答パターンに従うことを検討してください。 Azure Logic Apps や Durable Functions など、実行時間の長い操作をサポートするように設計されたテクノロジを使用します。
例
Contoso は、顧客向けマルチテナント ソリューションを実行します。 現在、6 つのテナントがあり、今後 18 か月以内に 300 テナントに拡大する予定です。 Contoso は、 テナントごとに専用データベースを持つマルチテナント アプリ のアプローチに従います。 次の図に示すように、すべてのテナント間で共有される 1 セットの App Service リソースと Azure SQL 論理サーバーをデプロイしてあり、テナントごとに専用の Azure SQL データベースをデプロイします。
Contoso は Bicep を使用して Azure リソースをデプロイします。
オプション 1 - すべてのデプロイ パイプラインを使用する
Contoso は、デプロイ パイプラインを使用して、すべてのリソースのデプロイを検討する可能性があります。 パイプラインでは、各テナントの Azure SQL データベースなど、すべての Azure リソースを含む Bicep ファイルをデプロイします。 次の図に示すように、パラメーター ファイルではテナント リストを定義し、Bicep ファイルでは リソース ループ を使用してリストされている各テナントのデータベースをデプロイします。
Contoso がこのモデルに従う場合は、新しいテナントのオンボードの一環としてパラメーター ファイルを更新する必要があります。 その後、パイプラインを再実行する必要があります。 また、予想外に高い速度で増加し、1 つの Azure SQL 論理サーバーでサポートされるデータベースの最大数に近づくなど、制限に近づいているかどうかを手動で追跡する必要があります。
オプション 2 - デプロイ パイプラインと命令型リソース作成の組み合わせを使用する
別の方法として、Contoso は Azure デプロイの責任を分離することを検討する可能性があります。
Contoso は、デプロイする必要がある共有リソースを定義する Bicep ファイルを使用します。 次の図に示すように、共有リソースではすべてのテナントがサポートされ、テナント マップ データベースが含まれます。
その後、Contoso チームは、テナント オンボード API を含むコントロール プレーンを構築します。 営業チームが新しい顧客への販売を完了すると、Microsoft Dynamics では API をトリガーしてオンボード プロセスを開始します。 Contoso は、顧客が使用できるセルフサービス Web インターフェイスも提供し、API のトリガーも行います。
API では、新しいテナントをオンボードするワークフローを非同期的に開始します。 ワークフローは、新しい Azure SQL データベースのデプロイを開始します。これは、次のいずれかの方法で実行できます。
- Azure SDK を使用して、Azure SQL データベースを定義する 2 つ目の Bicep ファイルのデプロイを開始します。
- Azure SDK を使用し、 管理ライブラリを使用して、Azure SQL データベースを強制的に作成します。
データベースがデプロイされた後、次の図に示すように、ワークフローによってテナントがテナント リスト データベースに追加されます。
進行中のデータベース スキーマの更新は、アプリケーション層によって開始されます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
その他の共同作成者:
- Bohdan Cherchyk | FastTrack for Azure のシニア カスタマー エンジニア
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- マルチテナント ソリューションの更新に関する考慮事項を確認します。
- ストレージとデータのアーキテクチャ アプローチについて検討します。
- マルチテナント ソリューション で Azure Resource Manager を使用する方法を検討します。