Azure Traffic Managerを理解するための前提
Traffic ManagerはDNS-level traffic steering serviceで、HTTP reverse proxyではない。clientはDNSで返されたendpointへ直接接続する。 profileはrouting methodとendpoint setを持ち、endpoint monitoringでhealthyな候補をDNS responseへ反映する。
routing methodsにはPriority、Weighted、Performance、Geographic、Multivalue、Subnet等がある。 failover時間はmonitoring intervalだけでなくDNS TTL、recursive resolver/client cache、application retryの影響を受ける。
Traffic Manager自体はTLS termination、WAF、HTTP header rewrite、content cachingを提供しない。必要ならendpoint側のFront Door/AppGW/LBと組み合わせる。 endpointはAzure serviceだけでなくexternal endpointも扱えるため、hybrid/multi-cloud DNS steeringにも使える。
Control plane / Data plane / Observability
Traffic Managerが選定endpointのDNS name/IPをresponseとして返す。
clientは返されたendpointへ直接connect。Traffic Managerはdata pathに入らない。
endpoint monitoringがDNS candidate setを更新する。
Client-to-backend path
- client/recursive resolverがapplication DNS nameをqueryする。
- CNAME等でTraffic Manager profile domainへqueryが到達する。
- Traffic Managerがrouting methodとendpoint healthを評価する。
- selected endpointのDNS answerをTTL付きで返す。
- clientはそのendpointへ直接TCP/TLS/HTTP接続する。
- endpoint failure後もcache TTLが残るclientは旧answerを使い続け得る。
仕組みを分解する
Traffic Managerの最大の誤解は、Front Doorのように「trafficがTraffic Managerを通過する」と考えることです。data plane pathには入りません。そのためclient IP preservationは問題にならない一方、DNS cacheのためfailoverは即時ではなく、endpoint側のTLS/WAF/cacheもTraffic Managerでは提供されません。
運用時はresource configurationだけで完了判定せず、実clientからの名前解決、TCP/TLS handshake、HTTP status、backend側のsource IP/Host/header、health telemetryを同じtimestampで揃えます。load balancer/proxyがhealthyでもapplication dependencyが壊れている場合があり、逆にbackend applicationが正常でもhealth probe条件やrouting ruleが不整合ならtrafficは到達しません。
設計判断
| 判断軸 | 設計方針 |
|---|---|
| Priority | active/passive DR。primary healthyならsecondaryへ配らない。 |
| Weighted | canary/gradual traffic split。DNS cacheのためrequest単位の厳密比率ではない。 |
| Performance | DNS resolver location/latency mapに基づくglobal distribution。 |
| Front Doorとの比較 | global HTTP proxy/WAF/cacheが必要ならFront Door。DNS-only/multi-protocol/external endpoint steeringならTraffic Manager。 |
確認手順
Read-only verification
- profile routing method、TTL、monitor configを確認する。
- endpoint type/status/monitor status/weight/priority/locationを確認する。
- 複数resolver/locationからdig/nslookupしてanswerとTTLを記録する。
- endpointをdisabled/unhealthyにしてTTLを跨いだfailoverを測る。
Evidence to keep
- resource ID / subscription / region / frontend / backend targetを保存し、同名resource取り違えを防ぐ。
- DNS answer、source IP、destination IP/port、Host/SNI、health status、timestampを同じincident recordへ残す。
- 変更前後で同じclient journeyをnew connectionとして再実行する。
- Portal表示だけでなくCLI/PowerShell/APIまたはlogsを併用し、観測面の一時差を識別する。
az network traffic-manager profile show -g <rg> -n <profile> -o jsonc
az network traffic-manager endpoint list -g <rg> --profile-name <profile> -o tableGet-AzTrafficManagerProfile -ResourceGroupName <rg> -Name <profile>
Get-AzTrafficManagerEndpoint -ResourceGroupName <rg> -ProfileName <profile> -Type AzureEndpoints障害切り分け
| 症状 | 第一候補 | 証拠 | 次の確認 |
|---|---|---|---|
| failoverが遅い | DNS cache/TTL | dig TTL + endpoint health | resolver/client cache確認 |
| 想定regionへ行かない | routing method/location | DNS answer source | resolver egress location確認 |
| TLS/WAF期待がない | service role誤認 | data path | endpoint service追加 |
| Weighted比率がずれる | DNS-level stickiness/cache | resolver query distribution | request単位比率と分離 |
| Degraded | endpoint monitoring failure | monitor status | probe protocol/path/cert |
変更時の確認と rollback
- routing method/endpoint weight/priority/TTLをexportする。
- DNS CNAME cutoverはold/new profile両方を一定期間維持する。
- TTL短縮はchange前に行わないと既存cacheには効かない。
- rollback評価はauthoritative responseだけでなく実client resolver cacheを含める。
Current notes — 2026-09-11
Traffic Managerは現在もDNS-based steering。Front Door Standard/Premiumのglobal reverse proxyとはdata-path roleが根本的に異なる。
Related articles
Official sources
動作、retirement、feature availability、health/TLS behaviorはMicrosoft Learnのcurrent documentationを基準に確認しています。production変更時は対象subscription/region/SKUの最新documentationとresource provider stateを再確認してください。