3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

RDS Proxy 経由で Aurora PostgreSQL の Blue/Green デプロイをやってみた

3
Last updated at Posted at 2026-04-14

1. はじめに

以前、Aurora for PostgreSQLのフルマネージドBlue/Greenデプロイについて検証しました。

上記の検証ではクラスタエンドポイントへの直接接続でしたが、実際の本番環境では RDS Proxy を挟んでいるケースも多いと思います。

2026年4月、ついに RDS Blue/Green Deployments が RDS Proxy を正式サポート しました。

以前は B/G デプロイ時に Proxy のターゲット登録解除→再登録というワークアラウンドが必要でしたが、今回の対応で Proxy がスイッチオーバーを自動検知して Green 環境へ接続をリダイレクト してくれるようになりました。DNSレコードの更新や伝播待ち(TTL切れ待ち)が発生しません。

ということで、実際にやってみます。

今回の検証ゴール

# 検証項目
1 RDS Proxy を登録したまま B/G デプロイを作成できるか
2 スイッチオーバー時に Proxy が自動で Green に切り替わるか
3 ダウンタイムはどの程度か

2. 構成

構成のポイント

Amazon Aurora PostgreSQL のメジャーバージョンアップ(v13.23 → v17.9)を RDS Proxy 経由で実施することで、ダウンタイムがどの程度になるのか検証するための構成です。

各コンポーネントの詳細

①クライアント層

EC2 踏み台 (psql)

  • データベース操作を行うクライアント環境
  • 直接データベースのエンドポイントを指定するのではなく、RDS Proxy のエンドポイント経由で接続する

②認証・中継層

AWS Secrets Manager (postgres-bgtest)

  • データベースのマスターユーザー(postgres)の認証情報を管理
  • RDS Proxy は接続時にこのシークレットを参照してバックエンドの DB へログイン

Amazon RDS Proxy (bgdb-proxy)

  • アプリケーション(EC2)とデータベースの間を仲介
  • 役割: Blue/Green の切り替え(スイッチオーバー)時に、接続先を Blue から Green へ自動的にルーティングする。これにより、クライアント側の接続エラーを最小限に抑える

③データベース層(Blue/Green デプロイ)

Blue Environment(現行)

項目
クラスタ bgdb-cluster
バージョン PostgreSQL 13.23
DB名 bgdb

Green Environment(新環境)

項目
クラスタ bgdb-cluster-green-xxxxx
バージョン PostgreSQL 17.9
データ同期 論理レプリケーション(Blue 側の更新をリアルタイムで Green 側に反映)

3. 検証手順&実施

①Aurora PostgreSQLクラスタの準備

今回は前述のとおり、 bgdb-cluster というクラスタを作成します。

image.png

前回の検証のとおり、Blue/Greenデプロイを実施するためにはパラメータ設定で logical replication を設定しておく必要があります1

②Secretsの作成

作成した bgdb-cluster向けのSecrets を作成します。

image.png

③RDS Proxy 作成 & クラスタ登録

bgdb-proxyという名前の RDS Proxy を作成します。

image.png

ターゲットグループは「bgdb-cluster」を指定します。

image.png

ターゲットグループへの認証情報を次のように設定します。
シークレットは②で作成したシークレットを選択します。

image.png

サブネットやセキュリティグループなどの情報を適切に設定します(Auroraの設定から)。セキュリティグループは当然ですが psql の接続元から接続できるように設定されている必要があります。

image.png

image.png

⚠️ ここ重要
Blue/Green デプロイを作った後に Proxy にクラスタを登録しようとすると、以下のエラーでブロックされます。
RDS can't register the target with the proxy because a blue-green deployment exists for this target
必ず Blue/Green デプロイ作成前に登録してください。

④Blue/Green デプロイ作成

「bg-deploy-test」という名前のBlue/Greenデプロイを作成します。
13.23→17.9へのメジャーバージョンアップが行われる形になります。

スクリーンショット 2026-04-14 173317.png

スクリーンショット 2026-04-14 173330.png

スクリーンショット 2026-04-14 173338.png

実行すると、次のように Blue/Greenデプロイが プロビジョンされます。

スクリーンショット 2026-04-14 181446.png

⑤切り替え & ダウンタイム計測

ここが今回の検証の核心です。

まず、Proxy 経由で 1秒おきにクエリを投げます。

⑤-1. 切り替え実行

スクリーンショット 2026-04-14 181930.png

⑤-2. 監視ログの確認

切り替え時のログは次のようになりました、約3秒のダウンタイムであることが確認できます:

[09:19:56] 30ms | 13.23
[09:19:57] 30ms | 13.23
[09:19:58] 28ms | 13.23
[09:19:59] 28ms | 13.23
[09:20:00] 43ms | 13.23
[09:20:01] 80ms | 13.23
[09:20:02] 36ms | 13.23
[09:20:03] 43ms | 13.23
[09:20:04] 1714ms | SSL connection has been closed unexpectedly      ← 切断開始
connection to server was lost
[09:20:07] 71ms | 17.9  ← Green に切り替わった!
[09:20:08] 58ms | 17.9
[09:20:09] 24ms | 17.9
[09:20:10] 29ms | 17.9
[09:20:11] 24ms | 17.9
[09:20:12] 29ms | 17.9
[09:20:13] 27ms | 17.9

⑤-3. 最終確認

新しい環境でバージョンを確認します。

SELECT version();
 PostgreSQL 17.9

スクリーンショット 2026-04-14 182220.png

無事バージョンアップ が確認できました 🎉


4. 以前との比較

ダウンタイム

接続方式 ダウンタイム 理由
クラスタエンドポイント直接 前回検証時は2分程度 DNS伝播(TTL 5秒)+ クライアント再接続
RDS Proxy 経由(今回) 数秒 Proxy がトポロジ変更を検知、DNS不要

なぜ Proxy だと速いのか?

クラスタエンドポイント直接接続の場合、スイッチオーバー後にDNSが新しいクラスタを指すまで待つ必要があり、さらにクライアントが新しい接続を張り直す必要があります。

一方 RDS Proxy の場合、スイッチオーバー時に Proxy は クライアント(アプリ)との接続を維持したまま、バックエンドの DB 接続を Blue から Green へ透過的に切り替えます。この間、アプリからのクエリは Proxy 内部で一時的にキューイング(保留)されるため、アプリ側では「接続エラー」ではなく「少し応答が遅延した」ように見えるケースもあります。

⚠️ アプリ側のタイムアウト設定に注意
Proxy がクエリをキューイングしてくれるとはいえ、数秒の遅延は発生します。アプリや ORM の 接続タイムアウト(Connect Timeout)クエリタイムアウト(Statement Timeout) が短すぎる(例: 1〜2秒)と、Proxy の恩恵を受ける前にアプリ側でタイムアウトエラーが発生してしまいます。スイッチオーバーを計画する際は、タイムアウト値が少なくとも 5〜10秒以上に設定されていることを確認しておきましょう。また、再接続などを実装しておくとより影響低減が可能になると考えています。

ポイント

項目 以前(Proxy非対応) 今(2026年4月〜)
B/G デプロイ作成前 Proxy ターゲット登録解除 そのまま作成 OK
スイッチオーバー後 Proxy ターゲット再登録 自動切替、操作不要
アプリ接続先 変更なし 変更なし

5. まとめ

RDS Proxy の Blue/Green デプロイ正式サポートにより、Proxy を外さずにバージョンアップ + スキーマ変更を数秒のダウンタイムで実施 できるようになりました。

以前の「Proxy ターゲット登録解除→Blue/Greenデプロイ作成→スイッチオーバー→Proxy再登録」という煩雑なワークアラウンドが不要になったのは、運用面でかなり大きな改善だと思います。

本番で RDS Proxy を使っている環境でも安心して Blue/Green デプロイでメンテナンスできますね。

参考

  1. https://qiita.com/asahide/items/0914ac4132169220ae5f#%E4%BA%8B%E5%89%8D%E6%BA%96%E5%82%99%E5%89%8D%E6%8F%90%E3%81%AE%E7%A2%BA%E8%AA%8D

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?