【Azure】ルーティング、負荷分散について

Azureネットワーク設計・構築入門　基礎知識から利用シナリオ、設計・運用ベストプラクティスまで [ 山本 学 ] 価格：3,520円（税込、送料無料) (2025/5/27時点) 楽天で購入

はじめに

ルーティング、負荷分散は"ユーザに近いところにトラフィックを流す"、"サーバ1台あたりのトラフィック量を減らす"という観点ではパフォーマンスに影響し、"リージョンや可用性ゾーンの障害"、"バックエンドインスタンスの障害が発生した"場合には、正常稼働しているインスタンスにトラフィックを流してサービスを継続するという観点では可用性に影響する重要なポイントです。

負荷分散サービスの分類

Azure Front Door

Azure Front Doorとは、世界中からのWebアクセスを最適な経路で届ける「入口」サービスです。詳細を確認をされたい方は以下のブログ記事をご参照ください。

1. フロントエンドホストのマッチング

• プロトコル：（https://www.foo.com/users/index.htmlの場合、HTTPS）
• ドメイン：（https://www.foo.com/users/index.htmlの場合、www.foo.com）
• パス：（https://www.foo.com/users/index.htmlの場合、/users/index.html）

2. バックエンドの決定手順

• 可用性のチェック：最初に選択された配信元グループに所属するすべてのバックエンドの正常性プローブの状態、有効/無効をチェックし問題ないものだけ選出する。
• プライオリティ：可用性に問題ないバックエンドのうち、最も優先度が高く設定されたものを選出する。
• レイテンシ：Azure Front Doorからバックエンドまでのレイテンシをチェックし、許容設定範囲内のものを選出する。
• ウェイト：最後まで選出されたバックエンドに対してウェイトの設定に基づいてトラフィックを比例配分する。

Front Doorはセッションアフィニティにも対応しており、最初のリクエストは前述の3つの軸で評価し、以降のトラフィックは選択したバックエンドに配信されます。

セッションアフィニティとは、ロードバランサーがあるクライアントから通信を受け取ったときに特定のバックエンドサーバに通信を中継する仕組み

Azure Traffic Manager

DNSロードバランサーの一種で、クライアントからのDNSクエリに対して適切なCNAMEを返すことで、フローの最適化を行います。詳しく確認されたい方は以下をご確認ください。

1. フロー最適化手順(例)
   • ユーザは、キャッシュDNSサーバに対してwww.contoso.comのクエリを送信する
   • キャッシュDNSサーバは、再帰的に名前解決を行い、権威DNSでwww.contoso.comのCNAMEにあたるcontoso.trafficmanager.netを取得する
   • キャッシュDNSサーバは、さらにcontoso.trafficmanager.netの名前解決を、このドメインの権威DNSであるTraffic Managerにクエリ（問合せ）する
   • Traffic Managerは、クエリに対して、バックエンドの正常性、ルーティング方法に従ってアクセス先となるバックエンドを選択する
   • Traffic ManagerはさらにCNAMEのregion-a.contoso.comを返す
   • キャッシュDNSサーバは、region-a.contoso.comの名前解決を行い、Aレコードを取得する
   • キャッシュDNSサーバは、クライアントにアクセス先のIPアドレスを返す
   • クライアントは、直接アクセス先のバックエンドに通信を行う

こちらの手順に関する詳細を確認されたい方は、Azureネットワーク設計・構築入門をぜひ手に取ってみてください。Azureネットワークがこの1冊に詰まっており、私の会社でも神本と評されてます。

Azureネットワーク設計・構築入門　基礎知識から利用シナリオ、設計・運用ベストプラクティスまで [ 山本 学 ] 価格：3,520円（税込、送料無料) (2025/5/27時点) 楽天で購入

Traffic Managerは、あくまでDNSのシーケンスに介入して、クライアントがアクセスするべきバックエンドを提示するというのが特徴です。Front Doorのようにクライアントとバックエンドの実通信には介入しません。

ルーティング

Traffic Managerで利用できるルーティングの評価基準は以下の6つです。

1. プライオリティ：1から1000まで優先順位を付けて、優先順位の高いものへルーティングします。複数のバックエンドに対して同じ優先順位は付けれません。
2. ウェイト：ウェイトの値に基づいてトラフィックをバックエンドに分配します。
3. パフォーマンス：DNSクエリを中継するキャッシュDNSサーバの送信元IPに対して最もレイテンシの短いバックエンドを選択します。
4. 地理（Geographic）：DNSクエリの送信元IPを元にどの国、地域から送信されたクエリかを特定し、指定されたリージョンのバックエンドを選択します。
5. 複数値：1つのDNSクエリに対して複数の正常なバックエンドを返す。IPv4とIPv6を同時に返したい場合や、複数返しておいてクライアントが1つのバックエンドに正常にアクセスできない場合に、クライアント側でフォールバックさせるようなときに利用します。
6. サブネット：ユーザ側で「どのIPセグメントからのクエリであれば、どのバックエンドを返すのか」を自分で管理することが可能です。

Application Gateway

HTTP/HTTPS用のL7ロードバランサーであり、主な特徴は以下の通りです。

• SSL/TLSの終端
• WAF
• バックエンドへのルーティング

Application Gatewayに紐づけられたフロントエンドIPに対して、クライアントに対するインターフェイスであるリスナーを持ちます。一方でバックエンドのインスタンスをグループ化したバックエンドプールを設定しておきます。リスナーに着信したトラフィックをどのバックエンドプールのどのインスタンスに分配するかはルールで制御します。

Application Gatewayの詳細について知りたい方は、以下のブログ記事をご参照ください。

Azure Load Balancer

送信元/宛先のIPアドレス、およびTCP/UDPのポート番号に基づいてトラフィックを分配するL4ロードバランサーです。

Load Balancerの負荷分散方式は、以下の3つがあります。

1. ハッシュベース：クライアントからのトラフィックをバックエンドのいずれかに分配する。セッションは永続化しない。（ステートレスなアプリケーション）
2. セッション永続化（クライアントIP）：クライアントのIPと宛先IP（Load BalancerのIP）の組み合わせでバックエンドに分配する。そのため、クライアント毎にアクセスするバックエンドが固定される。（セッションは固定されるが、複数のクライアントのうちトラフィックの過多にばらつきがある場合、特定のバックエンドにトラフィックが集中し十分な負荷分散ができない場合がある）
3. セッション永続化（クライアントIPとプロトコル）：クライアントのIPとプロトコル、宛先IP（Load BalancerのIP）の組み合わせでバックエンドに分配する。そのため、クライアントのセッション毎にアクセスするバックエンドが固定される。（特定のクライアントのセッションが他のクライアントより著しく大きな場合にバックエンドの負荷が偏ります）

またLoad BalancerでインバウンドNATを構成すると、Load BalancerのフロントエンドIPに着信した特定の通信を、指定したVM、ポートにNATしながら受け流すことが可能です。例えば、フロントエンドのTCP3390に来たトラフィックを、配下のWindows VM1のTCP3389（RDP）へNATすることで、直接VMにアクセスできない環境でRDPやSSHでのメンテナンスを行いたい場合や特定のVMのみで特殊なサービスを提供する場合に利用できます。

最後にバックエンドがアウトバウンド通信する場合は注意が必要です。

• UDRによってAzure FIrewallやNVA（ネットワーク仮想アプライアンス）のようなSNATをサポートする機器へ経路を向ける
• バックエンドのVMのサブネットにNAT Gatewayを紐づける
• バックエンドの各VMにインスタンスレベルのパブリックIPアドレスを割り当てる
• パブリックLoad Balancerの送信規則を設定し、Load BalancerのフロントエンドIPを使って送信元NATを行う

<参考>

Microsoftが公開しているどの負荷分散サービスを使うかのガイダンスとして、デシジョンツリー（判断フローチャート）が提供されてます。どのロードバランサーを使えばいいか悩まれた際には、活用してみてください。

https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview