Zenn
🐬

Aurora V2(MySQL5.7)を Blue/Green Deploymentを使ってアップグレードした話

2024/03/27に公開
AWS
MySQL
aurora
SRE
tech

はじめに

HousmartでCTOをしている佐藤です。SREチームの取り組みで Amazon Aurora MySQL v2(MySQL5.7)をv3(MySQL8.0)にアップグレードした時の話です。

背景

Aurora MySQL v2の標準サポート期限が2024年10月31日ということで、期限までにはアップグレードするように予定していましたが、MySQL8.0が5.7よりもパフォーマンスが向上しているということもあってプロダクトへ期待できる要因があるため、実施することにしました。

アップグレード方法の検討

今回は「Blue/Green デプロイ」にて実施しました。インプレースアップグレードも選択肢としてあったのですが、ダウンタイムの発生を極力短くすむようにアップグレードを行いたいため、Blue/Green デプロイで実施しました。

計画と事前準備

現在の環境でBlue/Greenデプロイが実施可能かどうか、また 実施時のオペレーションの確認のためにDBのスナップショットから実施テスト用のDBを作成し検証を行い、事前検証および調査で、以下のことがわかりました。

  • Blue/Greenデプロイを実施するために、バイナリログを使用したレプリケーションを伴うので、バイナリログ出力を有効にしておく必要があって、パラメータグループのbinlog_formatをMIXEDに設定する必要がある。
  • Blue環境からGreen環境へのスイッチのタイミングで、ダウンタイムが発生する（概ね2～3分）

既存のクラスターパラメータグループには、binlog_formatを設定していないため、binlog_formatを設定後に再起動する必要があるので、アップグレード時に設定変更を行うと2回ダウンタイムが発生することになる。
切替のタイミングで、ダウンタイムが発生するが短時間のためサービスへの影響が少ないと判断しました。

ステージング環境での実施検証

まずは、本番環境に近い ステージング環境で実施を行い 移行手順 及び 実施時の懸念事項がないかを検証しました。

既存クラスターパラメータグループの変更

binlog_formatをMIXEDに変更する作業は、アップグレード時に設定変更を行わないで、DBのメンテナンスにあわせて事前に設定変更を行いメンテナンスで再起動するようにして、アップグレード時のダウンタイムを1回で済むようにしました。

Blue環境 ⇒ Green環境 切替

Blue環境からGreen環境への切替ができない問題が発生しました。原因は、定期的に動いているバッチ処理で書込み処理を行っているタイミングにあたって切替に失敗しているようでした。バッチ処理が動作していない時間帯・タイミングで切替することで無事に切替が完了しました。

アップグレード後のマイグレーション

サーバーサイドにRailsを採用していて マイグレーションにridgepoleを利用しているのですが、アップグレード後にマイグレーションを実行した際に ALTER TABLE が実行され 処理に時間がかかり ステージング環境がアクセスできない時があった。

原因は、テーブルによって文字セットが utf8 と utf8mb4 が設定されていたこと。また、Schemafileの設定で utf8mb4 の照合順序を設定していなかった。そのため、ridgepoleのオプションに --mysql-change-table-options がついていたため、DBとSchemafileのテーブルオプションの差分を適用しようとするため、ALTER TABLE が実行されていた。

ridgepoleのオプション --mysql-change-table-options を外すことで回避。また、Schemafileを以下のような差分のでない状態に変更することで、問題解決。

  • utf8 ⇒ utf8mb3
    • MySQLのutf8 は、utf8mb3 のエイリアスのため、CHARSET=utf8 から CHARSET=utf8mb3 に変更
  • utf8mb4 に照合順序を設定
    • utf8mb4のデフォルトの照合順序が 8.0で、utf8mb4_general_ci から utf8mb4_0900_as_ci に変更になったため 既存との互換を保つために COLLATE=utf8mb4_general_ci を追加
create_table "hogehoge", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb3" do |t|
  t.string   "title"
  t.text     "text"
  t.datetime "created_at"
  t.datetime "updated_at"
end

create_table "fugafuga", force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci" do |t|
  t.string   "title"
  t.text     "text"
  t.datetime "created_at"
  t.datetime "updated_at"
end

本番環境での実施

事前検証・ステージング環境での実施の結果を踏まえて、アップグレード作業・切替作業、時間帯や切替タイミングを計画し直した結果、本番環境での実施は、サービスに大きな影響なく、アップグレードを完了させることができました。

おわりに

Amazon Aurora V2(MySQL5.7) から V3(MySQL8.0)へアップグレードしたことについての実施内容やその時の課題などについて紹介しました。
これから アップグレードを検討されている方、データベースのアップデートに伴うメンテナンスを実施される方々の参考になれば幸いです。

Discussion