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