Azure Traffic Manager

解決する課題

• 複数リージョン・複数データセンターに配置したアプリを、1 つのドメイン名でまとめて公開し、ユーザーを最適なエンドポイントへ誘導したい
• あるリージョンが障害になったとき、自動でフェイルオーバーして稼働中のリージョンへ切り替えたい
• ユーザーからネットワーク的に最も近い・遅延が小さいエンドポイントへ振り分け、体感速度を上げたい
• Azure リージョン内に閉じない、Azure 外（オンプレミスや他クラウド）も含めたグローバルな分散を DNS レベルで実現したい

主要概念と用語

• Traffic Manager プロファイル: 設定全体の入れ物。<name>.trafficmanager.net という DNS 名を持ち、ルーティング方式やヘルスチェック設定を保持する
• エンドポイント: 振り分け先。Azure エンドポイント（App Service / Public IP など）、外部エンドポイント（任意の FQDN/IP、他クラウドやオンプレ）、入れ子（Nested）エンドポイント（別プロファイルを子として束ねる）の 3 種類がある
• ルーティング方式: 応答するエンドポイントの選び方。優先度（Priority）、重み付き（Weighted）、パフォーマンス（Performance）、地理（Geographic）、マルチバリュー（MultiValue）、サブネット（Subnet）から選ぶ
• エンドポイント監視（ヘルスチェック）: 指定プロトコル・ポート・パスへ定期的にプローブを送り、正常なエンドポイントだけを DNS 応答に含める
• TTL（Time To Live）: 返した DNS 応答をクライアントやリゾルバがキャッシュする秒数。短くするほど切り替えが速いが、問い合わせ回数は増える
• エンドポイントの状態: 有効・無効（手動停止）・劣化（プローブ失敗）・停止・チェック中などの状態を持ち、応答に含めるかを決める

仕様・制限・クォータ

• Traffic Manager は DNS の名前解決の層だけで動作する。実際のトラフィックはクライアントから選ばれたエンドポイントへ直接流れ、Traffic Manager を経由しない（プロキシではない）
• そのため、L4/L7 のデータ経路には介在しない。SSL 終端・キャッシュ・URL ベースルーティングなどは行わない（必要なら Front Door や Application Gateway と併用）
• ルーティングはあくまでどの IP/CNAME を返すかの制御であり、クライアントやリゾルバが応答を TTL の間キャッシュするため、切り替えには TTL 相当のラグが生じる
• 1 プロファイルに登録できるエンドポイント数や、サブスクリプションあたりのプロファイル数などにクォータがある（必要に応じて引き上げ申請）
• 監視プローブの間隔・タイムアウト・許容失敗回数は設定可能で、これらの組み合わせでフェイルオーバー検知までの時間が決まる

内部の仕組み

クライアントが app.contoso.com を解決すると、CNAME がたどられ最終的に Traffic Manager の DNS 名へ到達します。Traffic Manager の権威 DNS が、プロファイルのルーティング方式と各エンドポイントの監視状態を評価し、最適な 1 つ（またはマルチバリューでは複数）のエンドポイントを応答として返します。

• 返ってきた IP/ホスト名に対し、クライアントは直接接続する。以降の通信に Traffic Manager は関与しない
• バックグラウンドでは、各エンドポイントへヘルスプローブを継続送信し、劣化したものを応答候補から除外する。回復すれば自動で復帰する
• 入れ子（Nested）プロファイルを使うと、たとえば「親はパフォーマンスで地域を選び、子は各地域内で重み付き分散」のように方式を多段で組み合わせられる
• 応答には TTL が付き、リゾルバ/クライアントはその間キャッシュする。TTL を短くするとフェイルオーバーは速くなるが、DNS 問い合わせ頻度が上がる

設計パターン / ベストプラクティス

• アクティブ-スタンバイ（DR）: 優先度ルーティングで主リージョンを優先し、障害時に副リージョンへ自動フェイルオーバー
• アクティブ-アクティブ: 重み付きで複数リージョンへ比率配分。新リージョンの段階投入（カナリア）にも使える
• 遅延最適化: パフォーマンスルーティングでユーザーに最も近い・速いリージョンへ誘導し、体感速度を改善
• データ主権/地域要件: 地理ルーティングで「日本からの要求は日本のエンドポイントへ」のように国・地域単位で固定
• 多段構成: 入れ子プロファイルで「パフォーマンスで地域選択 → その地域内は重み付き」のように方式を組み合わせる
• HTTP 層の機能が必要なら併用: キャッシュ・WAF・SSL オフロード・パスベースルーティングは Front Door / Application Gateway に任せ、Traffic Manager はグローバルな DNS 振り分けに専念させる

運用・監視

• Azure Monitor / メトリクスで、エンドポイントやプロファイル単位の正常性・クエリ数を監視できる
• 各エンドポイントの**監視状態（正常/劣化）**を確認し、劣化が続く場合はプローブのパス・ポート・プロトコルとアプリ側の応答（期待ステータスコード）を点検する
• 監視プローブは想定どおりのパス・ステータスを返す軽量なヘルスエンドポイントを用意しておくとよい
• フェイルオーバー検知時間はプローブ間隔 × 許容失敗回数 + TTLでおおよそ見積もれる。要件に合わせて調整する

コスト

• 課金は主に DNS クエリ数（百万クエリ単位） と、ヘルスチェックされるエンドポイント数が中心。データ転送量では課金されない（トラフィックは経由しないため）
• エンドポイントの種類（Azure / 外部 / 入れ子）や、付加的な監視機能によって単価が変わる場合がある
• TTL を極端に短くすると DNS クエリ数が増え、クエリ課金が増える可能性がある。フェイルオーバー速度とコストのバランスで TTL を決める
• 変動する具体的な単価は公式の料金ページで確認すること

セキュリティ

• Traffic Manager は DNS 応答を返すだけで、トラフィックの中身には触れない。したがって暗号化・認証・WAF は各エンドポイント側の責務になる
• エンドポイント自体の保護（TLS、ファイアウォール、WAF、ネットワーク制限）は、App Service / VM / Front Door など配信元の層で実装する
• DNS 応答で内部 IP やプライベートな FQDN を露出しないよう、外部エンドポイントの登録内容に注意する
• グローバル公開する Web では、Traffic Manager の前段または各リージョン前段に Front Door の WAF / DDoS 保護を組み合わせて L7 防御を担保するとよい

Well-Architected の観点

• 信頼性（Reliability）: マルチリージョン構成と自動フェイルオーバーにより、単一リージョン障害でも可用性を維持する中核機能。TTL とプローブ設定が**実効的な復旧時間（RTO）**を左右する
• パフォーマンス効率（Performance Efficiency）: パフォーマンスルーティングで最寄り・最速リージョンへ誘導し、グローバルユーザーの遅延を低減する
• 運用上の優秀性: ヘルスエンドポイントの整備とメトリクス監視で、障害検知と切り替えを自動化・観測可能にする
• コスト最適化: トラフィック経由ではないためデータ転送課金がなく、グローバル分散を比較的低コストで実現できる

試験で問われるポイント

関連サービス・比較

• 同じ「DNS で振り分ける」役割として、Azure の Traffic Manager は AWS の Route 53 に最も近い。両者ともトラフィックを経由せず、応答する IP/名前を制御する点が共通
• Azure 内の役割分担: グローバル L7（経由型）= Front Door、リージョン内 L7 = Application Gateway、リージョン内 L4 = Load Balancer、グローバル DNS 振り分け = Traffic Manager。HTTP のキャッシュや WAF が要るなら Front Door、純粋に「どのリージョンへ向けるか」だけなら Traffic Manager を選ぶ
• DNS ベースのため任意のエンドポイント（他クラウド・オンプレ）も束ねられる柔軟性が強み。一方で TTL キャッシュの影響を受ける点は Front Door の経由型フェイルオーバーと異なる

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Traffic Manager プロファイルを作成（優先度ルーティング + HTTP 監視）
az network traffic-manager profile create \
  --resource-group demo-rg \
  --name demo-tm \
  --routing-method Priority \
  --unique-dns-name demo-tm-contoso \
  --ttl 30 \
  --protocol HTTP --port 80 --path "/health"

# プライマリのエンドポイント（外部 FQDN、優先度 1）を追加
az network traffic-manager endpoint create \
  --resource-group demo-rg \
  --profile-name demo-tm \
  --name primary-japaneast \
  --type externalEndpoints \
  --target www.contoso-japaneast.com \
  --endpoint-status Enabled \
  --priority 1

# セカンダリのエンドポイント（外部 FQDN、優先度 2 = スタンバイ）を追加
az network traffic-manager endpoint create \
  --resource-group demo-rg \
  --profile-name demo-tm \
  --name secondary-westus \
  --type externalEndpoints \
  --target www.contoso-westus.com \
  --endpoint-status Enabled \
  --priority 2

# プロファイルとエンドポイントの監視状態を確認
az network traffic-manager profile show \
  --resource-group demo-rg \
  --name demo-tm \
  --query "{fqdn:dnsConfig.fqdn, method:trafficRoutingMethod, status:monitorConfig.profileMonitorStatus}"