MySQL5からAmazon Aurora移行した際の失敗談

こんにちは。深緑です。
結構前の話ですが、オンプレミスのシステムをAWSに移行するお仕事をやらせていただきました。
その時の失敗談を記述いたします。

はじめに

移行対象はオンプレミスのシステムです。
そのシステムのDBはMySQL5で、AWSに移行する際にDBはAmazon Auroraとしました。
DBの作りは比較的古い設計で、ストアードプロシージャ・ファンクションも使われています。

結論から言うと、MySQL5→Amazon Auroraは飛び過ぎでしたね。
まずはMySQL Multi-AZぐらいに留めておけばよかったと反省しています。

Auroraの設定調整

最初に、以下の設定調整を行なっています。

• 文字コードのUTF8化
• テーブル名などの大文字・小文字を区別をしない（lower_case_table_nameを1に）
• プロシージャとファンクションの有効化 - AWSサポート

プロシージャとファンクションがroot権限で作られていたので、Aurora側の設定を調整。

一部プロシージャ・ファンクション側も修正する必要がありました。
また、プロシージャ・ファンクションの中身は独自のルールがあったらしく、
テーブル名などが大文字で書かれていたので修正なしで動くよう設定側を調整しました。

問題点と対策

①メモリ不足によるSQLの停止

重い帳票出力で発生。
実はリードレプリカも設けたので、費用の面からオンプレミスのMySQLから物理メモリの量が減っていました。
だとしてもこのような事態にはなるとは思っていませんでした・・・。
改めてオンプレミスのMySQLを調べたところ、my.confでゴリゴリにチューニングしてました。
これは聞いてなかった話でしたね・・・。
同じようなチューニングをAuroraに持ってくことも検討したのですが、
ゴリゴリすぎてこれを適用してしまうとAWSが用意したAuroraに適したパラメータ調整が崩れてしまうと思い断念。
SQL側を調整することにしました。
トランザクションの分割、巨大なSQLの分割、一時テーブルの廃止＋ファイル化などを行なっています。

②書き込み速度の大幅低下

これは予測していたのですが、遅さが予想をはるかに超えていましたね。
オンプレのMySQLに比べて何十倍も劣化しており、バッチ処理は全滅でした。

仕方ないのでバッチ処理を全体的にチューニング。
ループ＋インサートをBULK INSERTやCSVのロードに変えています。

CSVロードはWEBサーバー上にCSVファイルを作り、LOAD DATA LOCAL INFILEコマンドでファイルを読ませる形式を取りました。
Auroraの機能を使うことも検討しましたが、プロジェクトの後半でエンドポイントの作成などVPCをいじるのは嫌
だなと思い回避しました。
今改めて見ればVPCをいじると言っても、そんなに大きな変更点でもなかったなと思いますが、当時はバッチ全滅というインパクトのでかい現象を前にして焦ったので枯れた手法をとりたかったのだと思います。

Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード - AWS

③大量に書き込み後にSELECTが動かない

②の問題を解決させた後に発生。
本件私のプロジェクト以外では見たことはありません。
どうも大量書き込み後、Aurora内部で分散配置されたDB全てで統計情報の更新が終わるまでに、
SELECTしてしまうとSELECTが返ってこないことがあるようです。
完全に予想外です。
統計情報の更新が遅れたとしても、それで起きるのは最大でSELECTが遅くなるだけだろう・・・と思っていたので、意表を突かれました。

苦肉の策として、バッチ処理の大量更新後に統計情報の更新コマンドを入れて対処しています。

まとめ

改めて見てみると、ここまでしてなんでAurora？合ってなかったんじゃないの？と思います。

合ってませんでした。
MySQL Multi-AZにすればよかったと思います。

当時は社内にDBはAuroraに統一しようという流れがあったんですよね。
その流れをオンプレのMySQLに適用してしまいました。

オンプレの移行はまずはリホストから始めるべきですね。
移行方式を決める際の判断誤りだったと思います。

【レポート】リホストから始めるAWSへのサーバー移行 #AWSSummit DevelopersIO

本記事に記した内容が移行方式やDBエンジン選びの参考になれば幸いです。