どのように MySQL on EC2 から Aurora に移行したのか / Migration from MySQL to Aurora

Data Migration Night に登壇してデータ移行の Tips を紹介してきた
http://kakakakakku.hatenablog.com/entry/2017/05/23/003600

Transcript

1. どのように MySQL on EC2 から Aurora に移行したのか @kakakakakku 2017.05.22 Data Migration Night
2. 吉田 慶章 @kakakakakku - Makuake : CyberAgent Crowd Funding, Inc. - DevOps Engineer 兼 技術広報 - AWS, DevOps, Rails, Certified Scrum Master - 今年からプログラミング講師の仕事もしてます - 趣味はブログを書くことです
 http://kakakakakku.hatenablog.com/
3. https://developers.cyberagent.co.jp/blog/archives/6588/ CyberAgent Developers Blog 今日は5分しかなく， 詳しくはブログで！
4. 伝えたいこと 本当にそのデータは必要なのか？ どのように Aurora に移行したのか？ どんな場面でも無停止が正解なのか？
5. 伝えたいこと 本当にそのデータは必要なのか？ どのように Aurora に移行したのか？ どんな場面でも無停止が正解なのか？
6. 移行を考える前に
7. 「本当にそのデータは必要なのか？」 と考えて，データ量を削減するアプローチを選択すると，無駄がなくなる
8. 不要なテーブルを削除した - 約20テーブルの削除に成功 - 現在は使われていないテーブル - 1度も使われることなく残されたテーブル - 合わせてアプリケーションコードも削除してスリム化
9. ハウスキーピングを実装した - レポート系テーブルなど，直近n世代だけあれば良いのに，
 過去世代のデータが全て残ったままになっていた - バッチ処理 (いろいろ!) にハウスキーピングを実装して，
 自動で過去世代のデータを削除できるようにした - 約1000万レコードの削除に成功
10. 環境間のスキーマを合わせた - prd / stg / ci など環境間のスキーマが合っていなかった - テーブルの差異，カラムの差異，インデックスの差異など - MySQL 公式ツール mysqldiff を使って合わせた - 超便利 : http://kakakakakku.hatenablog.com/ entry/2017/04/02/105901
11. 伝えたいこと 本当にそのデータは必要なのか？ どのように Aurora に移行したのか？ どんな場面でも無停止が正解なのか？
12. 移行概要 - MySQL 5.5 on EC2 -> Aurora に移行 - データ量を削減した「レポート DB」を「メイン DB」に統合 - 全機能テスト (手動) を実施 - 障害検証 (ALTER SYSTEM CRASH コマンド) を実施
13. app db (master) Read / Write CBUDI 日次 mysqldump db (report) db (slave) Read / Write レプリ Read Read フェーズ1 リストア リストア S3 Aurora Reader Aurora Reader 同期 Aurora Writer .dump.sql
14. app db (master) Read / Write batch db (report) Aurora Reader Read / Write Aurora Reader レプリ 同期 Read Read フェーズ2 多段レプリ Aurora Writer db (slave) レプリ
15. app db (master) Read / Write batch db (report) db (slave) Read / Write Aurora Reader レプリ レプリ Read フェーズ3 Reader Read 同期 参照系を Aurora にする Aurora Writer Aurora Reader
16. app db (master) batch db (report) db (slave) Aurora Reader Aurora Reader レプリ レプリ 同期 Read メンテナンス = 更新なし メンテナンス = 更新なし mysqldump を 直接流し込む (DB 統一) フェーズ4 Writer Read / Write Aurora Writer Read / Write
17. app Read / Write batch Aurora Writer Aurora Reader Read / Write Aurora Reader 同期 Read Amazon ES + Kibana aggregator redash スロークエリ集計 分析 フェーズ5 最終型
18. 伝えたいこと 本当にそのデータは必要なのか？ どのように Aurora に移行したのか？ どんな場面でも無停止が正解なのか？
19. 無停止は素晴らしいこと だと思うし
20. 移行できたときの達成感も大きい と思う
21. でも，移行フローが複雑になる 可能性があるし
22. 事故ったときに影響範囲が広がる ことだってある
23. 無停止の夢を捨てて 戦略的にメンテナンスを選択する勇気 サービスの特性を考慮して， ユーザーへの影響を最小限に抑えて， メンテナンスを組織全体の重要なイベントとして理解してもらう そのためには，経営層とのコミュニケーションが必須だし， 「あの人が移行するなら成功しそう感」がとにかく重要 ( これ以上話すとエモトークになるので，この話題はまた今度 )
24. まとめ - MySQL 5.5 on EC2 -> Aurora に移行できた - パフォーマンス面と運用面で，メリットしかない！ - データ量の削減，メンテナンスの必要性も事前に検討する - 「無停止の夢」を捨てる勇気も必要