Aurora MySQLのBGデプロイで簡単・爆速・安全なversion upを行う
はじめに:
初めまして、DELTAの馬場です。クラウドエンジニアをしています。
この記事は AWS（Amazon Web Services） Advent Calendar 2023 の 12日目 です。
概要:
社内で何気ない会話をしている際に、「RDS（Aurora）のBlue Green デプロイ(以降 BGデプロイ)ってめっちゃ便利そうなんだけど触ったことないんだよね」という話があったので、実際に触ってみました。
MySQLでありがちな5.7系から8.0系にverupしたいけど、なるべく停止させずに安全にやりたい！といった要望がかなえられそうか？
というところを簡単に確認していきます。
※RDS周辺の検証はとにかく時間がかかるので、触ってみたいなという時は時間があるときにされることをおすすめします！！
なぜBGデプロイが良さそうなのか？
上記に記載がある内容なのですが
- 切り替えにかかる時間がわずかで済む。
- 論理レプリケーションされるため、verup等によるデータ損失を心配しないで済む。
- データ同期されるグリーン環境を後から操作することができ、準備や確認を丁寧にできる。
- 切り替えでトラブった際のロールバック処理が自動
といった部分にメリットを感じたので検証してみることにしました。
実際にやってみる：
前提
- 662MB のストレージ利用のあるAurora MySQL 5.7 ver 相当の2.11.3 で検証実施。
- 移行先バージョンのMySQL 8系相当の3.X.Xは検証環境等で移行可能なことを検証している。
or 移行に必要な対応を終えているとする。 - BGデプロイ自体の動作を見るため、アプリケーション等に繋いでの検証は実施しない。
事前準備
何も考えずにBGデプロイを実行した際に2つほどハマりポイントがあったので
その解消のために必要な設定等を行っておきます。
どんなエラーに遭遇したか
-
既存インスタンスタイプがverup先でサポートされていなかった
-
BGデプロイ時に必要になるbinlogを有効化する必要があった
ということで先んじて設定をしておきます。
やることとしては2つです。
- インスタンスタイプをverup先のエンジンバージョンがサポートしているものにする。
ここから対応しているものを探します - クラスターのパラメータグループで "binlog_format" の値を "MIXED" にして、インスタンスを再起動して設定を反映させる。
(BGデプロイ時にMySQL8系へのverupまで行う場合は、8系のカスタムクラスターパラメータグループも用意しておきます。)
Tips
インスタンスを1台ずつ設定変更と再起動しても良いのですが
本番環境を想定すると停止時間が長くなってしまいます。
そのため以下の方法を用いることで短い停止時間で設定の反映を終えられるようにします。
-
既存インスタンスとインスタンスタイプ以外同じ設定、AZでリーダーインスタンスを追加
雑に "new-writer" と "new-reader" というインスタンスを追加しました。
-
フェイルオーバーの実行
すぐ終わります。
-
古いインスタンスを削除
追加したnew-XXXなインスタンスだけが残るようにします。
※カスタムエンドポイントを利用している場合は、そちらも合わせて更新してください。
BGデプロイの実行
BGデプロイの作成
移行対象のクラスターを選択し、”アクション” から "ブルー/グリーンデプロイの作成 - 新規" を選択します。
"ブルー/グリーンデプロイ識別子" は一意であれば何でもいいので適当に入力します。
グリーンデータベースの以下については動作検証を行った際のversion等に合わせてください。
- エンジンバージョン
- DBクラスターパラメータグループ
- DBパラメータグループ
検証時の設定項目は以下です。
- 適当に8系のエンジンバージョンを選択
- クラスターパラメータグループはbinlog_formatの設定を追加するために独自に用意したところブルーDBがカスタムパラメータグループだったら、グリーンDBもカスタムじゃないとダメだよと怒られたのでデフォルトからコピーしただけのものを作成して設定しました。
- パラメータグループはデフォルトのままにしました。
作成されるグリーンDBのコストが見れることがちょっと便利だなと思います。
気が利くな～
"ステージング環境の作成" をクリックするとBGデプロイが作成されていきます。
しばらく待ってGreen環境が利用可能な状態になるまで待ちます。
私が検証した際は1時間ほど待ちました。実際に動いているDBだともっとかかってくる想定です。
この時ブルーDBのクラスターイベントを見ると何も新規に発生していないため、既存環境に影響を与えずにグリーンDBを作成しているはずです。
BGデプロイの実行
めっちゃ簡単です。
ロールがブルー/グリーンデプロイになっているレコードを選択し、 "アクション" から
"切り替え" を選択して実行するだけです。
切り替え時に時間を指定することができ、指定した時間以内に切り替え処理が終了しなかった場合、自動でロールバックしてくれます。
試しに最低時間の30秒でやってみたところ、時間が足りずロールバックしていました。
再度時間を5分に設定してみたところ切り替えが完了しました。
実際に切り替え作業を行う場合は、DBの利用が少ないタイミングに切り替えを行うか
こちらに記載のメトリクス等を確認しておき、負荷の少ないタイミングをチェックしておくのがおすすめです。
お片付け:
切り替えが完了するとブルーDBに "-old" とつきます。
動作確認等を終えたら不要になってくるはずなので削除していきます。
このBGデプロイ時に作成されるロールから先に消します。
インスタンスの方からやろうとするとめちゃくちゃ時間かかるような挙動になります。。。
ロールが消えたらインスタンス→クラスターの順番で削除していけばお片付けも完了です！
実行結果：
BGデプロイの切り替えは2分程度で完了しました。
設定値反映のためのフェイルオーバーにも1分かかりましたが
合計3分程度のダウンタイムでversion upを完了できることが分かりました。
まとめ：
BGデプロイによるバージョンアップは、従来の方法と比較するとダウンタイムを圧倒的に短縮できることが分かりました。
特に、トラブル時に自動的なロールバックを行ってくれる点は非常に重要で、この点における準備の手間が軽減されることの恩恵はかなりデカいです。
実際に動いているサービスでの検証には、検証用DBに本番環境で実行されるクエリをキネシス等を活用して同期されるようにし、実際どの程度の時間が必要か計測し、計測結果が耐えうるものかどうか精査する必要があります。
また、そもそも新しいDBのバージョンにアプリケーションを対応させるのが大変等、BGデプロイまでたどり着くことが大変なことも重々承知しています。
しかしながら、この機能を活用することで、従来は時間的制約により実現困難だったDBのバージョンアップを可能にします。
それによって、新しいインスタンスタイプやAWSが提供する新機能を利用しより優れたアーキテクチャや高品質なサービスを提供できる可能性を秘めていると言えます！
おまけ：
BG利用時の注意事項も用意されていたのでこちらも併せて実施前に確認していただくとよいかと思います！
参考記事：
We're hiring!
最後までお読みいただきありがとうございます。
現在DELTA では一緒に働いてくださる仲間を大募集中です！
ご興味をお持ちいただけましたら、お気軽にフォームからご連絡ください。
Discussion