Azure Front Door は、最新のクラウド コンテンツ配信ネットワーク (CDN) であり、世界中のユーザーとアプリケーションの静的および動的 Web コンテンツの間で、高速で信頼性の高いアクセスを提供します。 このアーティクルでは、マルチテナント システムで作業する場合に役立つ Azure Front Door の機能の一部について説明します。 また、関連するその他のガイダンスと例も示します。
マルチテナント ソリューションの一部として Azure Front Door を使用する場合は、ソリューションの設計と要件に基づいていくつかの決定を行う必要があります。 次の要因について検討します。
現在持っているテナントの数と、今後使用する予定のテナントの数を検討します。
複数のテナント間でアプリケーション層を共有するか、多数のシングルテナント アプリケーション インスタンスをデプロイするか、複数のテナントが共有する個別のデプロイ スタンプをデプロイするかを決定します。
テナントが独自のドメイン名を持ち込むかどうかを特定します。
ワイルドカード ドメインを使用するかどうかを決定します。
独自のトランスポート層セキュリティ (TLS) 証明書を使用する必要があるか、Microsoft が TLS 証明書を管理するのかを評価します。
Azure Front Door に適用される クォータと制限 を考慮してください。 ソリューションのスケーリングに応じてアプローチできる制限を特定します。 これらの制限に近い場合は、複数の Azure Front Door プロファイルを使用するか、Azure Front Door を使用して許容される制約内に留まるように調整することを検討してください。 Premium SKU には、Standard SKU よりも高い制限があります。
自分またはテナントが、IP アドレスのフィルター処理、geo ブロック、または Web アプリケーション ファイアウォール規則のカスタマイズの要件を持っているかどうかを判断します。
すべてのテナントのアプリケーション サーバーがインターネットに接続されているかどうかを確認します。
マルチテナント機能をサポートする Azure Front Door の機能
このセクションでは、マルチテナント ソリューションに役立つ Azure Front Door のいくつかの主要な機能について説明します。 ワイルドカード ドメインと TLS 証明書に関する情報など、Azure Front Door を使用してカスタム ドメインを構成する方法について説明します。 また、Azure Front Door ルーティング機能を使用してマルチテナントをサポートする方法についても説明します。
カスタム ドメイン
Azure Front Door には、 contoso.z01.azurefd.netなど、作成する各エンドポイントの既定のホスト名が用意されています。 ただし、ほとんどのソリューションでは、独自のドメイン名を Azure Front Door エンドポイントに関連付けます。 カスタム ドメイン名を使用すると、独自のブランドを使用し、クライアントの要求に含まれるホスト名に基づいてルーティングを構成できます。
マルチテナント ソリューションでは、テナント固有のドメイン名またはサブドメインを使用し、テナントのトラフィックをそのテナントのワークロードの正しい配信元グループにルーティングするように Azure Front Door を構成できます。 たとえば、tenant1.app.contoso.com のようなカスタム ドメイン名を構成できます。 1 つの Azure Front Door プロファイルで複数のカスタム ドメインを構成できます。
詳細については、「 Azure Front Door にカスタム ドメインを追加する」を参照してください。
ワイルドカード ドメイン
ワイルドカード ドメインを使用すると、共有ステム ドメインとテナント固有のサブドメインを使用する場合に、ドメイン ネーム システム (DNS) レコードと Azure Front Door トラフィック ルーティングの構成が簡略化されます。 たとえば、テナントが tenant1.app.contoso.com や tenant2.app.contoso.com などのサブドメインを使用してアプリケーションにアクセスするとします。 各テナント固有のドメインを個別に構成する代わりに、ワイルドカード ドメイン、*.app.contoso.com を構成できます。
Azure Front Door では、ワイルドカードを使用するカスタム ドメインの作成がサポートされています。 その後、ワイルドカード ドメインに到着する要求のルートを構成できます。 新しいテナントをオンボードするときに、DNS サーバーを再構成したり、新しい TLS 証明書を発行したり、Azure Front Door プロファイルの構成を更新したりする必要はありません。
ワイルドカード ドメインは、すべてのトラフィックを 1 つの配信元グループに送信する場合に適切に機能します。 ただし、ソリューションのスタンプが別々にある場合は、単一レベルのワイルドカード ドメインでは不十分です。 複数レベルのステム ドメインを使用するか、追加の構成を指定する必要があります。 たとえば、各テナントのサブドメインのルートをオーバーライドできます。 詳細については、マルチテナント ソリューションでドメイン名を使用する場合の考慮事項を参照してください。
Azure Front Door では 、ワイルドカード ドメインのマネージド TLS 証明書は発行されないため、独自の証明書を購入して指定する必要があります。
マネージド TLS 証明書
TLS 証明書の取得とインストールは、複雑でエラーが発生しやすいプロセスになる可能性があります。 TLS 証明書は一定期間 (通常は 1 年) 後に期限切れになり、アプリケーション トラフィックの中断を避けるために再発行して再インストールする必要があります。 Azure Front Door で管理される TLS 証明書を使用する場合、Microsoft はカスタム ドメインの証明書の発行、インストール、更新を担当します。
配信元アプリケーションは、Azure App Service などのマネージド TLS 証明書も提供する別の Azure サービスでホストされている場合があります。 Azure Front Door は、他のサービスと透過的に連携して TLS 証明書を同期します。
テナントが独自のカスタム ドメインを提供でき、Azure Front Door でこれらのドメイン名の証明書を発行する場合、テナントは DNS サーバーで証明機関承認 (CAA) レコードを構成しないでください。 これらのレコードにより、Azure Front Door がテナントに代わって証明書を発行できなくなる可能性があります。 マルチテナントの詳細については、マルチテナント ソリューションの TLS 証明書と SSL 証明書に関する説明を参照してください。 Azure Front Door の詳細については、「Azure Front Door を使用した TLS 暗号化」を参照してください。
ルーティング
マルチテナント アプリケーションには、テナントにサービスを提供する 1 つ以上のアプリケーション スタンプがある場合があります。 スタンプは、マルチリージョンデプロイを有効にしたり、多数のテナントへのソリューションのスケーリングをサポートしたりするために頻繁に使用されます。
Azure Front Door には、多くのマルチテナント アーキテクチャをサポートできる強力なルーティング機能のセットがあります。 ルーティングを使用すると、スタンプ内の配信元間でトラフィックを分散したり、特定のテナントの正しいスタンプにトラフィックを送信することができます。 個々のドメイン名、ワイルドカード ドメイン名、および URL パスに基づいてルーティングを構成できます。 また、ルール エンジンを使用して、ルーティング動作をさらにカスタマイズできます。
詳しくは、ルーティング アーキテクチャの概要をご覧ください。
ルール エンジン
Azure Front Door ルール エンジンを使用して、Azure Front Door がネットワーク エッジで要求を処理する方法をカスタマイズできます。 ルール エンジンを使用すると、Azure Front Door 要求処理パイプライン内でロジックの小さなブロックを実行できます。 ルール エンジンは、次のリスト 項目を含むが、これらに限定されないさまざまなタスクに使用できます。
URL とパスのセグメントを含む HTTP 要求に関する情報を取得し、その情報を要求の別の部分に伝達する。
HTTP 要求が配信元に送信される前に、要求の要素を変更する。
クライアントに返される前に、HTTP 応答の要素を変更します。
要求の送信先となる配信元グループの変更などにより、要求のルーティング構成をオーバーライドする。
次のアプローチ例では、マルチテナント ソリューションで Azure Front Door ルール エンジンを使用します。
次のシナリオ例で説明するように、テナント固有のワイルドカード サブドメインも使用するマルチテナント アプリケーション層をデプロイするとします。 ルール エンジンを使用して、要求サブドメインからテナント識別子を抽出し、それを要求ヘッダーに追加できます。 この規則は、アプリケーション層が要求の元となるテナントを決定するのに役立ちます。
マルチテナント アプリケーション層をデプロイし、それぞれテナント 1 とテナント 2 の
https://application.contoso.com/tenant1/welcomeやhttps://application.contoso.com/tenant2/welcomeなどのパスベースのルーティングを使用するとします。 ルール エンジンを使用して、URL パス セグメントからテナント識別子セグメントを抽出し、URL を書き換えて、アプリケーションが使用するクエリ文字列パラメーターまたは要求ヘッダーにテナント識別子を含めることができます。
詳細については、「 Azure Front Door ルール エンジン」を参照してください。
シナリオの例
次のシナリオ例は、Azure Front Door でさまざまなマルチテナント アーキテクチャを構成する方法と、行った決定が DNS と TLS の構成にどのように影響するかを示しています。
多くのマルチテナント ソリューションでは、デプロイ スタンプ パターンが実装されています。 このデプロイ アプローチを使用する場合、通常は 1 つの共有 Azure Front Door プロファイルをデプロイし、Azure Front Door を使用して受信トラフィックを適切なスタンプにルーティングします。 このデプロイ モデルは最も一般的なモデルであり、このアーティクルのシナリオ 1 から 4 では、それを使用してさまざまな要件を満たす方法を示します。
ただし、場合によっては、ソリューションの各スタンプに Azure Front Door プロファイルをデプロイすることがあります。 シナリオ 5 では、このデプロイモデルを説明します。
シナリオ 1: プロバイダーマネージド ワイルドカード ドメイン、単一スタンプ
Contoso は、小規模なマルチテナント ソリューションを構築しています。 会社は 1 つのリージョンに 1 つのスタンプをデプロイし、そのスタンプはすべてのテナントにサービスを提供します。 すべての要求は、同じアプリケーション サーバーにルーティングされます。 Contoso は、 tenant1.contoso.com や tenant2.contoso.comなど、すべてのテナントにワイルドカード ドメインを使用することにしました。
Contoso は、次の構成を使用して Azure Front Door をデプロイします。
DNS の構成
1 回限り構成: Contoso は、2 つの DNS エントリを構成します。
*.contoso.comのワイルドカード TXT レコードは、カスタム ドメインのオンボード プロセス中に Azure Front Door によって指定される値に設定されます。ワイルドカード CNAME レコード (
*.contoso.com) は、Contoso の Azure Front Door エンドポイントcontoso.z01.azurefd.netのエイリアスです。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
TLS の構成
1 回限り構成: Contoso はワイルドカード TLS 証明書を購入し、キー コンテナーに追加し、Azure Front Door にコンテナーへのアクセス権を付与します。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
Azure Front Door の構成
1 回限り構成: Contoso は、Azure Front Door プロファイルと 1 つのエンドポイントを作成します。
*.contoso.comという名前のカスタム ドメインを 1 つ追加し、ワイルドカード TLS 証明書をそのカスタム ドメイン リソースに関連付けます。彼らはアプリケーションサーバーの単一のオリジンを含む単一のオリジングループを構成します。
カスタム ドメインを配信元グループに接続するようにルートを構成します。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
メリット
このシナリオは比較的簡単に構成でき、Contoso ブランドの URL を顧客に提供します。
この方法では、多数のテナントがサポートされています。
新しいテナントがオンボードされている場合、Contoso は Azure Front Door、DNS、または TLS 証明書を変更する必要はありません。
デメリット
この方法では、1 つのアプリケーション スタンプまたはリージョンを超えて簡単にスケーリングすることはできません。
Contoso はワイルドカード TLS 証明書を購入し、有効期限が切れたときに証明書を更新してインストールする必要があります。
シナリオ 2: プロバイダーマネージド ワイルドカード ドメイン、複数のスタンプ
Proseware は、オーストラリアとヨーロッパの両方にデプロイされる複数のスタンプにまたがるマルチテナント ソリューションを構築しています。 1 つのリージョン内のすべての要求は、そのリージョンのスタンプによって処理されます。 Contoso と同様に、Proseware では、 tenant1.proseware.com や tenant2.proseware.comなど、すべてのテナントにワイルドカード ドメインを使用することにしました。
Proseware では、次の構成を使用して Azure Front Door がデプロイされます。
DNS の構成
1 回限り構成: Proseware では、2 つの DNS エントリが構成されます。
*.proseware.comのワイルドカード TXT レコードは、カスタム ドメインのオンボード プロセス中に Azure Front Door によって指定される値に設定されます。ワイルドカード CNAME レコード (
*.proseware.com) は、Proseware の Azure Front Door エンドポイントproseware.z01.azurefd.netのエイリアスです。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
TLS の構成
1 回限り構成: Proseware はワイルドカード TLS 証明書を購入し、キー コンテナーに追加し、Azure Front Door にコンテナーへのアクセス権を付与します。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
Azure Front Door の構成
1 回限り構成: Proseware では、Azure Front Door プロファイルと 1 つのエンドポイントが作成されます。 この会社では、リージョンごとにアプリケーション スタンプまたはサーバーごとに 1 つずつ、複数の配信元グループを構成します。
新しいテナントがオンボードされたとき: Proseware は、カスタム ドメイン リソースを Azure Front Door に追加します。
*.proseware.comという名前を使用し、ワイルドカード TLS 証明書をカスタム ドメイン リソースに関連付けます。テナントの要求の転送先となる配信元グループまたはスタンプを指定するルートを作成します。 前の図では、オーストラリアリージョンの配信元グループへのルートを
tenant1.proseware.comし、ヨーロッパ リージョンの配信元グループへのルートをtenant2.proseware.comしました。
メリット
新しいテナントがオンボードされている場合、DNS または TLS 構成の変更は必要ありません。
Proseware では、複数のリージョン間で複数のスタンプにトラフィックをルーティングするために、Azure Front Door の 1 つのインスタンスが維持されます。
デメリット
Proseware では、新しいテナントがオンボードされるたびに Azure Front Door を再構成する必要があります。
Proseware は、Azure Front Door のクォータと制限、特にルートとカスタムドメインの数、および複合ルーティングの制限に注意を払う必要があります。
Proseware では、ワイルドカード TLS 証明書を購入する必要があります。
Proseware は、証明書の有効期限が切れたときの更新とインストールを担当します。
シナリオ 3: プロバイダー管理のスタンプベースのワイルドカード サブドメイン
Fabrikam はマルチテナント ソリューションを構築しています。 同社はオーストラリアと北米にスタンプを展開しています。 1 つのリージョン内のすべての要求は、そのリージョンのスタンプによって処理されます。 Fabrikam では、 tenant1.australia.fabrikam.com、 tenant2.australia.fabrikam.com、 tenant3.us.fabrikam.comなどのスタンプベースのステム ドメインが使用されます。
会社は、次の構成を使用して Azure Front Door をデプロイします。
DNS の構成
1 回限り構成: Fabrikam は、スタンプごとに次の 2 つのワイルドカード DNS エントリを構成します。
スタンプごとに、ワイルドカード TXT レコードの
*.australia.fabrikam.comと*.us.fabrikam.comは、カスタム ドメインのオンボード プロセス中に Azure Front Door が指定する値に設定されます。スタンプごとに、ワイルドカード CNAME レコード
*.australia.fabrikam.comと*.us.fabrikam.comはどちらも Azure Front Door エンドポイントfabrikam.z01.azurefd.netのエイリアスです。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
TLS の構成
1 回限り構成: Fabrikam は各スタンプのワイルドカード TLS 証明書を購入し、キー コンテナーに追加し、Azure Front Door にコンテナーへのアクセス権を付与します。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
Azure Front Door の構成
1回限りの構成: Fabrikam は、Azure Front Door プロファイルと単一のエンドポイントを作成します。
スタンプごとに配信元グループを構成します。
スタンプ ベースのサブドメイン (
*.australia.fabrikam.comと*.us.fabrikam.com) ごとにワイルドカードを使用して、カスタム ドメインを作成します。各スタンプのカスタム ドメインのルートを作成して、適切な配信元グループにトラフィックを送信します。
新しいテナントがオンボードされたとき: 追加の構成は必要ありません。
メリット
このアプローチにより、Fabrikam は多数のテナントに対応できるように複数のデータセンターで拡張することができます。
新しいテナントがオンボードされている場合、DNS または TLS 構成の変更は必要ありません。
Fabrikam では、複数のリージョン間で複数のスタンプにトラフィックをルーティングするために、Azure Front Door の 1 つのインスタンスが維持されます。
デメリット
URL はマルチパート の Stem ドメイン構造を使用するため、ユーザーが操作する URL は複雑になる可能性があります。
Fabrikam では、複数のワイルドカード TLS 証明書を購入する必要があります。
Fabrikam は、有効期限が切れたときの TLS 証明書の更新とインストールを担当します。
シナリオ 4: バニティ ドメイン
Adventure Works Cycles は、マルチテナント ソリューションを構築しています。 同社は、オーストラリアや北米など、複数のリージョンにスタンプを展開しています。 1 つのリージョン内のすべての要求は、そのリージョンのスタンプによって処理されます。 Adventure Works を使用すると、テナントは独自のドメイン名を持ち込めます。 たとえば、テナント1はtenant1app.tenant1.comのようなカスタムドメイン名を設定できます。
会社は、次の構成を使用して Azure Front Door をデプロイします。
DNS の構成
1 回限り構成: なし。
新しいテナントがオンボードされたとき: テナントは、独自の DNS サーバーに 2 つのレコードを作成する必要があります。
TXT レコードはドメイン検証用です。 たとえば、テナント 1 では、
tenant1app.tenant1.comという名前の TXT レコードを構成し、カスタム ドメインのオンボード プロセス中に Azure Front Door によって指定される値に設定する必要があります。CNAME レコードは、Adventure Works の Azure Front Door エンドポイントのエイリアスです。 たとえば、テナント 1 では、
tenant1app.tenant1.comという名前の CNAME レコードを構成し、adventureworks.z01.azurefd.netにマップする 必要があります。
TLS の構成
Adventure Works とそのテナントは TLS 証明書の発行元を決定する必要があります。
最も簡単なオプションは、Azure Front Door を使用して証明書を発行および管理することです。 ただし、テナントは DNS サーバーで CAA レコードを構成しないでください。 その場合、レコードによって Azure Front Door 証明機関が証明書を発行できなくなる可能性があります。
または、テナントが独自の証明書を提供することもできます。 Adventure Works と連携して証明書をキー コンテナーにアップロードし、Azure Front Door へのアクセスを提供する必要があります。
Azure Front Door の構成
1 回限りの構成: Adventure Works は、Azure Front Door プロファイルと単一のエンドポイントを作成します。 スタンプごとに配信元グループを構成します。 カスタム ドメイン リソースやルートは作成されません。
新しいテナントがオンボードされたとき: Adventure Works は、カスタム ドメイン リソースを Azure Front Door に追加します。
テナント指定のドメイン名を使用し、適切な TLS 証明書をカスタム ドメイン リソースに関連付けます。
次に、テナントの要求の転送先となる配信元グループまたはスタンプを指定するルートを作成します。 前の図では、
tenant1app.tenant1.comはオーストラリア リージョンの配信元グループへのルートとなり、tenant2app.tenant3.comは米国 リージョンの配信元グループへのルートとなります。
メリット
お客様は、独自のドメイン名を指定できます。 Azure Front Door は、マルチテナント ソリューションに要求を透過的にルーティングします。
Adventure Works では、複数のリージョン間で複数のスタンプにトラフィックをルーティングするために、Azure Front Door の 1 つのインスタンスが維持されます。
デメリット
Adventure Works では、新しいテナントがオンボードされるたびに Azure Front Door を再構成する必要があります。
テナントは、オンボーディング プロセスに関与する必要があります。 DNS を変更し、TLS 証明書を発行する必要があります。
テナントは DNS レコードを制御します。 DNS レコードに対する変更は、Adventure Works ソリューションにアクセスする機能に影響する可能性があります。
Adventure Works では、Azure Front Door のクォータと制限に注意を払う必要があります。特にルートやカスタムドメインの数、そして複合ルーティングの制限に注意が必要です。
シナリオ 5: 各スタンプの Azure Front Door プロファイル
スタンプごとに Azure Front Door プロファイルをデプロイできます。 10 個のスタンプがある場合は、Azure Front Door のインスタンスを 10 個デプロイします。 この方法は、各スタンプの Azure Front Door 構成の管理アクセスを制限する必要がある場合に便利です。 また、リソース クォータまたは制限を超えないように、複数の Azure Front Door プロファイルを使用する必要がある場合にも役立ちます。
ヒント
Azure Front Door は、グローバルなリソースです。 リージョンスコープのスタンプをデプロイする場合でも、各 Azure Front Door プロファイルはグローバルに分散されます。 実際に複数の Azure Front Door プロファイルをデプロイし、それが提供する特定の利点を評価する必要があるかどうかを検討する必要があります。
複数のテナントにサービスを提供するスタンプがある場合は、各テナントにトラフィックをルーティングする方法を検討する必要があります。 前のシナリオで説明した方法を確認します。 要件に合わせてアプローチを組み合わせることを検討してください。
メリット
構成を複数のプロファイルにわたって拡張する場合、Azure Front Door リソースの制限に達する可能性は低くなります。 たとえば、多数のカスタム ドメインをサポートする必要がある場合は、ドメインを複数の Azure Front Door プロファイルに分割し、各プロファイルの制限内に留めることができます。
この方法を使用すると、Azure Front Door のリソース管理アクセス許可のスコープを設定できます。 Azure ロールベースのアクセス制御を使用して、管理者に 1 つのスタンプのプロファイルへのアクセス権を付与できます。
デメリット
この方法では、通常、より多くのプロファイルをデプロイするため、高いコストが発生します。 詳細については、「 Azure Front Door の課金について」を参照してください。
1 つの Azure サブスクリプションにデプロイできる Azure Front Door プロファイルの数には制限があります。 詳細については、「 Azure Front Door のクォータと制限」を参照してください。
各スタンプの Azure Front Door プロファイルを個別に構成する必要があり、各スタンプの DNS 構成、TLS 証明書、TLS 構成を管理する必要があります。
共同作成者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要執筆者
- John Downs | プリンシパル ソフトウェア エンジニア
- Raj Nemani | ディレクター、パートナー テクノロジーストラテジスト
その他の共同作成者:
Mick Alberts | テクニカルライター
Fernando Antivero | フルスタック開発者とクラウドプラットフォームエンジニア
Duong Au | シニア コンテンツ 開発者、C+E Skilling Content R&D
ハリクリシュナン M B (ハリ) |Product Manager 2、Azure Networking
Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
- トレーニング: Azure Front Door の概要
- Azure Front Door の概要
- Azure Front Door とは何ですか？
関連リソース
- Azure でマルチテナント ソリューションを設計する
- Azure でマルチテナント ソリューションを設計および構築するためのチェックリスト
- マルチテナント ソリューションで検討すべきテナントモデル