Azure可用性を高めるTraffic ManagerをAZ CLIで構築する|AWS Route 53との機能比較

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Azure > Azure可用性を高めるTraffic ManagerをAZ CLIで構築する|AWS Route 53との機能比較
「リージョン障害が起きたとき、トラフィックを自動で別リージョンへ切り替えたい」
「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との最大の違いはヘルスチェックがプロファイルに統合されている点


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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

Fast Probing(10秒間隔)は標準モード(30秒間隔)より追加コストがかかります。フェイルオーバー速度とコストのバランスを考慮して設定してください。

本記事のまとめ

やりたいこと 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名以上の実績を持つ宮崎智広が直接指導します。

>> セミナー詳細・お申込みはこちら

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。