Amazon Aurora 移行大全 #1

今年もはじまりました Retty Advent Calendar 2019 !
初日を担当いたします技術部の西村です。

さて私は 2 回に分けて 『Amazon Aurora 移行大全』 という内容で書いていきます。
※ Amazon Aurora については Amazon Aurora をご参照ください。
※ 以降 Aurora と記載

2 回にわたる内容は下記を予定してます。

• 移行対象環境の説明
• 移行の経緯
• 事前調査/検証
• 移行準備
• 並行運用
• メンテナンス作業
• 移行を終えて

初回は 「移行準備」 まで触れて終わりにします。

ちなみに Aurora 移行は今月中旬を予定しており、まだ移行しておりません！
移行成否によって 2 回目の内容が変わってくるので、成功したのか、失敗したのか含めご期待ください。

移行対象環境の説明

まず今回移行対象となる環境は RDS for MySQL 5.7 の環境になります。
※ 以降 RDS と記載

リーダーに関しては通常のサービスに利用しているものや、キャッシュ生成用、社内サービス用、検索用などでインスタンスを分けて利用してます。
子レプリカがこれ以上作成できないので多段で組んでます。
参考資料 : Amazon RDS リードレプリカ

移行の経緯

Aurora への移行は前々から意識しており、どのタイミングで移行しようかと検討していました。
ただそれを早くやらねばと駆り立てたもの、、そう障害。。。

サービスの一部機能でレプリケーション遅延が発生すると通知などの処理に影響がでる実装になっていました。
以前はそれほど問題視されることは無かったのですが、ユーザ数の増加、データ更新量の増加などによりレプリケーション遅延が目立ち、障害に繋がる事例が増えてきました。

解決策として、

1. 実装方法を変更する
2. レプリケーション遅延を限りなく減らす仕組みにする

の両面から取り組んでおり、今回は 2 の紹介となります。

事前調査/検証

移行の必要性は認識できました。
ではそのまま素直に移行できるのでしょうか。

もちろん事前の調査/検証が必要になります。
今回はコスト調査、テーブルスキーマ変更調査、カスタムエンドポイント調査、性能検証を行いましたので、以降それぞれ見ていきます。

コスト調査

移行対象環境は RDS なのですが、 Aurora はそれより高いです。
そのためコストがどの程度かかるのか事前に試算する必要がありました。

試算した結果、月数万円程度の増額となり、コスト面では特に問題はありませんでした。

Retty では RDS を Multi-AZ 構成で使用しており 2 台分のコストがかかってましたが、 Aurora では RDS で言うところの Standby インスタンスがリードレプリカとして利用できるため、コストアップの差分は想定よりも低い額で収まりました。

また並行運用期間中はプラスで 35 万程度かかることも分かりました。

なお RDS のリザーブドインスタンスを購入しており、上手く利用できないかと思って下記を調べたのですが、無理そうでした。

• 販売できる？

  • Amazon EC2 のみ販売できる。RDS は販売不可。
  • リザーブドインスタンスマーケットプレイス

• RDS から Aurora にリザーブドインスタンスの付け替えできる？

  • 出来ない

ということで今回はリザーブドインスタンスが切れるタイミングで移行する予定で進めてます。

テーブルスキーマ変更調査

そのまま RDS からポチポチと移行できるかというといくつか制限があります。
参考資料 : Amazon RDS MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータを移行する

• MyISAM 未サポート
• テーブルフォーマットの COMPRESSED 未サポート

このため事前に対応する必要があります。

ただ RDS の管理コンソールの 「アクション」 を確認すると 「Aurora リードレプリカの作成」 ボタンがあります。
もしかしたら上記制限を内部的に変換してくれるのでは？と思って master のスナップショットから検証環境を作成して、早速 Aurora リードレプリカを作りました。
ステータスが 「作成中」 になっていてうまくいきそうです。

3 日経ちました...

ステータス変化なしです。
AWS サポートに問い合わせたところ、 各種制限は事前に対応しておいてください、とのこと。
エラーも出てないため内部的にどのような状態になっているのか知りたい欲求はあるのですが、時間も無いので、事前に対応を行っていきます。

MyISAM から InnoDB への変換

MyISAM を利用しているテーブルを出力するため下記クエリを実行しました。

mysql> SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema NOT IN ('sys','mysql','information_schema','performance_schema') AND engine <> 'InnoDB';

テーブルスキーマを確認するため下記クエリを実行しました。

mysql> SHOW CREATE TABLE <tablename>;

テーブルスキーマを変更するため下記クエリを実行しました。

mysql> ALTER TABLE <tablename> ENGINE=InnoDB;

対象テーブルでいちばん時間がかかったのは下記でした。

行数	データサイズ(MB)	変換時間
50046310	5392	25m12.455s

COMPRESSED から DYNAMIC への変換

この作業は圧縮テーブルを展開します。
そのため事前にストレージ残容量の確認と、必要であれば前もって容量を増加させておきます。

最近はストレージが自動で拡張されるようになりましたが、それでもエラーになったので事前に 500 GB 追加しました。
KEY_BLOCK_SIZE を元にどのくらい追加する必要があるか検討します。

ROW フォーマットが COMPRESSED であるテーブルを出力するため下記クエリを実行しました。

mysql> SELECT table_schema, table_name, ROW_FORMAT FROM information_schema.tables WHERE table_schema NOT IN ('sys','mysql','information_schema','performance_schema') AND ROW_FORMAT = 'COMPRESSED';

変換コマンドは下記を実行しました。

mysql> ALTER TABLE <tablename> ROW_FORMAT=DYNAMIC KEY_BLOCK_SIZE=0;

対象テーブルでいちばん時間がかかったのは下記でした。

行数	データサイズ(MB)	変換時間
176972922	53491	199m41.981s

カスタムエンドポイント調査

移行対象環境記載の通りサービスに利用している環境だけではなく、社内用、キャッシュ作成用が混在してます。
そのため Aurora が用意している読み取りエンドポイントを利用すると全レプリカが参照対象に入るため、このままでは利用できません。

これを解消するためカスタムエンドポイントを利用します。
参考資料 : Amazon Auroraで組み合わせ自由なエンドポイントが設定可能になりました

ただカスタムエンドポイントの設定を変更すると、その変更中はカスタムエンドポイントが利用できない、つまりサービス利用できない状態になりますのでご注意ください。

性能検証

今回はパフォーマンス改善が目的では無いですが、現状のパフォーマンスが落ちるようなことがあれば移行はそもそも出来ないので、性能検証を行いました。

下記条件で性能検証を行いました。

• mysqlslap と独自スクリプトで検証
• インスタンスサイズは都合上通常より低いサイズを使用
• パフォーマンスインサイト
  • RDS
    • 無効
  • Aurora
    • 有効
• クエリは 1 日の中のピークタイムのクエリを抽出
  • SELECT のみ
• 下記の並列数で実行。クエリはランダムで選択されたもので、それぞれ別のクエリがほぼ同時実行される。応答時間は 300 回実行した平均。
  • 100
  • 250
  • 500
  • 800
  • 900

mysqlslap では満たせないランダムなクエリ実行を行うために独自スクリプトを実装しました。

実行結果は下記となりました。

同時接続数	Aurora 応答時間	RDS 応答時間	備考
100	4.414095 秒	4.501928 秒	300 回実行した平均
250	9.327125 秒	9.644878 秒	300 回実行した平均
500	13.411717 秒	13.539396 秒	300 回実行した平均
800	13.359580 秒	14.272025 秒	300 回実行した平均
900	12.936538 秒	14.588518 秒	300 回実行した平均

大幅な改善は見られませんでしたが、同程度の性能は確認できました。
特にパフォーマンスインサイトを有効にしているので今回はこれで良いと思ってます。

移行準備

アプリケーション側の動作確認は進行中ですが、概ね移行ができそうだと言うことが分かりました。
ではどうやって新環境を作っていきましょうか。
上記記載の通り事前にテーブルスキーマ等の変更作業が必要になります。
通常はメンテナンスを設けて事前に master に対して作業を行うと思いますが、今回は事前作業にメンテナンスを設けず、下記の手順で新環境を作っていく方針です。

1. 子レプリカから新規に孫レプリカ(aurora-tmp) を増やす
2. aurora-tmp の read_only を OFF にする
3. aurora-tmp に対して MyISAM => InnoDB, COMPRESS => DYNAMIC の変更作業を実施
4. aurora-tmp から Aurora のリードレプリカを生成する

詳細に関しては次回記載する予定です。

ここまで読んでいただいてありがとうございます！
明日以降の Retty Advent Calendar 2019 もどうぞよろしくお願いします！

参考資料

• Amazon Aurora PDF
• RDS for MySQL データベースを Amazon Aurora へ移行するためのベストプラクティス
• Amazon RDS リードレプリカ
• Amazon RDS MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータを移行する
• Amazon Auroraで組み合わせ自由なエンドポイントが設定可能になりました
• Amazon RDS DB インスタンスのストレージを使用する
• Amazon RDSパフォーマンスインサイトの使用
• リザーブドインスタンスマーケットプレイス
• Amazon Aurora 接続管理