💭

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

2022/06/19に公開

AWS

Route53

tech

Route53のA(alias)レコードの値を変更し、変更内容が反映されるまでの間、対象ドメインへのリクエストはどうなるのか、ふと気になったので調べました。

背景

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秒です。^[1]

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

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

検証方法

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

次の方法で検証します。

ターミナルで検証コマンドを実行しておく
コマンドを流しながらRoute53レコードの値を変更する

検証コマンドの実行

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

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

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

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

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

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

trコマンドとechoコマンドは出力を整えるために使っています。tee コマンドで標準出力とファイルに実行結果を出力しています。

Route53レコードの変更

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

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

2. datahaikuninja.link A (alias) ALBのDNS名

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

結論

Route53で対象ドメインのレコード値の変更をリクエストしてから反映されるまでの間も、Route53はトラフィックのルーティングを継続します。
変更中に対象ドメインへのリクエストがエラーになることはありませんでした。

１→２のタイミング

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になっています。

脚注

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resource-record-sets-editing.html ↩︎

GitHubで編集を提案

背景