Azure Traffic Manager が入れ子状のプロファイルを新たにサポート
このポストは、10 月 29 日に投稿された New: Azure Traffic Manager Nested Profiles の翻訳です。
Azure Traffic Manager が入れ子状の Traffic Manager プロファイルをサポートするようになりました。この機能を使用すれば、より柔軟かつ強力な負荷分散とフェールオーバーのスキームを作成して、大規模で複雑なデプロイメントのニーズに対応できます。
この機能は REST API や PowerShell コマンドレットで使用できます。
はじめに
Traffic Manager を使用すると、受信したトラフィックを複数の Azure デプロイメントで負荷分散できます。主なシナリオとしては、エンド ユーザーを最寄りのデプロイメントに誘導してアプリケーションのパフォーマンスを向上させるといったものや、サービスの監視と障害発生時の自動フェールオーバーを通じて高い可用性を実現するといったものがあります。先日、加重を考慮したトラフィック分散、Azure 外部のエンドポイントのサポートも発表 (英語) され、クラウドへのフェールオーバー、クラウド バースト、オンプレミスからクラウドへの移行など、さまざまなシナリオが可能になっています。
本日は入れ子状の Traffic Manager プロファイルという新機能についてご紹介します。この機能を使用すれば、より柔軟かつ強力な負荷分散とフェールオーバーのスキームを作成して、大規模で複雑なデプロイメントのニーズに対応できます。
入れ子状のプロファイルは、REST API や PowerShell コマンドレット (英語) でのみ作成可能です (Azure PowerShell の使用を開始するにはこちらのページを参照してください。バージョン 0.8.8 以降が必要になります)。Azure 管理ポータルからは作成できません。
以下では、例を挙げながら、この機能のメリットと活用方法を解説します。
例 1: パフォーマンスの負荷分散方式を用いた新しいデプロイメントの試験
アプリケーションが米国東部、米国西部、北ヨーロッパ、西ヨーロッパ、東アジア、東南アジアなど複数の Azure リージョンにデプロイされているとします。このとき Traffic Manager の「パフォーマンス」の負荷分散方式を使用すると、トラフィックがユーザーの最寄りのリージョンに分散されます。
現在少数のユーザーが利用しているサービスを広範にロールアウトする前に、サービスの更新を試してみようと思います。これには、トラフィックのごく一部を試験用デプロイメントに送信できる「加重ラウンドロビン」の負荷分散方式を使用します。これまでは、加重ラウンドロビンとパフォーマンスの負荷分散方式を併用することができませんでしたが、入れ子状のプロファイルを使用して両方の負荷分散方式を実行できるようになりました。
その方法についてご説明しましょう。たとえば、北ヨーロッパの新しいデプロイメントの試験が必要になったとします。その場合、既存のデプロイメントと共に試験用デプロイメントをセットアップし、これら 2 つのエンドポイントと加重ラウンドロビン負荷分散方式を使用して Traffic Manager プロファイルを作成します。次に、パフォーマンス負荷分散方式を試用している「親」プロファイルに、この「子」プロファイルをエンドポイントとして追加します。
この例について、概念図と PowerShell スニペットを以下に示します。
# 子プロファイルを作成
$child = New-AzureTrafficManagerProfile -Name "eunorth-child" -DomainName "eunorth.trafficmanager.net" -LoadBalancingMethod "RoundRobin" -Ttl 30 -MonitorProtocol "Http" -MonitorPort 80 -MonitorRelativePath "/"
$child = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $child -DomainName "eunorth.cloudapp.net" -Status "Enabled" -Type "CloudService" -Weight 99
$child = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $child -DomainName "eunorth-new.cloudapp.net" -Status "Enabled" -Type "CloudService" -Weight 1
Set-AzureTrafficManagerProfile –TrafficManagerProfile $child
# 親プロファイルを作成
$parent = New-AzureTrafficManagerProfile -Name "parent" -DomainName "myapp.trafficmanager.net" -LoadBalancingMethod "Performance" -Ttl 30 -MonitorProtocol "Http" -MonitorPort 80 -MonitorRelativePath "/"
$parent = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $parent -DomainName "eunorth.trafficmanager.net" -Status "Enabled" -Type "TrafficManager" -Location "North Europe"
$parent = Add-AzureTrafficManagerEndpoint -TrafficManagerProfile $parent -DomainName "euwest.cloudapp.net" -Status "Enabled" -Type "CloudService"
# 他のエンドポイントについても上記の行を実行
Set-AzureTrafficManagerProfile –TrafficManagerProfile $parent
このように調整することで、親プロファイル経由のトラフィックは通常どおり各リージョンに分散されます。北ヨーロッパ リージョン内では、トラフィックは設定された加重に応じて既存のデプロイメントと試験用デプロイメントに分散されます。
パフォーマンスの負荷分散方式を使用する親プロファイルに子プロファイルを割り当てるとき、子プロファイルの場所を指定した点にご留意ください (外部エンドポイントの場所を指定する場合とまったく同じ方法で、type = 'Any' を使用します。詳しくは過去のブログ記事を参照してください)。
入れ子状のプロファイルにおけるエンドポイントの監視
Traffic Manager は各サービス エンドポイントの正常性をアクティブに監視しています (その方法はこちらのページを参照してください)。エンドポイントが正常ではないと判断すると、Traffic Manager はユーザーを別のエンドポイントに振り分けてサービスの全体的な可用性を維持します。このエンドポイントの監視とフェールオーバーは、(「フェールオーバー」の方式だけでなく) すべての負荷分散方式で使用できます。
ただし、入れ子状のプロファイルでのエンドポイントの監視は若干異なります。親プロファイルに子プロファイルが入れ子状のエンドポイントとして構成されている場合、親プロファイルが子プロファイルを直接プローブすることはありません。代わりに、子プロファイルのエンドポイントの正常性から子プロファイル全体の正常性を計算し、その結果を基に親プロファイルがトラフィックを子プロファイルに送信するかどうかを判断します。
では、前述の例に戻りましょう。北ヨーロッパの既存デプロイメントで障害が発生したとします。既定で、「子」プロファイルはすべてのトラフィックを試験用デプロイメントに送信します。試験用デプロイメントでも障害が発生してしまうと、親プロファイルは、すべての子エンドポイントが正常ではないため、子プロファイルはトラフィックを受信すべきではないと判断し、北ヨーロッパのすべてのトラフィックを他のリージョンにフェールオーバーします。
これで十分に対応できる場合もありますが、お客様によっては、北ヨーロッパのすべてのトラフィックを試験用デプロイメントにフェールオーバーすべきではない、つまり、北ヨーロッパの既存デプロイメントに障害が発生したときには、試験用デプロイメントの正常性が確認されたとしても、他のリージョンにフェールオーバーした方がよいとお考えになるかも知れません。その場合には、もう 1 つの方法があります。子プロファイルを親プロファイルのエンドポイントとして構成する際に MinChildEndpoints パラメーターを指定する方法です。このパラメーターは、子プロファイルで利用可能なエンドポイントの最小数を定義できます。その最小数を下回ると (既定値は 1)、親プロファイルは子プロファイルが全面的に利用できないと判断し、トラフィックを他の親プロファイルのエンドポイントに送信します。
下図の例では、MinChildEndpoints の値が 2 に設定されており、北ヨーロッパのいずれかのデプロイメントで障害が発生すると、親プロファイルは子プロファイルがトラフィックを受信すべきではないと判断して、ユーザーを他のリージョンに振り分けます。
子プロファイルで「フェールオーバー」負荷分散方式を使用する場合、その子プロファイルへのすべてのトラフィックは単一のエンドポイントで受信されます。このため、MinChildEndpoints に 1 以外の値を設定してもメリットはありません。
例 2: 主要地域内フェールオーバー
前述の例 (最初の図) では、エンドポイント (北ヨーロッパなど) で障害が発生した場合、そのエンドポイントに送信されていたすべてのトラフィックが、代わりに全リージョンの他のエンドポイントに分散されるとご説明しました (これは Traffic Manager のパフォーマンス負荷分散方式の既定の動作で、「2 番目の最寄り」のエンドポイントに負荷がかかりすぎるのを回避することが目的です)。
では、北ヨーロッパのトラフィックを西ヨーロッパにフェールオーバーし、これら両方のエンドポイントが共に利用不可の場合にのみ別のリージョンに送信したい場合はどうすればよいでしょう。これには、フェールオーバー負荷分散方式を使用する子プロファイルを作成します。次の図をご覧ください。
同じパターンをすべてのリージョンについて繰り返します。親プロファイルの 6 つすべてのエンドポイントを 6 つの子プロファイルで置き換え、それぞれについてリージョン内フェールオーバーを用意します。
例 3: エンドポイント単位の監視の設定
Traffic Manager を使用すると、旧来のオンプレミス Web サイトから Azure でホスティングするクラウドベースの新たな Websites にトラフィックをスムーズに移行できます。旧来の Web サイトではホーム ページ (パスは「/」) を使用してサイトの正常性を監視しますが、新しいクラウドベースの Websites ではカスタムの監視ページ (パスは「/monitor.aspx」)を実装し、その他のチェックも実施できます。
Traffic Manager プロファイルの監視設定は、そのプロファイル内のすべてのエンドポイントに適用されるので、従来は両方のサイトで同じパスを使用しなければなりませんでした。しかし、今回リリースされた入れ子状の Traffic Manager プロファイルを使用すれば、Websites ごとに子プロファイルを使用してそれぞれ異なる監視設定を定義できます。
よく寄せられる質問
入れ子状のプロファイルは Azure 管理ポータルで使用できますか。
入れ子状の Traffic Manager プロファイルは、現在 REST API および PowerShell コマンドレットでのみ構成可能で、Azure 管理ポータルからは作成できません。
ただし、入れ子状のプロファイルを使用したプロファイルのステータスは、Azure 管理ポータルでも確認できます。また、エンドポイントの有効化/無効化や監視設定の構成など、プロファイルのその他の設定を管理することもできます。
Traffic Manager では何層の入れ子が可能ですか。
プロファイルは、10 層の入れ子にすることが可能です (とはいえ、これほど多くの層を使用する方はあまりいらっしゃらないでしょう)。ただし、「ループ」にすることはできません。
1 つの Traffic Manager のプロファイル内に、他の種類のエンドポイント (Cloud Services 、 Websites 、外部エンドポイント ) と入れ子状の「子」プロファイルを混在させることはできますか。
はい。プロファイル内で異なる種類のエンドポイントを組み合わせるうえで、特に制限はありません。
入れ子状のプロファイルに適用される料金モデルを教えてください。
Traffic Manager には、監視対象エンドポイント単位と 100 万 DNS クエリ単位の 2 つの料金モデルがあります (詳細については、料金のページをご覧ください)。入れ子状のプロファイルの場合は、次のように適用されます。
- 監視対象エンドポイント単位: 親プロファイルのエンドポイントとして構成されている子プロファイルについては料金が発生しません。基盤のサービスを監視する子プロファイルのエンドポイントについては、通常どおり料金が発生します。
- 100 万 DNS クエリ単位: 1 クエリで 1 回と数えます。子プロファイルからエンドポイントを返す親プロファイルへのクエリは、親プロファイルにのみ課金されます。
Azure Traffic Manager に関する詳細情報はどこで入手できますか。
Azure ポータルから、Traffic Manager サービスおよびそのシナリオの概要を参照できます。料金や SLA の詳細も確認できます。
MSDN には、Traffic Manager の負荷分散方式やエンドポイントの監視、構成などの説明を含む詳細な概要が用意されています。また、MSDN では Traffic Manager の REST API、.NET Management Library (英語)、PowerShell コマンドレット (英語) の参考資料も公開しています。
以前のブログ記事では、Azure Traffic Manager の PowerShell を初めて使用される方向けに、外部エンドポイントおよび加重ラウンドロビンの構成などについて解説しました。
Azure 全般において DNS や Traffic Manager に関するご不明点がございましたら、Azure の有償サポート プランの他に、MSDN フォーラムもご利用いただけます。機能に関するご要望は、フィードバック用サイト (英語) からお送りください。また、既にお寄せいただいているご要望への投票も受け付けております。