こんにちは。クラウドソリューション事業部の倉岡です。
今回はAWS RDSのAuroraにおけるBlue/Green Deploymentについて解説します。この機能は、ダウンタイムを最小限に抑えながらデータベースのアップデートを行うための手法です。私たちのメモを元に、Blue/Green Deploymentの設定手順や注意点について紹介します。
RDSblue GreenデプロイとはについてはAWS公式をご覧ください。
なお、一言で説明するとRDS Blue/Greenデプロイとは、Amazon RDSデータベースのアップグレードや変更を、ダウンタイムを最小化しつつ安全に実行するための機能です。
Green環境の作成基準
下記の事例の時にgreen環境を作成して対応しました。
- 大規模なデータベースの場合、MySQLのアップデートを実施すると、以下のエラーが発生する可能性があります。
- optimize table の実施や partition upgrade エラー
- そのため、同じバージョンでgreen環境作成後、green環境でoptimize table を実施します。このクエリはレコード数にもよりますが、１億レコードなどある場合は5時間程度かかったりする場合があります。
- オンラインDDLサポートされているみたいですが、一応グリーン環境を作成してそちらで実施することで通常サービスを提供しているブルー環境にできるだけ負荷をかけずにmysql8化をするための準備ができるということですね。
- 本番環境しかない場合
- 一時的にテスト環境としてスナップショットから複製してRDSupdate検証しても良いのですがそれをするくらいならgreen環境作成してmysql8になること確認動作確認してそのままBGデプロイした方が良いという場合
- メンテナンス時間を限りなく少なくしたい
- 本番環境をB/Gデプロイを使わずにupdate実施するとmysql5.7からmysql8になるまで少なくとも30分かかりその後もmysql8になってからサイト接続などの動作確認をしていると1時間かかる可能性があります。
- B/Gデプロイ10分15分程度で作業が完了し圧倒的な速度でメンテナンス時間を減らすことができます。
- 単体updateの時のダウンタイム数分かかる場合がありますが、B/Gデプロイが1分程度のダウンタイムの方が圧倒的に上です。
- 1分程度のダウンタイムが許容できるサイトであれば、メンテナンス画面を表示させなくても済みますね。
Blue/Green Deploymentの事前準備
まず、Blue/Green Deploymentを使用するためには、以下の設定を事前に行う必要があります。
DBパラメーターの設定
RDSパラメーターグループの設定で
- binlog_format を ROW に設定する必要があります。
- この設定を変更しないと、Blue/Green環境を作成することができません。
- ちなみに自分はmysql5.7用とGreenでmysql8になった後にも更新があったりしたら困るのでmysql8のパラメーターグループにもbinlog_format を ROW 設定しました。(下記の画像)
パラメーター変更後の注意点
- パラメーター変更後は、RDSインスタンスの再起動が必要です。
- 再起動に伴い、20〜30秒程度のダウンタイムが発生します。
green環境作成
Blue/Green環境を作成する際は、以下の手順に従って進めます。
- 作成したいクラスターを選択します。
- 「アクション」メニューから「Blue/Green環境の作成」を選択します。
- 作成時にMySQLのバージョンを選択できます。
- ブルーグリーンの間の名称(識別子)を好きな名前をつけます。
- MySQL 8にアップデートするか、5.7のままにするかを選ぶことが可能です。
今回はmysql5.7を選択したまま複製してみます。その後green環境をmysql8にしてみます。
確認画面は以下になります。
Green環境作成のプロセス
Green環境が作成される際の流れは以下の通りです。
- クラスターの複製が行われる
- ライターインスタンスの複製が行われる
- MySQLのアップデートが実施される（作成時にアップデートを選択している場合）
- 今回は同じバージョンで作成しましたのでこちらの事象は起きません。
- 必要な台数分のリーダーインスタンスが作成される
green環境作成と同時にメジャーバージョンアップデートする場合の注意点
- 事前にスナップショットを取得してから、green環境作成アップデートをすることを推奨します。
- 大規模なデータベースの場合は、まずはMySQLのバージョンを同じにしてgreen環境を作成し、その後手動でgreen環境をアップデートを実施するほうが安全です。
green環境作成後メジャーバージョンアップデートを手動で実施
- green環境のクラスターを選択して「変更」を押してエンジンバージョンをmysql8を選択します。
- その後、確認ボタンを押して変更内容を確認して今すぐ適用を選択してmysql8になるまで待ちます。
- 今回はmysql8のエンジンバージョンとともにカスタムパラメーターも選択しています。
- (binlog_format を ROW を設定したmysql8パラメーターグループを使用します。)
Blue/Green環境の切り替え手順
「Blue/Green Deployment」を選択し、「アクション」から「切り替え」を選ぶことで、Green環境を本番環境（Blue環境）に切り替えることができます。
切り替える内容はこのように記載されるようです。
切替時間は今回はすぐ終わりました。
イベントログでは1分ほど、1分もかかってなかった気がします。(早い)
切り替え時のダウンタイム
- RDSインスタンスのエンドポイント切り替えに伴い、数秒程度のダウンタイムが発生します。
- 一部のクエリがタイムアウトになる可能性がありますが、データの欠損はありません。
切り替え後、Green環境は元のBlue環境の名称を引き継ぎ、元のBlue環境には -old という名前が付与されます。
Blue/Green環境の削除手順
切り替え作業が完了した後、以下の手順で不要なBlue/Green接続を削除します。
- 「Blue/Green Deployment」の部分を削除
- クラスター自体を削除するわけではなく、接続部分を削除して切り離す作業です。
- 削除と凄い怖い表記ですが、この接続部分を削除するという意味みたいです。
こちらを実行すると先ほどの「新しいブルー」「古いブルー」の表記が消えてそれぞれ独立したAurora RDSのようになります。
その後は、手動で不要なクラスターを削除して作業完了です。
よくあるトラブルと解決方法
非対応インスタンスタイプに注意
- Aurora V3に非対応のインスタンスタイプ（例: db.t3.small）では、アップデートが不可能です。
フェイルオーバーによるエラー
- フェイルオーバーによってリーダーになっているインスタンスがある場合、以下のエラーが発生することがあります。
1DB instance auroramysql-instance-1 has a different role than auroramysql-instance-1-green-5xclwb 2 - この場合、再度フェイルオーバーを実施してライターとリーダーの役割を調整し、「切り替え」を実施するとエラーが解消します。
まとめ
Blue/Green環境を作成する際の注意点を以下にまとめます。
- ダウンタイムが発生するタイミング
- パラメーター設定適用時
- Blue/Green切り替え時
- ダウンタイムの許容が可能な場合
- OSアップデートやメンテナンスの適用時にBlue/Green Deploymentを活用できます。
- ダウンタイムの許容が難しい場合
- 切り替え作業を事前に検証し、数秒程度のダウンタイムで対応可能です。
補足情報
Green環境は書き込みおよび読み込みが可能です。ただし、データ同期において以下の変更点に注意が必要です。
レプリケーション互換がある変更
- テーブルの新規作成
- インデックスの作成・削除
- テーブルの最後に新しい列を追加
レプリケーション互換がない変更
- 列名やテーブル名の変更
- マスターキーの重複
これらの変更点を十分に考慮し、事前に検証を行うことが重要です。
AWSの公式ドキュメントによると、Green環境はあくまでレプリカとして使用することが推奨されています。
参考リンク：