この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
先日行われた Ops JAWS Meetup#22 re:Invent 2022 recap & LT大会 にて、Amazon Route 53 Application Recovery Controller zonal shift 試してみたというタイトルで発表しました。
当日の発表資料の共有・およびその補足を行います。
おことわり
- Amazon Route 53 Application Recovery Controller zonal shift は現時点でプレビューです
- 正式リリース時には仕様や公式ドキュメントの記述が変わる可能性がありますのでご留意ください
- わたしの発表内容は2022/12/7時点の情報に基づいています
公式ドキュメントはこちら。
登壇資料
登壇動画
1:08:32 頃からめちゃくちゃ揺れながら登場します。
画面に登場する10秒くらい前からずっと揺れてスタンバイしてました。
Amazon Route 53 Application Recovery Controller zonal shift とは何なのか
一言で表すと、「特定のゾーンのノードの IP アドレスを名前解決結果から除外する」になるかと思います。
前提として、ELB の DNS 名にはリージョナルなものとゾーナルなものがあります。
前者の例は以下です。これはzonal-shift-demoという名称のインターネット向け NLB の DNS 名を名前解決をした結果です。
% dig +noall +ans zonal-shift-demo-ace1e899c37cc768.elb.us-east-1.amazonaws.com
zonal-shift-demo-ace1e899c37cc768.elb.us-east-1.amazonaws.com. 60 IN A 54.243.133.47
zonal-shift-demo-ace1e899c37cc768.elb.us-east-1.amazonaws.com. 60 IN A 44.211.1.84
zonal-shift-demo-ace1e899c37cc768.elb.us-east-1.amazonaws.com. 60 IN A 44.206.102.42↑ 3つの AZ にまたがるように配置したため、ノードの IP アドレスが3つ返ってきています。
それに対して後者のゾーナルな DNS 名の例は以下です。ELB が持つデフォルトの DNS 名の前に AZ 名を付与しています。
% dig +noall +ans us-east-1a.zonal-shift-demo-ace1e899c37cc768.elb.us-east-1.amazonaws.com
us-east-1a.zonal-shift-demo-ace1e899c37cc768.elb.us-east-1.amazonaws.com. 60 IN A 54.243.133.47↑特定のゾーンの IP アドレスのみが返却されています。
Application Recovery Controller zonal shift は特定のゾーン、特定の ELB を指定して実行します。実行すると以下のようになります。
- 対象 ELB のリージョナルな DNS 名の名前解決結果に、指定したゾーンのノードの IP アドレスが含まれなくなる
- 期間は 1分〜3日でユーザーが指定する *1
- ゾーナルな DNS 名の名前解決結果は影響を受けない
- ノードが持つ IP アドレスは影響を受けず、トラフィックの処理も引き続き行われる
よって、例えば AZ-A で zonal shift を実行すると以下の状態になります。
現時点で zonal shift の対象としてサポートされているのはクロスゾーン負荷分散が無効な ALB/NLB のみです。つまり上記のシフトが行われることによって、特定ゾーンのターゲットに対するトラフィックを抑制できるようになります。
Amazon Route 53 Application Recovery Controller とは別物だと考えよう
zonl shift は Amazon Route 53 Application Recovery Controller の一部の機能としてリリースされましたが、従来のそれとは別物として考えた方が良さそうです。
これまで単に Application Recovery Controller と呼ばれていたものはマルチーリージョンでの切り替えを前提とした機能です。利用するためには専用のリソースを作成する必要がありました。その複雑さを理解するには以下を参照するとよいでしょう。
zonl shift の場合は対象のリソースがあれば自動的に検出され、そのリソースに対して実行する、というだけの作りになっています。「対象のリソース」がクロスゾーン負荷分散が無効な ALB/NLB を指すというのは先述の通りです。
Application Recovery Controller zonal shift やってみる
実際に zonal shift を試す場合には以下ブログを参考にするとよいです。
挙動を試せるシナリオと、その実行に必要なリソースを準備する CloudFormation テンプレートが提供されています。
この CloudFormation テンプレートでデプロイされる主要なリソースは以下です。
3つの AZ にまたがるインターネット向け NLB がデプロイされ、以下に対して CloudWatch Synthetics カナリーによる外形監視が実施されます。
- NLB のリージョナル DNS 名
- NLB の AZ-A~C のゾーナル DNS 名
AZ は a,b,c を利用する前提のテンプレートになっているので、多くの方は東京リージョンではエラーが発生するはずです。（1a,1c,1d のみを利用できる方が多いため。）
大まかには以下の流れで確認を行います。
- テンプレートをデプロイする
- CloudWatch ダッシュボードで各 AZ で正常に処理が行われていることを確認する *2
- FIS 実験テンプレートで AZ-B のインスタンスに障害を注入する
- CloudWatch ダッシュボードで以下に影響が出ていることを確認する
- リージョナル DNS 名宛のアクセス
- AZ-B DNS 名宛のアクセス
- AZ-B を指定し zonal shift を実行する
- CloudWatch ダッシュボードで以下に影響が出ていることを確認する
- リージョナル DNS 名宛のアクセスでレスポンスタイムが改善
- （AZ-B DNS 名宛のアクセスは変化なし）
- AZ-A および AZ-C のノードでのプロセスバイト数が増加
AZ-B で zonal shift を実施することにより、リージョナルな DNS 名宛のアクセスは AZ-A もしくは AZ-C にノードに到達します。そのため、両 AZ のターゲットは通常時より高い負荷がかかることになります。（普段は 3 AZ で捌いているものを 2 AZ で受けることになる。）
zonal shift を実行する際にはそのあたりも考慮しておくとよいでしょう。
終わりに
Amazon Route 53 Application Recovery Controller zonal shift を試してみました。
特別な作りこみをせずとも（あらかじめ専用のリソースを用意しておかなくとも）条件を満たせば実行できる機能、という理解をしました。できることの選択肢として押さえておくと良さそうです。
繰り返しになりますが、現時点ではプレビュー機能なので、正式リリース時には仕様が変わっている可能性があります。
正式リリースが待ち遠しいですね。
以上、 チバユキ (@batchicchi) がお送りしました。
15
