マルチテナント ソリューションで Azure Front Door を使用する

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 ブロック、WAF ルールのカスタマイズに関する要件がありますか?
• テナントのすべてのアプリケーション サーバーはインターネットに接続されていますか?

マルチテナント機能をサポートする 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のようなカスタム ドメイン名を構成できます。 Azure Front Door を使用すると、1 つの Azure Front Door プロファイルに複数のカスタム ドメインを構成できます。

詳細については、「Front Door にカスタム ドメインを追加する」を参照してください。

ワイルドカード ドメイン

ワイルドカード ドメインを使用すると、Stem ドメインとテナント固有のサブドメインを使用する場合に、DNS レコードと Azure Front Door トラフィック ルーティング構成の構成が簡略化されます。 たとえば、 tenant1.app.contoso.com や tenant2.app.contoso.comなどのサブドメインを使用して、テナントがアプリケーションにアクセスするとします。 各テナント固有のドメインを個別に構成する代わりに、 ワイルドカード ドメイン、 *.app.contoso.com、を構成できます。

Azure Front Door では、ワイルドカードを使用するカスタム ドメインの作成がサポートされています。 その後、ワイルドカード ドメインに到着する要求のルートを構成できます。 新しいテナントをオンボードするときに、DNS サーバーを再構成したり、新しい TLS 証明書を発行したり、Azure Front Door プロファイルの構成を更新したりする必要はありません。

ワイルドカード ドメインは、すべてのトラフィックを 1 つの配信元グループに送信する場合に適切に機能します。 ただし、ソリューションのスタンプが別々にある場合は、単一レベルのワイルドカード ドメインでは不十分です。 マルチレベルの Stem ドメインを使用するか、テナントのサブドメインごとに使用するルートをオーバーライドするなどして、追加の構成を指定する必要があります。 詳細については、「マルチテナント ソリューションでドメイン名を使用する場合の考慮事項」を参照してください。

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 でこれらのドメイン名の証明書を発行する場合、テナントは、Azure Front Door が自分の代わりに証明書を発行するのをブロックする可能性がある DNS サーバー上の CAA レコードを構成しないでください。 詳細については、「TLS/SSL 証明書」を参照してください。

TLS/SSL 証明書の詳細については、「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 は https://application.contoso.com/tenant1/welcome、テナント 2 は 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 プロファイルと単一のエンドポイントを作成します。 *.contoso.com という名前を持つカスタム ドメインを 1 つ追加し、ワイルドカード TLS 証明書をカスタム ドメイン リソースに関連付けます。 次に、アプリケーション サーバーの 1 つの配信元を含む 1 つの配信元グループを構成します。 最後に、カスタム ドメインを配信元グループに接続するルートを構成します。

新しいテナントがオンボードされたとき: 追加の構成は必要ありません。

メリット

• この構成は比較的簡単に構成でき、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.comProseware の Azure Front Door エンドポイント: proseware.z01.azurefd.net の別名です。

新しいテナントがオンボードされたとき: 追加の構成は必要ありません。

TLS の構成

1 回限り構成: Proseware はワイルドカード TLS 証明書を購入し、キー コンテナーに追加し、Azure Front Door にコンテナーへのアクセス権を付与します。

新しいテナントがオンボードされたとき: 追加の構成は必要ありません。

Azure Front Door の構成を取得します

1 回限りの構成: Proseware は、Azure Front Door プロファイルと単一のエンドポイントを作成します。 会社では、リージョンごとにアプリケーション スタンプ/サーバーごとに 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 では、スタンプベースの Stem ドメイン (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 回限りの構成: Contoso は、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 で指定された値に設定する必要があります。
• Adventure Works Azure Front Door エンドポイントに別名を付けた CNAME レコード。 たとえば、テナント 1 では、 tenant1app.tenant1.com という名前の CNAME レコードを構成し、 adventureworks.z01.azurefd.netにマップする 必要があります。

TLS の構成

Adventure Works とそのテナントは、TLS 証明書を発行するユーザーを決定する必要があります。

• 最も簡単な方法は、Azure Front Door を使用して証明書を発行および管理することですが、テナントは DNS サーバーで CCA レコードを構成しないでください。 その場合、レコードによって 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 ロールベースのアクセス制御 (RBAC) を使用して、管理者に 1 つのスタンプのプロファイルへのアクセス権を付与できます。

デメリット

• この方法では、通常、より多くのプロファイルをデプロイするため、高いコストが発生します。 詳細については、 Front Door の課金についてを参照してください。
• 1 つの Azure サブスクリプションにデプロイできる Azure Front Door プロファイルの数には制限があります。 詳しくは、 Front Door のクォータと制限に関するページを参照してください。
• 各スタンプの Azure Front Door プロファイルを個別に構成する必要があり、各スタンプの DNS 構成、TLS 証明書、TLS 構成を管理する必要があります。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

• Raj Nemani | ディレクター、 パートナー テクノロジ ストラテジスト
• John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• Mick Alberts | テクニカル ライター
• Fernando Antivero | フルスタック 開発者 & クラウド プラットフォーム エンジニア
• Duong Au | シニア コンテンツ 開発者、C+E Skilling Content R&D
• Harikrishnan M B (HARI) | プロダクト マネージャー 2、Azure ネットワーク
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

• トレーニング: Azure Front Door の概要
• Azure Front Door の概要
• Azure Front Door とは

関連リソース

• Azure でのマルチテナント ソリューションの設計
• Azure でマルチテナント ソリューションを設計および構築するためのチェックリスト
• マルチテナント ソリューションに対して考慮すべきテナント モデル