Traffic Manager についてよく寄せられる質問 (FAQ)

2025-06-25

Traffic Manager の基礎

Traffic Manager ではどの IP アドレスが使用されますか。

「Traffic Manager のしくみ」の説明にあるとおり、Traffic Manager はドメインネームシステム(DNS) のレベルで動作します。 Traffic Manager では、DNS 応答を送信して、クライアントを適切なサービスエンドポイントに転送します。クライアントはサービスエンドポイントに、Traffic Manager 経由ではなく、直接接続します。

そのため、Traffic Manager では、クライアントが接続するためのエンドポイントまたは IP アドレスは提供されません。サービス用に静的 IP アドレスが必要な場合は、Traffic Manager ではなくサービスで構成する必要があります。

Traffic Manager を使用して、どのような種類のトラフィックをルーティングできますか。

「Traffic Manager のしくみ」で説明したとおり、Traffic Manager エンドポイントとして、Azure の内部または外部でホストされているインターネット接続サービスを指定することができます。したがって、Traffic Manager は、インターネットに接続されている一連のエンドポイントにパブリックインターネットからのトラフィックをルーティングすることができます。エンドポイントがプライベートネットワーク内にある場合 (Azure Load Balancer の内部バージョンなど)、またはユーザーがそのような内部ネットワークから DNS 要求を行う場合、Traffic Manager を使ってこのトラフィックをルーティングすることはできません。

Traffic Manager では "スティッキー" セッションはサポートされていますか。

また、Traffic Manager が受信する DNS クエリの発信元 IP アドレスは、クライアントではなく、再帰 DNS サービスのものであることに注意してください。そのため、Traffic Manager は個々のクライアントを追跡する手段を持たず、'スティッキー' セッションを実装できません。この制限は DNS ベースのすべてのトラフィック管理システムに共通であり、Traffic Manager だけではありません。

Traffic Manager を使用していると HTTP エラーが表示されたのはなぜですか。

「Traffic Manager のしくみ」の説明にあるとおり、Traffic Manager は DNS レベルで動作します。 Traffic Manager では、DNS 応答を使用して、クライアントを適切なサービスエンドポイントに転送します。クライアントはサービスエンドポイントに、Traffic Manager 経由ではなく、直接接続します。 Traffic Manager は、クライアントとサーバーの間の HTTP トラフィックを認識しません。そのため、表示される HTTP エラーはすべて、アプリケーションによって生成されたものと考えられます。クライアントがアプリケーションに接続するための DNS 解決手順は、すべて完了しています。これには、Traffic Manager がアプリケーショントラフィックフローにおいて行う対話がすべて含まれます。

そのため、詳細な調査はアプリケーションを対象とする必要があります。

クライアントのブラウザーから送信される HTTP ホストヘッダーが、問題の最もよくある原因です。お使いのドメイン名の正しいホストヘッダーを受け入れるようにアプリケーションが構成されていることを確認してください。 Azure App Service を使用しているエンドポイントの場合は、「Traffic Manager を使用して Azure App Service Web アプリのカスタムドメイン名を構成する」を参照してください。

Traffic Manager を使用するときに 500 (内部サーバーエラー) の問題を解決するにはどうすればよいですか?

Traffic Manager の使用中にクライアントまたはアプリケーションで HTTP 500 エラーが発生する場合、古い DNS クエリが原因として考えられます。この問題を解決するには、DNS キャッシュをクリアし、クライアントが新しい DNS クエリを発行できるようにします。

サービスエンドポイントが応答しないと、そのエンドポイントを使っているクライアントとアプリケーションは、DNS キャッシュが更新されるまでリセットされません。キャッシュの期間は、DNS レコードの Time-to-Live (TTL) によって決定されます。詳細については、「Traffic Manager と DNS キャッシュ」をご覧ください。

この記事の次の関連 FAQ も参照してください。

DNS TTL とは何ですか。DNS TTL はユーザーにどのような影響を及ぼしますか。
Traffic Manager の応答に設定できる TTL の値を教えてください。
マイプロファイルへのクエリの量を把握する方法を教えてください。

Traffic Manager を使用すると、パフォーマンスにどのような影響がありますか。

「Traffic Manager のしくみ」の説明にあるとおり、Traffic Manager は DNS レベルで動作します。クライアントはサービスエンドポイントに直接接続するため、接続の確立後は、Traffic Manager を使ってもパフォーマンスに影響しません。

Traffic Manager は DNS レベルでアプリケーションと統合されるため、追加の DNS 参照を DNS 解決チェーンに挿入する必要はありません。 Traffic Manager が DNS 解決時間に与える影響は最小限です。 Traffic Manager では、ネームサーバーのグローバルネットワークが使用されます。また、エニーキャストネットワーキングが使用されるため、DNS クエリは常に、使用可能な最も近いネームサーバーにルーティングされます。さらに、DNS 応答がキャッシュされるため、Traffic Manager の使用に伴って発生する DNS 待機時間の増加がごく一部のセッションにしか適用されなくなります。

パフォーマンス方式は、利用可能な最も近いエンドポイントにトラフィックをルーティングします。最終的に、このメソッドに関連付けられているパフォーマンス全体の影響を最小限に抑える必要があります。 DNS 待機時間の増大は、エンドポイントへのネットワーク待ち時間を短縮することで相殺する必要があります。

Traffic Manager ではどのようなアプリケーションプロトコルを使用できますか。

「Traffic Manager のしくみ」の説明にあるとおり、Traffic Manager は DNS レベルで動作します。 DNS 参照が完了すると、クライアントはアプリケーションエンドポイントに Traffic Manager 経由ではなく直接接続します。そのため、この接続では、任意のアプリケーションプロトコルを使用できます。監視プロトコルとして TCP を選択すると、アプリケーションプロトコルを使用せずに、Traffic Manager のエンドポイント正常性監視を実行できます。アプリケーションプロトコルを使用して正常性を検証する場合、エンドポイントは HTTP または HTTPS の GET 要求に応答できる必要があります。

"ネイキッド" ドメイン名で Traffic Manager を使用することはできますか。

はい。 Azure Traffic Manager プロファイルを参照するためのドメイン名の頂点に対するエイリアスレコードを作成する方法を確認するには、「Traffic Manager で頂点のドメイン名をサポートするエイリアスレコードを構成する」を参照してください。

Traffic Manager では、DNS クエリを処理するときにクライアントのサブネットアドレスは考慮されますか。

はい。 Traffic Manager では、DNS クエリのソース IP アドレス (通常は DNS リゾルバーの IP アドレス) に加えて、エンドユーザーの代わりに要求を行う DNS リゾルバーによって送信される DNS クエリ内に、クライアントのサブネットアドレスが含まれている場合も考慮されます。これらの IP アドレスは、ルーティング方法 (地理的、パフォーマンス、サブネット) を最適化するために使用されます。具体的には、RFC 7871 – Client Subnet in DNS Queries によって提供される Extension Mechanism for DNS (EDNS0) をサポートするリゾルバーから、クライアントのサブネットアドレスを伝えることができます。

DNS TTL とは何ですか。DNS TTL はユーザーにどのような影響を及ぼしますか。

Traffic Manager が DNS クエリを受信すると、応答に Time to Live (TTL) と呼ばれる値が設定されます。この値 (秒単位) は、ダウンストリームの DNS リゾルバーに、この応答のキャッシュ期間を示します。 DNS リゾルバーはこの結果をキャッシュするとは限りませんが、キャッシュすれば、Traffic Manager の DNS サーバーにアクセスする代わりに、キャッシュを使って以降のクエリに応答できます。応答への影響は次のとおりです。

TTL を大きくすると、Traffic Manager の DNS サーバーが受信するクエリの数が減ります。Traffic Manager では、提供されるクエリの数に基づいて課金されるため、お客様はコストを削減できます。
TTL を大きくすると、DNS 参照の実行に要する時間が削減される可能性があります。
TTL が大きいということは、Traffic Manager がプローブエージェントを介して取得した最新の正常性情報が、データに反映されていないことも意味します。

Traffic Manager の応答に設定できる TTL の値を教えてください。

DNS TTL は、プロファイルレベルで 0 ～ 2,147,483,647 秒に設定できます (最大範囲は RFC-1035 に準拠しています)。 TTL を 0 にすると、ダウンストリームの DNS リゾルバーはクエリの応答をキャッシュせず、すべてのクエリは解決のために Traffic Manager の DNS サーバーに送られるはずです。

マイプロファイルへのクエリの量を把握する方法を教えてください。

Traffic Manager が提供しているメトリックの 1 つに、プロファイルが応答するクエリ数があります。プロファイルレベルの集計でこの情報を取得できます。または、これをさらに分割して、特定のエンドポイントが返されたクエリの量を確認できます。また、アラートを設定して、クエリ応答量が設定した条件を超えた場合に通知できます。詳細については、「Traffic Manager のメトリックとアラート」を参照してください。

Traffic Manager プロファイルを削除した時、そのプロファイルの名前が再使用可能になるまでの時間はどのくらいですか?

Traffic Manager プロファイルを削除すると、関連付けられているドメイン名は一定期間予約されています。同じテナント内の他の Traffic Manager プロファイルは、その名前をすぐに再利用できます。ただし、予約の有効期限が切れるまで、別の Azure テナントは同じプロファイル名を使用できません。この機能により、ユーザーはデプロイする名前空間に対する権限を維持でき、名前が別のテナントによって取得される可能性を心配しなくてよくなります。

たとえば、Traffic Manager プロファイルの名前が label1 の場合、プロファイルを削除した場合でも、label1.trafficmanager.net はそのテナント用に予約されています。 xyz.label1 や 123.abc.label1 などの子名前空間も予約されています。予約の有効期限が切れると、その名前は他のテナントで使用できるようになります。無効にされたプロファイルに関連付けられている名前は、無期限に予約されています。名前が予約されている期間に関する質問は、アカウント担当者に問い合わせてください。

Traffic Manager ではどのバージョンの TLS が必要ですか?

Microsoft による以前の TLS バージョンの実装に脆弱性があるわけではありませんが、TLS 1.2 以降では、Perfect Foward Secrecy やさらに強力な暗号スイートなどの機能によって、セキュリティが強化されています。セキュリティを強化し、データのクラス最高の暗号化を提供するために、Traffic Manager では、2025 年 2 月 28 日より前にトランスポート層セキュリティ (TLS) 1.2 以降を使用してサービスとの対話をセキュリティで保護する必要があります。 TLS 1.0 と 1.1 に対する Traffic Manager のサポートは、この日付で終了します。この日付は、Azure 全体の TLS 1.0 および TLS 1.1 の提供終了日とは異なる場合があります。

推奨される操作

サービスの中断を回避するために、Traffic Manager と対話するリソースでは TLS 1.2 以降を使用する必要があります。

リソースで既に TLS 1.2 以降のみを使用している場合、追加のアクションを実行する必要はありません。
リソースに TLS 1.0 または 1.1 への依存関係が引き続きある場合は、2025 年 2 月 28 日までに TLS 1.2 以降に移行してください。

TLS 1.0 および 1.1 から TLS 1.2 への移行の詳細については、「TLS 1.0 の問題の解決」を参照してください。

Azure Traffic Manager でサポートされている TLS 暗号スイートは何ですか?

Azure Traffic Manager では、セキュリティで保護された通信を確保するために、TLS 1.2 と TLS 1.3 の最新の TLS 暗号スイートがサポートされています。次の暗号スイートがサポートされています。

TLS 1.3 暗号スイート

これらは プロトコル 772 (TLS 1.3 に対応) に関連付けられています。

暗号スイート	プロトコル
TLS_AES_256_GCM_SHA384	772
TLS_AES_128_GCM_SHA256	772

TLS 1.2 暗号スイート

これらは プロトコル 771 (TLS 1.2) または 65277 (TLS 1.2 の内部/カスタムコードとして一部のシステムで使用) に関連付けられています。

暗号スイート	プロトコル
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	771, 65277
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	771, 65277
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	771, 65277
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	771, 65277
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256	771, 65277
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	771, 65277
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384	771, 65277
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	771, 65277

これらの暗号スイートは強力な暗号化を提供し、最新のセキュリティ標準に準拠しています。 Traffic Manager は、TLS ハンドシェイクプロセス中に使用可能な最良の暗号スイートを自動的にネゴシエートします。

Traffic Manager の地理的トラフィックルーティング方法

地理的ルーティングが役立つ例を教えてください。

地理的ルーティングタイプは、Azure をご利用のお客様が地理的リージョンに基づいてユーザーを識別する必要がある場合に使用できます。たとえば、地理的トラフィックルーティング方法を使用して、特定のリージョンのユーザーに、他のリージョンとは異なるユーザーエクスペリエンスを提供できます。また別の例として、ローカルデータの主権性に関する (特定の地域のユーザーに対し、その地域のエンドポイントからのみサービスを提供する) 義務への準拠が挙げられます。

パフォーマンスルーティング方法を使用するか、地理的ルーティング方法を使用するかを判断する方法を教えてください。

これら 2 つの一般的なルーティング方法の主な違いは、パフォーマンスルーティング方法の主な目標が呼び出し元の待ち時間を最小にできるエンドポイントにトラフックを送信することであるのに対して、地理的ルーティング方法の主な目標が呼び出し元にジオフェンスを適用して故意に呼び出し元を特定のエンドポイントにルーティングすることであることです。地理的な近さと待ち時間の短かさには相関があるため重複が発生しますが、いつも重複するわけではありません。呼び出し元の待ち時間を短縮できるエンドポイントが異なる地域に存在する可能性があり、その場合、パフォーマンスルーティングではユーザーはそのエンドポイントにルーティングされますが、地理的ルーティングではユーザーはユーザーの地理的リージョンにマップされたエンドポイントに常にルーティングされます。わかりやすくするために、次の例について考えてみます。地理的ルーティングでは、アジアからのすべてのトラフィックを米国内のエンドポイントに送信し、米国のすべてのトラフィックをアジアのエンドポイントに送信するというような一般的ではないマッピングを作成できます。その場合、地理的ルーティングはユーザーが構成したとおりのことを意図的に実行し、パフォーマンスの最適化は考慮しません。

注

パフォーマンスルーティングと地理的ルーティングの両方の機能を必要とするシナリオがあるかもしれません。このようなシナリオの場合、入れ子になったプロファイルの選択が最適な場合があります。たとえば、北米からのすべてのトラフィックを米国内にエンドポイントがある入れ子になったプロファイルに送信する地理的ルーティングを使用して親プロファイルを設定し、パフォーマンスルーティングを使用してその設定内の最適なエンドポイントにこれらのトラフィックを送信できます。

Traffic Manager の地理的ルーティングがサポートされる地域を教えてください。

Traffic Manager によって使用される国/地域階層は、こちらでご覧いただけます。このページは常に最新の状態に保たれ、変更があれば反映されますが、Azure Traffic Manager REST API を使えば、プログラムでも同じ情報を取得できます。

ユーザーがどこからクエリを実行しているのかを Traffic Manager はどのようにして判別しているのですか。

Traffic Manager は、クエリの送信元 IP (ほとんどの場合、ユーザーの代わりにクエリを実行するローカル DNS リゾルバーになります) を調べ、リージョンと IP を対応付ける内部マップを使って場所を特定します。このマップは、インターネットにおける変化を考慮して絶えず更新されます。

Traffic Manager では、どのような場合でもユーザーの正確な地理的場所を正しく特定できることが保証されていますか。

いいえ。次の理由から、Traffic Manager では、DNS クエリの送信元 IP アドレスから推測される地理的リージョンが、ユーザーの場所に常に対応することは保証できません。

第 1 に、前の FAQ で説明したように、送信元 IP アドレスはユーザーの代わりに検索を実行する DNS リゾルバーの IP アドレスです。 DNS リゾルバーの地理的な場所は、ユーザーの地理的な場所に適したプロキシですが、この DNS リゾルバーサービスとお客様が使用する DNS リゾルバーサービスのフットプリントによっては、DNS リゾルバーの地理的な場所が異なる場合もあります。たとえば、マレーシアにいるお客様が、シンガポールにある DNS サーバーを使ってユーザー/デバイスのクエリ解決を処理する DNS リゾルバーサービスを使用することを、デバイスの設定で指定しているとします。その場合、Traffic Manager では、シンガポール地域に対応するリゾルバーの IP アドレスのみを認識できます。このページのクライアントサブネットアドレスのサポートに関する FAQ もご覧ください。
第 2 に、Traffic Manager は内部マップを使用して、IP アドレスの地理的リージョンへの変換を実行します。このマップは、精度を高めるため、またインターネットの進化し続ける特性を考慮して、継続的に検証および更新されていますが、それでも、その情報ですべての IP アドレスの地理的位置が正確に表されていない可能性があります。

エンドポイントは、地理的ルーティングの構成に使われたものと同じリージョン内に物理的に存在している必要がありますか?

いいえ。どの地域をエンドポイントにマッピングできるかが、エンドポイントの場所によって制限されることはありません。たとえば米国中部の Azure リージョンのエンドポイントに、インドからのすべてのユーザーを誘導することもできます。

地理的ルーティングを行うように構成されていないプロファイルのエンドポイントに地理的リージョンを割り当てることはできますか?

はい。プロファイルのルーティング方法が地理的でない場合は、Azure Traffic Manager REST API を使って、そのプロファイルのエンドポイントに地理的リージョンを割り当てることができます。ルーティングの種類が [地域] ではないプロファイルの場合、この構成は無視されます。そのようなプロファイルを後から地理的ルーティングタイプに変更した場合、Traffic Manager はそれらのマッピングを使用できます。

既存のプロファイルのルーティング方法を地理的ルーティングに変更しようとしたときにエラーが発生するのはなぜですか。

地理的ルーティングが適用されているプロファイルのすべてのエンドポイントには、少なくとも 1 つのリージョンが対応付けられている必要があります。既にあるプロファイルを地理的ルーティングタイプに変換するにはまず、Azure Traffic Manager REST API を使って、そのすべてのエンドポイントにリージョンを関連付ける必要があります。そのうえでルーティングタイプを地理的ルーティングに変更してください。ポータルを使用する場合は、まずエンドポイントを削除し、プロファイルのルーティング方法を地理的ルーティングに変更してから、エンドポイントを地理的リージョンマッピングと共に追加します。

地理的ルーティングを有効にしたプロファイルには、エンドポイントではなく、入れ子にしたプロファイルを作成することが強く推奨されているのはなぜですか。

プロファイルで地理的ルーティング方法が使われている場合は、その中の 1 つのエンドポイントにのみリージョンを割り当てることができます。そのエンドポイントが、子プロファイルがアタッチされた入れ子タイプではない場合、そのエンドポイントで異常が発生しても、Traffic Manager はそれにトラフィックを送信し続けます。これは、代わりにトラフィックの送信を止める方が良いわけではないためです。 Traffic Manager は、別のエンドポイントへのフェールオーバーは、たとえそれが異常なエンドポイントに割り当てられているリージョンの "親" リージョンが割り当てられているものであっても行いません (たとえば、スペインリージョンのエンドポイントで異常が発生した場合、ヨーロッパリージョンが割り当てられている別のエンドポイントにはフェールオーバーしません)。 Traffic Manager は、お客様がそのプロファイルの中で設定した地理的境界を尊重するようになっているためです。エンドポイントで異常が発生したときに別のエンドポイントにフェールオーバーするメリットを得られるよう、地理的リージョンは、個々のエンドポイントではなく、複数のエンドポイントを含む入れ子になったプロファイルに割り当てることをお勧めします。そうすることで、入れ子になった子プロファイルのいずれかのエンドポイントで異常が発生した場合、入れ子にされている同じ子プロファイル内の別のエンドポイントにトラフィックがフェールオーバーされます。

このルーティングタイプをサポートする API バージョンに制限はありますか。

はい。地理的ルーティングタイプのサポートは、API バージョン 2017-03-01 以降に限られます。以前の API バージョンを使って、地理的ルーティングタイプのプロファイルを作成したり、エンドポイントに地理的リージョンを割り当てたりすることはできません。以前の API バージョンを使って Azure サブスクリプションからプロファイルを取得している場合、地理的ルーティングタイプのプロファイルは返されません。また、以前の API バージョンを使って返されたプロファイルに、地理的リージョンが割り当てられたエンドポイントが含まれている場合、地理的リージョンの割り当ては表示されません。

Traffic Manager のサブネットトラフィックルーティング方法

サブネットルーティングが役立つユースケースを教えてください。

サブネットルーティングを使用すると、DNS 要求 IP アドレスの送信元 IP によって識別される特定のユーザーのセットに対して提供するエクスペリエンスを区別することができます。たとえば、ユーザーが企業の本社から Web サイトに接続している場合に別のコンテンツを表示することができます。もう一つは、特定の ISP のユーザについて、IPv6 使用時にそれらの ISP のパフォーマンスが劣る場合は、IPv4 接続のみをサポートするエンドポイントのみにアクセスするように制限することです。

サブネットルーティング方法を使用すべきもう 1 つの理由は、入れ子になったプロファイルセット内にある、他のプロファイルに関連しています。たとえば、ユーザーのジオフェンスのために地理的なルーティング方法を使用する一方で、特定の ISP には別のルーティング方法を使用したい場合は、サブネットルーティング方法を使用するプロファイルを親プロファイルにし、その ISP をオーバーライドして特定の子プロファイルが使用されるようにします。そうすることで、これ以外ではすべて標準の地理的プロファイルとなります。

注

Azure Traffic Manager では、サブネットプロファイルのサブネットオーバーライドで IPv6 アドレスがサポートされます。この機能により、IPv4 アドレスと IPv6 アドレスの両方を含む、DNS クエリの送信元 IP アドレスに基づいて、トラフィックルーティングをより細かく制御できます。

Traffic Manager はどのような方法でエンドユーザーの IP アドレスを把握するのですか。

エンドユーザーのデバイスでは、通常、DNS 参照が DNS リゾルバーによって代行されます。このようなリゾルバーの発信 IP が、Traffic Manager によって送信元 IP と見なされます。また、サブネットルーティング方法でも、要求で渡された EDNS0 Extended Client Subnet (ECS) 情報があるかどうかが調べられます。 ECS 情報が存在する場合は、それがルーティングの決定に使用されるアドレスになります。 ECS 情報がない場合は、クエリの送信元 IP がルーティングの目的で使用されます。

サブネットルーティングを使用する場合に IP アドレスを指定するにはどうすればよいですか。

エンドポイントに関連付ける IP アドレスは、2 とおりの方法で指定できます。 1 つ目は、範囲を指定するために、開始アドレスと終了アドレスを示す Quad Dot の 10 進数オクテット表記を使用する方法です (例: 1.2.3.4-5.6.7.8 または 3.4.5.6-3.4.5.6)。 2 つ目は、範囲を指定するために CIDR 表記を使用する方法です (例: 1.2.3.0/24)。複数の範囲を指定することができ、範囲のセットの中で両方の種類の表記を使用することができます。いくつかの制限が適用されます。

各 IP アドレスは 1 つのエンドポイントだけにマッピングされる必要があるため、アドレス範囲を重複させることはできません
開始アドレスを終了アドレスより大きくすることはできません
CIDR 表記の場合、"/" の前の IP アドレスは、その範囲のネットワークアドレスになっている必要があります (たとえば、1.2.3.0/24 は有効ですが、1.2.3.4.4/24 は有効ではありません)

サブネットルーティングを使用する場合にフォールバックエンドポイントを指定するにはどうすればよいですか。

サブネットルーティングを含むプロファイルでは、サブネットがマップされていないエンドポイントがある場合、他のエンドポイントと一致しない要求はすべて、ここに送られます。プロファイルに、このようなフォールバックエンドポイントを指定することを強くお勧めします。要求が到着し、どのエンドポイントにもマップされない場合、またはエンドポイントにマップされていてもそのエンドポイントに異常がある場合、Traffic Manager からは NXDOMAIN 応答が返されるためです。

サブネットルーティング型のプロファイルでエンドポイントが無効になっている場合はどうなりますか。

サブネットルーティングを含むプロファイルでは、それが無効になっているエンドポイントがある場合、Traffic Manager は、そのエンドポイントとそれが持つサブネットマッピングが存在しないかのように動作します。 IP アドレスマッピングと一致するクエリが受信され、エンドポイントが無効になっている場合、Traffic Manager はフォールバックエンドポイント (マッピングを持たないエンドポイント) を返します。そのようなエンドポイントがない場合は、NXDOMAIN 応答を返します。

Traffic Manager の複数値トラフィックルーティング方法

複数値ルーティングが役立つユースケースを教えてください。

複数値ルーティングでは、単一のクエリ応答で複数の正常なエンドポイントが返されます。この主な利点は、エンドポイントに異常がある場合、クライアントには別の DNS 呼び出し (アップストリームキャッシュから同じ値が返される可能性があります) を行わずに再試行できるオプションがほかにあることです。この方法は、ダウンタイムを最小限に抑える必要がある、可用性が重要なアプリケーションに適しています。複数値ルーティング方式のもう 1 つの用途は、エンドポイントが IPv4 アドレスと IPv6 アドレスの両方の "デュアルホーム" になっていて、呼び出し元がエンドポイントへの接続を開始するときにどちらのオプションも選択できるようにする場合です。

複数値ルーティングを使用する場合、何個のエンドポイントが返されますか。

ユーザーは返されるエンドポイントの最大数を指定でき、MultiValue は、クエリを受信したとき、その数より多くの正常なエンドポイントを返しません。この構成に設定できる最大値は 10 です。

複数値ルーティングを使用する場合、同じエンドポイントのセットが取得されますか。

各クエリで同じエンドポイントのセットが返されるとは限りません。これは、一部のエンドポイントが正常でなくなり、そのエンドポイントは応答に含まれない可能性があるという事実にも影響されます

リアルユーザー測定

Real User Measurements のメリットは何ですか。

パフォーマンスによるルーティング方法を使用する場合、Traffic Manager は、送信元 IP および EDNS クライアントのサブネットを確認し (渡された場合)、そのサブネットを、サービスによって保持されているネットワーク待機時間インテリジェンスと照合することで、エンドユーザーにとって最適な接続先 Azure リージョンを選択します。 Real User Measurements により、エンドユーザーベースのこの動作が強化されます。待機時間テーブルでは、エンドユーザーが Azure に接続する場所からエンドユーザネットワークを適切に網羅するという保証に加えて、エンドユーザーの経験がこのテーブルに反映されるためです。これにより、エンドユーザーのルーティングの精度が向上します。

Azure 以外のリージョンで Real User Measurements を使用できますか。

Real User Measurements では、Azure リージョンにアクセスするときの待機時間のみが測定およびレポートされます。非 Azure リージョンでホストされているエンドポイントでパフォーマンスベースのルーティングを使っている場合でも、このエンドポイントと関連付けするよう選んだ代表的な Azure リージョンに関する待機時間情報を増やすと、この機能からメリットを得られます。

どのルーティング方法が Real User Measurements のメリットを得られますか。

Real User Measurements から取得された追加情報は、パフォーマンスによるルーティング方法を使用するプロファイルにのみ適用されます。 Real User Measurements リンクは、Azure portal で表示すると、すべてのプロファイルから利用できます。

Real User Measurements は、プロファイルごとに個別に有効にする必要がありますか。

いいえ。サブスクリプションごとに 1 回有効にすれば、測定およびレポートされたすべての待機時間情報を、すべてのプロファイルで利用できます。

サブスクリプションの Real User Measurements をオフにするには、どうすればよいですか。

クライアントアプリケーションからの待機時間の測定値の収集と送信を停止すると、Real User Measurements 関連の課金を停止できます。たとえば、測定 JavaScript が Web ページに埋め込まれている場合は、JavaScript を削除するか、ページがレンダリングされるときに、その呼び出しをオフにすることで、この機能の使用を停止できます。

キーを削除して、Real User Measurements をオフにすることもできます。キーを削除すると、そのキーで Traffic Manager に送信されるすべての測定値が破棄されます。

Web ページ以外のクライアントアプリケーションで Real User Measurements を使用できますか。

はい。Real User Measurements は、さまざまな種類のエンドユーザークライアントによって収集されたデータを取り込むように設計されています。新しい種類のクライアントアプリケーションがサポートされるようになったら、この FAQ は更新されます。

Real User Measurements が有効な Web ページのレンダリング 1 回あたりの測定数はどのくらいですか。

測定 JavaScript を指定して Real User Measurements が使用されている場合、ページレンダリングあたり 6 つの測定値が取得されます。この測定値は Traffic Manager サービスにレポートされます。この機能の料金は、Traffic Manager サービスにレポートされた測定数に基づいて発生します。たとえば、測定中にユーザーが Web ページから離れた場合でも、レポートされる前であれば、その測定は課金の対象にはなりません。

Web ページで Real User Measurements スクリプトが実行されるまでの間に、遅延が発生しますか。

いいえ。スクリプトが呼び出される前にプログラムされた遅延はありません。

Real User Measurements を使用できるのは、測定対象の Azure リージョンでだけですか。

いいえ。リアルユーザー測定スクリプトは、呼び出されるたびに、サービスによって決定される 6 つの Azure リージョンのセットを測定します。このセットは呼び出しによって異なり、大量の呼び出しが発生すると、測定範囲はさまざまな Azure リージョンにまたがります。

測定数を特定の数値に制限できますか。

測定 JavaScript は Web ページに埋め込まれており、使用の開始と停止のタイミングは完全にご自身で制御できます。 Traffic Manager サービスが、測定対象の Azure リージョン一覧に対する要求を受け取れる限り、リージョンセットが返されます。

Real User Measurements の一環としてクライアントアプリケーションによって取得される測定を表示できますか。

クライアントアプリケーションから測定ロジックが実行されるため、待機時間の測定値の表示など、動作を完全に制御できます。 Traffic Manager は、サブスクリプションにリンクされたキーで受信された測定値の集計ビューをレポートしません。

Traffic Manager によって提供される測定スクリプトを変更できますか。

Web ページに埋め込まれた内容を制御しているときは、待機時間が正しく測定およびレポートされるように、測定スクリプトは変更しないようにすることを強くお勧めします。

Real User Measurements で使用しているキーを、他のユーザーが見ることはできますか。

測定スクリプトを Web ページに埋め込むと、そのスクリプトと自分のリアルユーザー測定 (RUM) キーを、他のユーザーも見ることができるようになります。ただし、このキーは、サブスクリプション ID とは異なり、Traffic Manager によって生成されて、この目的でのみ使われることを知っておくことが重要です。 RUM キーが知られても、Azure アカウントの安全性に問題が発生することはありません。

自分の RUM キーを、他のユーザーが悪用することはできますか。

あるユーザーのキーを他のユーザーが使って、誤った情報を Azure に送信することはできますが、受信した他のすべての測定値も考慮されるため、いくつかの誤った測定値によってルーティングが変更されることはありません。キーを変更する必要がある場合は、古いキーが破棄された時点で、キーを再生成できます。

すべての Web ページに測定 JavaScript を配置する必要がありますか。

測定数が多くなると、Real User Measurements によって提供される値も増えます。そうではあっても、それをすべての Web ページに配置するか、一部だけにするかは、自分で決められます。最初は、ユーザーのアクセスが多く、アクセスしたユーザーが 5 秒以上留まっているページに配置することをお勧めします。

Real User Measurements を使用している場合、Traffic Manager によってエンドユーザーの情報を識別することは可能ですか。

提供されている測定 JavaScript を使うと、Traffic Manager は、エンドユーザーのクライアント IP アドレスと、エンドユーザーが使っているローカル DNS リゾルバーのソース IP アドレスを認識できます。 Traffic Manager がクライアント IP アドレスを使用できるのは、測定値を送信したエンドユーザーを特定できないように、クライアント IP アドレスが切り詰められた後だけです。

Real User Measurements を測定している Web ページは、ルーティング用に Traffic Manager を使用する必要がありますか。

いいえ。Traffic Manager を使用する必要はありません。 Traffic Manager のルーティング側は、リアルユーザー測定部分とは別に動作します。両方を同じ Web プロパティに入れるのは良い考えですが、そうする必要はありません。

Real User Measurements と共に使用するために、Azure リージョンでホストしなければならないサービスはありますか。

いいえ。Real User Measurements を動作させるために、Azure 上でサーバー側コンポーネントをホストする必要はありません。測定 JavaScript によってダウンロードされた 1 つのピクセルイメージと、そのイメージをさまざまな Azure リージョンで実行するサービスは、Azure でホストおよび管理されます。

Real User Measurements を使用しているとき、Azure の帯域幅の使用量は増えますか。

前の回答で説明したように、Real User Measurements のサーバー側コンポーネントは、Azure によって所有および管理されます。つまり、リアルユーザー測定を使ったために、Azure の帯域幅の使用量が増えることはありません。これには、Azure の料金以外の帯域幅使用量は含まれません。 Microsoft では、Azure リージョンへの待機時間の測定のためにダウンロードするピクセルイメージを 1 つだけにして、帯域幅の使用量を最小限に抑えています。

トラフィックビュー

Traffic View は何をしますか。

Traffic View は Traffic Manager の機能で、ユーザーとユーザーエクスペリエンスを詳しく理解するうえで役立ちます。この Traffic View は、Traffic Manager で受信したクエリと、サービスによって保持されるネットワーク待機時間インテリジェンステーブルを使用します。このテーブルには、次の情報が示されています。

Azure のエンドポイントに接続しているユーザーが存在しているリージョン。
そのリージョンから接続しているユーザーの数。
ルーティング先の Azure リージョン。
これらの Azure リージョンへのルーティングでユーザーが体感した待ち時間。

この情報は、生データとしてダウンロードして使用することに加えて、ポータルで地理的な地図のオーバーレイと表形式ビューで使用することもできます。

Traffic View を使用することには、どのようなメリットがありますか。

Traffic View には、Traffic Manager プロファイルが受信するトラフィックの全体的なビューが表示されます。具体的には、これを使用することで、ユーザーベースの接続元を把握できます。また、これと同様に重要なのが、その待機時間の平均を知ることができる点です。この情報を使うと、焦点を当てる必要がある領域を見つけることができます。たとえば、ユーザーの待機時間を短くできるリージョンに Azure フットプリントを拡大することができます。 Traffic View から得られるもう 1 つの洞察は、さまざまなリージョンへのトラフィックパターンを確認することです。これは、こうしたリージョンにおける増減に関する決定を行ううえで役立ちます。

Traffic View は、Azure Monitor で使用できる Traffic Manager メトリックとは、どのように異なりますか。

Azure Monitor を使用すると、使用しているプロファイルとそのエンドポイントで受信したトラフィックを集計レベルで把握できます。また、正常性チェックの結果を公開することで、エンドポイントの正常性の状態を追跡することもできます。トラフィックビューは、さらに詳しい情報を確認して、Azure に接続しているエンドユーザーのエクスペリエンスをリージョンレベルで理解する必要がある場合に、ご利用いただけます。

Traffic View は EDNS クライアントサブネット情報を使用しますか。

Azure Traffic Manager によって処理される DNS クエリでは、ECS 情報を考慮に入れて、ルーティングの精度を高めています。しかし、ユーザーがどこから接続しているかを示すデータセットの作成時には、Traffic View は DNS リゾルバーの IP アドレスのみを使用しています。

Traffic View は何日分のデータを使用しますか。

Traffic View は、ユーザーが表示する日の前日から遡って 7 日間のデータを処理して、出力を作成します。これは移動ウィンドウであり、アクセスするたびに最新データが使われます。

Traffic View は外部エンドポイントをどのように処理しますか。

Traffic Manager プロファイルで Azure リージョン外でホストされている外部エンドポイントを使用する場合は、その待機時間特性に対するプロキシである Azure リージョンにマッピングするように選択できます (これはパフォーマンスによるルーティング方法を使用する場合には実際に必要です)。この Azure リージョンマッピングが含まれていると、トラフィックビューの出力の作成時に、その Azure リージョンの待ち時間メトリックが使われます。 Azure リージョンが指定されていない場合は、それらの外部エンドポイントに対するデータでは、待ち時間情報が空になります。

サブスクリプションのプロファイルごとに Traffic View を有効にする必要がありますか。

プレビューの期間中、Traffic View はサブスクリプションレベルで有効にされました。一般公開の前に加えた強化の一部として、Traffic View はプロファイルレベルで有効にできるようになっています。これにより、この機能をよりきめ細かに有効化できます。既定では、トラフィックビューはプロファイルで無効になっています。

注

プレビュー期間中にサブスクリプションレベルで Traffic View を有効にした場合、そのサブスクリプションのプロファイルごとに Traffic View を再度有効にする必要があります。

Traffic View をオフにするには、どうすればよいですか。

ポータルまたは REST API を使用して、任意のプロファイルの Traffic View をオフにできます。

Traffic View はどのように課金されますか。

Traffic View の価格は、出力の作成に使用されたデータポイントの数に基づきます。現時点でサポートされている唯一のデータ型は、プロファイルが受け取るクエリです。また、課金されるのは、トラフィックビューを有効にしていたときに行われた処理についてのみです。つまり、1 か月の間で Traffic View が有効になっている期間と、無効になっている期間がある場合、この機能を有効にしていた期間に処理されたデータポイントだけが課金対象としてカウントされます。

Traffic Manager エンドポイント

複数のサブスクリプションのエンドポイントで Traffic Manager を使用できますか。

Azure Web Apps では、複数のサブスクリプションのエンドポイントを使うことはできません。 Azure Web Apps の要件により、Web Apps で使用するカスタムドメイン名を使用できるのは 1 つのサブスクリプション内に限定されます。同じドメイン名で複数のサブスクリプションから Web Apps を使うことはできません。

他の種類のエンドポイントの場合は、複数のサブスクリプションのエンドポイントで Traffic Manager を使用できます。 Resource Manager では、任意のサブスクリプションのエンドポイントを Traffic Manager に追加できますが、Traffic Manager プロファイルを構成するユーザーにそのエンドポイント対する読み取りアクセス権が必要となります。これらのアクセス許可は、Azure ロールベースのアクセス制御 (Azure RBAC ロール) を使用して付与できます。他のサブスクリプションのエンドポイントは、Azure PowerShell または Azure CLI を使用して追加できます。

クラウドサービス 'Staging' スロットで Traffic Manager を使用できますか。

はい。クラウドサービス 'Staging' スロットは、Traffic Manager で外部エンドポイントとして構成できます。正常性チェックには、Azure エンドポイントの料金が課金されます。

Traffic Manager では IPv6 エンドポイントはサポートされていますか。

はい。Traffic Manager では IPv6 エンドポイントが完全にサポートされています。 Traffic Manager では IPv4 と IPv6 の両方のアドレス指定可能なネームサーバーが提供されているため、クライアントはどちらのプロトコルを使用してもシームレスに接続できます。 IPv6 クライアントは、IPv6 対応の再帰 DNS サービスを介して DNS 要求を直接行うことができ、Traffic Manager は IPv6 エンドポイントの DNS 名または IP アドレスで応答できるため、IPv6 ネットワークとの完全な互換性が実現します。

同じリージョン内の複数の Web アプリで Traffic Manager を使用できますか。

通常、Traffic Manager は、さまざまなリージョンにデプロイされたアプリケーションにトラフィックを送信するときに使用されます。ただし、この Traffic Manager は、同じリージョンに複数のアプリケーションがデプロイされている場合も使用できます。 Traffic Manager の Azure エンドポイントでは、同じ Azure リージョンの複数の Web アプリエンドポイントを、同じ Traffic Manager プロファイルに追加することはできません。

Traffic Manager プロファイルの Azure エンドポイントを別のリソースグループまたはサブスクリプションに移動する操作方法を教えてください。

Traffic Manager プロファイルに関連付けられている Azure エンドポイントは、それぞれのリソース ID を使用して追跡されます。エンドポイントとして使用している Azure リソース (パブリック IP、クラシッククラウドサービス、Web アプリ、入れ子にして使用されている別の Traffic Manager プロファイルなど) を別のリソースグループまたはサブスクリプションに移動すると、リソース ID が変更されます。このシナリオの場合、現時点では、まずエンドポイントを削除してから Traffic Manager プロファイルに追加することにより、プロファイルを更新する必要があります。

詳しくは、「エンドポイントを移動するには」をご覧ください。

Azure Traffic Manager は DNS (ECS) の IPv6 拡張メカニズムをサポートしていますか?

Azure Traffic Manager では、DNS (ECS) の拡張メカニズムを備えた IPv6 アドレスがサポートされています。つまり、DNS クエリに ECS 情報が含まれている場合、Azure Traffic Manager は、ECS 内のソース IP アドレスを使用してインテリジェントなルーティング決定を行うことができます。

IPv6 ECS のサポートには、いくつかの利点があります。

ローカライズの改善: ECS の IPv6 アドレスを考慮することで、Traffic Manager はユーザーを最も近いエンドポイントまたは最も適切なエンドポイントにルーティングし、待機時間を短縮してユーザーエクスペリエンスを向上させることができます。
トラフィック制御の強化: IPv6 ECS を使用すると、トラフィックルーティングの決定をより細かく行い、グローバルトラフィックと分散をより適切に管理できます。

IPv6 ECS を使用する場合は、エンドポイントが IPv6 トラフィックを処理するように正しく構成されていることを確認するのが重要です。また、再帰リゾルバーを含む DNS インフラストラクチャが、IPv6 アドレスを使用して ECS 情報を処理できることを確認します。

Traffic Manager エンドポイントの監視

Traffic Manager には Azure リージョンの障害に対する回復性がありますか。

トラフィックマネージャーは、Azure での高可用性アプリケーションの配信の重要なコンポーネントです。高可用性を実現するには、Traffic Manager は非常に高いレベルの可用性を実現し、地域の障害に対応できる必要があります。

仕様では、Traffic Manager のコンポーネントは、どの Azure リージョン全体の障害に対しても耐障害性を持っています。この回復性は Traffic Manager のすべての構成要素、つまり、DNS ネームサーバー、API、ストレージ層、エンドポイント監視サービスに適用されます。

万一 Azure リージョン全体が停止した場合で、Traffic Manager は引き続き正常に機能すると予想されます。複数の Azure リージョンにデプロイされたアプリケーションは、Traffic Manager を利用して、そのアプリケーションの利用可能なインスタンスにトラフィックを送ることができます。

リソースグループの場所の選択は Traffic Manager にどのような影響を与えますか。

Traffic Manager は、1 つのグローバルサービスです。リージョンごとではありません。リソースグループの場所をどこに選択しても、そのリソースグループにデプロイされる Traffic Manager プロファイルに違いはありません。

Azure Resource Manager では、すべてのリソースグループに対して場所を指定することが求められます。これに基づいて、リソースグループにデプロイされたリソースの既定の場所が決定されます。作成した Traffic Manager プロファイルは、リソースグループ内に作成されます。 Traffic Manager プロファイル自体の場所には、常に グローバル が使用され、リソースグループの既定値はオーバーライドされます。

各エンドポイントの現在の正常性を確認するには、どうすればよいですか。

各エンドポイントとプロファイル全体の現在の監視状態は、Azure ポータルに表示されます。この情報は、Traffic Manager の REST API、PowerShell コマンドレット、およびクロスプラットフォームの Azure CLI を使用して取得することもできます。

Azure Monitor を使用すると、エンドポイントの正常性を追跡して、視覚的に表現することもできます。 Azure Monitor の使用方法について詳しくは、Azure Monitoring のドキュメントをご覧ください。

HTTPS エンドポイントを監視できますか。

はい。 Traffic Manager は、HTTPS 経由のプローブをサポートしています。監視構成でプロトコルとして HTTPS を構成します。

Traffic Manager は、次のような証明書の検証を提供できません。

サーバー側証明書は検証されません
SNI サーバー側証明書は検証されません
クライアント証明書はサポートされていません

エンドポイントを追加する際には、IP アドレスと DNS 名のどちらを使用しますか。

Traffic Manager では、エンドポイントを参照する次の 3 つの方法を使用したエンドポイントの追加がサポートされています。

DNS 名として
IPv4 アドレスとして
IPv6 アドレスとして

エンドポイントが IPv4 または IPv6 アドレスとして追加された場合、クエリ応答のレコードタイプはそれぞれ A と AAAA になります。エンドポイントが DNS 名として追加された場合、クエリ応答のレコードタイプは CNAME になります。 IPv4 アドレスまたは IPv6 アドレスとして追加できるエンドポイントは、種類が外部のエンドポイントだけです。

この 3 種類のエンドポイントアドレス指定方法では、すべてのルーティング方法と監視設定がサポートされています。

エンドポイントを追加するときに、どの種類の IP アドレスを使用できますか。

Traffic Manager では、エンドポイントの指定に IPv4 アドレスまたは IPv6 アドレスを使用することができます。以下に挙げるような、いくつかの制限があります：

予約済みのプライベート IP アドレス空間に対応するアドレスは使用できません。これらのアドレスには、RFC 1918、RFC 6890、RFC 5737、RFC 3068、RFC 2544、および RFC 5771 で示されているアドレスが含まれます。
IP アドレスにポート番号を含めることはできません (使用するポートは、プロファイルの構成設定で指定することができます)。
同じプロファイル内の 2 つのエンドポイントに同じターゲット IP アドレスを指定することはできません。

1 つのプロファイル内で異なる種類のエンドポイントアドレス指定方法を使用することはできますか。

いいえ。 Traffic Manager では、 IPv4 と IPv6 のアドレス指定方法の混在ができる MultiValue ルーティングタイプのプロファイルの場合を除いて、プロファイル内でエンドポイントアドレス指定方法の混在はできません。

受信クエリのレコードタイプが、エンドポイントのアドレス指定方法に関連付けられているレコードタイプと異なる場合はどうなりますか。

Traffic Manager は、プロファイルに対するクエリを受信すると、まず、指定されたルーティング方法およびエンドポイントの正常性状態に基づいて返される必要があるエンドポイントを特定します。次に、受信クエリで要求されたレコードタイプと、エンドポイントに関連付けられているレコードタイプを調べたうえで、以下の表に基づいて応答を返します。

複数値以外のルーティング方法のプロファイルの場合:

受信クエリ要求	エンドポイントの種類	提供される応答
ANY	A/AAAA/CNAME	ターゲットエンドポイント
A	A/CNAME	ターゲットエンドポイント
A	AAAA	データなし
AAAA	AAAA/CNAME	ターゲットエンドポイント
AAAA	A	データなし
CNAME	CNAME	ターゲットエンドポイント
CNAME	A/AAAA	データなし

ルーティング方法が複数値に設定されているプロファイルの場合:

受信クエリ要求	エンドポイントの種類	提供される応答
ANY	A と AAAA の混在	ターゲットエンドポイント
A	A と AAAA の混在	タイプ A のターゲットエンドポイントのみ
AAAA	A と AAAA の混在	タイプ AAAA のターゲットエンドポイントのみ
CNAME	A と AAAA の混在	データなし

入れ子になったプロファイル内で、IPv4/IPv6 アドレスでエンドポイントが指定されているプロファイルを使用することはできますか。

はい。ただし、種類が [複数値] のプロファイルは、入れ子になったプロファイルセット内で親プロファイルにすることはできないという例外があります。

Web アプリケーションのエンドポイントを Traffic Manager プロファイルで停止しましたが、それを再起動した後でもトラフィックを受信していません。どうしたらいいですか。

Azure Web アプリケーションのエンドポイントが停止されると、Traffic Manager は正常性のチェックを停止し、エンドポイントが再起動されていることを検出した後にのみ正常性チェックを再開します。この遅延を防ぐには、エンドポイントを再起動した後で、Traffic Manager プロファイルでエンドポイントを無効にしてから再び有効にします。

アプリケーションが HTTP または HTTPS をサポートしていなくても、Traffic Manager を使用できますか?

はい。監視プロトコルとして TCP を指定すると、Traffic Manager は TCP 接続を開始し、エンドポイントからの応答を待機します。接続を確立するために、エンドポイントがタイムアウト期間内に接続要求に応答すると、そのエンドポイントは正常とマークされます。

TCP 監視を使用する場合、エンドポイントからどのような応答が必要ですか。

TCP 監視を使用すると、Traffic Manager は指定されたポートでエンドポイントに SYN 要求を送信して 3 方向の TCP ハンドシェイクを開始します。その後、エンドポイントからの SYN-ACK 応答が一定期間 (タイムアウト設定で指定) 待機されます。

監視設定で指定されたタイムアウト期間内に SYN-ACK 応答が受信された場合、そのエンドポイントは正常と見なされます。 FIN または FIN-ACK は、Traffic Manager がソケットを定期的に終了するときに予想される応答です。
指定されたタイムアウト後に SYN-ACK 応答が受信された場合は、Traffic Manager は RST で応答して接続をリセットします。

Traffic Manager は、どの程度迅速に異常なエンドポイントからユーザーを移動させますか。

Traffic Manager には、Traffic Manager プロファイルのフェールオーバーの動作を制御できる、次のような複数の設定が用意されています。

プローブ間隔を 10 秒に設定することで、Traffic Manager がエンドポイントをプローブする頻度を増やすことができます。これにより、異常が発生したエンドポイントを可能な限り速やかに検出できます。
正常性チェック要求がタイムアウトになるまでの待機時間を指定できます (最小タイムアウト値は 5 秒です)。
エンドポイントが異常としてマークされるまでに許容されるエラーの数を指定できます。この値を 0 にすることもできます。その場合、エンドポイントは、最初の正常性チェックに失敗するとすぐに異常とマークされます。ただし、エラーの許容数に最小値の 0 を使用すると、プローブ時に発生する可能性のある一時的な問題によって、エンドポイントがローテーションから除外される可能性があります。
DNS 応答の Time to Live (TTL) に 0 を指定できます。このようにすると、DNS リゾルバーは応答をキャッシュできず、新しいクエリのたびに、Traffic Manager が持つ最新の正常性情報を含む応答が取得されます。

これらの設定を使用することで、Traffic Manager はエンドポイントで異常が発生してから 10 秒以内にフェールオーバーを実行できるようになり、対応するプロファイルに対して DNS クエリが作成されます。

プロファイル内のエンドポイントごとに異なる監視設定を指定するにはどうすればよいですか。

Traffic Manager の監視設定は、プロファイルレベルで行われます。 1 つのエンドポイントにのみ別の監視設定を使用する必要がある場合、これを実現するには、監視設定が親プロファイルと異なる入れ子になったプロファイルとしてそのエンドポイントを使用します。

エンドポイントに対する Traffic Manager の正常性チェックに HTTP ヘッダーを割り当てるにはどうすればよいですか。

Traffic Manager では、エンドポイントに対して開始される HTTP(S) 正常性チェックにカスタムヘッダーを指定することができます。カスタムヘッダーを指定する場合は、プロファイルレベルで指定する (すべてのエンドポイントに適用する) か、エンドポイントレベルで指定することができます。ヘッダーが両方のレベルで定義されている場合は、エンドポイントレベルで指定されているものが、プロファイルレベル 1 をオーバーライドします。これの一般的なユースケースの 1 つは、マルチテナント環境でホストされているエンドポイントに Traffic Manager の要求が正しくルーティングされるように、ホストヘッダーを指定する場合です。もう 1 つのユースケースは、エンドポイントの HTTP (S) 要求ログから Traffic Manager の要求を識別することです

エンドポイントの正常性チェックには、どのようなホストヘッダーが使用されますか。

カスタムホストヘッダー設定が指定されていない場合、Traffic Manager によって使用されるホストヘッダーは、プロファイルで構成されているエンドポイントターゲットの DNS 名です (それが利用可能な場合)。

正常性チェックはどの IP アドレスから発信されますか。

この記事を参照して、Traffic Manager の正常性チェックの実行元になる IP アドレスの一覧を取得する方法を確認します。 REST API、Azure CLI、または Azure PowerShell を使用して、最新の一覧を取得できます。一覧に示されている IP を確認し、正常性状態をチェックするためにこれらの IP アドレスからの受信接続がエンドポイントで確実に許可されるように設定してください。

Azure PowerShell の使用例:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

注

パブリック IP アドレスは、予告なしに変更される可能性があります。必ず Service Tag Discovery API またはダウンロード可能な JSON ファイルを使用して、最新の情報を取得してください。

Traffic Manager では、エンドポイントに対して正常性チェックが何回実行されるのですか。

エンドポイントに対して実行される Traffic Manager の正常性チェックの回数は以下によって異なります。

監視間隔に設定した値 (間隔が短いほど、特定の期間にエンドポイントに到達する要求の数が増えます)。
正常性チェックの実行元である場所の数 (正常性チェックの実行元になる IP アドレスは、前の FAQ に記載されています)。

いずれかのエンドポイントがダウンした場合に通知を受ける方法を教えてください。

Traffic Manager が提供しているメトリックの 1 つにプロファイルのエンドポイントの正常性状態があります。プロファイル内のすべてのエンドポイントの集計として (たとえば、お使いのエンドポイントの 75% が正常) またはエンドポイントごとに正常性を確認できます。 Traffic Manager のメトリックは Azure Monitor を通じて公開され、そのアラート機能を使って、エンドポイントの正常性状態が変化したときに通知を受け取ることができます。詳細については、「Traffic Manager のメトリックとアラート」を参照してください。

正常性チェックを許可するようにファイアウォール規則を設定する方法

Azure Traffic Manager は、正常性プローブを使用してエンドポイントの可用性とパフォーマンスを監視します。プローブを成功させるには、エンドポイントに到達できる必要があり、パス内のファイアウォールまたはアクセス制御リスト (ACL) では、すべての Traffic Manager IP アドレスからのトラフィックを許可する必要があります。プローブの IP アドレスが許可されていない場合、正常性チェックが失敗する可能性があります。異常としてマークされたエンドポイントは、予期しないトラフィックの再ルーティングやダウンタイムを引き起こす可能性があります。

オプション 1: サービスタグを使用する (推奨) 推奨される方法は、NSG または Azure Firewall で AzureTrafficManager サービスタグを使用することです。サービスタグには最新の IP 範囲が自動的に含まれるので、手動で更新する必要はありません。

オプション 2: ファイアウォール規則を手動で更新する サービスタグを使用できない場合 (カスタムファイアウォールアプライアンスや Azure 以外の環境など)、ACL またはファイアウォール規則を更新して、最新の Azure Traffic Manager IP を許可します。

IP アドレスの完全な一覧は、 Azure IP 範囲とサービスタグ – パブリッククラウド JSON ファイルで公開されています。
規則を定期的に更新し、最新のIPアドレスが含まれていることを確認します。

Traffic Manager の入れ子になったプロファイル

入れ子になったプロファイルを構成するにはどうすればよいですか。

入れ子になった Traffic Manager プロファイルは、Azure Resource Manager と従来の Azure REST API (Azure PowerShell コマンドレットとクロスプラットフォームの Azure CLI コマンド) を使用して構成できます。新しい Azure portal でもサポートされます。

Traffic Manager でサポートされている入れ子の階層は何層ですか?

プロファイルは最大 10 レベルまで入れ子にすることができます。 'ループ' は許されません。

同じ Traffic Manager プロファイルに、入れ子になった子プロファイルと他の種類のエンドポイントを混在させることはできますか。

はい。プロファイル内での異なる種類のエンドポイントの組み合わせには制限はありません。

入れ子になったプロファイルに対して課金モデルはどのように適用されますか。

入れ子になったプロファイルの使用が料金に悪影響を及ぼすことはありません。

Traffic Manager の課金には、エンドポイントの正常性チェックと数百万の DNS クエリの 2 つの構成要素があります。

エンドポイントの正常性チェック: 親プロファイルのエンドポイントとして構成されている子プロファイルには課金されません。子プロファイル内のエンドポイントの監視は、通常の方法で課金されます。
DNS クエリ: 各クエリは 1 回だけカウントされます。子プロファイルからエンドポイントを返す親プロファイルに対するクエリは、親プロファイルにのみカウントされます。

詳細については、「Traffic Manager の価格」のページを参照してください。

入れ子になったプロファイルでは、パフォーマンスへの影響はありますか。

いいえ、入れ子になったプロファイルを使用しても、パフォーマンスに影響はありません。

Traffic Manager のネームサーバーは、各 DNS クエリを処理するときにプロファイル階層の内部をスキャンします。親プロファイルに対する DNS クエリは、子プロファイルのエンドポイントを含む DNS 応答を受信できます。単一のプロファイルまたは入れ子になったプロファイルのどちらを使うときも、単一の CNAME レコードが使われます。階層内のプロファイルごとに CNAME レコードを作る必要はありません。

Traffic Manager では、親プロファイルの入れ子になったエンドポイントの正常性をどのように計算するのですか。

親プロファイルでは、子の正常性チェックは直接には実行されません。代わりに、子プロファイルのエンドポイントの正常性を使用して、子プロファイルの全体的な正常性が計算されます。この情報は、入れ子になったプロファイルの階層の上位に伝達され、入れ子になったエンドポイントの状態が判断されます。親プロファイルでは、この正常性の集計結果を使用して、トラフィックを子プロファイルに送信できるかどうかを決定します。

次の表に、入れ子になったエンドポイントに対する Traffic Manager 正常性チェックの動作を示します。

子プロファイルモニターの状態	親エンドポイント監視の状態	注記
[無効]。子プロファイルは無効化されています。	停止済み	親エンドポイントの状態は、`Stopped` ではなく `Disabled` です。 `Disabled` の状態は、親プロファイルでエンドポイントを無効にしたことを示すために予約されています。
デグレード。 1 つ以上の子プロファイルエンドポイントが `Degraded` 状態です。	Online: 子プロファイルの `Online` エンドポイントの数が `MinChildEndpoints` の値以上です。 CheckingEndpoint: 子プロファイルの `Online` と `CheckingEndpoint` エンドポイントを加えた数が `MinChildEndpoints` の値以上です。 Degraded: それ以外の場合。	トラフィックは、`CheckingEndpoint` 状態のエンドポイントにルーティングされます。 `MinChildEndpoints` の設定値が大きすぎると、エンドポイントは常に低下状態になります。
オンライン。 1 つ以上の子プロファイルエンドポイントが `Online` 状態です。 `Degraded` 状態のエンドポイントはありません。	上記を参照してください。
エンドポイントの確認。 1 つ以上の子プロファイルエンドポイントが `CheckingEndpoint` です。 `Online` または `Degraded` のエンドポイントはありません	上記と同じです。
Inactive。すべての子プロファイルエンドポイントが `Disabled` 状態または `Stopped` 状態であるか、このプロファイルにエンドポイントがありません。	停止済み

重要

Azure Traffic Manager 内で、親プロファイルの下にある子プロファイルを管理する際、2 つの子プロファイルを同時に無効にしてから有効にすると、問題が発生する場合があります。これらのアクションが同時に発生した場合、両方のエンドポイントが無効になる短い期間が発生し、親プロファイルが侵害された状態になる可能性があります。

複数の子プロファイルを同時に変更する際は注意して、この問題を回避してください。ご利用のトラフィック管理構成での意図しない中断を防ぐには、これらのアクションは少しずらして行うことをご検討ください。

Traffic Manager プロファイルに Azure Cloud Services 拡張サポートエンドポイントを追加できないのはなぜですか?

Traffic Manager プロファイルに Azure Cloud Extended エンドポイントを追加するには、リソースグループに Azure Service Management (ASM) API との互換性がある必要があります。古いリソースグループに存在するプロファイルは ASM API 標準に準拠している必要があります。この標準では、プロファイルとは異なるサブスクリプションからのパブリック IP アドレスエンドポイントまたはエンドポイントの組み込みを禁止しています。これを解決するには、Traffic Manager プロファイルおよび関連付けられているリソースを、ASM API と互換性のある新しいリソースグループに移動することを検討してください。

次のステップ:

Traffic Manager のエンドポイントの監視と自動フェールオーバーの詳細を確認する。
Traffic Manager のトラフィックルーティング方法の詳細を確認する。

フィードバック

このページはお役に立ちましたか?