[アップデート] ELBにアプリケーションの可用性を向上する4つの機能が発表されました！#reinvent

AWS事業本部コンサルティング部の後藤です。

re:Invent 2022が始まり、たくさんのアップデートがリリースされています。その中から、今回ご紹介するのはこちらです。

Elastic Load Balancing capabilities for application availability

ALB(Application Load Balancer)とNLB(Network Load Balancer)に新しく以下4つ (内 3つがGA、1つはPreview) の新機能が発表されました！

• クロスゾーン負荷分散のオフ機能(ALB)
• ヘルスチェック機能の改善(NLB)
• 最小の正常ターゲット数設定(ALB/NLB)
• ゾーンシフト(ALB/NLB) (11月29日時点、Previewになります。)

3つのGA機能については全商用リージョン、及びGovCloud(米国)で利用頂けます。Preview機能については以下リージョンでお試し頂けます。

• オレゴン
• バージニア北部
• オハイオ
• アイルランド
• フランクフルト
• ストックホルム
• 東京
• シドニー
• ジャカルタ

それぞれどの様な機能なのか、ざっくり見ていきましょう！

クロスゾーン負荷分散のオフ機能(ALB)

こちらは少し前に発表があった機能ですね。ALBでは標準で有効となっていたクロスゾーン負荷分散機能が任意でオフにする事が出来るようになったようです！

クロスゾーン負荷分散とは、2つのAZで起動しているターゲットノード(EC2インスタンス)に偏りがある場合でもトラフィックを均等に各ターゲットノードに分散してくれる機能の事です。クロスゾーン負荷分散は基本的には有効化した方が良いシーンが多いかと思いますが、クロスゾーン負荷分散によるデメリットとしては以下のような事が挙げられます。

• AZ間の通信で 2ms前後のレイテンシ増加
• 異なるAZへの通信費用発生 ($0.010/GB

この機能については既に記事がありますので、以下をご参照頂ければと思います。

ヘルスチェック機能の改善(NLB)

今までNLBのヘルスチェック機能では、タイムアウトまでの時間やヘルスチェック間隔値、応答コード等はデフォルト値から変更出来ませんでしたが、今回のアップデートによりALBのような細かいヘルスチェック設定が可能になりました！

やってみた

実際にAWSコンソールで確認をしてみます。NLBのヘルスチェック機能はターゲットグループで設定が可能なため、NLB用ターゲットグループのHealth Checks項目からEditで編集が可能です。

Advanced health check settings の項目を開くと、今まで固定値だったタイムアウトまでの時間やヘルスチェック間隔値、応答コード等が設定出来るようになっていました！

注意頂きたいのが、旧コンソール版でNLBターゲットグループのヘルスチェックを変更しようとすると、先程設定出来た項目はグレーで表示されており設定出来ませんでした。今だけかもしれませんが、ヘルスチェック設定を変更する場合は旧コンソールではなく新コンソールで試してみてください。

最小の正常ターゲット数設定(ALB/NLB)

ALB/NLBでトラフィックを処理するための正常ターゲット数を設定する事が出来るようになりました！

今までは正常なターゲットが1つでも存在した場合、ALB/NLBはトラフィックを対象のターゲットグループにルーティングをしていました。しかし、フリートが大きい場合正常なターゲットが1台のみ存在していても十分にトラフィックを捌ききる事が出来ません。

そこで、今回追加された機能ではALB/NLBの正常ターゲット最小数を整数、もしくはパーセンテージで設定し、閾値を下回ると以下のようなアクションを取るように設定する事が出来るようになりました。

• DNSフェイルオーバ
• ルーティングフェイルオーバ

DNSフェイルオーバは、AZ毎の正常ターゲット数が閾値を下回ると、下回ったゾーンのLBノードIPアドレスがDNSで異常判定されます。それに伴い、ELBエンドポイント名で接続すると正常なゾーンのみトラフィックがルーティングされるようになるそうです。

ルーティングフェイルオーバでは、AZ毎の正常ターゲット数が閾値を下回ると、異常なターゲットも含め、使用可能な全てのターゲットにトラフィックを送信するようになります。これはターゲットが一時的にヘルスチェックに失敗した場合でもサーバに接続する可能性を高める効果があるそうです。

やってみた

正直よくわからないので、実際に試してみました。

正常ターゲット数の最小数はターゲットグループで設定可能なようです。ターゲットグループを選択して Attributes から設定できます。

また、この機能がゾーン毎に値をチェックしているため、クロスゾーン負荷分散の機能をオフにして試してみます。

一番下にある項目 Target group health requirements から設定出来ます。

Requirements as applied to the target group にも記載されているように、現在のターゲット構成は以下のように設定しています。

• AZ 1a に 1台
• AZ 1c に 2台
• 合計 3台構成

正常ターゲット最小数を1台のままALBのエンドポイントに接続すると、クロスゾーン負荷分散をオフにしているため AZ 1a のターゲットに多く接続されていますが、各ターゲットにルーティングされています。

sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web01 ap-1a
sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web02 ap-1c
sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web01 ap-1a
sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
Web01 ap-1c

続いて、正常ターゲット最小数を2台にしてみます。するとAZ-1aに対して DNS failover + fail open という表記が出ました。この状態で先程と同様、ALBエンドポイントに接続を試みてみます。

sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web02 ap-1c
sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web02 ap-1c
sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web02 ap-1c
sh-4.2$ curl http://alb-new-update-451341422.ap-northeast-1.elb.amazonaws.com
web02 ap-1c

AZ-1aに対しては正常ターゲット最小数が 2 を下回っているため、ルーティングがされなくなりました。

今回は整数で動作を確認してみましたが、実際はパーセンテージや、詳細設定で各アクション実行の閾値を調整する事も可能なようです。

ゾーンシフト(ALB/NLB)

本機能は11月29日時点ではPreview機能となっており、GAの際には仕様が変わっている可能性があります。

ALB/NLBの新機能、ではなくRoute53のApplication Recovery Controller(ARC)の新機能として「ゾーンシフト」が追加されたようです。

Route53 の Application Recovery Controllerに関しては、以下の記事をご参照ください。

ゾーンシフトがALB/NLBにどの様に機能するかは、以下記事に詳細に書かれています。

内容をざっくり掻い摘んで説明してみます。

ゾーンシフト機能はクロスゾーン負荷分散機能がオフになっているALB/NLBを対象に利用出来る機能です。3AZのターゲットに対して負荷分散を行っている状況で、1AZに対して詳細なヘルスチェックでも検出が困難、だが確実に問題が発生している所謂グレーな障害が発生したとします。図では1AZだけレイテンシーが上昇している事が書かれています。

このような時、ゾーンシフト機能を使用する事で異常な1AZへのトラフィックを止め、正常な2AZで処理を行わせ、その間に1AZの原因解決を実施する。という事が可能になる機能の様です。

ゾーンシフト機能が試せるCloudFormationが公開されていましたので、興味がある方はこちらから試してみてください。

CloudFormationを実行すると、以下リソースが生成されます。東京リージョンでスタックを作成するとAZ-Bが存在しないエラーが出ますので、us-east-1(バージニア北部)でスタック作成する事推奨です。

• クロスゾーン負荷分散が無効になっている3AZのNLB
• 3AZ毎に2つのサーバを作成するAutoScaling
• ELB経由でファイルをポーリング、レイテンシーを記録する CloudWatch Synthetics カナリア
• ELBのゾーンエンドポイントを経由してファイルをポーリング、レイテンシーを記録する CloudWatch Synthetics カナリア
• 各AZ毎のパフォーマンスを表示するCloudWatchダッシュボード
• Fault Injection Simulator（ハード障害、及びグレー障害の実験テンプレート）
• Route53 Application Recovery Controller のゾーンシフト機能

かなり多くのリソースが生成されるため、ゾーンシフト機能検証後は削除を忘れないようにしてください。

最後に

以上、速報でざっくりとまとめてみました。

ゾーンシフト機能についてはもう少し理解した後、CloudFormationのやってみた記事を執筆出来ればと思います。ALB/NLBともにクロスゾーン負荷分散の機能をオフに出来るようになり、それに伴い可用性を向上させる機能が追加された印象でした。今後はクロスゾーン負荷分散を使用しない新しいルーティング戦略が出てきそうですね。

この記事が何方かのお役に立てば幸いです。