スペースマーケットでSREを担当しています小見です。
今回は、2022年11月に発表されたばかりのAmazon Aurora Blue/Greenデプロイを利用して、
サポート終了となるAurora1のアップグレードを実施した時の調査や、躓いたところをまとめていきます。
実践している記事がほぼ皆無なため情報は公式の情報とAWSサポートに問い合わせた内容となります。
- https://aws.amazon.com/jp/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/
- https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html
概要
今回実施したことは、Aurora1からAurora2にアップグレードを行うときにAurora Blue/Greenデプロイを利用して、ダウンタイムを最小限に抑えて、Auroraのメジャーバージョンアップを行う方法となっております。
手順
手順はざっくり以下となります。
- アップデート対象のパラメータグループでバイナリログを有効にする（ダウンタイムあり）
- バイナリログ保有期間の設定
- 適当なデータをInsert Delete
- Blue/Greenデプロイの作成
- 切り替え実施（ダウンタイムあり）
- 後片付け
それぞれ詳細に記載していきます。
アップデート対象のパラメータグループでバイナリログを有効にする（ダウンタイムあり）
クラスターパラメータグループのbinlog_formatをMIXEDに変更します。
変更しただけでは、反映が行われないので、ライターインスタンスの再起動を行い反映を行なってください。
この時ライターだけではなく、リーダーインスタンスも再起動が行われるためリードしてないからダウンしないだろうと油断は禁物です。しっかりダウンしていきます。
※Aurora2.10以降は、リーダーの再起動タイミングを調整することが可能らしく、リーダーを増やして順番に再起動することでリードのダウンタイムをゼロにすることは可能かもしれません。
バイナリログ保有期間の設定
Blue/Greenデプロイはグリーン環境をブルー環境からレプリケーションして、一気に切り替えを行う機能ですので、
レプリケーションを行うためのバイナリログの保有期間を設定します。
実行の際に権限不足の可能性がありますのでその点ご注意ください。
# バイナリログの保有期間を24時間に設定
call mysql.rds_set_configuration('binlog retention hours', 24);
# 確認
call mysql.rds_show_configuration;
→24と設定されていればOK
実行の際にユーザによっては、権限不足の可能性がありますのでその点ご注意ください。
※もしかしたら不要な作業かもしれませんがAWSサポートに問い合わせをした時にこちらの手順も記載されていたため、念の為実施しております。
適当なデータをInsert Delete
テストのため、スナップショットから復元したばかりのDBでBlue/Greenデプロイを実施したところ以下イベントログに以下エラーメッセージが表示されました。
Read Replica Replication Error - IOError: 1236, reason: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
こちらもAWSサポートに問い合わせをしたところ
バイナリログ設定した後に書き込みが何もないとレプリケーションの開始ポイントが更新されない不具合？があるらしく、適当なデータをInsert＆Deleteして、ログファイルを更新させます。
念の為更新されたことを以下で確認しておりました。
# 現在のバイナリログを確認
SHOW MASTER STATUS\G
*************************** 1. row ***************************
File: mysql-bin-changelog.00000x
# 対象ファイルのファイルサイズを確認
SHOW BINARY LOGS;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.00000x | 120 |
Insert & Deleteを実施
# ファイルサイズが増えていることを確認してログファイルが追記されたことを確認して完了
SHOW BINARY LOGS;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.00000x | 851 |
これで前述のエラーが回避できるようになりました。
ここが本当に躓きました。
Blue/Greenデプロイの作成
Auroraクラスターを選択して、アクションの中にブルー/グリーンデプロイの作成が存在しますのでそれを選択してください。
以下を設定して作成を行なってください。
- 更新先のバージョン
- 識別子
- ここの識別子は今回の作業だけのものですのでそこまで気にかけてちゃんとした名前にする必要はないと思います。（今回の説明ではbg-deploymentと呼びます。）
- パラメータグループ
- クラスターパラメータグループ
- インスタンスパラメータグループ
何度かテストしたところ、作成には１時間から2時間半かかりました。（結構ブレがある）
読み書き量やデータ容量によって変わる部分だと思いますので、実施する場合は一度本番のサイズでテストをしました。
切り替え実施（ダウンタイムあり）
Blue/Greenデプロイメントが準備完了したら、切り替えの実施です。
ただ、やることは本当に簡単で、bg-deploymentを選択して、タイムアウト時間を設定して切り替えボタンを押すだけです。
AWSのドキュメントを読む限りコネクションを切る等の記載があるのでダウンタイムがありそうなのですが、自分がテスト環境で試した限りではダウンタイムは見つかりませんでした。
もしかしたら、あまりにも短すぎて気づいていないだけかもしれません。
実際に利用する際はこのタイミングは気を張る必要があると思います。
（弊社が実施したときはメンテナンスモードで利用者影響がないように実施しました。）
これで切り替わります。。。。
がっ！
AWSマネジメントコンソール画面が切り替え作業が終わるまで落ちます。
（Auroraは死んでないので多分大丈夫）
テストで何度か実施しましたが、毎回発生していたので、そのうち修正されると思いますが、ドキドキしながらクラッシュが治るのを待ちましょう。
別Webタブとかで見直したりすると治りが早かったりしました。
これにてバージョンアップの本作業は完了になります。
後片付け
切り替え後、今まで稼働していたブルー環境とbg-deploymentの削除が必要になります。
（お金等を気にしなければ残したままで良いですが。
bg-deploymentは、もうインスタンスなどが紐づいていないので単純に削除ボタンを押して削除できます。
ブルー環境は、通常のAuroraクラスター削除作業と同じで、
リーダーインスタンス
→ライターインスタンス（念の為削除スナップショットの保存）
を行い作業完了になります。
まとめ
一度パラメータグループの設定をしてしまえば、ダウンタイムが発生しそうなのは切り替えタイミングのみ。
しかも弊社で確認した限りではダウンタイムを見つけられないぐらい短い期間でした。
今までDBのバージョンアップのために、8時間程度メンテナンスで止めていたのが、1時間程度で済みそうです。（極限を突き詰めるなら5分とかでも良さそう。）
しかも作業自体も非常に楽で、実行者の負担が大幅に減ります。
さらに、さらに、こういったバージョンアップ時にはバッチなどを止める必要があると思いますが、ダウンタイムが最小限なので、再実行の対象なども絞られて本当にバージョンアップへのハードルが下がりました。
あまりにも直近でたサービスで、エラーも出てましたし使うのを諦めてたのですが、使って良かった限りです。
宣伝
弊社では、今まで取り扱っていなかった新しい技術に関しても前向きに進んでおります。
ご興味持っていただけたら以下より応募をお願いいたします。
弊社は人、文化が良いなと個人的には感じておりますのでこちらも併せて読んでいただけますと嬉しいです。
スペースを簡単に貸し借りできるサービス「スペースマーケット」のエンジニアによる公式ブログです。 弊社採用技術スタックはこちら -> whatweuse.dev/company/spacemarket
Discussion