Zenn
🦄

NLBのAvailability Zonal DNS affinityを試してみた

2023/10/13に公開
AWS
nlb
tech

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

日本時間 2023年10月12日に NLB の機能追加が発表されました。
そのうちの1つ Availability Zonal DNS affinity を試してみます。

何が嬉しいか

Aniffity を英和辞典で調べてみると、親近感、一体感、類似性といった意味だそうです。
IT の世界だと Node Aniffity、Session Aniffity といった言葉が見つかります。何かを何かに紐付けるような意味合いです。Pod を Node に、セッションを特定サーバーに関連付けるなどです。

NLB の Availability Zonal DNS affinity は、クライアントから NLB の DNS 名を名前解決した際に独自のアベイラビリティーゾーン(AZ)の IP アドレスを優先的に返す機能です。

今回追加された Client routing policy は3通りです。

  • Availability Zone affinity – 100 percent zonal affinity
    • 同じ AZ の NLB IP アドレスを優先して返す
  • Partial Availability Zone affinity – 85 percent zonal affinity
    • 85% は同じ AZ の NLB IP アドレスを返す、残りは正常な AZ の IP アドレスを返す
  • Any Availability Zone (default) – 0 percent zonal affinity
    • 従来通り全ての AZ の正常な AZ の IP アドレスを返す

主な利点は以下の通りです。

  • クライアント 〜 NLB 配下のサーバー間通信が同じ AZ で完結するためレスポンスに優位
  • 同じ理由で料金面でも優位 (AZ 間通信は通信料金が発生)
  • 他 AZ 内で発生しているサービス障害の影響を受けにくい
  • Zonal DNS affinity な場合でもその AZ のサーバーが全て異常 (unhealthy) になれば正常な AZ の IP アドレスを返すため弾力性はある

留意点もあります。

  • Zonal DNS affinity は Route 53 Resolver を使用して名前解決をするクライアントのみに適用される
  • AZ 間でリクエストの不均等が発生する可能性がある、そうならないようにクライアントやリクエストを調整する必要がある
  • クロスゾーン負荷分散を無効にしないとならない
  • 各 AZ 単独で AZ 内のリクエストに耐えられるような構成・考慮が必要

ELB (ALB も NLB も) から背後のターゲットへのリクエストをゾーン均等に分けるか、ゾーン内で完結させるのかは設計によります。
ゾーン均等に分散させたほうが可用性は高まると妄信的に考えていた時期が私にもありましたが、必ずしもそうではありません。
レスポンスを考えれば同一ゾーンで通信したほうが優位ですし、可用性に関しても 2AZ なのか 3AZ なのかによって選択肢は変わってきます。

やってみた

構成はこのようにしました。

img



上の構成を作成した後 NLB の Client routing policy を変更します。
NLB の属性タブから変更可能です。

img

img

動作確認

まずは NLB のパブリック IP アドレスとリージョンを確認します。

$ aws ec2 describe-network-interfaces --filters Name=interface-type,Values=network_load_balancer | jq '.NetworkInterfaces[] | .Association.PublicIp + " " + .AvailabilityZone'
"54.203.146.0 us-west-2a"
"35.167.51.146 us-west-2b"
"44.231.80.160 us-west-2c"

手元の Mac から NLB の名前解決してみます。ヨシッ。

$ dig yoshii-nlb-dns-affinity-nlb-14bf3ae748442dd9.elb.us-west-2.amazonaws.com +short
54.203.146.0
35.167.51.146
44.231.80.160

踏み台から名前解決

各 AZ に作成した踏み台サーバーから名前解決してみます。打つコマンドは以下です。

for i in `seq 10`
do
  dig yoshii-nlb-dns-affinity-nlb-14bf3ae748442dd9.elb.us-west-2.amazonaws.com +short
  sleep 1
done

us-west-2a の踏み台

54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0
54.203.146.0

us-west-2b の踏み台

35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146
35.167.51.146

us-west-2c の踏み台

44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160
44.231.80.160

デフォルトに戻す

当たり前の結果で驚きはありません。
念のため NLB の Client routing policy をデフォルトに戻してみます。（個人的な感覚ですが、設定変更をしてから反映するまで数分かかるようです。）

同じコマンドを打ってみました。出力は省略しますがデフォルトに戻すを3つの IP アドレスが返ってきます。これも驚きはないです。

44.231.80.160
35.167.51.146
54.203.146.0

Partial にしてみる

Client routing policy の残りの選択肢である 「Partial Availability Zone affinity (85%)」 にしてみます。

これ同じ dig コマンドを1000回くらい実行しました。
出力は省略します。よく理解ができない結果をなりました。
一定期間同じ AZ の IP アドレスが返ってきて、あるタイミングで3つの IP アドレスが返るようになります。そしてしばらくしてまた AZ の IP アドレスが返ってきます。
dig を1000回打って最初の850回は AZ の IP アドレス、残り150回は3つの IP アドレスみたいなイメージです。
アクセス回数なのか、タイムスタンプで判断しているのか、このあたりの仕様はもう少し調べる必要がありそうです。

EC2をダウンさせてみる

us-west-2a の Web サーバーを停止します。
ターゲットグループで対象インスタンスが unheathy になるまで待ちます。

us-west-2a の踏み台サーバーから dig コマンドを実行します。
他 AZ の IP アドレスが返ってきました。

35.167.51.146
44.231.80.160

ダウンさせた EC2 を起動させ、しばらく待つと同じ AZ の IP アドレスのみになりました。

まとめ

静的安定性(システムが静的な状態で動作し、依存関係に障害が発生しても、通常通り動作し続けることができる)を優先に考える場合、特定 AZ または AZ 内のあるサービスがダウンしたとしても、システムとしては正常に動作していなければなりません。我々エンジニアはそのための備えをしておかなければなりません。
今回の機能追加 Availability Zonal DNS affinity は静的安定性を実現する一つの手段になるはずです。

参考

Announcing new AWS Network Load Balancer (NLB) availability and performance capabilities
Availability Zone DNS affinity
アベイラビリティーゾーンを使用した静的安定性
[レポート] SUP401 Building resilient multi-site workloads using AWS global services
AWS の障害分離境界について学べるホワイトペーパー AWS Fault Isolation Boundaries を読んでみた
AZ障害時の緊急回避手段「zonal shift」が発表されました！

Discussion