パフォーマンスの問題は、Azure Front Door サービス、配信元、要求元クライアント、またはこれらのホップ間のパスなど、いくつかの潜在的な領域で発生する可能性があります。 このトラブルシューティング ガイドでは、問題の根源である可能性が最も高いデータパス上のホップがどれなのか、また、問題の解決方法を特定できるようにします。
既知の問題を確認する
開始する前に、次のような既知の問題を確認します。
- Azure Front Door プラットフォーム。
- パス内のインターネット サービス プロバイダー (ISP)。
- データ接続して取得する要求元クライアントの機能。
シナリオ 1: 配信元を調査する
配信元サーバーのいずれかが遅い場合、Azure Front Door を介したオブジェクトに対する最初の要求が遅くなります。 さらに、コンテンツが Azure Front Door のポイント オブ プレゼンス (POP) でキャッシュされていない場合、要求は配信元に転送されます。 配信元から送られる場合、POP の近接性と要求元クライアントへのローカル配信という利点が打ち消され、代わりに配信元のパフォーマンスに依存するようになります。
シナリオ 1: 必要な環境情報
- Azure Front Door エンドポイント名
- エンドポイント ホスト名
- エンドポイントのカスタム ドメイン (該当する場合)
- 配信元のホスト名
- 影響を受けるファイルの完全な URL
シナリオ 1: トラブルシューティング手順
影響を受ける要求からの応答ヘッダーを確認します。
応答ヘッダーを確認するには、Bash で次の
curlの例を使用します。 F12 キーを選択して、ブラウザーの開発者ツールを使用することもできます。 [Networking] タブを選択し、調査する関連ファイルを選択し、[ヘッダー] タブを選択します。ファイルが見つからない場合は、開発者ツールを開いたままページを再読み込みします。最初の応答では、
x-cacheヘッダーの値はTCP_MISSまたはCONFIG_NOCACHEになっているはずです。 Azure Front Door POP は、この値を持つ要求を配信元に転送します。 配信元は、同じパス上のリターン トラフィックを要求元のクライアントに送信します。TCP_MISSを示す例を次に示します。$ curl -I https://www.contoso.com/styles.css HTTP/2 200 date: Wed, 28 Aug 2024 17:02:09 GMT content-type: text/css content-length: 2837 last-modified: Thu, 09 May 2024 20:49:36 GMT etag: "b15-6180b8e9bd897" vary: Accept-Encoding x-azure-ref: 20240828T170209Z-AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00 x-fd-int-roxy-purgeid: 0 x-cache: TCP_MISS accept-ranges: bytesTCP_HITを示す例を次に示します。curl -I https://www.contoso.com/styles.css HTTP/2 200 date: Wed, 28 Aug 2024 17:04:38 GMT content-type: text/css content-length: 2837 last-modified: Thu, 09 May 2024 20:49:36 GMT etag: "b15-6180b8e9bd897" vary: Accept-Encoding x-azure-ref: 20240828T170438Z-BB22CC33DD44EE55FF66AA77BB88CC99DD00EE11 x-fd-int-roxy-purgeid: 0 x-cache: TCP_HIT x-cache-info: L1_T2 accept-ranges: bytesx-cacheヘッダーの値がTCP_HITになるまで、エンドポイントに対する要求を続けます。最初に
CONFIG_NOCACHEが表示された場合は、ルート構成でキャッシュが有効になっていません。 この場合、TCP_HITは表示されません。パフォーマンスの問題が解決されたなら、問題の原因は Azure Front Door のパフォーマンスではなく、配信元の速度でした。 所有者は、パフォーマンスを向上させるために、Azure Front Door キャッシュ設定または配信元に対処する必要があります。
問題が解決しない場合は、コンテンツを要求しているクライアントまたは Azure Front Door サービスが原因である可能性があります。 原因を特定するにはシナリオ 2 に移動します。
シナリオ 2: 単一のクライアントまたは場所 (ISP など) の速度が遅い
単一のクライアントまたは場所では、要求元クライアントと Azure Front Door POP の間に不適切なネットワーク ルートがある場合に速度が低下する可能性があります。 不適切なルートは、POP までの距離に影響し、Azure Front Door の POP の近接性という利点がなくなるため、排除する必要があります。
仮想プライベート ネットワーク (VPN) を使用している場合、または分散した企業ネットワークの一部である場合は、ISP の問題が原因で、待ち時間が長くなったり帯域幅が低下したりする可能性があります。 企業ネットワークでは、すべてのトラフィックを中央のリモート ポイントを介して実行している可能性があります。
シナリオ 2: 必要な環境情報
- Azure Front Door エンドポイント名
- エンドポイント ホスト名
- エンドポイントのカスタム ドメイン (該当する場合)
- 配信元のホスト名
- 影響を受けるファイルの完全な URL
- 要求元クライアントの情報
シナリオ 2: トラブルシューティング手順
POP へのパスを確認する場合、pathping や 500 パケットの同様のツールを使用してネットワーク ルートを確認します。
pathping には、最大 250 個のクエリがあります。 500 までテストするには、次のクエリを 2 回実行します。
pathping /q 250 <Full URL of Affected File>トラフィックで、時間がより長くかかったり遠くのリージョンまで移動したりするパスが使用されているかどうかを判断します。
地域に基づいて適切なルートを使用していない (たとえば、ヨーロッパのトラフィックが米国にルーティングされている) IP、市区町村、または地域のコードを探すか、過剰なホップ数を探します。
クライアント設定の要求を除外するには、同じリージョン内の別の要求元クライアントからテストします。
余分なホップやリモート リージョンが特定された場合、この問題は、Azure Front Door サービス自体ではなく、Azure Front Door POP にアクセスしているクライアントに関するものです。 エンドポイント間のホップは、接続プロバイダーまたは VPN プロバイダーが対処する必要があります。
余分なホップまたはリモート リージョンが特定されず、"かつ" コンテンツがキャッシュ () から提供されている場合、問題は Azure Front Door サービスにあります。
x-cache: TCP_HITサポート リクエストを作成することが必要な場合があります。 このトラブルシューティング記事への参照と、実行した手順を含めてください。
注
コンテンツが配信元 (x-cache: TCP_MISS) から提供されている場合は、この記事の前半のシナリオ 1を参照してください。
シナリオ 3: Web サイトの読み込みが遅い
単一のファイルには問題ないのですが、(Azure Front Door にプロキシされた) Web ページのパフォーマンスが全体的に不十分であるというシナリオがいくつか存在します。 Web ページ パフォーマンス ツールでは、Azure Front Door の外部の Web ページと比較してサイトのパフォーマンスが低下しています。
たいてい、Web ページは多くのファイルで構成されています。 Web サイトは、Azure Front Door が各ファイルを Web ページで提供している場合のみ利点を受けられます。 利点を最大限に生かすには、Azure Front Door を構成する必要があります。
次の例を確認してください。
- 配信元:
origin.contoso.com - Azure Front Door カスタム ドメイン:
contoso.com - 読み込もうとしているページ:
https://contoso.com
ページが読み込まれると、"/" ディレクトリにある初期ファイルから他のファイルが呼び出され、ページが構築されます。 これらのファイルは、画像、JavaScript、テキスト ファイルなどです。 これらのファイルが Azure Front Door のホスト名 (contoso.com) を使用して呼び出されない場合、このページでは Azure Front Door が使用されません。 そのため、Web サイトによって要求されたファイルの 1 つが http://www.images.fabrikam.com/businessimage.jpg である場合、このファイルは Azure Front Door を使用することによる利点を受けられません。 代わりに、要求元クライアント上のブラウザーによって、images.fabrikam.com サーバーからこのファイルに直接要求されます。
シナリオ 3: 必要な環境情報
- Azure Front Door エンドポイント名
- エンドポイント ホスト名
- エンドポイントのカスタム ドメイン (該当する場合)
- 配信元のホスト名
- 配信元の地理的な場所
- 影響を受ける Web ページの完全な URL
- パフォーマンスを測定するツールとメトリック
シナリオ 3: トラブルシューティング
パフォーマンスの低下を示すメトリックを確認します。
重要
Microsoft は、所有していないツールで測定されている内容を識別できません。
ブラウザーで Azure Front Door Web ページを開き、F12 キーを押して開発者ツールを開きます。
ブラウザーの開発者ツールを使用すると、提供されているファイルの提供元を特定できます。 開発者ツールで 要求 URL を表示するには、[ネットワーク] タブを選択し、調査中のファイルを選択してから、[全般] を選択します。 ファイルが見つからない場合は、開発者ツールを開いたままページを再読み込みします。
ファイルの提供元または要求 URL をメモします。
Azure Front Door ホスト名を使用しているファイルと使用していないファイルを特定します。
前の例では、Azure Front Door でホストされているイメージは
https://www.contoso.com/productimage1.jpgになります。 Azure Front Door でホストされていないイメージはhttp://www.images.fabrikam.com/businessimage.jpgになります。Azure Front Door で提供されているファイルのパフォーマンス、その配信元、および (該当する場合) テスト Web ページをテストします。
配信元またはテスト Web ページが、パフォーマンスをテストするツールに近い地理的リージョンから提供されている場合、ツールまたは要求元クライアントを別のリージョンで使用して、Azure Front Door の POP の近接性の利点を調べることが必要になる可能性があります。
重要
Azure Front Door ホスト名の外部から提供されるファイルでは、その利点を受けられません。 これを行うには、Web ページの再設計が必要になる場合があります。
ファイルがキャッシュされることになっている場合は、必ず、応答ヘッダー
x-cache: TCP_HITを持つファイルをテストします。収集したデータに基づいて次のアクションを実行します。
収集されたデータに、Azure Front Door のホスト名の外部のサーバーからファイルが発行されている場合、Azure Front Door は想定どおりに動作しています。
Web サイトの読み込みが遅い場合は、Web ページの設計を変更する必要があります。 Azure Front Door を使用するように Web サイトを最適化するのに役立つ方法については、Web サイトの設計チームまたは Microsoft ソリューション プロバイダーにお問い合わせください。
注
Web サイトの読み込みに時間がかかる問題については、Web サイトの設計の複雑さとそのファイル呼び出し手順に基づいて、確認に時間を要する場合があります。
収集されたデータで、配信元またはテスト サイトと比較して、Azure Front Door でのファイルの読み込みパフォーマンスが向上していることを示す場合、Azure Front Door は期待どおりに動作しています。 問題の原因は、個別のクライアント要求である可能性があります。 その場合は、この記事の前半の「シナリオ 1」を参照してください。
収集されたデータに Azure Front Door でのパフォーマンスの方が優れては "いない" ことが示されている場合、詳細に調査するためにサポート リクエストが必要になる可能性があります。 このトラブルシューティング記事への参照と、実行した手順を含めてください。