Make sure that your network and client configurations don’t increase the DNS cache Time-To-Live (TTL) beyond five seconds, which is the default for RDS DNS zones.  Otherwise, applications will continue to send write traffic to the blue environment after  switchover.

DNSがちゃんとTTL通りに名前解決するようにしろ。ここに5秒というキーワードがある。

ということで、ちょっとBlue/Greenデプロイ時のDNS応答の様子を眺めてみた。

サンプル

サンプルはAurora for MySQLのクラスタエンドポイントのホスト名で問い合わせたもの。

Blue/Greenデプロイを作る前

CNAMEレコードでWriterのホストを返すのを経由して、WriterのIPアドレスを解決している。

ここではTTLは60秒。

AWSの名前解決はALBなどのエイリアスレコードの場合も60秒なので、TTL60秒が標準なのだろう。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 60 IN CNAME hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com. 60 IN A 172.31.12.95

Blue/Greenデプロイを作った後

応答内容は同じでTTLが5秒になった。

なるほど。これで行儀がよいクライアントなら5秒未満で接続先を切り替えることができるわけだ。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-aurora.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.31.12.95

Greenに切り替えた後

CNAMEレコードがGreenのWriterのものになった。

ちゃんとTTL通りに接続先を解決しなおしていれば、5秒未満で接続先が切り替わる。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME hoge-ap-northeast-1c-green-yyyy.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-ap-northeast-1c-green-yyyy.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.31.10.119

Blue/Greenデプロイを削除した後

CNAMEレコードがデプロイ前と同じものになるが、それが示す先はB/Gで切り替えたものと同じになっている。

TTLは5秒のままだが、少し待ってから再問合せしたらいつの間にか60秒になっていた。

;; ANSWER SECTION:
hoge-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME hoge-ap-northeast-1c.xxxx.ap-northeast-1.rds.amazonaws.com.
hoge-ap-northeast-1c.xxxx.ap-northeast-1.rds.amazonaws.com. 5 IN A 172.31.10.119

所感など

5秒未満のダウンタイムになる理屈はなんとなく分かった気がする。

実際には名前解決以外にもBlueへの問い合わせ失敗から再接続までのオーバヘッドなどがある、この理論値通りにはならない。

別にAWSの回し者ではないが、理論値に近づけたければRDS Proxyを挟んだり、チューニングされた接続ライブラリを使うのが良いのだろう。

この動作に最適化されているAWS公式のJDBCドライバはこちら。

同日に最新版がリリースされているので、ガチでチューニングする際の参考になるのかもしれない（詳しくは見ていない）。

github.com