Route53 A(alias)レコードの変更の反映が完了するまでの間にダウンタイムは発生するのか

datahaikuninja

2022年3月10日 21:42

Route53のA(alias)レコードの値を変更し、変更内容が反映されるまでの間、対象ドメインへのリクエストはどうなるのか調べた結果をのこしておきます。

2022/03/12 コマンドを見直して再検証した結果を追記しました。結論は変わりませんが、より分かりやすい検証結果を出せました。

今回のお題

api.hoge.com というAPIがあるとします。このドメインはRoute53のhoge.comというホストゾーンで管理されており、現在のDNSレコードの設定は次のようになっています。

api.hoge.com A (alias) ALBのDNS名

諸事情があり、api.hoge.com へのトラフィックをCloudFrontへルーティングすることになりました。

api.hoge.com A (alias) CloudFrontのディストリビューションドメイン

さて、Route53でDNSレコードの設定を変更し、変更内容が反映されるまでの間、api.hoge.com へのリクエストはどうなるのでしょうか。正常に処理されるでしょうか、エラーになるでしょうか。

検証して確認してみるのが今回のお題です。

DNSレコード変更反映までの所要時間

ご存じの方も多いでしょうが、Route53 の alias レコードにはTTLが設定できません。反映までにかかる時間はalias先のドメインのTTLに依存します。今回のお題であるALBとCloudFrontのドメインのTTLは60秒です。

参考

レコード変更が反映されるまでの60秒間、APIへのリクエストがエラーになるのだとしたら事業へのインパクトがあるため、以下のようなことを考えなくてはいけません。

60秒のダウンタイムを許容できるか
ユーザーへアナウンスするか
早朝や深夜など、リクエストが少ない時間帯を狙って変更するか

検証方法

以下のコマンドを実行しながら、Route53のA(alias)レコードの変更を試します。

DNSレコード変更反映のタイミングを知るコマンド

while :;do date "+%Y/%m/%d %H:%M:%S";dig +noall +ans A datahaikuninja.link; sleep 3; echo; done

ダウンタイムが生じたか知るためのコマンド

❯ while :;do \
date "+%Y/%m/%d %H:%M:%S" | tr '\n' ' '; \
curl -ksS -o /dev/null https://datahaikuninja.link/index.html -w '{"http_status_code" : "%{http_code}"}'; \
sleep 3; \
echo; \
done

datahaikuninja.link というドメインを使います。
CloudFront+S3の構成と、ALB+EC2の構成を二つ用意しておきます。
どちらの構成においても、datahaikuninja.link/index.htmlというパスで「test page」と書かれた静的なファイルを配信するように準備します。

上記のコマンドを裏で流しながら、Route53のA(alias)レコードを次の順に変更します。（1は初期状態です）

datahaikuninja.link A (alias) CloudFrontのディストリビューションドメイン
datahaikuninja.link A (alias) ALBのDNS名
datahaikuninja.link A (alias) CloudFrontのディストリビューションドメイン

digコマンドを定期実行することでDNSレコード変更反映のタイミングがわかるので、その前中後のcurlコマンドの結果を知ることで検証できると考えました。

コマンドの解説

dateコマンドはフォーマットを指定しています。digコマンドは出力結果を絞るオプション（+noall +ans）をつけています。A はレコードタイプの指定です。sleepコマンドで3秒おきにdateコマンドとdigコマンドを実行します。

curlコマンドのオプションは、-k でSSL証明書エラーを無視、-sS で通信の進捗状況の出力を抑える一方でエラーは出力させるようにし、-o でダウンロード結果を/dev/nullに捨て、-w で出力するレスポンス情報をカスタマイズしています。

trコマンドとechoコマンドは出力を整えるために使っています。

検証結果

１→２のタイミング

正常な応答が連続しています。

２→３のタイミング

正常な応答が連続しています。

結論

Route53のA(alias)レコード変更反映が完了するまでの間も、リクエストは正常に処理されていたため、ダウンタイムは生じないと考えてよさそうです。

ただし、検証方法に不備がある可能性もあるので断言はしません。
sleep 1 にすればよかったかもと思います。

2022/3/12 再検証

コマンドを見直して再検証しました。
変更点は以下の通りです。

digとcurlの実行間隔を1秒に変更 sleep 1
curlコマンドの出力結果にリモートホストのIPアドレスを追加 -w '{"http_status_code" : "%{http_code}", "remote_ip" : "%{remote_ip}"}'
tee コマンドで標準出力とファイルに実行結果を出力

while :;do date "+%Y/%m/%d %H:%M:%S";dig +noall +ans A datahaikuninja.link; sleep 1; echo; done

while :;do \
date "+%Y/%m/%d %H:%M:%S" | tr '\n' ' '; \
curl -ksS -o /dev/null https://datahaikuninja.link/index.html -w '{"http_status_code" : "%{http_code}", "remote_ip" : "%{remote_ip}"}'; \
sleep 1; \
echo; \
done | \
tee curl_result_20220312

結論は最初に検証したときと変わりません。Route53で対象ドメインのレコード値の変更をリクエストしてから反映されるまでの間も、Route53はトラフィックのルーティングを継続しますし、変更中に対象ドメインへのリクエストがエラーになることはありませんでした。1秒おきにコマンドを実行するようにして、curlの出力にリモートホストのIPを追加したことで、より丁寧な検証になったと思います。

１→２のタイミング

DNSレコードの変更が反映される間もステータスコード200が連続しています。remote_ip の結果を得るようにしたことで、DNSレコードの変更が反映されたタイミングと、変更後のホストにリクエストを送信するタイミングは数十秒ずれていることが分かります。

２→３のタイミング

11:38:53 にDNSレコードの変更が反映されたように見えますが、その後の数秒に何度かALBのノードのIPが返ってきています。digの結果から察するに、datahaikuninja.linkと紐づく複数のネームサーバーのうち、まだ変更が反映されていないネームサーバーが応答したのではないかな、と思います。
なお、curlコマンドの結果を見ると、CloudFrontのIPが返ってきたのは11:39:12からです。

11:39:00 以降、digの結果はCloudFrontのIPになっています。

この記事が気に入ったらサポートをしてみませんか？