Azure Front Door の配信元と配信元グループ

  • [アーティクル]

重要

Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、Azure Front Door (クラシック) の廃止に関するページを参照してください。

Note

この記事の 配信元 と 配信元グループ は、Azure Front Door (クラシック) 構成のバックエンドとバックエンド プールを指します。

この記事では、Azure Front Door で Web アプリのデプロイがマップされる方法に関する概念について説明します。 Azure Front Door 構成における "配信元" と "配信元グループ" とは何か説明します。

出発地

配信元とは、Azure Front Door がコンテンツを取得する元となるアプリケーションのデプロイを指します。 Azure Front Door では、Azure でホストされている配信元と、オンプレミスのデータセンターまたは別のクラウド プロバイダーでホストされているアプリケーションがサポートされます。 配信元を、データベース層やストレージ層と混同しないでください。 配信元は、アプリケーション バックエンドのエンドポイントと見なす必要があります。 また、Front Door 構成で配信元グループに配信元を追加する際に、次の設定を構成する必要があります。

  • 配信元の種類: 追加するリソースの種類。 Front Door では、App Service、クラウド サービス、または Storage からのアプリケーション バックエンドの自動検出がサポートされています。 Azure または Azure 以外のバックエンドで別のリソースが必要な場合は、カスタム ホストを選択します。

    重要

    構成中、API では、配信元が Front Door 環境からアクセスできないかどうかは検証されません。 Front Door が配信元にアクセスできることを確認してください。

  • サブスクリプションと配信元ホスト名: バックエンドのホストの種類としてカスタム ホストを選択しなかった場合は、バックエンドを選択します。そのためには、適切なサブスクリプションと、対応するバックエンド ホスト名を選択します。

  • Private Link: Azure Front Door Premium レベルは、Private Link を使用した配信元へのトラフィックの送信をサポートします。 詳細については、Private Link を使用した配信元のセキュリティ保護に関する記事を参照してください。

  • Certificate subject name validation (証明書のサブジェクト名の検証): Azure Front Door から配信元への TLS 接続の進行中に、Azure Front Door は要求ホスト名が配信元が提供した証明書のホスト名と一致するかどうかを検証します。 セキュリティの観点から、Microsoft では証明書のサブジェクト名のチェックを無効にすることを推奨していません。 特にこの機能を無効にする場合、詳細については、「エンド ツー エンド TLS 暗号化」を参照してください。

  • 配信元のホスト ヘッダー: 各要求でバックエンドに送信されるホスト ヘッダーの値。 詳細については、「配信元のホスト ヘッダー」を参照してください。

  • 優先順位。 すべてのトラフィックにプライマリ サービス バックエンドを使用する場合は、さまざまなバックエンドに優先順位を割り当てます。 さらに、プライマリまたはバックアップのバックエンドが使用できない場合は、バックアップを用意します。 詳細については、優先順位に関するセクションを参照してください。

  • 重み。 均等にまたは重み係数に従って一連のバックエンド間でトラフィックを分散するには、さまざまなバックエンドに重みを割り当てます。 詳細については、重みに関するセクションを参照してください。

重要

配信元が無効である場合、配信元へのルーティングと正常性プローブも無効になります。

配信元のホスト ヘッダー

Azure Front Door によって配信元に転送される要求には、対象のリソースを取得するために配信元で使用されるホスト ヘッダー フィールドが含まれます。 このフィールドの値は通常、ホスト ヘッダーとポートが含まれている配信元の URI から取得します。

たとえば、www.contoso.com に対する要求にはホスト ヘッダーwww.contoso.com が含まれます。 Azure portal を使用して配信元を構成する場合、このフィールドの既定値は配信元のホスト名です。 配信元が contoso-westus.azurewebsites.net の場合、Azure portal で配信元のホスト ヘッダーに自動的に設定される値は contoso-westus.azurewebsites.net です。 ただし、このフィールドを明示的に設定せずに Azure Resource Manager テンプレートまたは別の方法を使用すると、Front Door ではホスト ヘッダーの値として受信ホスト名が送信されます。 www.contoso.com に対して要求が行われ、配信元 contoso-westus.azurewebsites.net に空のヘッダー フィールドがある場合、Front Door ではホスト ヘッダーが www.contoso.com に設定されます。

ほとんどのアプリ バックエンド (Azure Web Apps、Blob Storage、Cloud Services など) では、ホスト ヘッダーがバックエンドのドメインと一致している必要があります。 ただし、配信元にルーティングするフロントエンド ホストでは、www.contoso.net などの別のホスト名が使用されます。

配信元でホスト ヘッダーが配信元のホスト名と一致している必要がある場合は、配信元のホスト ヘッダーに配信元のホスト名が含まれていることを確認してください。

注意

App Service を配信元として使用している場合は、App Service にもカスタム ドメイン名が構成されていることを確認してください。 詳細については、「既存のカスタム DNS 名を Azure App Service にマップする」を参照してください。

配信元に対する配信元のホスト ヘッダーの構成

配信元グループ セクション内の配信元用に [origin host header](配信元のホスト ヘッダー) フィールドを構成するには、次のようにします。

  1. お使いのフロント ドア リソースを開き、構成する配信元が含まれている配信元グループを選択します。

  2. 配信元を追加していない場合は追加します。または、既存のものを編集します。

  3. [origin host header](配信元のホスト ヘッダー) フィールドをカスタム値に設定するか、空白のままにします。 受信要求のホスト名は、ホスト ヘッダー値として使用されます。

配信元グループ

Azure Front Door において配信元グループとは、アプリケーションに対して同様のトラフィックを受信する一連の配信元を指します。 同じトラフィックを受信し、想定された動作で応答する世界中のアプリケーション インスタンスの論理的なグループとして、配信元グループを定義できます。 これらの配信元は、異なるリージョンにまたがって、または同じリージョン内にデプロイされます。 すべての配信元は、アクティブ/アクティブまたはアクティブ/パッシブの構成にデプロイできます。

配信元グループでは、正常性プローブによって配信元を評価する方法を定義します。 また、それらの間での負荷分散方法も定義します。

正常性プローブ

Azure Front Door では、構成された配信元それぞれに定期的な HTTP または HTTPS プローブ要求が送信されます。 プローブ要求では、エンドユーザーの要求を負荷分散するために、各配信元の近接性と正常性が判断されます。 配信元グループの正常性プローブの設定では、アプリ バックエンドの正常性状態をポーリングする方法が定義されています。 次の設定は、負荷分散構成で使用できます。

  • パス: この配信元グループ内のすべての配信元に対するプローブ要求に使用される URL。 たとえば、配信元の 1 つが contoso-westus.azurewebsites.net で、パスを /probe/test.aspx に設定すると、Front Door では正常性プローブ要求が http://contoso-westus.azurewebsites.net/probe/test.aspx に送信されます (プロトコルが HTTP に設定されている場合)。

  • プロトコル: Front Door から配信元への正常性プローブ要求を HTTP と HTTPS プロトコルのどちらで送信するかを定義します。

  • メソッド: 正常性プローブの送信に使用される HTTP メソッド。 オプションには、GET または HEAD (既定値) があります。

    Note

    バックエンドの負荷とコストを抑えるため、Front Door では正常性プローブに HEAD 要求を使用することが推奨されています。

  • 間隔 (秒) :配信元に対する正常性プローブの頻度、つまり各 Front Door 環境でプローブが送信される間隔を定義します。

    Note

    フェールオーバーを高速化するには、間隔をより小さい値に設定してください。 値が小さくなると、バックエンドが受信する正常性プローブのボリュームは大きくなります。 たとえば、間隔が 30 秒に設定されていて、100 個の Front Door POP が世界中に存在する場合、各バックエンドは 1 分あたり約 200 件のプローブ要求を受信します。

詳細については、「正常性プローブ」を参照してください。

負荷分散の設定

配信元グループの負荷分散の設定では、正常性プローブの評価方法が定義されます。 これらの設定により、配信元が正常か異常かが判断されます。 また、配信元グループ内の異なる配信元間でのトラフィックの負荷分散方法も確認されます。 次の設定は、負荷分散構成で使用できます。

  • サンプル サイズ: 配信元の正常性評価のために検討が必要な正常性プローブのサンプル数を特定します。

  • 成功サンプル サイズ: 前述のとおり、サンプル サイズ、つまり配信元が正常であると見なすために必要な成功サンプルの数を定義します。 たとえば、Front Door の正常性プローブの間隔が 30 秒、サンプル サイズが 5、成功サンプル サイズが 3 だとします。 配信元の正常性プローブを評価するたびに、150 秒間 (5 x 30) で最新の 5 つのサンプルを確認します。 配信元が正常であると宣言するには、少なくとも 3 つのプローブが成功している必要があります。

  • 待機時間感度 (追加の待機時間): Azure Front Door で、待機時間の測定感度範囲内の配信元に要求を送信するか、または最も近いバックエンドに要求を転送するかを定義します。

詳細については、最小限の待ち時間ベースのルーティング方法に関するセクションを参照してください。

次のステップ