2024.12.05
【弊社紹介】社内勉強会開催!2024上期総集編
2024.11.08
AWSAmazon Aurora PostgreSQLでBlue/Green デプロイやってみた
早速ですが2024/10/31でAurora(MySQL)2のEOLになりましたね。
今回はAurora PostgreSQL (Compatible with PostgreSQL 12.X)のEOLが近づいてきたのでとりあえずやってみました。
Blue/Greenデプロイとは現状の本番環境(ブルー)とは別に新しい本番環境(グリーン)を構築した上で、ロードバランサーの接続先を切り替えるなどして新しい本番環境をリリースする運用方法のこと
Amazon RDS ブルー/グリーンデプロイを使用すると、本稼働環境に影響を与えずに、ステージング環境のデータベースに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、データベースパラメータの変更、スキーマの変更をステージング環境で行うことができます。準備ができたら、ステージング環境を新しい本番稼働データベース環境に昇格でき、通常、ダウンタイムは 1 分未満です。
データベース更新のために Amazon RDS ブルー/グリーンデプロイを使用する
楽にダウンタイムを抑えてアップデート出来る方法です。
※サーバーの複製が行われるためインプレースでアップデートするよりは多少費用が掛かります。
大前提としてブルー/グリーンデプロイには下記の制約次項があります。
そのうえでAurora PostgreSQLは以下の制限が存在するためここをクリアしている必要があります。
ブルー/グリーンデプロイの Aurora PostgreSQL の制限
さらにAurora PostgreSQLのブルー/グリーンデプロイは下記のような制限があります。
ブルー/グリーンデプロイの PostgreSQL 論理レプリケーションの制約事項
この段階で
・制限、制約事項を見てダメそう
・制限、制約事項がよくわからない
とかであればあきらめましょう。
まあ、制限を気にせずにとりあえず試してみたければ検証環境とかでどうぞ。。
それでは改めて、今回は12.9からアップデートを進めていきたいと思います。
メジャーバージョンアップ先は15.7にします。
アップデート元の現在のバージョンとアップデート先のバージョンを確認します。
下記にAurora PostgreSQL によるブルー/グリーンデプロイが可能なバージョンが記載されているためブルー/グリーンデプロイが可能か確認しましょう。
ブルー/グリーンデプロイでサポートされているリージョンと Aurora DB エンジン
12.9はブルー/グリーンデプロイが使用できないようなのでインプレースでマイナーバージョンアップが必要です。
インプレースで12.16以上にバージョンアップします。
以下に設定が必要な内容が記載されています。
ブルー/グリーンデプロイ用 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;
パラメータグループに問題が無ければブルー/グリーンデプロイの作成が進みます。
※問題があった場合はグリーンのクラスター作成に失敗してブルー/グリーンデプロイの作成が止まります。
グリーンの作成とアップデートが出来たらブルー/グリーンデプロイの作成が完了します。
マルチAZだった場合パラメータグループの反映ができていない場合があるのでインスタンスを再起動して反映してください。
その後グリーンに接続して確認を行いましょう。
[アクション]より[切り替え]を選択して切り替えを実施します。
タイムアウト設定はデフォルトだと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万円を超える金額になります。
RDS、AuroraのEOLは放置していると気が付いたら延長サポート料金でランニングコストが増えるとかいう財布にも大きなダメージがあるので、まだまだサービスを続けるのであれば忘れずに対応してください。
【記事への感想募集中!】
記事への感想・ご意見がありましたら、ぜひフォームからご投稿ください!【テクノデジタルではエンジニア/デザイナーを積極採用中です!】
下記項目に1つでも当てはまる方は是非、詳細ページへ!Qangaroo(カンガルー)
【テクノデジタルのインフラサービス】
当社では、多数のサービスの開発実績を活かし、
アプリケーションのパフォーマンスを最大限に引き出すインフラ設計・構築を行います。
AWSなどへのクラウド移行、既存インフラの監視・運用保守も承りますので、ぜひご相談ください。
詳細は下記ページをご覧ください。
最近の記事
タグ検索