RDS/Aurora PostgreSQL のメジャーバージョンアップグレードを Blue/Green Deployment で行うメリットと注意点

先日、RDS/Aurora PostgreSQL のメジャーバージョンアップグレードを実施しました。今回のアップグレードでは、従来の In-place アップグレードではなく Blue/Green Deployment を採用しています。

この記事では、Blue/Green Deployment を採用した理由と、実際に運用してみて分かった注意点についてまとめました。

RDS/Aurora PostgreSQL のメジャーバージョンアップグレードを安全に実施したい方や、Blue/Green Deployment の利用を検討している方の参考になれば幸いです。

In-place の課題

これまでアップグレードは In-place で実施していました。In-place は構成がシンプルで追加コストもかからないというメリットがありますが、ダウンタイムが長くなりやすく、結果としてメンテナンス時間も長くなってしまうという課題がありました。

以前 In-place で実施した時のブログもあるので、ぜひこちらも見てみてください。

アップグレード自体に時間がかかる

In-place アップグレード自体にも数分〜十数分かかり、その間はDBへのアクセスができません。DBのサイズやインスタンスタイプによって時間は変わりますが、事前に十分なメンテナンス時間を確保しておく必要があります。

アップグレード直後にANALYZEを実施する必要がある

In-place では、アップグレード直後に ANALYZE (統計情報の更新) を実行する必要があります。ANALYZE が完了するまで統計情報が更新されないため、最適な実行計画が生成されず、クエリの実行時間が長くなる可能性があります。そのため、ANALYZEの実行時間もメンテナンス時間に含めて考える必要がありました。

In-place では、事前にアップグレードや ANALYZE を実行することができず、メンテナンス時間中に想定外のトラブル対応が発生することもありました。運用する側としても精神的な負担が大きく、より安全な方法を検討する必要がありました。

Blue/Green Deployment のメリット

こうした課題を受けて、今回からは Amazon RDS の Blue/Green Deployment を使う方式に切り替えました。

AWS公式ドキュメント:

• Amazon RDS ブルー/グリーンデプロイの概要
• Amazon Aurora ブルー/グリーンデプロイの概要

Blue/Green Deployment では旧バージョンのDB（ブルー環境）から新バージョンのDB（グリーン環境）にデータをリアルタイムで同期し続け、準備ができたタイミングでスイッチオーバーします。

この方式では、アップグレード作業や ANALYZE を事前に実行しておくことができるため、当日のメンテナンス時間を大幅に短縮することができました。

スイッチオーバーが1分未満

ブルー環境とグリーン環境の同期が追いついていれば、スイッチオーバーは 1 分未満で完了します。そのため、In-place アップグレードと比べてダウンタイムを大幅に削減することができました。

事前に ANALYZE を済ませられる

In-place アップグレードの課題だった ANALYZE を、スイッチオーバー前にグリーン環境で実行しておくことが可能です。これにより、メンテナンス当日の作業時間を大幅に削減することができました。

Blue/Green Deployment の前提条件

Blue/Green Deployment では、アップグレードの種類とDBの種類によってレプリケーション方式が異なります。

RDS のマイナーバージョンアップは物理レプリケーションで行われるため、論理レプリケーション固有の制約は発生しません。一方、RDS/ Aurora メジャーバージョンアップでは論理レプリケーションが使用されるため、いくつかの前提条件があります。

論理レプリケーションの有効化

パラメータグループで以下を設定し、再起動しておく必要があります。

rds.logical_replication = 1 

この設定が有効でない場合、Blue/Green Deployment は利用できません。

全テーブルへのプライマリキー設定

論理レプリケーションでは プライマリキーのないテーブルをレプリケートできません。そのため、すべてのテーブルにプライマリキーが必要です。
プライマリキーがないテーブルについては REPLICA IDENTITY の設定が必要になります。

Blue/Green Deployment の注意点

使ってみて気づいた点もいくつかあります。

DDL 変更がレプリケートされない

論理レプリケーションの制限として、CREATE TABLE や ALTER TABLE などの DDL はグリーン環境に反映されません。Blue/Green Deployment が稼働中にマイグレーションを実行してしまうと、グリーン環境がレプリケーション低下状態になり、作り直しが必要になります。

事前にエンジニア全員にアナウンスして、Blue/Green Deployment 作成中はマイグレーションを行わないようお願いしました。

Blue/Green Deployment 中は約2倍のコストがかかる

2つの環境が同時に稼働するため、その期間のコストは通常の約2倍になります。ウォンテッドリーではなるべく作業を短時間に集中させ、使い終わったら速やかに古いブルー環境を削除するようにしています。

スイッチオーバー後は切り戻し機構がない

AWS 側には切り戻し用の機能がありません。問題が起きた場合は、スイッチオーバー後に残っている古いブルー環境（-old1 サフィックスが付いたインスタンス）への接続情報に手動で書き換える必要があります。

スイッチオーバー後は PITR が利用できなくなる

Blue/Green Deployment ではスイッチオーバー時に新しい DB インスタンスへ切り替わるため、それまでのバックアップを使った PITR は利用できなくなります。

まとめ

Blue/Green Deployment の場合、論理レプリケーションの有効化の手間やコスト増加といったデメリットはありますが、In-place と比べてダウンタイムを短く抑えられる点が大きなメリットです。今後のメジャーバージョンアップでも、Blue/Green Deployment で進める予定です。

おまけ：AWS がさらにダウンタイムを短縮

2026年1月、AWS が Blue/Green Deployment のダウンタイムを5秒未満に短縮した というアップデートを発表しました。