koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

見せてもらおうか、RDSのBlue/Greenデプロイの性能とやらを

先立つ2025年1月20日に以下のようなAWSのRDS Blue/Green Deploymentsについての記事が出た。

aws.amazon.com

なんでも、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ドライバはこちら

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

github.com