RDSのブルー/グリーンデプロイを利用してみた
会社で利用しているサービスでAmazon RDSのAuroraを利用していますが、DBのエンジンがMySQL5.7を利用しています。
Auroraが2024年2月にサポートが切れることもあり、RDSのブルー/グリーンデプロイの機能を用いて、MySQL5.7からMySQL8.0への切り替えを行いました。
Amazon RDS Blue/Green Deploymentsとは
公式によると、
本稼働環境のワークロードに影響を与えずに、グリーン環境の RDS DB インスタンスに変更を加えることができます。例えば、DB エンジンのメジャーまたはマイナーバージョンのアップグレード、データベースパラメータの変更、スキーマの変更をステージング環境で行うことができます。グリーン環境での変化を徹底的にテストできます。準備ができたら、環境を切り替えてグリーン環境を新しい本稼働環境にプロモートできます。切り替えには通常 1 分もかからず、データが失われることはなく、アプリケーションを変更する必要もありません。
つまり、RDS Blue/Greenデプロイを利用することで、本来の目的であるDBエンジンのメジャーバージョンのアップグレードを可能にし、レプリケーションも自動的に行いながら安全にDBの切り替えが行われるわけです。
Blue/Green Deploymentsの手順
切り替えまでは大きく3ステップに分けて作業を行いました。
1. 事前準備
2. B/Gデプロイ環境の作成
3. Blue環境からGreen環境への切り替え
余談ですが、RDS環境はterraform化していますが、B/Gデプロイを初めて行うのとクラスターのエンドポイントやクラスター・インスタンス識別子が切り替え後に変わらないこともあり、マネジメントコンソールからぽちぽち作業していきました。(※作業終了後に環境差分をなくすためにterraformのコードは修正しています)
各ステップごとに行うことを記述していきます。
事前準備
あらかじめBlue/Gree Deploymentsを利用することを決めた時から公式リファレンスや皆様の様々な記事を読み情報を集めておりました。ブルー/グリーンデプロイの作成の前に以下の2つの変更をインスタンスに加える必要があります。
- バイナリログの有効化を行う
- 切り替え対象のインスタンスサイズは最低
db.t3.medium
が必要
バイナリログ有効化
バイナリログ有効化はクラスターに割り当ててある「クラスターパラメータグループ」の binlog_format
を変更することで有効化できます。
現在利用しているクラスターに割り当ててあるクラスターパラメータグループから binlog_format
の値を ROW
に設定します。
インスタンスサイズの変更
Amazon Auroraで利用するMySQL8系がサポートしている最小インスタンスサイズは db.t3.medium
になります。
今回切り替えを行うRDSのインスタンスサイズは db.t2.small
だったので、ブルー/グリーンデプロイの作成が失敗するため事前にインスタンスサイズを上げる必要があります。
ブルー/グリーンデプロイ環境の作成
ここからBlue/Green Deployment環境を作成します。
AWSマネジメントコンソールからBlue/Green Deploymentを行うRDSのクラスターを選択します。
「アクション」> 「ブルー/グリーンデプロイの作成 - 新規」を選択します。すると以下のような画面が表示されますので各々必要な項目を記述します。
※今回は test-cluster
を用意してお見せしております。
確認ポイント
ブルーデータベース識別子は選択したクラスターに所属するインスタンスの識別子であるかをチェックしましょう
入力項目について確認していきます。
- ブルー/グリーンデプロイ識別子
- 任意の値をつけることができます。自由に好きな値を設定しましょう。
- グリーンデータベースのエンジンバージョン
- 今回のゴールを達成するために必要な箇所です。変更したいバージョンを選択しましょう。画像では「MySQL 8.0.32」を選択しています。
- グリーンデータベースのDBクラスターパラメータグループ
- 画像ではdefaultで用意されているものを選択していますが用途にあったパラメータグループを選択します。
- グリーンデータベースのDBパラメータグループ
- こちらもクラスターのパラメータグループ同様に自分たちに必要なパラメータグループを選択します。
最後に「ステージング環境の作成」を押すと環境の作成が始まります。
もしバイナリの有効化やインスタンスサイズが小さすぎる場合だとここでエラーが発生すると思います。うまくいかない場合は設定を見直してみましょう。
環境作成が完了しますと、以下の画像のように「ブルーグリーンデプロイ環境」「グリーン環境」が新たに作成されていると思います。
この時点でグリーン環境へのデータのレプリケーションも完了しています。ブルー環境へのアクセスを許可しているEC2インスタンスやオンプレ環境からグリーン環境のDBインスタンスへアクセスできると思いますので、事前テストなどに利用できます。
ブルー/グリーン環境の切り替え
ブルーグリーン環境の作成が完了したらブルー環境とグリーン環境を切り替えましょう。
AWSマネジメントコンソールのデータベース一覧から作成した「ブルー/グリーンデプロイ」を選択します。「アクション」> 「切り替え」を選びます。
選択しますと以下のような切り替え画面が表示されます。
ここでブルー環境(ブルーデータベース)とグリーン環境(グリーンデータベース)の情報を確認します。問題なければ切り替えを行います。
1分ほどで切り替えが完了します。切り替えを行うとグリーン環境が本番利用するデータベースとなり、ブルー環境の識別子に置き換わりアプリケーション側で変更する必要がありません。
下記は切り替え後のマネジメントコンソールになりますが、グリーン環境のタグがついたクラスター・インスタンスがレプリケーション元のクラスター・インスタンスの識別子になり、ブルー環境の識別子が *-old1
のような識別子に置き換わっていることがわかります。
ブルー/グリーンデプロイメントにて切り替えを行うとクラスター・インスタンスが変更になっても識別子が変わらないことからエンドポイントがそのまま利用でき、インフラに変更を加えたにもかかわらずアプリケーションでの設定に修正をしなくて良くなります。
まとめ
今回は本番環境で利用しているMySQLを5.7から8.0系へとバージョンアップを行う際にブルー/グリーンデプロイメントを利用してみました。
環境の作成時にレプリケーションを行ってくれたり作成後にアクセスできることから簡単にテストを行えたりと簡単な作業で切り替えができました。
AWSマネジメントコンソールでの設定もすごく簡単に行えたのでぜひ活用してみてください!
Discussion