Application Load Balancer を使っている場合でもクロスゾーン負荷分散を無効化するオプションが利用できるようになりました

2022.11.18

いわさです。

本日のアップデートで Application Load Balancer でクロスゾーン負荷分散をオフにするオプションが利用できるようになりました。

このクロスゾーン負荷分散はこれまで Application Load Balancer では常に有効で無効化は出来ませんでした。

今回のアップデートで Application Load Balancer でもできるようになりました。
厳密には Load Balancer ではなくてターゲットグループで挙動を上書きするパラメータを利用する形です。

設定方法とどういう時に利用出来そうなのかを調べてみましたので紹介します。

クロスゾーン負荷分散

Elastic Load Balancer にはクロスゾーン負荷分散の概念があります。
以下は Network Load Balancer の図ですがひとつひとつの構成からメリット・デメリットまでとてもわかりやすくまとまっている記事です。

クロスゾーン負荷分散は有効化したほうが良いシーンが多いと思いますが、小さなデメリットがあるので稀に無効化したいシーンもあるようです。
少し古めですが以下の AWS Black Belt Online Seminar の 公開 QA でも紹介されています。

Q. クロスゾーン負荷分散を有効にする際のデメリットはどういう点がありますか?
A. クロスゾーン負荷分散は、アベイラビリティーゾーンにまたがって負荷を分散するため、各 EC2 インスタンスへの負荷を平均化できますが、唯一考えられるデメリットとしてはAZ間で通信が発生するため、AZ間ネットワーク料金がかかることと多少の Latency が発生するということです。

設定方法

まず Application Load Balancer の属性としては引き続き「有効」のままで設定変更は出来ません。

今回のアップデートではターゲットグループの属性でクロスゾーン負荷分散について設定できるようになりました。
こちらを使って設定を行っていきます。

設定値としてはロードバランサー属性から設定を継承するか、オンかオフで上書きをするかが選択出来ます。

いくつか前提条件もあります。
クロスゾーン負荷分散をオフにするとスティッキーセッションが利用できなくなります。

また、クロスゾーン負荷分散は Network Load Balancer 用のターゲットグループでも属性として設定出来ますが、Lambda 関数をターゲットとしている場合は利用が出来ません。

動作確認

以下のように 2 つの AZ にインスタンスを起動したターゲットグループを用意しました。
インスタンスはレスポンスとして EC2 のプライベート IP アドレスを返します。

クロスゾーン負荷分散が有効

ALB の特定 AZ のノードへ IP アドレスで直接アクセスした場合でも AZ ごとに振り分けを行っています。
ALB の 1a ノードから 1c の EC2 へ転送している感じですね。

% nslookup hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Server:        2404:1a8:7f01:b::3
Address:    2404:1a8:7f01:b::3#53

Non-authoritative answer:
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 13.231.90.47
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 54.238.248.55

% curl http://13.231.90.47/       
172.31.3.58
% curl http://13.231.90.47/
172.31.35.238
% curl http://13.231.90.47/
172.31.35.238
% curl http://13.231.90.47/
172.31.3.58
% curl http://13.231.90.47/
172.31.3.58
% curl http://13.231.90.47/
172.31.3.58
% curl http://13.231.90.47/
172.31.35.238%

クロスゾーン負荷分散が無効

アクセスした ALB のノードと同じゾーンのターゲットへ転送されています。

% curl http://13.231.90.47/
172.31.35.238
% curl http://13.231.90.47/
172.31.35.238
% curl http://13.231.90.47/
172.31.35.238
% curl http://13.231.90.47/
172.31.35.238

% curl http://54.238.248.55/
172.31.3.58
% curl http://54.238.248.55/
172.31.3.58
% curl http://54.238.248.55/
172.31.3.58
% curl http://54.238.248.55/
172.31.3.58

インスタンス停止時の挙動を確認してみる

このままだと AZ 障害で特定のターゲットにアクセス出来なくなった場合は DNS ラウンドロビンによって停止されたインスタンスに固定でアクセスしてしまいそうです。
以下ドキュメントに記述があり、対象ゾーンの全てのインスタンスが Unhealthy となった場合は DNS から対象ゾーンのレコードが削除されるそうです。ステータスが正常になった場合はまた対象ゾーンのレコードが追加されます。
これによって AZ 障害が発生してもずっと障害ゾーンにアクセスし続けてしまうということは無さそうです。

ターゲットのひとつを停止したときの挙動を確認してみます。

クロスゾーン負荷分散が有効

停止直後はステータスが Unhealthy となるまでクロスゾーンで分散されています。
そのため一定期間は停止されたインスタンスへアクセスしています。

% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238

ステータスが切り替わったタイミングで正常インスタンスへのみアクセスしています。

しかし、DNS については引き続きどちらのゾーンへも名前解決され続けています。

% nslookup hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com    
Server:        2404:1a8:7f01:b::3
Address:    2404:1a8:7f01:b::3#53

Non-authoritative answer:
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 54.238.248.55
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 13.231.90.47

% nslookup hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Server:        2404:1a8:7f01:b::3
Address:    2404:1a8:7f01:b::3#53

Non-authoritative answer:
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 13.231.90.47
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 54.238.248.55

異常なインスタンスへ転送はされないですが、ゾーン障害が解決するまではクロスゾーンのアクセスが発生し続けますね。

クロスゾーン負荷分散が無効

クロスゾーン負荷分散を無効化した場合も Unhealthy となるまでは引き続き異常なホストに転送されますが、その後正常ホストへのみ転送されるようになりました。

% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
</body>
</html>
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
</body>
</html>
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238
% curl http://hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com/
172.31.35.238

名前解決結果は以下のようになりました。

% nslookup hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Server:        2404:1a8:7f01:b::3
Address:    2404:1a8:7f01:b::3#53

Non-authoritative answer:
Name:    hoge1118alb-1007261348.ap-northeast-1.elb.amazonaws.com
Address: 13.231.90.47

ドキュメント記載のとおり異常ターゲットのみのゾーンの ALB ノード IP アドレスは取得されなくなりました。
その後異常だった EC2 インスタンスが復旧すると再び名前解決は 2 つのゾーンの IP アドレスを返却するようになりました。

さいごに

本日は Application Load Balancer を使っている場合でもクロスゾーン負荷分散を無効化するオプションが利用できるようになったので試してみました。

DNS レベルで異常ゾーンが切り離されるような動きをしているので、AZ 障害に対応しつつクロスゾーン負荷分散のデメリットを無視できないワークロードの場合などには有効なオプションとなりそうです。