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