「AWSのRoute 53フェイルオーバールーティングに相当するものがAzureにもあるのか」
Azureではこの要件を Traffic Manager が担います。DNS ベースのグローバルルーティングサービスで、エンドポイントの死活監視と自動フェイルオーバーを一体で提供します。
この記事では、azure可用性を高めるTraffic ManagerのしくみをAZ CLIで構築する手順を解説します。想定環境はAzure CLI 2.50以降・Linux(Ubuntu 22.04/RHEL 9系)です。あわせてAWS Route 53との機能比較も網羅します。
この記事のポイント
・Traffic ManagerはDNS層で動作するため、VMもコンテナも関係なく冗長化できる
・AZ CLIで profile create → endpoint create の2ステップで構築完了
・ルーティングはPerformance・Priority・Geographic・Weightedから選ぶ
・Route 53との最大の違いはヘルスチェックがプロファイルに統合されている点
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Azure Traffic Managerとは何か|DNSベースのグローバルルーティング
Traffic Managerは、Azureが提供するDNSベースのトラフィックルーティングサービスです。特定のFQDN(例:myapp.trafficmanager.net)を払い出し、クライアントからのDNSクエリに対して、設定したルーティングメソッドとエンドポイントのヘルス状態に基づいて最適なIPアドレスを返します。ポイントは「ネットワークプロキシではない」という点です。Traffic Manager自体はパケットを転送しません。DNS応答でクライアントを誘導するだけなので、送客先はAzureのApp ServiceでもVMでも、AWSやオンプレミスの外部エンドポイントでも構いません。
ヘルスプローブはTraffic Managerが定期的にHTTP/HTTPS/TCPでエンドポイントへリクエストを送り、200系以外が返った場合や接続タイムアウトが続くとそのエンドポイントをDegradedに設定してルーティング対象から外します。DNSのTTLが切れた後、次のクエリからはフェイルオーバー先のIPが返るようになります。
Traffic Managerが返すFQDNのDNSの仕組み全般についてはLinux DNS 設定の基本も参考になります。
ルーティングメソッド5種類と選択基準
Traffic Managerには以下のルーティングメソッドがあります。| メソッド | 動作 | 主なユースケース |
|---|---|---|
| Priority | 優先度の高いエンドポイントへ。障害時に次点へフェイルオーバー | 本番/DR構成(アクティブ・スタンバイ) |
| Performance | クライアントから応答レイテンシが最も低いエンドポイントへ | グローバルユーザー向けのレイテンシ最適化 |
| Weighted | 重みの割合でランダムに分散 | カナリアリリース・段階的移行 |
| Geographic | クライアントの地理的位置でルーティング | データ主権要件(EU向けはEUリージョンのみ) |
| Multivalue | 複数の健全なエンドポイントIPを一度に返す | クライアント側でフェイルオーバーするDNSラウンドロビン |
azure可用性の観点でよく使われるのはPriority(アクティブ・スタンバイ型フェイルオーバー)とPerformance(常にレイテンシ最低のリージョンへ)の2つです。どちらもヘルスプローブが死活監視を担い、障害リージョンを自動排除します。
AZ CLIでTraffic Managerを構築するハンズオン手順
1. リソースグループとApp Serviceを2リージョンに用意する
Traffic Managerは複数エンドポイントを束ねる上位サービスなので、まず送客先を作ります。ここでは東日本(japaneast)と西日本(japanwest)にApp Serviceをそれぞれデプロイします。# リソースグループを2リージョンに作成 az group create --name rg-tm-japaneast --location japaneast az group create --name rg-tm-japanwest --location japanwest # App Serviceプランを各リージョンに作成(B1相当) az appservice plan create --name plan-east --resource-group rg-tm-japaneast --sku B1 --is-linux az appservice plan create --name plan-west --resource-group rg-tm-japanwest --sku B1 --is-linux # WebAppをデプロイ(名前はグローバルで一意にする) az webapp create --name myapp-east-20241101 --resource-group rg-tm-japaneast --plan plan-east --runtime "NODE|18-lts" az webapp create --name myapp-west-20241101 --resource-group rg-tm-japanwest --plan plan-west --runtime "NODE|18-lts"
# az webapp create 成功時の出力(抜粋) { "defaultHostName": "myapp-east-20241101.azurewebsites.net", "location": "Japan East", "state": "Running" }
2. Traffic Managerプロファイルを作成する
プロファイルはTraffic Managerの中心となるリソースです。ルーティングメソッドとDNS設定を定義します。# Traffic Managerプロファイルを作成(Priorityメソッド) az network traffic-manager profile create --name tm-myapp-profile --resource-group rg-tm-japaneast --routing-method Priority --dns-config-relative-name tm-myapp-20241101 --ttl 30 --monitor-protocol HTTPS --monitor-port 443 --monitor-path /healthcheck # 作成後のFQDNを確認 az network traffic-manager profile show --name tm-myapp-profile --resource-group rg-tm-japaneast --query dnsConfig.fqdn --output tsv
tm-myapp-20241101.trafficmanager.net
--dns-config-relative-name に指定した文字列が .trafficmanager.net の前に付いてFQDNになります。--ttl はDNSのTTL秒数で、フェイルオーバーを素早く反映させたい場合は30秒程度に設定します(最小値は0秒ですが、DNS基盤への負荷を考慮して30秒が目安です)。3. エンドポイントを登録する
Azureのリソースを直接参照するazureEndpoints タイプでApp Serviceを登録します。# 東日本WebAppのリソースIDを取得 EAST_ID=$(az webapp show --name myapp-east-20241101 --resource-group rg-tm-japaneast --query id --output tsv) # 東日本エンドポイントを優先度1(Primary)で登録 az network traffic-manager endpoint create --name ep-japaneast --profile-name tm-myapp-profile --resource-group rg-tm-japaneast --type azureEndpoints --target-resource-id $EAST_ID --priority 1 --endpoint-status Enabled # 西日本WebAppのリソースIDを取得 WEST_ID=$(az webapp show --name myapp-west-20241101 --resource-group rg-tm-japanwest --query id --output tsv) # 西日本エンドポイントを優先度2(Secondary)で登録 az network traffic-manager endpoint create --name ep-japanwest --profile-name tm-myapp-profile --resource-group rg-tm-japaneast --type azureEndpoints --target-resource-id $WEST_ID --priority 2 --endpoint-status Enabled
--priority は数値が小さいほど優先度が高くなります。Priority 1のエンドポイントが健全な間はすべてのトラフィックがそこへ誘導され、Degradedになった瞬間にPriority 2へフェイルオーバーします。4. DNS名でのアクセスと動作確認
Traffic Managerから払い出されたFQDNをdigコマンドで確認します。dig コマンドで DNS を調べるを使った確認方法は以下のとおりです。# Traffic ManagerのFQDNをdigで解決 dig tm-myapp-20241101.trafficmanager.net # エンドポイントのヘルス状態を確認 az network traffic-manager endpoint show --name ep-japaneast --profile-name tm-myapp-profile --resource-group rg-tm-japaneast --type azureEndpoints --query endpointMonitorStatus --output tsv
Online
endpointMonitorStatus が Online ならヘルスプローブが正常に到達しています。Degraded の場合はプローブパス(/healthcheck)が200系を返しているか、App ServiceのHTTPS設定を確認してください。AWS Route 53との機能比較
Traffic ManagerとAWS Route 53は「DNSを使ったトラフィック制御」という面で共通しますが、設計思想と機能範囲に違いがあります。| 機能 | Azure Traffic Manager | AWS Route 53 |
|---|---|---|
| 動作層 | DNS(Layer 7 ではなくDNS解決層) | DNS(同左) |
| ヘルスチェック | プロファイルに統合(HTTP/HTTPS/TCP) | 独立リソースとして作成(HTTP/HTTPS/TCP/文字列マッチ) |
| フェイルオーバー | Priority メソッドで実現 | Failoverルーティングポリシーで実現 |
| レイテンシ最適化 | Performance メソッド | Latency ルーティングポリシー |
| 地理ルーティング | Geographic メソッド(大陸・国単位) | Geolocation(国・大陸)/ Geoproximity(座標・バイアス) |
| プライベートDNS | 非対応(パブリックDNSのみ) | Private hosted zoneで対応 |
| 外部エンドポイント | 対応(AWS・オンプレミスなど) | 対応(エイリアスレコードはAWSリソース限定) |
| ネストされたプロファイル | 対応(子プロファイルでルーティング組み合わせ) | 対応(Traffic flow / レコードのチェーン) |
| コスト単位 | クエリ数+エンドポイント数+ヘルスチェック数 | ホストゾーン数+クエリ数+ヘルスチェック数 |
Traffic Managerの大きなメリットはヘルスチェックがプロファイル内に統合されている点です。Route 53では「ヘルスチェックリソース → ルーティングレコード → フェイルオーバーポリシー」と複数リソースを組み合わせる必要がありますが、Traffic Managerはプロファイル作成時にモニタリング設定も一括で定義できます。
一方、プライベートDNS対応はRoute 53の強みです。VPC内のみで解決するRoute 53 Private Hosted Zoneに相当する機能はTraffic Managerにはなく、VNet内の内部名前解決にはAzure Private DNSを組み合わせる別設計が必要になります。
よくあるエラーと対処法
「エンドポイントが Degraded になる」
ヘルスプローブがエンドポイントに到達できない場合に発生します。主な原因と確認手順は以下のとおりです。・プローブパスが存在しない:
--monitor-path に指定したパス(例: /healthcheck)がアプリ側で実装されているか確認する・NSG/ファイアウォールの遮断: Traffic Managerのプローブ元IPレンジ(
AzureTrafficManager サービスタグ)をNSGの受信規則で許可する・HTTPSプローブでSNI不一致: カスタムドメインとSSL証明書が一致しているか確認する
# NSGにTrafficManagerプローブを許可するルールを追加 az network nsg rule create --nsg-name myNSG --resource-group myRG --name AllowTrafficManagerProbe --priority 100 --source-address-prefixes AzureTrafficManager --destination-port-ranges 443 --protocol Tcp --access Allow
「DNSフェイルオーバーが遅い」
Traffic ManagerのTTLとプローブ間隔の設定を確認します。デフォルトのプローブ間隔は30秒、許容失敗回数は3回なので、最悪90秒以上かかることがあります。高速フェイルオーバーが必要な場合は以下を設定します。# プローブ間隔を10秒・許容失敗数を3回に変更(Fast Probing) az network traffic-manager profile update --name tm-myapp-profile --resource-group rg-tm-japaneast --ttl 10 --interval 10 --tolerated-number-of-failures 3 --timeout-in-seconds 5
本記事のまとめ
| やりたいこと | AZ CLIコマンド・ポイント |
|---|---|
| Traffic Managerプロファイル作成 | az network traffic-manager profile create --routing-method Priority |
| Azureエンドポイントを追加 | az network traffic-manager endpoint create --type azureEndpoints --priority 1 |
| ヘルス状態を確認 | az network traffic-manager endpoint show --query endpointMonitorStatus |
| プローブ間隔を短縮(高速フェイルオーバー) | az network traffic-manager profile update --interval 10 --ttl 10 |
| NSGでプローブを許可 | 送信元サービスタグ AzureTrafficManager をインバウンドルールで許可 |
Traffic Managerは「DNS層でフェイルオーバー」という一点に特化したシンプルな設計で、AzureのVM・App Service・Container Appsを問わず横断的に可用性を高められます。Route 53のフェイルオーバールーティングを知っているAWSエンジニアなら、Priority+ヘルスプローブの組み合わせは直感的に理解しやすいはずです。
Azureのインフラをより体系的に学ぶなら、Azureハンズオン学習コース(azure.linuxmaster.jp)も参考にしてください。VNet設計からセキュリティ設定まで実務に直結した内容をまとめています。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
Linux Master Pro Seminarでは、座学ゼロ・ハンズオン100%の2日間で、即戦力のサーバー管理スキルを習得できます。受講者3,100名以上の実績を持つ宮崎智広が直接指導します。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:azure可用性セット・可用性ゾーン構築ガイド|AWSマルチAZと比較
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます