Traffic Manager のルーティング方法Traffic Manager routing methods

Azure Traffic Manager では、さまざまなサービス エンドポイントにネットワーク トラフィックをルーティングする方法を決定するために、4 つのトラフィック ルーティング方法をサポートしています。Azure Traffic Manager supports four traffic-routing methods to determine how to route network traffic to the various service endpoints. Traffic Manager では、受信する DNS クエリごとにトラフィック ルーティング方法が適用されます。Traffic Manager applies the traffic-routing method to each DNS query it receives. トラフィック ルーティング方法によって、DNS 応答で返されるエンドポイントが決まります。The traffic-routing method determines which endpoint returned in the DNS response.

Traffic Manager では、次の 4 つのトラフィック ルーティング方法を使用できます。There are four traffic routing methods available in Traffic Manager:

  • 優先順位: すべてのトラフィックにプライマリ サービス エンドポイントを使用し、プライマリ エンドポイントまたはバックアップ エンドポイントが使用できない場合に備えてバックアップを用意する場合は、"優先順位" を選択します。Priority: Select Priority when you want to use a primary service endpoint for all traffic, and provide backups in case the primary or the backup endpoints are unavailable.
  • 重み付け: 一連のエンドポイントに、均等にまたは定義した重みに従ってトラフィックを分散させる場合は、"重み付け" を選択します。Weighted: Select Weighted when you want to distribute traffic across a set of endpoints, either evenly or according to weights, which you define.
  • パフォーマンス: 複数のエンドポイントが地理的に異なる場所にあり、エンド ユーザーが、ネットワーク待ち時間が最も短いという意味で "最も近い" エンドポイントを使用できるようにする場合は、"パフォーマンス" を選択します。Performance: Select Performance when you have endpoints in different geographic locations and you want end users to use the "closest" endpoint in terms of the lowest network latency.
  • 地理的: DNS クエリの発信元の地理的な場所に基づいてユーザーを特定のエンドポイント (Azure、外部、または入れ子になっているエンドポイント) に割り当てる場合は、"地理的" を選択します。Geographic: Select Geographic so that users are directed to specific endpoints (Azure, External, or Nested) based on which geographic location their DNS query originates from. こうすることで、Traffic Manager の利用者は、ユーザーのリージョンを把握し、そのリージョンに基づいてユーザーをルーティングすることが重要なシナリオを実現できます。This empowers Traffic Manager customers to enable scenarios where knowing a user’s geographic region and routing them based on that is important. データ主権規制、コンテンツおよびユーザー エクスペリエンスのローカライズ、さまざまなリージョンからのトラフィックの測定がその例に挙げられます。Examples include complying with data sovereignty mandates, localization of content & user experience and measuring traffic from different regions.

すべての Traffic Manager プロファイルには、エンドポイントの正常性とエンドポイントの自動フェールオーバーの監視が含まれます。All Traffic Manager profiles include monitoring of endpoint health and automatic endpoint failover. 詳細については、 Traffic Manager のエンドポイント監視に関する記事をご覧ください。For more information, see Traffic Manager Endpoint Monitoring. 1 つの Traffic Manager プロファイルで使用できるトラフィック ルーティング方法は 1 つに限られます。A single Traffic Manager profile can use only one traffic routing method. プロファイルの別のトラフィック ルーティング方法をいつでも選択できます。You can select a different traffic routing method for your profile at any time. 変更は 1 分以内に適用され、ダウンタイムは発生しません。Changes are applied within one minute, and no downtime is incurred. 入れ子になった Traffic Manager プロファイルを使用することで、トラフィック ルーティング方法を組み合わせることができます。Traffic-routing methods can be combined by using nested Traffic Manager profiles. 入れ子にすることで、高度で柔軟性のあるトラフィック ルーティング構成が可能になり、より大規模で複雑なアプリケーションのニーズに対応できます。Nesting enables sophisticated and flexible traffic-routing configurations that meet the needs of larger, complex applications. 詳細については、「 入れ子になった Traffic Manager プロファイル」をご覧ください。For more information, see nested Traffic Manager profiles.

優先順位トラフィック ルーティング方法Priority traffic-routing method

多くの場合、組織ではサービスの信頼性を提供したいと考えており、主要なサービスがダウンした場合に備えて 1 つ以上のバックアップ サービスをデプロイすることでこれを実行しています。Often an organization wants to provide reliability for its services by deploying one or more backup services in case their primary service goes down. "優先順位" トラフィック ルーティング方法を使用すると、Azure ユーザーはこのフェールオーバー パターンを簡単に実装できます。The 'Priority' traffic-routing method allows Azure customers to easily implement this failover pattern.

Azure Traffic Manager の "優先順位" トラフィック ルーティング方法

Traffic Manager プロファイルには、サービス エンドポイントの優先順位リストが含まれます。The Traffic Manager profile contains a prioritized list of service endpoints. Traffic Manager では、既定では、すべてのトラフィックがプライマリ (優先順位が一番高い) エンドポイントに送信されます。By default, Traffic Manager sends all traffic to the primary (highest-priority) endpoint. プライマリ エンドポイントを使用できない場合、Traffic Manager は、2 番目のエンドポイントにトラフィックをルーティングします。If the primary endpoint is not available, Traffic Manager routes the traffic to the second endpoint. プライマリとセカンダリのどちらのエンドポイントも使用できない場合、トラフィックは 3 番目のエンドポイントに送信されます。以降も同様です。If both the primary and secondary endpoints are not available, the traffic goes to the third, and so on. エンドポイントの可用性は、構成済みのステータス (有効または無効) とエンドポイントの継続的な監視に基づきます。Availability of the endpoint is based on the configured status (enabled or disabled) and the ongoing endpoint monitoring.

エンドポイントの構成Configuring endpoints

Azure Resource Manager では、エンドポイントごとに "priority" プロパティを使用して、エンドポイントの優先順位を明示的に構成します。With Azure Resource Manager, you configure the endpoint priority explicitly using the 'priority' property for each endpoint. このプロパティの値の範囲は、1 ~ 1000 です。This property is a value between 1 and 1000. 値が小さいほど、優先順位が高くなります。Lower values represent a higher priority. 同じ優先順位の値を複数のエンドポイントに指定することはできません。Endpoints cannot share priority values. プロパティの設定は省略可能です。Setting the property is optional. 省略した場合、エンドポイントの順序に基づく既定の優先順位が使用されます。When omitted, a default priority based on the endpoint order is used.

重み付けトラフィック ルーティング方法Weighted traffic-routing method

"重み付け" トラフィック ルーティング方法を使用すると、トラフィックを均等に分散したり、定義済みの重み付けを使用したりできます。The 'Weighted' traffic-routing method allows you to distribute traffic evenly or to use a pre-defined weighting.

Azure Traffic Manager の "重み付け" トラフィック ルーティング方法

重み付けトラフィック ルーティング方法では、Traffic Manager プロファイル構成で各エンドポイントに重みを割り当てます。In the Weighted traffic-routing method, you assign a weight to each endpoint in the Traffic Manager profile configuration. 重みは 1 から 1000 の整数です。The weight is an integer from 1 to 1000. このパラメーターは省略可能です。This parameter is optional. 省略すると、Traffic Managers では、既定の重みの "1" が使用されます。If omitted, Traffic Managers uses a default weight of '1'. 重みが大きくなると、優先順位がそれだけ上がります。The higher weight, the higher the priority.

Traffic Manager では、受信する DNS クエリごとに、使用可能なエンドポイントをランダムに選択します。For each DNS query received, Traffic Manager randomly chooses an available endpoint. あるエンドポイントが選択される確率は、すべての利用可能なエンドポイントに割り当てられている重みに基づきます。The probability of choosing an endpoint is based on the weights assigned to all available endpoints. すべてのエンドポイント間で同じ重みを使用すると、トラフィック分散は均一になります。Using the same weight across all endpoints results in an even traffic distribution. 特定のエンドポイントの重みを大きくする (または小さくする) と、それらのエンドポイントは DNS からの応答の頻度が増えます (または減ります)。Using higher or lower weights on specific endpoints causes those endpoints to be returned more or less frequently in the DNS responses.

重み付け方式を使用することで、有用なシナリオをいくつか実現できます。The weighted method enables some useful scenarios:

  • アプリケーションの段階的アップグレード: 新しいエンドポイントにルーティングするトラフィックのパーセンテージを割り当て、時間と共に 100% までトラフィックを徐々に増やします。Gradual application upgrade: Allocate a percentage of traffic to route to a new endpoint, and gradually increase the traffic over time to 100%.
  • Azure へのアプリケーション移行: Azure と外部エンドポイントの両方を含むプロファイルを作成します。Application migration to Azure: Create a profile with both Azure and external endpoints. エンドポイントの重みを調整して新しいエンドポイントを優先します。Adjust the weight of the endpoints to prefer the new endpoints.
  • 追加容量のクラウド バースト: Traffic Manager プロファイルに対応させることで、オンプレミスのデプロイメントをクラウドにすばやく拡張します。Cloud-bursting for additional capacity: Quickly expand an on-premises deployment into the cloud by putting it behind a Traffic Manager profile. クラウドに追加容量が必要なとき、エンドポイントを追加または有効にして、各エンドポイントに送るトラフィックの割り当てを指定します。When you need extra capacity in the cloud, you can add or enable more endpoints and specify what portion of traffic goes to each endpoint.

Resource Manager Azure Portal は、重み付けトラフィック ルーティングの構成をサポートしています。The Resource Manager Azure portal supports the configuration of weighted traffic routing. Resource Manager バージョンの Azure PowerShell、CLI、REST API を使用して重み付けを構成することができます。You can configure weights using the Resource Manager versions of Azure PowerShell, CLI, and the REST APIs.

クライアントと、DNS 名を解決するためにクライアントが使用する再帰 DNS サーバーによって、DNS 応答がキャッシュされることに留意してください。It is important to understand that DNS responses are cached by clients and by the recursive DNS servers that the clients use to resolve DNS names. このキャッシュは、重み付けトラフィック分散に影響を与える可能性があります。This caching can have an impact on weighted traffic distributions. クライアントと再帰 DNS サーバーの数が多い場合は、トラフィック分散が期待どおりに機能します。When the number of clients and recursive DNS servers is large, traffic distribution works as expected. ただし、クライアントまたは再帰 DNS サーバーの数が少ない場合は、キャッシュによってトラフィック分散に大きな偏りが生じる可能性があります。However, when the number of clients or recursive DNS servers is small, caching can significantly skew the traffic distribution.

一般的なユース ケースは次のとおりです。Common use cases include:

  • 開発環境とテスト環境Development and testing environments
  • アプリケーション間の通信Application-to-application communications
  • 共通の再帰 DNS インフラストラクチャを共有する、限られたユーザーを対象としたアプリケーション (たとえば、プロキシ経由で接続する会社の従業員など)Applications aimed at a narrow user-base that share a common recursive DNS infrastructure (for example, employees of company connecting through a proxy)

これらの DNS キャッシュの影響は、Azure Traffic Manager だけでなく、DNS ベースのすべてのトラフィック ルーティング システムに共通するものです。These DNS caching effects are common to all DNS-based traffic routing systems, not just Azure Traffic Manager. DNS キャッシュの明示的なクリアが回避策になる場合もあれば、In some cases, explicitly clearing the DNS cache may provide a workaround. 別のトラフィック ルーティング方法の方が適している場合もあります。In other cases, an alternative traffic-routing method may be more appropriate.

パフォーマンス トラフィック ルーティング方法Performance traffic-routing method

世界中の複数の場所にエンドポイントをデプロイすると、ユーザーに "最も近い" 場所にトラフィックをルーティングすることで、多くのアプリケーションの応答性を向上させることができます。Deploying endpoints in two or more locations across the globe can improve the responsiveness of many applications by routing traffic to the location that is 'closest' to you. "パフォーマンス" トラフィック ルーティング方法が、この機能を提供します。The 'Performance' traffic-routing method provides this capability.

Azure Traffic Manager の "パフォーマンス" トラフィック ルーティング方法

"最も近い" エンドポイントが必ずしも地理的な距離で最も近いとは限りません。The 'closest' endpoint is not necessarily closest as measured by geographic distance. "パフォーマンス" トラフィック ルーティング方法では、代わりに、ネットワーク待ち時間を尺度として最も近いエンドポイントを特定します。Instead, the 'Performance' traffic-routing method determines the closest endpoint by measuring network latency. Traffic Manager は、インターネット待機時間テーブルを管理して、IP アドレス範囲と各 Azure データセンター間のラウンドトリップ時間を追跡します。Traffic Manager maintains an Internet Latency Table to track the round-trip time between IP address ranges and each Azure datacenter.

Traffic Manager は、受信 DNS 要求の送信元 IP アドレスをインターネット待機時間テーブルで見つけます。Traffic Manager looks up the source IP address of the incoming DNS request in the Internet Latency Table. Traffic Manager は、その IP アドレス範囲について待機時間が最も短くなる Azure データ センター内の使用可能なエンドポイントを選び、DNS 応答でそのエンドポイントを返します。Traffic Manager chooses an available endpoint in the Azure datacenter that has the lowest latency for that IP address range, then returns that endpoint in the DNS response.

Traffic Manager の動作のしくみで説明したように、Traffic Manager は、クライアントから直接には DNS クエリを受信しません。As explained in How Traffic Manager Works, Traffic Manager does not receive DNS queries directly from clients. 代わりに、DNS クエリは、クライアントが使用するように構成された再帰 DNS サービスから受信します。Rather, DNS queries come from the recursive DNS service that the clients are configured to use. そのため、"最も近い" エンドポイントの特定に使用される IP アドレスは、クライアントの IP アドレスではなく、再帰 DNS サービスの IP アドレスになります。Therefore, the IP address used to determine the 'closest' endpoint is not the client's IP address, but it is the IP address of the recursive DNS service. 実際には、この IP アドレスはクライアントにとって適切なプロキシとなります。In practice, this IP address is a good proxy for the client.

Traffic Manager は、インターネット待機時間テーブルを定期的に更新して、グローバル インターネットと新しい Azure リージョンの変化に対応しています。Traffic Manager regularly updates the Internet Latency Table to account for changes in the global Internet and new Azure regions. ただし、アプリケーションのパフォーマンスは、インターネット全体におけるリアルタイムな負荷の変動によって変わります。However, application performance varies based on real-time variations in load across the Internet. パフォーマンスによるトラフィック ルーティングでは、特定のサービス エンドポイントの負荷は監視されません。Performance traffic-routing does not monitor load on a given service endpoint. ただし、エンドポイントを使用できなくなった場合は、Traffic Manager は DNS クエリの応答にそのエンドポイントを含みません。However, if an endpoint becomes unavailable, Traffic Manager does not include it in DNS query responses.

注意する点:Points to note:

  • プロファイルに同一 Azure リージョン内の複数のエンドポイントが含まれている場合は、Traffic Manager では、そのリージョンで利用可能なエンドポイントにトラフィックが均等に分散されます。If your profile contains multiple endpoints in the same Azure region, then Traffic Manager distributes traffic evenly across the available endpoints in that region. リージョン内で別のトラフィック分散を使用する場合は、入れ子になった Traffic Manager プロファイルを使用できます。If you prefer a different traffic distribution within a region, you can use nested Traffic Manager profiles.
  • 最も近い Azure リージョン内のすべての有効なエンドポイントの機能が低下している場合は、Traffic Manager によって次に近い Azure リージョン内のエンドポイントにトラフィックが移動されます。If all enabled endpoints in the closest Azure region are degraded, Traffic Manager moves traffic to the endpoints in the next closest Azure region. 希望するフェールオーバー シーケンスを定義する場合は、「入れ子になった Traffic Manager プロファイル」を使用してください。If you want to define a preferred failover sequence, use nested Traffic Manager profiles.
  • 外部エンドポイントまたは入れ子になったエンドポイントでパフォーマンス トラフィック ルーティング方法を使用する場合は、エンドポイントの場所を指定する必要があります。When using the Performance traffic routing method with external endpoints or nested endpoints, you need to specify the location of those endpoints. デプロイメントに最も近い Azure リージョンを選択してください。Choose the Azure region closest to your deployment. これらの場所は、インターネット待機時間テーブルでサポートされている値です。Those locations are the values supported by the Internet Latency Table.
  • エンドポイントを選択するアルゴリズムは確定的です。The algorithm that chooses the endpoint is deterministic. 同じクライアントからの反復 DNS クエリは、同じエンドポイントに送信されます。Repeated DNS queries from the same client are directed to the same endpoint. 通常、クライアントは、出張中に別の再帰 DNS サーバーを使用します。Typically, clients use different recursive DNS servers when traveling. このクライアントは、別のエンドポイントにルーティングされる可能性があります。The client may be routed to a different endpoint. また、ルーティングは、インターネット待機時間テーブルの更新の影響を受ける場合もあります。Routing can also be affected by updates to the Internet Latency Table. そのため、パフォーマンス トラフィック ルーティング方法では、クライアントが常に同じエンドポイントにルーティングされる保証はありません。Therefore, the Performance traffic-routing method does not guarantee that a client is always routed to the same endpoint.
  • インターネット待機時間テーブルが変更されたときに、一部のクライアントが別のエンドポイントにルーティングされていることに気付く場合があります。When the Internet Latency Table changes, you may notice that some clients are directed to a different endpoint. このルーティングの変更は、最新の待機時間データに基づいてより厳密に行われます。This routing change is more accurate based on current latency data. これらの更新は、インターネットが継続的に発展する中で、パフォーマンス トラフィック ルーティングの精度を維持するために不可欠となります。These updates are essential to maintain the accuracy of Performance traffic-routing as the Internet continually evolves.

地理的トラフィック ルーティング方法Geographic traffic-routing method

Traffic Manager プロファイルで地理的ルーティング方法を使用するように構成できます。これにより、DNS クエリの発信元の地理的な場所に基づいて、ユーザーを特定のエンドポイント (Azure、外部、または入れ子) にルーティングされます。Traffic Manager profiles can be configured to use the Geographic routing method so that users are directed to specific endpoints (Azure, External or Nested) based on which geographic location their DNS query originates from. こうすることで、Traffic Manager の利用者は、ユーザーのリージョンを把握し、そのリージョンに基づいてユーザーをルーティングすることが重要なシナリオを実現できます。This empowers Traffic Manager customers to enable scenarios where knowing a user’s geographic region and routing them based on that is important. データ主権規制、コンテンツおよびユーザー エクスペリエンスのローカライズ、さまざまなリージョンからのトラフィックの測定がその例に挙げられます。Examples include complying with data sovereignty mandates, localization of content & user experience and measuring traffic from different regions. 地理的ルーティング用にプロファイルを構成したら、そのプロファイルに関連付けられた各エンドポイントに地理的なリージョンのセットを割り当てる必要があります。When a profile is configured for geographic routing, each endpoint associated with that profile needs to have a set of geographic regions assigned to it. リージョンは、次のレベルの粒度で指定できます。A geographic region can be at following levels of granularity

  • 世界 – 任意のリージョンWorld– any region
  • リージョン グループ – アフリカ、中東、オーストラリア/太平洋などRegional Grouping – for example, Africa, Middle East, Australia/Pacific etc.
  • 国/リージョン – アイルランド、ペルー、香港特別行政区などCountry/Region – for example, Ireland, Peru, Hong Kong SAR etc.
  • 都道府県 – 米国カリフォルニア州、オーストラリア クイーンズランド州、カナダ アルバータ州など (注: 都道府県でこのレベルの粒度がサポートされているのは、オーストラリア、カナダ、英国、米国のみです)。State/Province – for example, USA-California, Australia-Queensland, Canada-Alberta etc. (note: this granularity level is supported only for states / provinces in Australia, Canada, UK, and USA).

エンドポイントにリージョンまたはリージョンのセットが割り当てられると、それらのリージョンからの要求は、そのエンドポイントにのみルーティングされます。When a region or a set of regions is assigned to an endpoint, any requests from those regions gets routed only to that endpoint. Traffic Manager は、DNS クエリの発信元 IP アドレスを使用して、ユーザーがクエリを送信しているリージョンを特定します。通常、これはユーザーの代わりにクエリを実行するローカル DNS リゾルバーの IP アドレスになります。Traffic Manager uses the source IP address of the DNS query to determine the region from which a user is querying from – usually this is the IP address of the local DNS resolver doing the query on behalf of the user.

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

Traffic Manager は DNS クエリの発信元 IP アドレスを読み取り、送信元のリージョンを決定します。Traffic Manager reads the source IP address of the DNS query and decides which geographic region it is originating from. 次に、この地理的リージョンがマップされているエンドポイントがあるかどうかを確認します。It then looks to see if there is an endpoint that has this geographic region mapped to it. この検索は、最も低い粒度レベル (サポートされている場合は都道府県、それ以外の場合は国/リージョン レベル) で始まり、最も高いレベルである世界まで進みます。This lookup starts at the lowest granularity level (State/Province where it is supported, else at the Country/Region level) and goes all the way up to the highest level, which is World. このトラバーサルを使用して見つかった最初の一致が、クエリの応答で返されるエンドポイントとして指定されます。The first match found using this traversal is designated as the endpoint to return in the query response. 入れ子になっている種類のエンドポイントと一致する場合、ルーティング方法に基づいて、その子プロファイル内のエンドポイントが返されます。When matching with a Nested type endpoint, an endpoint within that child profile is returned, based on its routing method. 次の点がこの動作に関係します。The following points are applicable to this behavior:

  • ルーティングの種類が地理的ルーティングの場合、リージョンは Traffic Manager プロファイル内の 1 つのエンドポイントにのみマップできます。A geographic region can be mapped only to one endpoint in a Traffic Manager profile when the routing type is Geographic Routing. これにより、ユーザーのルーティングが確定的になるため、明確な地理的境界を必要とするシナリオを実現できます。This ensures that routing of users is deterministic, and customers can enable scenarios that require unambiguous geographic boundaries.
  • ユーザーのリージョンが 2 つの異なるエンドポイントの地理的マッピングに属する場合、Traffic Manager は、粒度が低いほうのエンドポイントを選択します。そのリージョンからもう 1 つのエンドポイントへのルーティング要求は考慮されません。If a user’s region comes under two different endpoints’ geographic mapping, Traffic Manager selects the endpoint with the lowest granularity and does not consider routing requests from that region to the other endpoint. たとえば、Endpoint1 と Endpoint2 の 2 つのエンドポイントが含まれた、ルーティングの種類が地理的ルーティングのプロファイルを考えてみましょう。For example, consider a Geographic Routing type profile with two endpoints - Endpoint1 and Endpoint2. Endpoint1 はアイルランドからのトラフィックを受信するように構成し、Endpoint2 はヨーロッパからのトラフィックを受信するように構成します。Endpoint1 is configured to receive traffic from Ireland and Endpoint2 is configured to receive traffic from Europe. 要求がアイルランドから送信された場合、常に Endpoint1 にルーティングされます。If a request originates from Ireland, it is always routed to Endpoint1.
  • リージョンをマップできるのは 1 つのエンドポイントに限られるため、Traffic Manager は、エンドポイントが正常かどうかに関係なくそのエンドポイントを返します。Since a region can be mapped only to one endpoint, Traffic Manager returns it regardless of whether the endpoint is healthy or not.

    重要

    地理的ルーティング方法を使用する場合は、少なくとも 2 つのエンドポイントを含む子プロファイルを持つ入れ子になった種類のエンドポイントに関連付けることを強くお勧めします。It is strongly recommended that customers using the geographic routing method associate it with the Nested type endpoints that has child profiles containing at least two endpoints within each.

  • エンドポイントの一致が見つかったときに、そのエンドポイントが停止状態の場合、Traffic Manager は NODATA 応答を返します。If an endpoint match is found and that endpoint is in the Stopped state, Traffic Manager returns a NODATA response. この場合、地理的リージョンの上位階層に対する検索はそれ以上行われません。In this case, no further lookups is made higher up in the geographic region hierarchy. この動作は、子プロファイルが停止または無効の状態のときの、入れ子になったエンドポイントの種類にも該当します。This behavior is also applicable for nested endpoint types when the child profile is in the Stopped or Disabled state.
  • エンドポイントが無効状態の場合、リージョンの照合プロセスの対象には含まれません。If an endpoint displays a Disabled status, it won’t be included in the region matching process. この動作は、エンドポイントが無効状態のときの、入れ子になったエンドポイントの種類にも該当します。This behavior is also applicable for nested endpoint types when the endpoint is in the Disabled state.
  • クエリが、そのプロファイルでマッピングされていない地理的リージョンから送信されている場合、Traffic Manager は NODATA 応答を返します。If a query is coming from a geographic region that has no mapping in that profile, Traffic Manager returns a NODATA response. そのため、リージョン "世界" が割り当てられた 1 つのエンドポイント (子プロファイル内に少なくとも 2 つのエンドポイントを含む入れ子になった種類が理想的) で地理的ルーティングを使用することを強くお勧めします。Therefore, it is strongly recommended that customers use geographic routing with one endpoint, ideally of type Nested with at least two endpoints within the child profile, with the region World assigned to it. これにより、リージョンにマップされていない IP アドレスも確実に処理されるようになります。This also ensures that any IP addresses that do not map to a region are handled.

Traffic Manager の動作のしくみで説明したように、Traffic Manager は、クライアントから直接には DNS クエリを受信しません。As explained in How Traffic Manager Works, Traffic Manager does not receive DNS queries directly from clients. 代わりに、DNS クエリは、クライアントが使用するように構成された再帰 DNS サービスから受信します。Rather, DNS queries come from the recursive DNS service that the clients are configured to use. そのため、リージョンの特定に使用される IP アドレスは、クライアントの IP アドレスではなく、再帰 DNS サービスの IP アドレスになります。Therefore, the IP address used to determine the region is not the client's IP address, but it is the IP address of the recursive DNS service. 実際には、この IP アドレスはクライアントにとって適切なプロキシとなります。In practice, this IP address is a good proxy for the client.

次の手順Next steps

Traffic Manager endpoint monitoringLearn how to develop high-availability applications using Traffic Manager endpoint monitoring

Traffic Manager プロファイルの作成Learn how to create a Traffic Manager profile