Azure でマルチテナント ソリューションを設計および構築するには、さまざまな方法があります。 一方では、ソリューション内のすべてのリソースをすべてのテナント間で共有できます。 その一方では、すべてのテナントに対して分離されたリソースをデプロイできます。 すべてのテナントに対して個別のリソースをデプロイすることが簡単に思えますが、機能するのはテナントの数が少ない場合のみです。 ただし、通常はコスト効率が良くなく、リソースの管理が困難になる可能性があります。 また、これらの両端の間に適合するさまざまなアプローチもあります。そして、そのすべてに、スケール、分離、コスト効率、パフォーマンス、実装の複雑さ、管理のしやすさなどのトレードオフが求められます。
このセクションでは、コンピューティング、ストレージとデータ、ネットワーキング、デプロイ、ID、メッセージング、人工知能と機械学習、IoT など、ソリューションを構成する Azure サービスの主なカテゴリについて説明します。 各カテゴリについて、マルチテナント ソリューションを設計する際に考慮できる主要なパターンとアプローチ、および回避すべきいくつかのアンチパターンについて概説します。
デプロイ スタンプ パターン
デプロイ スタンプ パターンは、マルチテナント ソリューションで頻繁に使用されます。 テナントまたはテナントのグループ用の専用インフラストラクチャをデプロイします。 1 つのスタンプが複数のテナントに対応する場合もあれば、1 つのテナントに専用で割り当てられる場合もあります。
シングルテナント スタンプを使用する場合、デプロイ スタンプ パターンは実装しやすい傾向があります。各スタンプが他のスタンプを認識しない可能性が高く、マルチテナントのロジックや機能をアプリケーション レイヤーに構築する必要がないためです。 各テナントに独自の専用スタンプがある場合は、このパターンによって最高水準の分離が提供され、うるさい隣人の問題が軽減されます。 また、特定の地理的リージョン内への配置、特定の高可用性要件の設定など、独自の要件に従って、テナントを構成またはカスタマイズするオプションも用意されています。
マルチテナント スタンプを使用する場合は、他のパターンを考慮しながら、スタンプ内のマルチテナント機能を管理する必要があり、うるさい隣人の問題が引き続き適用される可能性があります。 ただし、デプロイ スタンプ パターンを使用することで、ソリューションの拡大に合わせて、継続的にスケーリングできます。
デプロイ スタンプ パターンの最大の問題は、シングルテナントへのサービス提供に使用されているとき、インフラストラクチャのコストになる傾向がある点です。 各スタンプには独自のインフラストラクチャのセットが必要であり、インフラストラクチャは他のテナントと共有されません。 また、そのテナントのワークロードのピーク負荷を満たすのに十分なリソースが、スタンプ用にデプロイされていることを確認する必要もあります。 価格モデルによって、テナントのインフラストラクチャのデプロイ コストが相殺されていることを確認してください。
シングルテナント スタンプは、多くの場合、テナントの数が少ないときにうまく機能します。 テナントの数が増えても、シングルテナント スタンプの集合を管理することは可能ですが、その管理は次第に難しくなります (例については、こちらのケース スタディを参照)。 また、デプロイ スタンプ パターンを適用して、マルチテナント スタンプを作成することもできます。これにより、リソースおよびコスト共有というメリットが得られます。
デプロイ スタンプ パターンを実装するには、自動化されたデプロイ アプローチを使用することが重要です。 デプロイ戦略によっては、Bicep ファイルや Terraform テンプレートなど、コードとしての宣言型インフラストラクチャを使用して、デプロイ パイプライン内でスタンプを管理することを考えてください。 また、たとえば Azure SDK を使用して、各スタンプをデプロイおよび管理するためのカスタム コードを作成することも検討できます。
対象ユーザー
このセクションの記事は、独立系ソフトウェア ベンダー (ISV) や SaaS ソリューションを開発するスタートアップ企業など、マルチテナント アプリケーションのソリューション アーキテクトやリード開発者を対象としています。 このセクションのガイダンスの多くが汎用的であり、カテゴリ内の複数の Azure サービスに適用されます。
次のステップ
Azure サービスの特定のカテゴリに関するガイダンスを確認する前に、マルチテナント ソリューションのリソース編成のアプローチに関するページを確認することをお勧めします。