クラウドインテグレーション部クラウドソリューション2課の川井です。
今回は、AWS の ネットワークロードバランサー（以降、NLB）の「クロスゾーン負荷分散」の挙動について検証環境を作成して、
実際どのような挙動になるのか検証してみましたので、こちらの内容ついて記載していきます。
具体的には、クロスゾーン負荷分散を "オン" にした場合と "オフ" にした場合での 挙動の違いと使いどころとをメインに、
NLB自体についての仕組みについてもふれていきます。
NLB (Network Load Balancer) のクロスゾーン負荷分散とは、AWS の異なるアベイラビリティゾーン（以降、AZ） に、
配置されたバックエンドのターゲットに対して、トラフィックを均等に分散させる機能です。
これにより、NLBからターゲットとなるサーバへのトラフィックを AZ間を跨いて均等に分散させることができます。
クロスゾーン負荷分散は、バックエンドの可用性とパフォーマンスを向上させるために使用されますが、
多くの追加コストがかかる場合もあるため、利用シーンに応じた適切な設定が重要です。
通常、NLB は各AZごとにトラフィックを分散します。クロスゾーン負荷分散を "オン" にすると、
全てのAZにあるターゲットに対して均等にトラフィックが分散されます。
たとえば、NLB が 2 つの AZ (AZ-A と AZ-B) に配置され、各 AZ に 2 つのターゲットがある場合、
クロスゾーン負荷分散が "オフ" だと、AZ-A からのリクエストは AZ-A 内のターゲットに、
AZ-B からのトラフィックは AZ-B 内のターゲットに分散されます。
しかし、クロスゾーン負荷分散が "オン" だと、NLB は全てのトラフィックを全てのターゲットに均等に分散します。
下記画像はクロスゾーン負荷分散が "オン" の際のトラフィックの動きで、
クライアント側からのトラフィックを NLB側でAZ間を跨いで均等に分散してくれています。
また、下記画像はクロスゾーン負荷分散が "オフ" の際のトラフィックの動きになります。
クライアント側からのリクエストは、各AZごとでトラフィック分散しています。こちらがNLBの通常の挙動となります。
クロスゾーン負荷分散が "オン" の場合、ターゲットがどの AZ に配置されているかに関係なく、
トラフィックが均等に分散されるため、ターゲット間での負荷が偏らず、より効率的なリソースの利用が可能です。
また、クロスゾーン負荷分散により、特定の AZ が障害を起こした場合でも、
他の AZ にトラフィックを分散できるため、サービスの可用性が向上します。
その為、この機能を活用することで、ターゲットグループ全体に対する負荷分散を最適化し、
より安定したサービス運用が可能になります。
クロスゾーン負荷分散を "オン" にすることでは、追加の料金は発生しません。
しかし、異なる AZ間でトラフィックを分散させた場合、NLBは一部のトラフィックを他の AZにあるターゲットにルーティングします。
この際、異なる AZ間でデータが転送されるため、AZ間のデータ転送料金が発生します。
リージョン内で異なる AZ間でデータを転送する際には、1GBあたりの料金が発生します。
クロスゾーン負荷分散は、負荷を均等に分散させ、アプリケーションの可用性とパフォーマンスを向上させるメリットがありますが、
その分コストが増加する可能性があります。コストとパフォーマンスのバランスを考慮し、必要に応じてクロスゾーン負荷分散
を "オン" にするかどうかを決定するのが良いでしょう。
また、異なるAZ間でのデータ転送料金を回避するために、必要ない場合はクロスゾーン負荷分散を "オフ" にするのもコスト削減の観点ではポイントとなります。
NLBは 各AZ において、固定のIPアドレスを持つことができるという特徴があります。
基本的にはNLBは、DNS名を使ってクライアントからアクセスされます。
DNS名が解決されると NLBに関連付けられたIPアドレスが返され、そのIPアドレスにクライアントが接続し、NLBは 各AZ において、固定のIPアドレスごとにトラフィックを分散します。
つまり、NLB に割り当てられたドメイン名を DNS 解決すると、関連付けられたAZごとのサブネットの数だけIP アドレスが返ってきます。
下記の画像は、3つの AZごとに配置した NLB をドメイン解決をした際の画像です。
「test-nlb-ed1036190b9c4cac.elb.ap-northeast-1.amazonaws.com」というドメインに対して、
3つ IPアドレスが返ってきています。
DNS 解決によって得られた複数の IP アドレス（IPアドレスのリスト）のうち、どの IP アドレスに接続するかは、
クライアント側の DNS リゾルバーやネットワーク設定に依存します。
多くの DNS リゾルバーは、返された複数の IP アドレスをラウンドロビン方式で順に使用します。
「ラウンドロビン方式」という表現は、主にDNSサーバー側での負荷分散に関連しています。
DNSサーバーがクライアントのリクエストに応じて、登録されている複数の IPアドレスを順番に返す場合があります。
例えば、最初のリクエストには IPアドレスA を先頭に、次のリクエストには IPアドレスB を先頭に返すといった具合です。
下記画像を見て頂ければ お分かり頂けると思いますが、
先のドメイン名を複数回をドメイン解決すると、毎回先頭の IPアドレスが異なっているのが分かると思います。
そして、クライアントは IPリストの中から最初の IPアドレスを選択し、その IPアドレスに接続を試みます。
接続が成功すればその IPアドレスを使用し、また失敗した場合は次の IPアドレスを使用します。
つまり、最初のリクエストでは最初の IP アドレス、次のリクエストでは次の IP アドレスを使うという方法です。
これにより、クライアントからのリクエストが自動的に複数の IP アドレスに均等に分散され 各AZごとのターゲットに対してトラフィックを分散させることができます。
NLB のドメイン解決した際のクライアント側の IPアドレスの受け取り方、
クライアント側での IPアドレスの選択方法を理解した上で、
クロスゾーン負荷分散が、 "オン" の場合と "オフ" の場合の挙動を確認してみます。
構成としまして、NLBを 3つの AZ に跨るように配置し 各AZごとにサーバを1台ずつ配置します。
そして、ログメッセージをシステムログに送るため "logger"コマンドを AZ-1c に配置した "Log Send Server" からNLBに送信します。
NLB 経由で各AZに配置したサーバにログメッセージを送っていきます。
構成図は以下の通りです。
また、"Log Send Server" からは下記のスクリプトを実行して、
ログメッセージに数値を入れてを送信していきます。
# 送信先のロードバランサーのDNS名またはIPアドレス
LB_ADDRESS="test-nlb-ed1036190b9c4cac.elb.ap-northeast-1.amazonaws.com"
PORT=514
# メッセージのプレフィックス
PREFIX="This is a test message with number: "
# メッセージに追加する数値の初期値
counter=1
while true
do
# メッセージの生成
message="${PREFIX}${counter}"
# logger コマンドを使用してメッセージを送信
logger -n "$LB_ADDRESS" -P "$PORT" -t test "$message"
# カウンターをインクリメント
counter=$((counter + 1))
# 一定時間待機（オプション）
sleep 1
done
クロスゾーン負荷分散が "オン" で ターゲットのサーバのヘルスステータスが全て "Healthy" の場合、
先ず、このパターンの場合に NLB のドメイン解決した際に返ってくる IPアドレスを確認してみます。
下記画像の通りですが、返ってきている IPアドレスの数は 3つです。
NLBは 各AZごとでサブネットに関連付けられていますので、各AZごとの IPアドレスそれぞれが返ってきています。
次に "Log Send Server" からログメッセージを送信してみます。
test-receive-server-1a
test-receive-server-1c
test-receive-server-1d
ターゲットのサーバのヘルスステータスが全て "Healthy" で 正常な状態なので、
(ちょっと1c が20番台のログがないので若干均等ではない気もしますが)大体均等にトラフィックが負荷分散されていますね。
クロスゾーン負荷分散が "オン" なので、AZ間での転送も発生しているかもしれません。
続いて、test-receive-server-1c のヘルスステータスを "UnHealthy" にした時の挙動を見てみます。
このパターンにおける NLB のドメイン解決した際に返ってくる IPアドレスを確認してみます。
下記画像の通りですが、返ってきている IPアドレスの数は前回同様 3つです。
"Unhealthy" のターゲット先があった場合でも、NLB は 各AZごとでサブネットに関連付けられている、
各AZごとの IPアドレスそれぞれが返しています。
次に "Log Send Server" からログメッセージを送信してみます。
test-receive-server-1a
test-receive-server-1d
NLB から返却されている IPアドレスは 3つなので、当然 "1c" に関連付けられているIPアドレスも、
クライアント側が接続の際に使用しています。しかし、クロスゾーン負荷分散が "オン" であるため "1c" に関連付けられているIPアドレスで接続したとしても AZ間 での接続が可能なので、接続がドロップ（するという挙動はしないと思いますが）することなく残り 2台のサーバで均等に負荷分散されています。
検証の結果を見て頂いて お分かり頂けたと思いますが、
クロスゾーン負荷分散が "オン" の状態であれば、仮にターゲットが AZ-1a のみにしかなかったとしても、
NLB の DNS 名を名前解決した際には、3 つの IP アドレスが全て返ってきます。
また、クライアントが 3 つの IP アドレスの中でどの IP アドレスで接続をしたとしても、ターゲットに接続が可能ということになります。
クロスゾーン負荷分散が "オフ" で ターゲットサーバのヘルスステータスが全て "Healthy" の場合の挙動は、
クロスゾーン負荷分散が "オン" で ターゲットサーバのヘルスステータスが全て "Healthy" の場合と同じ結果になる為、
こちらは省略します。
只、結果に殆ど差異はありませんが、クロスゾーン負荷分散が "オン" の場合とは異なり、
NLB側で AZ間での ターゲットへのトラフィックの調整はせず、クライアント側に ラウンドロビン方式で返却される IPリストの先頭のIPアドレスを使って接続しに行くため トラフィックに偏りが出るかもしれません。
続いて、クロスゾーン負荷分散が "オン" の時と同様に、
test-receive-server-1c のヘルスステータスを "UnHealthy" にした時の クロスゾーン負荷分散が "オフ" の挙動を見てみます。
このパターンにおける NLB のドメイン解決した際に返ってくる IPアドレスを確認してみます。
下記画像を見てお分かりだと思いますが、返ってきている IPアドレスの数は前回とは異なり "2つ" です。
"Unhealthy" のターゲット先があり、クロスゾーン負荷分散が "オフ" の場合、"Healthy" なターゲットがある AZ に対応する
NLB の IP アドレスのみが、NLB の ドメイン名から返却されています。
"Log Send Server" からログメッセージを送信します。
test-receive-server-1a
test-receive-server-1d
NLB側で、"UnHealthy" となったターゲット先（test-receive-server-1c ）の IPアドレスを クライアント側に返却していないので、"1a" と "1d" でトラフィックが負荷分散されるという挙動になります。
つまり、クロスゾーン負荷分散が "オフ" の場合に、NLB の ドメイン名を名前解決した際、
"Healthy" なターゲットの IP アドレスのみを返却します。なので、クライアントが 接続しにいく先は "1a" と "1d" となっています。
今回は、NLBのクロスゾーン負荷分散の挙動について記載しました。
クロスゾーン負荷分散が "オン" の場合と "オフ" の場合では、若干動きが異なることが分かって頂けたでしょうか。
クロスゾーン負荷分散が "オン" であれば、ターゲット先の状態がどういう状態であっても AZ間のトラフィック接続が可能な為、
AZ が障害を起こした場合でも 他の AZ にトラフィックを分散できるため、サービスの可用性が向上しますが、
その反面 AZ間のトラフィックが発生するため、コストが増える可能性があります。
また、クロスゾーン負荷分散が "オフ" の場合は、AZ間を跨くトラフィックがおこらないため コスト面では優位性が高いと思います。
しかしながら、ターゲットが "UnHealthy" になれば、そこに関連する IPアドレスが NLB から返却されないとしても、
"UnHealthy" になる間に接続しにいったトラフィックは接続に失敗するため、再接続となります。
その為、再接続しにいく分、遅延が発生する可能性があります。
クロスゾーン負荷分散の設定を入れるかどうかは、利用シーンに応じて適切に設定をして頂ければと思います。
本記事が、クロスゾーン負荷分散を "オン" にするか "オフ" にするかの検討の一助になれば幸いです。
また別の記事を執筆予定ですので、引き続きよろしくお願いいたします。
クラウドインテグレーション部
クラウドソリューション2課
川井 康敬