はじめに

早速ですが2024/10/31でAurora(MySQL)2のEOLになりましたね。

今回はAurora PostgreSQL (Compatible with PostgreSQL 12.X)のEOLが近づいてきたのでとりあえずやってみました。

Blue/Green デプロイって何？

Blue/Greenデプロイとは現状の本番環境（ブルー）とは別に新しい本番環境（グリーン）を構築した上で、ロードバランサーの接続先を切り替えるなどして新しい本番環境をリリースする運用方法のこと

3分でわかる ブルーグリーンデプロイメント

Blue/Greenデプロイのメリットは？

Amazon RDS ブルー/グリーンデプロイを使用すると、本稼働環境に影響を与えずに、ステージング環境のデータベースに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、データベースパラメータの変更、スキーマの変更をステージング環境で行うことができます。準備ができたら、ステージング環境を新しい本番稼働データベース環境に昇格でき、通常、ダウンタイムは 1 分未満です。

データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する

つまり？

楽にダウンタイムを抑えてアップデート出来る方法です。
※サーバーの複製が行われるためインプレースでアップデートするよりは多少費用が掛かります。

やってみた

大前提としてブルー/グリーンデプロイには下記の制約次項があります。

ブルー/グリーンデプロイの一般的な制約事項

そのうえでAurora PostgreSQLは以下の制限が存在するためここをクリアしている必要があります。

ブルー/グリーンデプロイの Aurora PostgreSQL の制限

さらにAurora PostgreSQLのブルー/グリーンデプロイは下記のような制限があります。

ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項

この段階で
・制限、制約事項を見てダメそう
・制限、制約事項がよくわからない
とかであればあきらめましょう。

まあ、制限を気にせずにとりあえず試してみたければ検証環境とかでどうぞ。。

それでは改めて、今回は12.9からアップデートを進めていきたいと思います。

メジャーバージョンアップ先は15.7にします。

1.バージョン確認

アップデート元の現在のバージョンとアップデート先のバージョンを確認します。
下記にAurora PostgreSQL によるブルー/グリーンデプロイが可能なバージョンが記載されているためブルー/グリーンデプロイが可能か確認しましょう。
ブルー/グリーンデプロイでサポートされているリージョンと Aurora DB エンジン

12.9はブルー/グリーンデプロイが使用できないようなのでインプレースでマイナーバージョンアップが必要です。
インプレースで12.16以上にバージョンアップします。

2.パラメータグループの設定確認

以下に設定が必要な内容が記載されています。
ブルー/グリーンデプロイ用 Aurora PostgreSQL DB クラスターの準備

パラメータグループと既存環境から以下の項目を確認しましょう。

2-1. rds.logical_replication
2-2. synchronous_commit
2-3. max_replication_slots
2-4. max_wal_senders
2-5. max_logical_replication_workers
2-6. autovacuum_max_workers
2-7. max_parallel_workers
2-8. max_worker_processes

以下に合わせてパラメータグループの値を変更していきます。

まずは下記を設定して反映します。

2-1. rds.logical_replication:1
2-2. synchronous_commit:on

続いて既存環境の値を確認しつつ設定をしていきます。

2-3. max_replication_slots
※この項目は最低でも以下の合計値以上を入れる必要があります。

SELECT * FROM pg_publication;
SELECT * FROM pg_subscription;

2-4. max_wal_senders
※この項目は最低でも以下の合計値以上を入れる必要があります。

SELECT COUNT() FROM pg_stat_replication; SELECT COUNT() FROM pg_subscription;

2-5. max_logical_replication_workers
※この項目は8で使用するための確認です。

SELECT COUNT(*) FROM pg_subscription;

2-6. autovacuum_max_workers
※この項目は8で使用するための確認です。

SHOW autovacuum_max_workers;

2-7. max_parallel_workers
※この項目は8で使用するための確認です。

SHOW max_parallel_workers;

2-8. max_worker_processes
※この項目は最低でもmax_logical_replication_workers、autovacuum_max_workers、max_parallel_workersと下記で確認できるその他のワーカーの合計値以上を入れる必要があります。

SELECT * FROM pg_stat_activity WHERE backend_type LIKE '%worker%';

以下の項目をDBから確認します。
論理レプリケーションが有効になっていることを確認

SHOW rds.logical_replication;

wal_level が logical に設定されていることを確認

SHOW wal_level;

3.ブルー/グリーンデプロイの作成

パラメータグループに問題が無ければブルー/グリーンデプロイの作成が進みます。
※問題があった場合はグリーンのクラスター作成に失敗してブルー/グリーンデプロイの作成が止まります。

グリーンの作成とアップデートが出来たらブルー/グリーンデプロイの作成が完了します。

4.パラメータグループ反映や確認

マルチAZだった場合パラメータグループの反映ができていない場合があるのでインスタンスを再起動して反映してください。
その後グリーンに接続して確認を行いましょう。

5.ブルーグリーンの切り替え

[アクション]より[切り替え]を選択して切り替えを実施します。
タイムアウト設定はデフォルトだと5分です。任意で変更してください。
※切り替えの間1分程度のダウンがあります。

切り替えが完了したら動確をしてブルー/グリーンデプロイの削除と-oldと付く古いサーバを削除しましょう。
※消し忘れるとそのサーバ分費用が跳ねます。

もし切り戻すのであれば以下が早いと思います。
・この-oldと付いたAuroraを使用するようアプリケーションを弄る
・-oldとアップデートされたAuroraの名前を変更する※名前の変更に多少時間がかかります。

最後に

参考までに東京リージョンにおける2年目までの費用でマルチAZ(2台)のクラスターを1ヶ月動かした場合を計算します。
ここではクラスターで使用しているインスタンスタイプをdb.t3.smallとします。

まず、東京リージョンでは延長サポートは次の金額です。
USD 0.12/VCPU-時間

db.t3.smallは2vCPUでマルチAZ(2台)のため4vCPU-時間で動いていることになります。

1ヶ月を30日とすると以下になります。

0.12(USD)*4(vCPU)*24(時間)*30(日)=345.6(USD)

1USD=150円とすると5万円を超える金額になります。

Amazon Aurora の料金

RDS、AuroraのEOLは放置していると気が付いたら延長サポート料金でランニングコストが増えるとかいう財布にも大きなダメージがあるので、まだまだサービスを続けるのであれば忘れずに対応してください。