マルチテナント ソリューションのデプロイと構成のアーキテクチャ アプローチ

Azure

Azure DevOps

Azure Pipelines

Azure Marketplace

GitHub

アーキテクチャと実装に使用するコンポーネントに関係なく、ソリューションのコンポーネントをデプロイして構成する必要があります。 マルチテナント環境では、特に各テナントの専用リソースをデプロイする場合や、システム内のテナントの数に基づいてリソースを再構成する場合に、Azure リソースをデプロイする方法を検討することが重要です。 このページでは、マルチテナント ソリューションのデプロイに関するガイダンスをソリューション アーキテクトに提供し、デプロイ戦略を計画する際に考慮すべきいくつかのアプローチを示します。

主な考慮事項と要件

デプロイ戦略を計画する前に、要件を明確に把握することが重要です。 具体的な考慮事項は次のとおりです。

• 予想されるスケール: 少数のテナント (5 つ以下など) をサポートする予定ですか、それとも多数のテナントに拡大しますか?
• 自動またはサポートされているオンボーディング: テナントをオンボードする準備ができたら、自動化された手順に従って自分でプロセスを完了できますか? または、新しいテナントが要求を開始し、要求を受信した後に手動でオンボードしますか? サービスの悪用を防ぐためなど、チームに手動の承認手順が必要ですか?
• プロビジョニング時間: テナントをオンボードする準備ができたら、オンボード プロセスをどのくらいの速さで完了する必要がありますか? 明確な回答がない場合は、秒、分、時間、または日で測定する必要があるかどうかを検討してください。
• Azure Marketplace: Azure Marketplace を使用してデプロイを開始する予定ですか? その場合は、 新しいテナントを追加するために満たす必要がある要件があります。

また、オンボードとプロビジョニングの手順、自動化、およびリソース管理の責任も検討する必要があります。

オンボードとプロビジョニングの手順

テナントをオンボードするときに必要なすべてのことを検討し、手動で実行された場合でも、このリストとワークフローを文書化します。 オンボード ワークフローには、通常、次のものが含まれます。

• 商用契約の承諾。
• 新しいテナントのシステムを構成するために必要な情報のコレクション。
• たとえば、サービスの不正行為や不正使用を防ぐための手動承認手順。
• Azure でのリソースのプロビジョニング。
• ドメイン名の作成または構成。
• テナントの最初のユーザー アカウントを作成し、その資格情報をテナントに安全に送信するなど、デプロイ後の構成タスクを実行します。
• DNS レコードの変更など、手動で構成を変更します。

新しいテナントのオンボードに必要なワークフローを明確に文書化します。

さらに、テナント用にプロビジョニングする必要がある特定の Azure リソースを検討してください。 テナントごとに専用リソースをプロビジョニングしない場合でも、新しいテナントのオンボード時にリソースのデプロイが必要な場合があるかどうかを検討してください。 これは、テナントがデータを特定のリージョンに格納する必要がある場合、またはソリューション内のスタンプまたはコンポーネントの制限に近づき、テナントの次のバッチ用に別のインスタンスを作成する必要がある場合に発生する可能性があります。

オンボーディング プロセスが他のテナント (特に同じインフラストラクチャを共有するテナント) に悪影響を及ぼす可能性があるかどうかを検討します。 たとえば、共有データベースを変更する必要がある場合、このプロセスによって、他のテナントが気付く可能性のあるパフォーマンスへの影響が発生する可能性がありますか。 これらの影響を回避できるか、通常の稼働時間外にオンボード プロセスを実行して軽減できるかを検討します。

オートメーション

クラウドでホストされるソリューションには、常に自動デプロイをお勧めします。 マルチテナント ソリューションを使用する場合、次の理由により、デプロイの自動化がさらに重要になります。

• 規模： テナントの人口が増加するにつれて、手動デプロイ プロセスはますます複雑になり、時間がかかります。 自動デプロイアプローチは、テナントの数が増えるにつれて簡単にスケーリングできます。
• 再現： マルチテナント環境では、すべてのテナントにわたるデプロイに一貫したプロセスを使用します。 手動プロセスでは、一部のテナントではなく、一部のテナントに対してエラーが発生したり、ステップが実行されたりする可能性があります。 これらの手動プロセスにより、環境が不整合な状態になり、チームがソリューションを管理することが困難になります。
• 停止の影響: 手動デプロイは、自動化されたデプロイよりも非常にリスクが高く、停止が発生しやすくなります。 マルチテナント環境では、すべてのテナントが影響を受ける可能性があるため、システム全体の停止 (デプロイ エラーによる) の影響が高くなる可能性があります。

マルチテナント環境にデプロイする場合は、デプロイ パイプラインを使用し、 Bicep、JSON ARM テンプレート、Terraform、Azure SDK などのコードとしてのインフラストラクチャ (IaC) テクノロジを使用する必要があります。

Azure Marketplace を通じてソリューションを提供する予定の場合は、新しいテナントに対して完全に自動化されたオンボード プロセスを提供する必要があります。 このプロセスについては、 SaaS フルフィルメント API のドキュメントで説明されています。

最大リソース容量

共有リソースにテナント リソースをプログラムでデプロイする場合は、各リソースの容量制限を考慮してください。 この制限に近づくと、さらにスケーリングをサポートするためにリソースの別のインスタンスを作成することが必要になる場合があります。 デプロイする各リソースの制限と、別のインスタンスのデプロイをトリガーする条件を検討してください。

たとえば、ソリューションに Azure SQL 論理サーバーが含まれており、ソリューションがテナントごとにそのサーバー上に専用データベースをプロビジョニングするとします。 1 つの論理サーバーには制限があります。これには、論理サーバーがサポートするデータベースの最大数が含まれます。 これらの制限に近づくと、テナントを引き続きオンボードできるように、新しいサーバーをプロビジョニングすることが必要になる場合があります。 このプロセスを自動化するか、手動で増加を監視するかを検討します。

リソース管理の責任

一部のマルチテナント ソリューションでは、テナントごとに専用の Azure リソース (テナントごとのデータベースなど) をデプロイします。 または、リソースの 1 つのインスタンスに格納するテナントのセット数を決定して、Azure にデプロイするリソースのセットを決定するテナントの数を決定することもできます。 他のソリューションでは、共有リソースの 1 つのセットをデプロイし、新しいテナントをオンボードするときにリソースを再構成します。

これらの各モデルでは、さまざまな方法でリソースをデプロイおよび管理する必要があります。また、プロビジョニングするリソースのライフサイクルをデプロイおよび管理する方法を検討する必要があります。 次の 2 つの一般的な方法があります。

• テナントをデプロイするリソースの 構成 として扱い、デプロイ パイプラインを使用してそれらのリソースをデプロイおよび構成します。
• テナントを データとして扱い、 コントロール プレーン をプロビジョニングし、テナントのインフラストラクチャを構成します。

これらのアプローチの詳細については、以下で説明します。

テスティング

デプロイのたびに、ソリューションを徹底的にテストすることを計画します。 自動テストを使用して、ソリューションの機能と非機能の動作を確認できます。 テナント分離モデルをテストし、 Azure Chaos Studio などのツールを使用して、実際の停止をシミュレートする障害を意図的に導入し、コンポーネントが使用できない場合や誤動作している場合でもソリューションが機能することを確認することを検討してください。

考慮すべきアプローチとパターン

Azure アーキテクチャ センターとより広いコミュニティからのいくつかの設計パターンは、マルチテナント ソリューションのデプロイと構成に関連しています。

デプロイ スタンプ パターン

デプロイ スタンプ パターンには、テナントまたはテナントのグループ用の専用インフラストラクチャのデプロイが含まれます。 1 つのスタンプに複数のテナントが含まれている場合もあれば、1 つのテナント専用である場合もあります。 1 つのスタンプをデプロイすることも、複数のスタンプ間でデプロイを調整することもできます。 テナントごとに専用スタンプをデプロイする場合は、スタンプ全体をプログラムでデプロイすることも検討できます。

展開リング

展開リング を使用すると、異なる時間に異なるインフラストラクチャ グループに更新プログラムをロールアウトできます。 この方法は デプロイ スタンプ パターンでよく使用され、スタンプのグループはテナントの基本設定、ワークロードの種類、その他の考慮事項に基づいて個別のリングに割り当てることができます。 詳細については、「 展開リング」を参照してください。

機能フラグ

機能フラグ を使用すると、1 つのコードベースを維持しながら、ソリューションの新しい機能またはバージョンをさまざまなテナントに段階的に公開できます。 Azure App Configuration を使用して機能フラグを管理することを検討してください。 詳細については、「 機能フラグ」を参照してください。

場合によっては、特定の顧客に対して特定の機能を選択的に有効にする必要があります。 たとえば、特定の機能へのアクセスを許可する価格 レベル が異なる場合があります。 通常、機能フラグは、これらのシナリオに適した選択肢ではありません。 代わりに、各顧客が持っている ライセンスの権利 を追跡して適用するプロセスを構築することを検討してください。

回避すべきアンチパターン

マルチテナント ソリューションをデプロイして構成するときは、スケーリングが妨げる状況を回避することが重要です。 これには以下が含まれます。

• 手動でのデプロイとテスト。 前述のように、手動デプロイ プロセスによってリスクが追加され、デプロイの能力が低下します。 自動化されたデプロイ、ソリューションのコードからのリソースのプログラムによる作成、またはその両方の組み合わせにパイプラインを使用することを検討してください。
• テナントに特化したカスタマイズ。 1 つのテナントにのみ適用される機能または構成のデプロイは避けてください。 このアプローチにより、デプロイとテスト プロセスが複雑になります。 代わりに、テナントごとに同じリソースの種類とコードベースを使用し、一時的な変更や段階的にロールアウトされる 機能の機能フラグ などの戦略を使用するか、ライセンスの権利を持つ 異なる価格レベル を使用して、それらを必要とするテナントの機能を選択的に有効にします。 分離されたリソースまたは専用のリソースを持つテナントでも、一貫性のある自動化されたデプロイ プロセスを使用します。

構成またはデータとしてのテナント リスト

マルチテナント ソリューションにリソースをデプロイする場合は、次の 2 つの方法を検討できます。

• 自動デプロイ パイプラインを使用して、すべてのリソースをデプロイします。 新しいテナントが追加されたら、各テナントのリソースをプロビジョニングするようにパイプラインを再構成します。
• 自動デプロイ パイプラインを使用して、テナントの数に依存しない共有リソースをデプロイします。 テナントごとにデプロイされるリソースについては、アプリケーション内に作成します。

2 つの方法を検討するときは、テナントリストを 構成 として扱うか データとして扱うかを区別する必要があります。 この区別は、システムの コントロール プレーン を構築する方法を検討する場合にも重要です。

構成としてのテナントの一覧

テナント一覧を構成として扱う場合は、一元化されたデプロイ パイプラインからすべてのリソースをデプロイします。 新しいテナントがオンボードされたら、パイプラインまたはそのパラメーターを再構成します。 通常、再構成は、次の図に示すように手動で変更を行います。

新しいテナントをオンボードするプロセスは、次のようになります。

1. テナントの一覧を更新します。 これは通常、パイプライン自体を構成するか、パイプラインの構成に含まれるパラメーター ファイルを変更することによって手動で行われます。
2. パイプラインを実行するようにトリガーします。
3. パイプラインは、新しいテナント固有のリソースを含む、Azure リソースの完全なセットを再デプロイします。

このアプローチは、少数のテナントや、すべてのリソースが共有されているアーキテクチャに適している傾向があります。 すべての Azure リソースを 1 つのプロセスを使用してデプロイおよび構成できるため、これは簡単なアプローチです。

ただし、5 ~ 10 以上など、より多くのテナントにアプローチする場合、テナントを追加するときにパイプラインを再構成するのは面倒になります。 多くの場合、デプロイ パイプラインの実行にかかる時間も大幅に増加します。 この方法では、セルフサービス テナントの作成も簡単にはサポートされません。また、パイプラインを実行するためにトリガーする必要があるため、テナントのオンボード前のリード タイムが長くなる可能性があります。

データとしてのテナント リスト

テナントリストをデータとして扱う場合でも、パイプラインを使用して共有コンポーネントをデプロイします。 ただし、テナントごとにデプロイする必要があるリソースと構成設定については、リソースを強制的にデプロイまたは構成します。 たとえば、コントロール プレーンでは 、Azure SDK を使用して特定のリソースを作成したり、パラメーター化されたテンプレートのデプロイを開始することができます。

新しいテナントをオンボードするプロセスは次のようになります。非同期的に行われます。

1. システムのコントロール プレーンへの API 要求を開始するなどして、テナントのオンボードを要求します。
2. ワークフロー コンポーネントは作成要求を受け取り、残りの手順を調整します。
3. ワークフローは、テナント固有のリソースの Azure へのデプロイを開始します。 これは、Azure SDK を使用するなど、命令型プログラミング モデルを使用するか、Bicep または Terraform テンプレートのデプロイを命令的にトリガーすることによって実現できます。
4. デプロイが完了すると、ワークフローによって新しいテナントの詳細が中央テナント カタログに保存されます。 各テナントに格納されるデータには、ワークフローで作成されたすべてのテナント固有のリソースのテナント ID とリソース ID が含まれる場合があります。

これにより、ソリューション全体を再デプロイすることなく、新しいテナントのリソースをプロビジョニングできます。 各テナントの新しいリソースのプロビジョニングにかかる時間は、それらのリソースのみをデプロイする必要があるため、短くなる可能性があります。

ただし、多くの場合、このアプローチは構築にはるかに時間がかかり、テナントの数または満たす必要があるプロビジョニング期間によって、費やす労力を正当化する必要があります。

この方法の詳細については、「 マルチテナント コントロール プレーンの考慮事項」を参照してください。

注

Azure のデプロイと構成の操作は、多くの場合、完了に時間がかかります。 これらの実行時間の長い操作を開始して監視するには、適切なプロセスを使用してください。 たとえば、 非同期 Request-Reply パターンに従うとします。 Azure Logic Apps や Durable Functions などの実行時間の長い操作をサポートするように設計されたテクノロジを使用します。

例

Contoso は、顧客向けにマルチテナント ソリューションを実行します。 現在、テナントは 6 つあり、今後 18 か月以内に 300 テナントに拡大する予定です。 Contoso は、 テナントアプローチごとに専用データベースを備えたマルチテナント アプリに 従います。 次の図に示すように、App Service リソースの 1 つのセットと、すべてのテナント間で共有される 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 | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• ボーダン・チェルチク |Azure 用 FastTrack のシニア カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• マルチテナント ソリューションの更新に関する考慮事項を確認します。
• ストレージとデータのアーキテクチャ アプローチを検討します。
• マルチテナント ソリューションで Azure Resource Manager を使用する方法を検討します。

アーキテクチャと実装に使用するコンポーネントに関係なく、ソリューションのコンポーネントをデプロイして構成する必要があります。 マルチテナント環境では、特に各テナントの専用リソースをデプロイする場合や、システム内のテナントの数に基づいてリソースを再構成する場合に、Azure リソースをデプロイする方法を検討することが重要です。 このページでは、マルチテナント ソリューションのデプロイに関するガイダンスをソリューション アーキテクトに提供し、デプロイ戦略を計画する際に考慮すべきいくつかのアプローチを示します。

主な考慮事項と要件

デプロイ戦略を計画する前に、要件を明確に把握することが重要です。 具体的な考慮事項は次のとおりです。

• 予想されるスケール: 少数のテナント (5 つ以下など) をサポートする予定ですか、それとも多数のテナントに拡大しますか?
• 自動またはサポートされているオンボーディング: テナントをオンボードする準備ができたら、自動化された手順に従って自分でプロセスを完了できますか? または、新しいテナントが要求を開始し、要求を受信した後に手動でオンボードしますか? サービスの悪用を防ぐためなど、チームに手動の承認手順が必要ですか?
• プロビジョニング時間: テナントをオンボードする準備ができたら、オンボード プロセスをどのくらいの速さで完了する必要がありますか? 明確な回答がない場合は、秒、分、時間、または日で測定する必要があるかどうかを検討してください。
• Azure Marketplace: Azure Marketplace を使用してデプロイを開始する予定ですか? その場合は、 新しいテナントを追加するために満たす必要がある要件があります。

また、オンボードとプロビジョニングの手順、自動化、およびリソース管理の責任も検討する必要があります。

オンボードとプロビジョニングの手順

テナントをオンボードするときに必要なすべてのことを検討し、手動で実行された場合でも、このリストとワークフローを文書化します。 オンボード ワークフローには、通常、次のものが含まれます。

• 商用契約の承諾。
• 新しいテナントのシステムを構成するために必要な情報のコレクション。
• たとえば、サービスの不正行為や不正使用を防ぐための手動承認手順。
• Azure でのリソースのプロビジョニング。
• ドメイン名の作成または構成。
• テナントの最初のユーザー アカウントを作成し、その資格情報をテナントに安全に送信するなど、デプロイ後の構成タスクを実行します。
• DNS レコードの変更など、手動で構成を変更します。

新しいテナントのオンボードに必要なワークフローを明確に文書化します。

さらに、テナント用にプロビジョニングする必要がある特定の Azure リソースを検討してください。 テナントごとに専用リソースをプロビジョニングしない場合でも、新しいテナントのオンボード時にリソースのデプロイが必要な場合があるかどうかを検討してください。 これは、テナントがデータを特定のリージョンに格納する必要がある場合、またはソリューション内のスタンプまたはコンポーネントの制限に近づき、テナントの次のバッチ用に別のインスタンスを作成する必要がある場合に発生する可能性があります。

オンボーディング プロセスが他のテナント (特に同じインフラストラクチャを共有するテナント) に悪影響を及ぼす可能性があるかどうかを検討します。 たとえば、共有データベースを変更する必要がある場合、このプロセスによって、他のテナントが気付く可能性のあるパフォーマンスへの影響が発生する可能性がありますか。 これらの影響を回避できるか、通常の稼働時間外にオンボード プロセスを実行して軽減できるかを検討します。

オートメーション

クラウドでホストされるソリューションには、常に自動デプロイをお勧めします。 マルチテナント ソリューションを使用する場合、次の理由により、デプロイの自動化がさらに重要になります。

• 規模： テナントの人口が増加するにつれて、手動デプロイ プロセスはますます複雑になり、時間がかかります。 自動デプロイアプローチは、テナントの数が増えるにつれて簡単にスケーリングできます。
• 再現： マルチテナント環境では、すべてのテナントにわたるデプロイに一貫したプロセスを使用します。 手動プロセスでは、一部のテナントではなく、一部のテナントに対してエラーが発生したり、ステップが実行されたりする可能性があります。 これらの手動プロセスにより、環境が不整合な状態になり、チームがソリューションを管理することが困難になります。
• 停止の影響: 手動デプロイは、自動化されたデプロイよりも非常にリスクが高く、停止が発生しやすくなります。 マルチテナント環境では、すべてのテナントが影響を受ける可能性があるため、システム全体の停止 (デプロイ エラーによる) の影響が高くなる可能性があります。

マルチテナント環境にデプロイする場合は、デプロイ パイプラインを使用し、 Bicep、JSON ARM テンプレート、Terraform、Azure SDK などのコードとしてのインフラストラクチャ (IaC) テクノロジを使用する必要があります。

Azure Marketplace を通じてソリューションを提供する予定の場合は、新しいテナントに対して完全に自動化されたオンボード プロセスを提供する必要があります。 このプロセスについては、 SaaS フルフィルメント API のドキュメントで説明されています。

最大リソース容量

共有リソースにテナント リソースをプログラムでデプロイする場合は、各リソースの容量制限を考慮してください。 この制限に近づくと、さらにスケーリングをサポートするためにリソースの別のインスタンスを作成することが必要になる場合があります。 デプロイする各リソースの制限と、別のインスタンスのデプロイをトリガーする条件を検討してください。

たとえば、ソリューションに Azure SQL 論理サーバーが含まれており、ソリューションがテナントごとにそのサーバー上に専用データベースをプロビジョニングするとします。 1 つの論理サーバーには制限があります。これには、論理サーバーがサポートするデータベースの最大数が含まれます。 これらの制限に近づくと、テナントを引き続きオンボードできるように、新しいサーバーをプロビジョニングすることが必要になる場合があります。 このプロセスを自動化するか、手動で増加を監視するかを検討します。

リソース管理の責任

一部のマルチテナント ソリューションでは、テナントごとに専用の Azure リソース (テナントごとのデータベースなど) をデプロイします。 または、リソースの 1 つのインスタンスに格納するテナントのセット数を決定して、Azure にデプロイするリソースのセットを決定するテナントの数を決定することもできます。 他のソリューションでは、共有リソースの 1 つのセットをデプロイし、新しいテナントをオンボードするときにリソースを再構成します。

これらの各モデルでは、さまざまな方法でリソースをデプロイおよび管理する必要があります。また、プロビジョニングするリソースのライフサイクルをデプロイおよび管理する方法を検討する必要があります。 次の 2 つの一般的な方法があります。

• テナントをデプロイするリソースの 構成 として扱い、デプロイ パイプラインを使用してそれらのリソースをデプロイおよび構成します。
• テナントを データとして扱い、 コントロール プレーン をプロビジョニングし、テナントのインフラストラクチャを構成します。

これらのアプローチの詳細については、以下で説明します。

テスティング

デプロイのたびに、ソリューションを徹底的にテストすることを計画します。 自動テストを使用して、ソリューションの機能と非機能の動作を確認できます。 テナント分離モデルをテストし、 Azure Chaos Studio などのツールを使用して、実際の停止をシミュレートする障害を意図的に導入し、コンポーネントが使用できない場合や誤動作している場合でもソリューションが機能することを確認することを検討してください。

考慮すべきアプローチとパターン

Azure アーキテクチャ センターとより広いコミュニティからのいくつかの設計パターンは、マルチテナント ソリューションのデプロイと構成に関連しています。

デプロイ スタンプ パターン

デプロイ スタンプ パターンには、テナントまたはテナントのグループ用の専用インフラストラクチャのデプロイが含まれます。 1 つのスタンプに複数のテナントが含まれている場合もあれば、1 つのテナント専用である場合もあります。 1 つのスタンプをデプロイすることも、複数のスタンプ間でデプロイを調整することもできます。 テナントごとに専用スタンプをデプロイする場合は、スタンプ全体をプログラムでデプロイすることも検討できます。

展開リング

展開リング を使用すると、異なる時間に異なるインフラストラクチャ グループに更新プログラムをロールアウトできます。 この方法は デプロイ スタンプ パターンでよく使用され、スタンプのグループはテナントの基本設定、ワークロードの種類、その他の考慮事項に基づいて個別のリングに割り当てることができます。 詳細については、「 展開リング」を参照してください。

機能フラグ

機能フラグ を使用すると、1 つのコードベースを維持しながら、ソリューションの新しい機能またはバージョンをさまざまなテナントに段階的に公開できます。 Azure App Configuration を使用して機能フラグを管理することを検討してください。 詳細については、「 機能フラグ」を参照してください。

場合によっては、特定の顧客に対して特定の機能を選択的に有効にする必要があります。 たとえば、特定の機能へのアクセスを許可する価格 レベル が異なる場合があります。 通常、機能フラグは、これらのシナリオに適した選択肢ではありません。 代わりに、各顧客が持っている ライセンスの権利 を追跡して適用するプロセスを構築することを検討してください。

回避すべきアンチパターン

マルチテナント ソリューションをデプロイして構成するときは、スケーリングが妨げる状況を回避することが重要です。 これには以下が含まれます。

• 手動でのデプロイとテスト。 前述のように、手動デプロイ プロセスによってリスクが追加され、デプロイの能力が低下します。 自動化されたデプロイ、ソリューションのコードからのリソースのプログラムによる作成、またはその両方の組み合わせにパイプラインを使用することを検討してください。
• テナントに特化したカスタマイズ。 1 つのテナントにのみ適用される機能または構成のデプロイは避けてください。 このアプローチにより、デプロイとテスト プロセスが複雑になります。 代わりに、テナントごとに同じリソースの種類とコードベースを使用し、一時的な変更や段階的にロールアウトされる 機能の機能フラグ などの戦略を使用するか、ライセンスの権利を持つ 異なる価格レベル を使用して、それらを必要とするテナントの機能を選択的に有効にします。 分離されたリソースまたは専用のリソースを持つテナントでも、一貫性のある自動化されたデプロイ プロセスを使用します。

構成またはデータとしてのテナント リスト

マルチテナント ソリューションにリソースをデプロイする場合は、次の 2 つの方法を検討できます。

• 自動デプロイ パイプラインを使用して、すべてのリソースをデプロイします。 新しいテナントが追加されたら、各テナントのリソースをプロビジョニングするようにパイプラインを再構成します。
• 自動デプロイ パイプラインを使用して、テナントの数に依存しない共有リソースをデプロイします。 テナントごとにデプロイされるリソースについては、アプリケーション内に作成します。

2 つの方法を検討するときは、テナントリストを 構成 として扱うか データとして扱うかを区別する必要があります。 この区別は、システムの コントロール プレーン を構築する方法を検討する場合にも重要です。

構成としてのテナントの一覧

テナント一覧を構成として扱う場合は、一元化されたデプロイ パイプラインからすべてのリソースをデプロイします。 新しいテナントがオンボードされたら、パイプラインまたはそのパラメーターを再構成します。 通常、再構成は、次の図に示すように手動で変更を行います。

新しいテナントをオンボードするプロセスは、次のようになります。

1. テナントの一覧を更新します。 これは通常、パイプライン自体を構成するか、パイプラインの構成に含まれるパラメーター ファイルを変更することによって手動で行われます。
2. パイプラインを実行するようにトリガーします。
3. パイプラインは、新しいテナント固有のリソースを含む、Azure リソースの完全なセットを再デプロイします。

このアプローチは、少数のテナントや、すべてのリソースが共有されているアーキテクチャに適している傾向があります。 すべての Azure リソースを 1 つのプロセスを使用してデプロイおよび構成できるため、これは簡単なアプローチです。

ただし、5 ~ 10 以上など、より多くのテナントにアプローチする場合、テナントを追加するときにパイプラインを再構成するのは面倒になります。 多くの場合、デプロイ パイプラインの実行にかかる時間も大幅に増加します。 この方法では、セルフサービス テナントの作成も簡単にはサポートされません。また、パイプラインを実行するためにトリガーする必要があるため、テナントのオンボード前のリード タイムが長くなる可能性があります。

データとしてのテナント リスト

テナントリストをデータとして扱う場合でも、パイプラインを使用して共有コンポーネントをデプロイします。 ただし、テナントごとにデプロイする必要があるリソースと構成設定については、リソースを強制的にデプロイまたは構成します。 たとえば、コントロール プレーンでは 、Azure SDK を使用して特定のリソースを作成したり、パラメーター化されたテンプレートのデプロイを開始することができます。

新しいテナントをオンボードするプロセスは次のようになります。非同期的に行われます。

1. システムのコントロール プレーンへの API 要求を開始するなどして、テナントのオンボードを要求します。
2. ワークフロー コンポーネントは作成要求を受け取り、残りの手順を調整します。
3. ワークフローは、テナント固有のリソースの Azure へのデプロイを開始します。 これは、Azure SDK を使用するなど、命令型プログラミング モデルを使用するか、Bicep または Terraform テンプレートのデプロイを命令的にトリガーすることによって実現できます。
4. デプロイが完了すると、ワークフローによって新しいテナントの詳細が中央テナント カタログに保存されます。 各テナントに格納されるデータには、ワークフローで作成されたすべてのテナント固有のリソースのテナント ID とリソース ID が含まれる場合があります。

これにより、ソリューション全体を再デプロイすることなく、新しいテナントのリソースをプロビジョニングできます。 各テナントの新しいリソースのプロビジョニングにかかる時間は、それらのリソースのみをデプロイする必要があるため、短くなる可能性があります。

ただし、多くの場合、このアプローチは構築にはるかに時間がかかり、テナントの数または満たす必要があるプロビジョニング期間によって、費やす労力を正当化する必要があります。

この方法の詳細については、「 マルチテナント コントロール プレーンの考慮事項」を参照してください。

注

Azure のデプロイと構成の操作は、多くの場合、完了に時間がかかります。 これらの実行時間の長い操作を開始して監視するには、適切なプロセスを使用してください。 たとえば、 非同期 Request-Reply パターンに従うとします。 Azure Logic Apps や Durable Functions などの実行時間の長い操作をサポートするように設計されたテクノロジを使用します。

例

Contoso は、顧客向けにマルチテナント ソリューションを実行します。 現在、テナントは 6 つあり、今後 18 か月以内に 300 テナントに拡大する予定です。 Contoso は、 テナントアプローチごとに専用データベースを備えたマルチテナント アプリに 従います。 次の図に示すように、App Service リソースの 1 つのセットと、すべてのテナント間で共有される 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 | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• ボーダン・チェルチク |Azure 用 FastTrack のシニア カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• マルチテナント ソリューションの更新に関する考慮事項を確認します。
• ストレージとデータのアーキテクチャ アプローチを検討します。
• マルチテナント ソリューションで Azure Resource Manager を使用する方法を検討します。