買い替え割サービスをAmazon RDSからAmazon Aurora MySQLへ移行したお話

はじめに

こんにちは、ZOZOTOWN開発本部リユースシステムブロックの西山です。最近の癒やしは飼い猫のお腹に吸いつくことです。普段は買い替え割サービスにおけるバックエンドの開発や運用保守を担当しています。

買い替え割サービスのデータベースはRDS for MySQL 5.7を利用していますが、2023年10月にサポートが終了するため次期バージョンへのアップデートが不可欠となっておりました。

また、サービスの成長に伴い、運用効率、可用性、耐障害性をさらに向上していくために、データベースそのものを見直す必要もありました。

この両面の課題に対応するため、RDS for MySQLからAurora MySQLへの移行をすることになりました。

本記事ではRDS for MySQL 5.7からAurora MySQL v3へ移行時と運用をしてみて気づいたことを紹介していきます。

買い替え割サービスとは

買い替え割サービスはZOZOTOWNが提供する「買い替え割」「いつでも買い替え割」サービスの総称です。

「買い替え割」はZOZOTOWNで購入したアイテムを下取りすることで、欲しいアイテムを割引価格で購入できるサービスです。

また、「いつでも買い替え割」はZOZOTOWNで購入したアイテムを好きなタイミングでZOZOポイントに交換できるサービスです。

図1：買い替え割サービス

抱えている課題

冒頭で軽く触れましたが現状抱えている課題を再度整理しました。

1. RDS for MySQL 5.7.39のサポート期限が2023年10月に迫っている。
2. サービス成長に伴いユーザーアクセスが増えている中で、メンテナンス作業時間の短縮を求められている。
3. DBの肥大化により、インデックス設定などのテーブル更新作業で1時間以上かかることもありメンテナンス作業が長時間化している。

Auroraの選定理由

Auroraを選定した理由について説明します。RDSとAuroraの違い、Aurora独自の機能を調査し、課題に対してどのように対応できるかを検討しました。

RDSとAuroraの違い

	RDS for MySQL	Aurora (MySQL)
SLA	99.0％以上、99.95％未満	99.0％以上、99.99％未満
処理性能 ※1	100,000 SELECT/秒	500,000 SELECT/秒
Failover完了までの時間	60～120 秒	30 秒以内
Failover時のDB接続先エンドポイント変更	あり	なし
ストレージ	EBS (Elastic Block Store)	仮想クラスターボリューム
最大ストレージ容量	16TiB	128TiB
ストレージ領域の自動拡張	なし	あり

（※1）参考： 「MySQL の 5 倍のパフォーマンス」とはどんな意味ですか?

特にRDSとAuroraではストレージが大きく異なります。RDSではEBSを利用しているのに対し、Auroraでは仮想Clusterボリュームを利用しています。

そのため、RDSでストレージを拡張する場合は手動で行う必要があり、EBSを1台のインスタンス毎にアタッチするためすべてのEBSに対してインスタンスタイプの変更が必要となります。

Auroraでは仮想クラスターボリュームで3つのAZにまたがって6つのストレージノードにレプリケートされ、高可用性を実現しながら自動で拡張するためストレージ領域の管理が不要となります。

図2：RDSとAuroraのストレージの違い

参考：Is Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL a better choice for me?

参考：Introducing the Aurora Storage Engine

Aurora独自の機能

Aurora独自の機能も見ていきます。

1. ZDP（ゼロダウンタイムパッチ）を利用することで、クライアントの接続を維持しながら5秒程度の遅延でパッチ適用が可能になる。
2. ストレージサイズを最大128TiBまで自動で拡張するため、ストレージサイズの管理が不要になる。
3. Auroraのフェイルオーバーではエンドポイントの書き換えが無いため、アプリケーション側のエンドポイントの書き換えが不要となりダウンタイムを短縮できる。

課題解決

現状抱えている課題がどのように解決出来るか見ていきます。

RDS for MySQL 5.7.39のサポート期限が2023年10月に迫っている。

次期8.0系のv3にバージョンアップすることで、サポート期限の延長及びv2からv3への移行の手間がなくなります。

v2は5.7系と互換性がありますが、今後メジャーバージョンのサポート切れになる可能性を考慮し、よりライフサイクルの長いv3が良いと判断しました。

サービス成長に伴いユーザーアクセスが増えている中で、メンテナンス作業時間の短縮を求められている。

Auroraマイナーバージョンはリリースから少なくとも12か月間利用が可能となっており、メンテナンス頻度の削減につながります。

RDSはベンダーによるコミュニティリリースに合わせてマイナーバージョンがリリースされます。2022年のマイナーバージョンアップは4,5回行われていました。

最新バージョンを利用するには、ベンダーのリリースに合わせてマイナーバージョンをアップデートする必要があります。また緊急性の高いセキュリティパッチは期限を過ぎると、強制的に再起動して適用されるため注意が必要です。

参考：Amazon RDS での MySQL のバージョン

DBの肥大化により、インデックス設定などのテーブル更新作業で1時間以上かかることもありメンテナンス作業が長時間化している。

ブルーグリーンデプロイを利用することで、運用しながらテーブル更新作業を事前に行えるためメンテナンス時間が短縮可能になります。

前述の内容を踏まえてよりクラウドネイティブに設計されメリットが多く、現状抱えている課題をまとめて解決が出来るAurora v3への移行を決断しました。

移行方法の検討

移行前後のシステム構成図

移行前のRDSと移行後のAuroraの簡略化したシステム構成です。移行前からMultiAZ構成になっていますが、移行後では更に別のAZにリードレプリカを1台増やして可用性を高めています。

図3：移行前後の構成図

移行方法

今回で検討した移行方法は大きく分けて3つありました。RDSからAurora v3へ直接アップデートは出来ないため、RDS→Aurora v2→Aurora v3の順でアップデートしました。

図4：移行方法の比較

移行方法	総評	データの移行速度	作業時間	データの整合性	クラウド環境への適正
1.スナップショットから昇格して移行する	◎	◎	◎	◎	◎
2.リードレプリカから昇格して移行する	◯	◎	△	◎	◎
3.ダンプ＋リストアして移行する	△	×	△	◎	◎

今回はデータの移行速度が早く、作業手順もシンプルでAWSが提供している1のスナップショットから昇格して移行する方針で対応しました。

参考：DB スナップショットを使用した MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータ移行

移行手順

移行当日に行った移行作業の流れについて説明します。また移行作業の際にハマった点や気づいた点は「移行した際の気づき」に後述します。

1. RDSのスナップショットを取得する
   • 当日作業に問題が発生した場合すぐに切り戻しが出来るようにRDSは残しておきます。
2. スナップショットからAurora v2のクローンを作成する
   • 作成したAurora v2は作業後不要になります。
3. Aurora v2のスナップショットを取得する
4. CloudFormation（以後CFnとする）のスタック更新でAurora v2のスナップショットを元にAurora v3のクラスターを作成する
   • チームの運用ルールとしてAWSのリソースをCFnで管理しています。AuroraもCFnで管理するため論理IDを新規に用意しました。

図5：移行作業の流れ

移行した際の気づき

移行による確認と変更

移行時に行った主な確認や変更点をまとめました。

• MySQL 5.7からMySQL 8.0で認証プラグインのデフォルト変更による影響の確認
  • MySQL 5.7では認証プラグインのデフォルトがmysql_native_passwordでしたが、MySQL 8.0ではcaching_sha2_passwordとなります
  • アプリケーション側はPHPを利用しておりDB接続に利用するPDOは現状caching_sha2_passwordに対応してません
  • Aurora v3では認証プラグインのデフォルトがmysql_native_passwordになっているため、移行による影響はありませんでした
• パラメータグループの設定値の変更と確認
  • Aurora専用のパラメータ追加、一部パラメータのデフォルト値変更があるためシステムに合わせた設定の調整が必要です
  • 文字コード、タイムゾーンはアプリケーション側と合っているか確認し必要に応じて設定しました
  • ログ周りの設定も必要かどうかを見直しました
    • general_logに関してはAuroraのパフォーマンスに影響をあたえるため本番稼働する環境では無効にすることを推奨していました
  • 一時領域に関するパラメータはシステムに合わせた設定が必要となります
    • 「ケース1：一時領域の不足エラー」で後述します
  • 上記以外のパラメータについては、実際のワークロードで性能が発揮できるようにチューニングしているためほとんどのパラメータ設定はデフォルト値で問題ありませんでした
    • 参考：Amazon Aurora MySQL データベース設定のベストプラクティス
• Auroraではオプショングループのパラメータ設定が変更できなくなる
  • 移行前にパラメータグループの設定を確認し、移行後で設定変更が必要なパラメータはないか確認する必要がありました
  • チームでは監査ログの取得にMariaDB Audit Pluginを利用していました
    • Aurora v3では監査ログを取得する機能が備わっているため必要に応じて設定を変更する必要があります
    • 参考：Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用
• 監視メトリクスが追加になる
  • Aurora v3では監視メトリクスが追加になります
  • デッドロックなどのメトリクスの追加があるため、アラート設定を見直しました
  • AuroraはRDSと比較しCPUやメモリ使用率が上昇するため、アラート設定を確認する必要があります

ケース1：Aurora v2を作成時デフォルトパラメータグループが存在しないエラーになる

事象

「図5：移行作業の流れ」のステップ2でAurora v2のクラスターを作成する際に以下のようなエラーが発生しました。

DBClusterParameterGroup not found: 'default.aurora-mysql'

原因

Auroraを構築したことがなくデフォルトパラメータグループも存在しないため発生していると考えられます。

原因に関して調査しましたが詳細は不明でした。

対応

対処法についても調査しましたがこれといった解決策は見つかりませんでした。

公式の方法ではないですが、スナップショット復元した後リードレプリカからAurora v3を作成することでデフォルトパラメータグループが作成された状態となります。

以降はスナップショットからAurora v2のクラスターを作成可能となりました。

ケース2：Aurora v3の作成で失敗する(その１)

事象

「図5：移行作業の流れ」のステップ4でAurora v3のクラスターを作成開始後、6時間経過しても作成が完了しない。

原因

テーブルのコメントでutf8mb3非対応の文字列が含まれているため、Aurora v3のクラスター作成時にエラーが発生していました。

エラーが出なかったため、原因調査ではMySQLバージョンなのかAuroraによる挙動の違いが原因なのかを切り分けていきました。

RDSのみでMySQL 5.7から8.0へのアップデートを行ったところ特に問題は発生せず、Aurora v2からAurora v3へのアップデートを行ったところエラーが発生しました。

Auroraのerrorログには以下のようなエラーが出力されていました。

Comment for table 'データベース名.テーブル名' contains an invalid utf8mb3 character string: '16進数の文字列'.

対応

ALTER文でテーブルのコメントを再度設定することでエラーが発生しなくなり、Aurora v3のクラスター作成が完了しました。

ケース3：Aurora v3の作成で失敗する(その２)

事象

「図5：移行作業の流れ」のステップ4でCFnからAurora v3のクラスターを作成する際に以下のようなエラーが発生しました。

The following resource(s) failed to create: [AuroraCluster].

原因

RDSとAuroraではCFnのプロパティが異なるため、エラーが出ていました。

対応

Auroraに対応したCFnのプロパティを設定することでAurora v3のクラスター作成が完了しました。

ケース4：別のAWSアカウントで作業時間が想定よりも長くかかった

事象

チームでは検証と本番でAWSのアカウントを分けて運用しています。

本番アカウントにて本番を想定したリハーサルの実施時、予定していた時間よりも長くかかってしまい当日の作業スケジュールに影響する可能性がありました。

移行当日にテーブルの更新作業も合わせて実施予定で、この更新作業が検証よりも1.4倍もの時間がかかっていました。

原因

考えられる原因としては、今回予定していたテーブルの更新作業は型の変換であるため、テーブルのフルスキャンが発生することです。

検証アカウントでは3か月前の本番相当データ量で実施しており、3か月分のデータ差分によって作業時間へ影響した可能性がありました。

対応

時間を短縮するためインスタンスタイプの一時的な変更や、パラメータの調整などを試みましたが、フルスキャンになる型の変更の場合は時間を短縮出来ないことが分かりました。

今回はRDSからAuroraへ移行がメインでテーブルの更新作業は別日に実施する判断となりました。

現状抱えている課題にもなるので、今後はブルーグリーンデプロイを活用することでメンテナンス時間の短縮を目指して行きたいと考えています。

運用した際の気づき

ケース1：一時領域の不足エラー

事象

リーダーインスタンスに対してクエリを実行した際に以下のようなエラーが発生しました。

[ERROR] [MY-013132] [Server] The table '/rdsdbdata/tmp/#sql294_800_1' is full! (handler.cc:4388)

原因

リーダーインスタンスとライターインスタンスでメモリ枯渇の挙動が異なり、今回はリーダーインスタンスのメモリ枯渇でエラーとなりました。

下記、参考URLのAppendix(Aurora MySQL 3.0)フロー図を参照するとリーダーインスタンス／ライターインスタンスでエラーになるまでのフローが確認できます。

参考 ：Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL

対応

クエリ実行後にTempTableの合計サイズを確認し、temptable_max_ramかtemptable_max_mmapの値を調整する必要があります。

今回はtemptable_max_mmapをTempTableの合計サイズより大きい値に設定することで解決しました。memory-mapped fileは作りすぎたとしても実体はメモリではないのでOOMのリスクはなく、あるとすればストレージ枯渇が考えられます。

temptable_max_ramに関しては値を誤るとメモリを使い切りライターのプロセスが落ちる可能性もあるため設定を慎重に行う必要があります。

ケース2：CFnとAWS管理コンソールでAuroraの設定変更による再起動の挙動の違い

事象

Auroraのリネームや動的パラメータ変更などAWS管理コンソールから変更した時、Auroraを再起動せずに変更した値の反映が可能です。

しかし、再起動が不要な変更をCFnからスタック更新すると再起動される事象を確認しました。

原因

原因について調査してみたところCFnによる仕様になっておりました。

参考：AWS::RDS::DBClusterParameterGroup

対応

CFnからスタック更新する際は、Auroraが再起動される可能性を想定し事前に確認する。

または、AWS管理コンソールから変更を行い後追いでスタック更新すると再起動なしで更新が可能になります。

パッチ適用で検証した際は再起動されずにスタック更新が終了することを確認しました。この時、スタック更新の挙動はパッチ適用済を確認してスタック更新を終了しました。

ケース3：プラグインに関するエラーメッセージ

事象

移行後にAuroraのerrorログで監査のプラグインに関するエラーログが出力されていました。

[ERROR] [MY-010901] [Server] Can't open shared library '/rdsdbbin/oscar-8.0.mysql_aurora.3.xx.0/lib/plugin/server_audit.so' (errno: 0 /rdsdbbin/oscar-8.0.mysql_aurora.3.xx.0/lib/plugin/server_audit.so: cannot open shared object file: No such file or di).

原因

こちらに関して調査しましたが原因に関する詳細は不明でした。現行の運用に影響が出ていないため、早急な対応は必要ないと判断しました。

対応

エラーとなっているプラグインを削除することで解消できそうだと考えましたがrootでは権限がないため実行できませんでした。

AWSで管理する権限でのみ操作が可能なため、今後のアップデートで解消することを期待しています。

ケース4：断続的に発生するコネクション関連のエラーログ

事象

Auroraのerrorログで以下のようなエラーログが断続的に出力されていました。

Aborted connection 1234 to db: 'unconnected' user: 'rdsadmin' host: 'localhost' (Got an error reading communication packets)

原因

こちらに関して調査しましたが原因に関する詳細は不明でした。

対応

運用に影響はないので、今後のアップデートで解消することを期待しています。

ケース5：ブルーグリーンデプロイ

Auroraではブルーグリーンデプロイの機能を提供しています。

ブルーグリーンデプロイは、クラスターを2つ用意し、1つのクラスターで運用しながらもう1つのクラスターで新しいバージョンのAuroraを構築します。テストを行い問題がなければ切り替えるというものです。

オンラインDDLでロックを取得せず運用中にスキーマ変更する機能もありますが、型変換などロックが取得されるものに関しては、一度メンテナンスしてからスキーマ変更する必要があります。

またDBが肥大化しているため実行時間が1時間以上かかるテーブルもありメンテナンス時間が長時間化してしまいます。

そこで、ブルーグリーンデプロイを利用することでメンテナンス時間の短縮が期待できます。まだ検証段階で事例がないので今後ナレッジが蓄積してきたらまた記事にしたいと思います。

まとめ

RDS for MySQL 5.7からAuroraへの移行に関する事例について、移行の流れや、移行作業、運用中のケーススタディを紹介しました。

検証やトライアンドエラーを繰り返し、リハーサルテストを重ね当日は無事に本番導入でき、リリース後も特に大きな問題なく稼働しています。今後も買い替え割サービスをはじめとしたリユースシステムのサービスをより良くしていくためにも、リプレイスや機能開発など進めていきたいと考えています。

最後に

リユースブロックは「買い替え割」や「いつでも買い替え割」など、買取した中古商品を販売しているZOZOUSED事業に関するサービスの開発チームです。

現在はリプレイスプロジェクトが進んでおり、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com