先立つ2025年1月20日に以下のようなAWSのRDS Blue/Green Deploymentsについての記事が出た。
なんでも、RDS(やAurora)をBlue/Greenデプロイで切り替える際のダウンタイムが5秒未満になるのだとか。
「マジ?」
どういう理屈でそうなるんだ? ということは、この辺から類推できるようなできないような。
Switching a blue/green deployment in Amazon RDS - Amazon Relational Database Service
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ドライバはこちら。
同日に最新版がリリースされているので、ガチでチューニングする際の参考になるのかもしれない(詳しくは見ていない)。









