自社ビジネスのソフトウェア ソリューションのうち、汎用化や他のビジネスへの販売が可能な部分を特定すると、会社に完全な新しい収益源が追加されます。 ただし、多くのテナントの負荷に対応するソリューションを構成するのは難しく、ほとんどの場合、障害となります。 このソリューションでは、トラフィックをセキュリティで保護してバランスを取る一連の Azure テクノロジを利用できます。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
Azure テクノロジ スイートによってトラフィックのセキュリティが確保され、負荷が分散されます。
Microsoft Azure Front Door によって初期タスクがいつか処理されます。
最初の要求の処理
リージョン全体への負荷分散
SSL (HTTPS) の終了とオフロード
リージョンの障害が発生した場合のフェールオーバー
Azure DNS によって DNS レコードが管理され、正しい Azure Front Door エンドポイントに確実にルーティングされます。
このアーキテクチャには、認証用の ID プロバイダーとして Microsoft Entra ID が使われます。
適切なリージョンにルーティングされると、Application Gateway によってルーティングと負荷分散が行われ、適切な Azure App Service に要求が送信されます。
このアーキテクチャでは、次の目的で App Service を使用することをお勧めします。
任意の HTTP ベースのアプリケーション。
Web コンテンツの提供。
RESTful API の公開。
フロントエンド アプリケーションの背後でのビジネス ロジックの実装。
App Service は、自動的にスケールアップおよびスケールアウトされるように構成できます。 このため、App Service は、多数のテナント HTTP ドリブン要求をオンデマンドでスケーリングするのに適しています。
データ アクセス層サービスも、負荷に基づいて個別にスケーリングされます。 データ サービスによってデータ モデル、接続クライアント、およびドライバーが管理されます。 また、サービスには、アプリケーションでデータを使用するすべての上位レベルのサービスに対して、一貫性のあるデータ インターフェイスも用意されています。 こうしたデータ サービスは、Azure Kubernetes Service (AKS) を使用してデプロイおよびスケーリングできます。 各 AKS クラスターが、レイヤー内の関連する一連の機能に対応しています。 AKS はマイクロサービ スアーキテクチャを実装できます。このアーキテクチャは一連のコンテナーを備え、各コンテナーによって、クラスター内の特定の機能がカプセル化されています。 これにより、コード内で高度な抽象化と分離ができます。 また、クラスターを個別にスケールアウトして、複数のテナントからの負荷の増加にも対応できます。 クラスターの負荷が増加した場合は、クラスターごとにそれぞれのリソースをスケールアップできます。 スケールアップしても、リソース グループ内の他のクラスターは、そのクラスターが増加していない限り影響を受けることはありません。
アプリケーション フレームワークの外部にリレーショナル データを格納して管理します。 これにより、いずれかのリージョンに対して単一のデータ入力ポイントが提供されます。 Azure SQL エラスティック プールの強みを活用すると、レプリケーション、可用性、スケーラビリティ、およびセキュリティを実現できます。 各テナントをプール内のデータベースとしてプロビジョニングします。 負荷と要求が発生したときに、プールで利用可能なリソースを、、必要に応じてデータベースに割り当てます。 これにより、テナントに使用できるデータベース リソースがご自身の予算に合わせて最適化されます。
コンポーネント
主要なコンポーネントは、このソリューションのアーキテクチャに対して推奨されるコンポーネントです。 主要なコンポーネントのいずれかがアーキテクチャに適していない場合は、代替コンポーネントの一覧を参照してください。
主要なコンポーネント
Azure Front Door: クライアント トラフィックを適切なリージョンにルーティングするリージョンのロード バランサー。 リージョンの障害が発生した場合は、2 番目のリージョンにフェールオーバーできます。また、Azure Web Application Firewall を介してインターネットに接続するエントリ ポイントをセキュリティで保護できます。
Microsoft Entra ID: アプリケーション全体の ID プロバイダーとして機能し、アプリケーションで要求の認証とエンド ツー エンドの認可を適用します。
Azure DNS:ドメイン名の解決のための Azure のホスティング サービス。 マルチテナント ソリューションでは、複数のクライアントがそれぞれ個別のドメインを介してソリューションにアクセスします。 Azure DNS を使用して、適切なアプリケーション スタックへのクライアント要求を構成して解決します。
Application Gateway:アプリケーション内部のトラフィックを、クライアントのビジネス ニーズを満たすさまざまなサービスにルーティングし、負荷を分散します。 Azure Front Door は高レベルのリージョン間で負荷を分散しますが、Application Gateway として、グループ内の個々のサービスの負荷も認識しています。 Azure Front Door と Application Gateway を組み合わせることにより、マルチテナント ソリューションのすべてのレベルで複雑な負荷分散が実現します。 Azure の負荷分散オプションの詳細については、「Azure の負荷分散オプションの概要」を参照してください。
App Service: Web アプリケーションおよび Web ベースの API 向けの Azure のプレミア サービス。 セキュリティは Microsoft Entra ID や Azure Key Vault などのサービスと統合されています。 自動スケーリングを構成できます。 また、スケーリングに使用できるリソースの量は、アプリを実行できるさまざまな App Service プランの間で柔軟に調整できます。 複数の環境への継続的インテグレーションとデプロイのために、統合された DevOps 機能を App Service で利用することもできます。 Azure プラットフォームのこうした機能やその他のサポート機能により、開発者はアプリケーション開発に専念できます。
Azure Kubernetes Service (AKS): クラスターにデプロイされたコンテナー イメージのインスタンスを調整します。 複数のクライアントのデータを管理するには、多くの場合、以下を管理するための一連のコンポーネントを実装する必要があります。
データ モデリング
データ ソース接続
抽出、変換、読み込み (ETL)
インポート/エクスポート アクティビティ
このような小さなコンポーネントを多数、コンテナー ベースのマイクロサービスとして開発すると、AKS クラスターへのデプロイに適したシナリオが作成されます。 自動スケール、負荷分散、およびアップグレードを行うための各ツールが、フレームワークに組み込まれています。 AKS は、利用可能な DevOps 機能と Azure Container Registry を使用して、継続的インテグレーション/継続的デリバリー (CI/CD) 戦略と緊密に統合されています。
Azure SQL エラスティック プール: リソース プールを使って一連のデータベースを柔軟に管理するためのソリューションを提供します。 サービスによって、リソースが必要に応じてデータベースに割り当てられ、 マルチテナント SaaS アーキテクチャの開発者は、必要に応じてデータベース リソースをクライアントに配信できます。 また、このサービスにより、未使用のコンピューティング リソースが大量に含まれる、複数の SQL Server を維持するための予算とオーバーヘッドが削減されます。
Azure Cognitive Search (以前の Azure Search): アプリケーションに強力なインデックス機能とクエリ エンジンを追加するサービス。 これによりクライアントが強力なクエリ機能にアクセスできます。 また、Azure の AI 機能を使用して、クエリ機能を強化および拡張することもできます。 Azure Cognitive Search は、テナントごとのインデックスまたはテナントごとのサービス戦略を利用して、マルチテナントを構成できます。
Azure Cache for Redis:キャッシュ レイヤーをサービスとしてソリューションに適用し、インメモリ マネージド キャッシュを提供することで待機時間を短縮し、クライアントのパフォーマンスを向上させます。 高スループットのため大量の要求が可能で、システムにアクセスするテナントを複数処理できます。 アプリケーションの負荷の増加に伴って、サービスは柔軟にスケールアップできます。 保存時の暗号化もサポートされ、キャッシュされたテナント データが保護および分離されます。
代替コンポーネント
Azure Virtual Machine Scale Sets: 必要に応じて自動的にスケーリングおよび拡張される仮想マシン (VM) 環境にサービスをデプロイできます。 Virtual Machine Scale Sets は Load Balancer または Application Gateway と緊密に統合され、スケール セットの拡大に応じて負荷が自動的に再調整されます。 Virtual Machine Scale Sets によって、このソリューションで必要なスケーラビリティが提供されますが、 多くの場合、完全な VM 環境を管理する必要はなく、そのレベルのスタックを App Service または AKS に延期できます。
Azure SQL Database:エラスティック プールの代わりに、個別の専用インスタンスとしてを実装します。 Azure SQL Database を使用すると、インスタンスを直接管理する際のオーバーヘッドが増加し、割り当てられたリソースに対してより多くのコストが発生します。 そうは言うものの、テナントに専用サーバーが必要な場合は、この代替手段も有効です。 特に、インスタンスおよび使用可能な専用リソースに対してより細かな制御が、クライアントに必要な場合があります。 専用 SQL Server を必要とするテナントは、エラスティック プール構成でテナントと並行して存在できます。 SaaS のライセンスを購入するとき、SQL データベースの価格レベルを、テナントが使用できる価格オプションに設定できます。
SQL Server on Virtual Machines: SQL データベースのデプロイ オプションの 1 つ。 テナントに、事前に存在する IT インフラストラクチャと、オンプレミスの既存の SQL Server が含まれている場合があります。 その場合、テナントは、現在のライセンスを、完全な移行またはハイブリッド シナリオで使用できます。 SaaS の分離特性により、アプリケーションのデータ層は、構成を介して任意の SQL Database を対象にすることができます。
シナリオの詳細
自社ビジネスのソフトウェア ソリューションのうち、汎用化や他のビジネスへの販売が可能な部分を特定すると、会社に完全な新しい収益源が追加されます。 ただし、多くのテナントの負荷に対応するソリューションを構成するのは難しく、ほとんどの場合、障害となります。
Azure には、以下を実現できるソフトウェア ソリューション管理サービスが用意されています。
すべてのクライアントのデータベースを柔軟に管理する。
ソリューションのビジネス層とロジック層をスケーリングして、コンピューティング レイヤーでのボトルネックを回避する。
可用性とリージョン内フェールオーバーを統合する。
すべてのソリューション レベルでエンド ツー エンド セキュリティを提供する。
考えられるユース ケース
次のユース ケースの設計パターンは、Azure でホストされているマルチテナント SaaS ソリューションからメリットを得ることができます。
顧客に販売できるカスタマー リレーションシップ マネジメント (CRM) ソリューションを開発する。
コンテンツ管理システム (CMS) システムを実装し、このアーキテクチャを使用して複数のユーザーに配信する。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
マルチテナント
このソリューションでは、マルチテナント ソリューションが重要な考慮事項です。 ソリューションにより、多くのクライアントが同時に処理されます。 また、すべてのクライアント要求を効果的に処理するためのリソースが十分に割り当てられます。 要求の処理中、ソリューションによってグローバル エンドポイントからのトラフィックがセキュリティで保護され、侵害と相互汚染を防ぐためにクライアント データが分離されます。 プライマリ ロケーションに基づいて、クライアントが 1 組のリージョン リソース グループに展開されます。 これにより、リージョン別の提供状況が最適化されます。
多数のクライアントを 1 つのコンピューティング グループに展開できます。これは、認証とクライアント キーに基づいて要求が分離され、これらの一意の識別子に基づいて要求が区別されるためです。 すべてのクライアント要求がキーによって個別に暗号化できるため、どのクライアントも他のクライアントのデータを暗号化解除できません。 1 つのコンピューティング スタックで複数のクライアントを管理すると、リソース割り当てを最適化し、コストに応じて必要な応答性をクライアントに提供できます。
クライアント要求はリージョン スタックから到着する可能性があるため、クライアント データベースの管理方法は、コンピューティング スタックの外部と同様です。 多くのクライアント データベースが、Transparent Data Encryption (TDE) によって分離され、セキュリティで保護された同じエラスティック プールに存在できます。 クライアント管理キーを使用してデータが暗号化されるように各データベースを構成し、Just-In-Time (JIT) でデータの暗号化を解除できます。 JIT で復号化すると、開発者とその他のクライアントの両方からクライアント データを保護できます。 エラスティック プールが利用され、それに割り当てられたクライアントにリソースが必要に応じて提供される一方で、コストは低く抑えられます。 レプリケーション ポリシーを各エラスティック プールに割り当てると、クライアント データのバックアップとフェールオーバーを実現できます。 システムにオンボードするクライアントを増やす場合は、より多くのエラスティック プールをオンラインにします。
マルチテナント ソリューションの詳細については、「Azure でのマルチテナント ソリューションを設計」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
スケーラビリティと可用性
このソリューションは、SaaS を使用して多数のテナントに対応するよう設計され、 多くのスケーラブルなコンポーネントとサービスを利用して、負荷に基づいて拡大します。 このアーキテクチャは、少数のテナントや、負荷の少ない要求およびデータにサービスを提供するソリューション向けに設計されたものではありません。 1 つのクライアントまたは少ない負荷を対象としたソリューションについては、その予算を圧迫することがあります。 また、グローバルな高可用性は不必要な複雑さとコストを増やすため、これが要件ではない場合、マルチリージョンのオーバーヘッドは不必要です。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
セキュリティについては、アプリケーションのレベルごとにエンド ツー エンドで対処されます。
Azure Front Door には、そのドメインの HTTPS サポートが組み込まれています。 つまり、SaaS アプリケーションへのすべてのトラフィックを暗号化できます。 また、Azure Front Door は Azure Web アプリケーション ファイアウォールを実装することで、要求がアプリケーションにルーティングされる前のエッジでの攻撃から SaaS スタックを保護します。
各リージョンの各アプリケーション スタックが、Azure Virtual Network 内にあります。 Azure Front Door からの要求を受け入れる仮想ネットワークへのトラフィックが制限され、すべてのアプリケーション サービスが外部トラフィックから保護されます。 セキュリティで保護されたファイアウォールの内部では、Application Gateway が SSL を終了し、アプリケーション内でパフォーマンスに優れた負荷分散とルーティングを提供できます。
Azure Key Vault を使用して、資格情報、シークレット、接続文字列をすべて安全に管理できます。 この機密データをシークレットとして管理することで、開発者が、デプロイ時に資格情報をアプリケーションに挿入できます。 これにより、機密情報がコードに入力されるのを確実に防ぐことができます。 シークレットを使用すると、コードの侵害や中間者攻撃によるテナント データベース アクセスができなくなり、これによりクライアント データが保護されます。
このシナリオでは、複数のテナントのデータが、同じデータベース サーバーに共存している可能性があります (同じデータベースではない場合)。 TDE と JIT 復号化を使用すると、データベース上のデータが保護されます。 保存データベースのすべてのデータが暗号化され、暗号化が解除されるのは、テナントから要求された場合だけです。 クライアントからは独自のキーが提供され、すべてのクライアント キーを Azure Key Vault に格納して、複数のテナントの暗号化を管理できます。 これはクライアント データをエンド ツー エンドで保護し、開発者がクライアント データにアクセスするのを防ぎます。また、テナント間でデータを分離し、セキュリティとデータのコンプライアンス要件を満たすうえで役立ちます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
Azure App Service には、必要な想定されるコンピューティング リソースに基づく多くの価格レベルが用意されています。 マルチテナント SaaS の場合、サービス プランを選択するうえで重要なコンポーネントとなるのが高可用性とスケールアウト機能です。 多数のテナントをホストする場合は、Premium または Isolated レベルを選んで、高トラフィック対応に必要なコンピューティング リソースを提供しなければならないことがあります。 Standard レベル、Premium レベル、および分離レベルはすべて専用の VM インスタンスです。 時間単位あたりのコストは、指定したレベルの VM の数によって計算できます。 詳細については、App Service 価格プランの概要に関するページをご覧ください。
Azure Kubernetes Service は、コスト効率に優れたコンテナー サービスを提供します。 AKS ノードの料金は使用量に応じて発生するため、以下についてのみ課金されます。
VM
使用されたストレージとネットワーク リソース
使用状況に直接関連するスケーリング コスト
コストを削減するには、AKS をデータ層サービスとして使用するのが理想的です。 AKS インスタンス レイヤーの価格の見積もりについては、Kubernetes サービス料金計算ツールに関するページをご覧ください。
仕様上、Azure SQL エラスティック プールの価格は、マルチテナント シナリオでのコスト効率が非常に優れています。 使用可能なリソースが、エラスティック プールのテナント データベースによって共有され、 時間の経過に伴ってテナント間で要求が移動すると、リソースも動きます。 Azure SQL エラスティック プールによって、使用可能な最大リソース数が、必要なデータベースに提供されます。どのデータベースでもリソースのオーバーヘッドが発生することはありません。 このサービスにより、SaaS とテナントの開発者に対するコストが低く抑えられます。 Azure SQL Database の料金計算ツールを使用して料金を確認し、料金レベルと、お使いのテナントとそのデータにサービスを提供するのに必要なリソースの量を確認します。
仮想コアの価格モデルを使用すると、必要なリソースに合わせてより柔軟なスケーリングが可能です。 また、Azure ハイブリッド特典を利用することもできます。 既存の SQL Server ライセンスにより、クラウド内の仮想コア SQL リソースに割引が提供されるため、 そのため、インスタンスでオンプレミスのサーバーが既に開発者インフラストラクチャに含まれている場合は、これらの割引を利用して、さらにコストを管理できます。 Azure ハイブリッド特典の節約額計算ツールを使用すると、見込みの節約額を見積もることができます。
Azure SQL Database 予約容量を購入して、SQL Server リソースのコストを節約することもできます。 予約容量を購入すると、長期的な SQL Database 使用のコミットメントが示されます。 期間は、通常、1 ～ 3 年で、 予約されているリソースのコンピューティング コストに割引が適用されます。 たとえば、32 個の汎用仮想コアを 1 年間予約すると、その年はその 32 個の仮想コアのコストが削減されます。 複数のテナントが SaaS のライセンスを購入することは、予約容量の使用がソリューションと一致していることを示す強い指標であり、このワークロードでは理想的なコストの節約になります。
Azure Cache for Redis の価格体系については、「Azure Cache for Redis の価格」ページを参照してください。 必要に応じて、Basic、Standard、Premium の各レベルの間でいつでもキャッシュ階層を調整できます。 より緩いキャッシュ制限や、レプリケーション、ディザスター リカバリーなど、追加機能に対する高い料金が表示されます。 Azure Cache for Redis には、長期的なコミットメントの予約容量に対する価格も用意されています。
Azure Front Door の価格は、サービスとの間でのデータ転送 (送受信) 量によって異なります。 送信データの場合、価格はゾーンによって異なります。 さまざまなリージョンによって、さまざまなコストが発生します。 価格に違いが見つかったら、コストを個別に見積もります。 価格にはルーティングとドメイン容量が多少含まれていますが、初期制限を超えた分にコストが発生します。 Azure Web Application Firewall を使用すると、適用されたポリシーまたはルールごとに、若干の追加料金がかります。 Azure Front Door の価格の詳細については、「Azure Front Door の価格」を参照してください。
Azure Cognitive Search の価格体系は、完全に階層化されています。 Free レベルは、開発とテストに使用できます。 その後、それぞれの階層について、割り当てられた Cognitive Search インスタンスごとに時間単位のコストが発生します。 階層が増えると、ストレージの合計、インデックス数、およびスケールアウトの制限も増えます。 Azure Cognitive Search によって、画像抽出がサービスとしてすべての有料レベルに同じ料金で提供されます。
次のステップ
Microsoft Entra ID のアプリケーションとサービス プリンシパル オブジェクトは、Microsoft Entra ID を利用してマルチテナント アプリを実装するためのものです。
「マルチテナント SaaS データベース テナント パターン」では、SQL でのマルチテナント パターンの実装について説明します。
Microsoft Entra ID のテナントも、Microsoft Entra ID を利用してマルチテナント アプリを実装するためのものです。
関連リソース
「高可用性を得るために複数の Azure リージョンで web アプリケーションを実行する」は、ソリューションのマルチリージョン要件のリファレンスです。
「Azure における高可用性とディザスター リカバリー用にビルドされた多層 Web アプリケーション」は、類似したサンプル ワークロード シナリオで、 Azure の大規模なアプリケーションに関する多くの考慮事項について説明しています。