Slide 1
Slide 1 text
Makuake の急成長を支える
Aurora 移行事例
AWS Solution Days 2017 ~ AWS DB Day ~
2017.07.05
Slide 2
Slide 2 text
吉田 慶章 @kakakakakku
- CyberAgent Crowd Funding, Inc.
- 開発本部所属
- DevOps エンジニア & サーバサイドエンジニア
- エンジニアリングマネージャー
- 趣味 : 技術ブログを毎週書くこと
- http://kakakakakku.hatenablog.com/
Slide 3
Slide 3 text
Makuake
- 2013年8月リリース
- 国内最大の「クラウドファンディング・プラットフォーム」
- プロジェクト情報, 決済情報, コミュニケーション情報など
多種多様なデータを扱っている
Slide 4
Slide 4 text
課題感
Slide 5
Slide 5 text
データベースのライフサイクルは長い
ウェブサーバと比較すると, スケールアウトも難しく, SPOF になりがち
Slide 6
Slide 6 text
課題感
- RDS ではなく MySQL 5.5 on EC2 を運用していた
- サービスをリリースしてから, 1度も止まらずに稼働していた
- uptime 1000 days 以上 ( ﾟдﾟ)!!!
- ボトルネックになる「アーキテクチャの課題」と「運用の課題」
- サービスの急成長を支える新基盤にリプレイスを検討していた
Slide 7
Slide 7 text
「アーキテクチャの課題」と「運用の課題」
- 「アーキテクチャの課題」
- フェールオーバーができなかった ( MHA などの考慮なし )
- バージョンアップが難しかった
- 1TB 以上の EBS (Magnetic) がアタッチされていた
- 「運用面の課題」
- 重い分析クエリが発行されてスレーブが高負荷になっていた
- スロークエリを確認するために, 直接サーバに接続していた
Slide 8
Slide 8 text
Amazon Aurora
そこで !!!
Slide 9
Slide 9 text
なぜ Aurora を採用したのか
Slide 10
Slide 10 text
なぜ Aurora を採用したのか
- クエリパフォーマンスの高さ
- Auto Scaling ストレージ (10 GB 単位)
- 限りなくゼロに近い, Reader のレプリカラグ
- 高速なフェイルオーバー
- MySQL 5.6 完全互換
Slide 11
Slide 11 text
Aurora 移行の前に考えたこと
Slide 12
Slide 12 text
1. データを削減するアプローチ
「本当にこのデータは必要なのか？」と考えた
Slide 13
Slide 13 text
データ削減
- 思っている以上に, 不要なデータが大量に残っている (はず)
- データ削減をすると, データ見積もりが容易になる
- さらに, データ移行時間を短くできるなど様々なメリットがある
- 実績
- 約20テーブルを削除した
- 不要なレポート系のデータを約1000万レコード削除した
Slide 14
Slide 14 text
2. メトリクスを見てスペックを見積もる
「適切な RDS インスタンスクラスはどれなのか？」と考えた
Slide 15
Slide 15 text
max_connections
- MySQL で connections 関連のメトリクスを取得した
- Max_used_connections を指標の1個にした
Slide 16
Slide 16 text
max_connections
- パラメータグループのデフォルト値
- GREATEST({log(DBInstanceClassMemory/
805306368)*45},{log(DBInstanceClassMemory/
8187281408)*1000})
- インスタンスクラスごとのサイズを見て, 適切なクラスを見積もる
- db.r3.large 1000
- db.r3.xlarge 2000
Slide 17
Slide 17 text
innodb_buffer_pool_size
- MySQL で InnoDB 関連のメトリクスを取得した
- Buffer Pool Size の使用量を指標の1個にした
last(mysql.innodb[buffer_pool_pages_free]) /
last(mysql.innodb[buffer_pool_pages_total]) * 100
Slide 18
Slide 18 text
innodb_buffer_pool_size
- パラメータグループのデフォルト値
- {DBInstanceClassMemory*3/4}
- インスタンスクラスごとのサイズを見て, 適切なクラスを見積もる
- db.r3.large 7.45 GiB
- db.r3.xlarge 18.72 GiB
Slide 19
Slide 19 text
パラメータグループのコツ
- 「適用タイプ : static」のパラメータを最優先に考える
- 反映に再起動が必要になるため
- 基本的にはデフォルト値のまま使う
- Aurora Team がチューニングして厳選した値のため
- default.aurora5.6 をコピーして環境ごとに用意しておく
- 稼働中にどうしても変更したい場合に備えて
Slide 20
Slide 20 text
Aurora 移行
Slide 21
Slide 21 text
移行概要
- MySQL 5.5 on EC2 -> Aurora に移行
- データ量を削減した「レポート DB」を「メイン DB」に統合
- 移行を「5フェーズ」に分類した
- システムメンテナンスあり
Slide 22
Slide 22 text
app
db
(master)
Read / Write
batch
日次 mysqldump
db
(report)
db
(slave)
Read / Write
レプリ
Read
Read
フェーズ1
リストア
リストア
S3
Aurora Reader Aurora Reader
同期
Aurora Writer
.dump.sql
Slide 23
Slide 23 text
app
db
(master)
Read / Write
batch
db
(report)
Aurora Reader
Read / Write
Aurora Reader
レプリ
同期
Read
Read
フェーズ2
多段レプリ
Aurora Writer
db
(slave)
レプリ
Slide 24
Slide 24 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 25
Slide 25 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 26
Slide 26 text
app
Read /
Write
batch
Aurora Writer
Aurora Reader
Read / Write
Aurora Reader
同期
Read
Amazon ES
+ Kibana
aggregator
Redash
スロークエリ集計
分析
フェーズ5
最終型
Slide 27
Slide 27 text
Aurora 移行後の効果
Slide 28
Slide 28 text
効果
- クエリパフォーマンスの向上
- スロークエリを可視化できるように
- データドリブンな意思決定ができるように
Slide 29
Slide 29 text
クエリパフォーマンスの向上
- 発行回数 TOP 5 のクエリ全てが2倍以上のパフォーマンスに
- SELECT 系 (単一テーブル, JOIN など)
- NewRelic で計測している
- Aurora スゴイ
Slide 30
Slide 30 text
スロークエリを可視化できるように
- fluent-plugin-rds-slowlog と
fluent-plugin-aws-elasticsearch-service を使って
スロークエリを Amazon ES Kibana で可視化できるようにした
- 事前にパラメータグループで設定しておく
Slide 31
Slide 31 text
データドリブンな意思決定ができるように
- 分析用の Aurora Reader を立てたことにより,
サービス影響を気にせずにクエリを発行できるようになった
- 新しく Redash を導入したことにより,
KPI など, データドリブンな意思決定ができるようになった
( ダッシュボード 27個 ) ( クエリ 146個 )
Slide 32
Slide 32 text
忘れてはいけないこと
Slide 33
Slide 33 text
Aurora は「銀の弾丸」ではない
Slide 34
Slide 34 text
忘れてはいけないこと
- 全てのクエリパフォーマンスが向上するわけではない
- 手動で全機能テストを実施して, 問題ないことを確認した
- 障害時に無停止でフェールオーバーができるわけではない
- ALTER SYSTEM CRASH で障害シュミレーションをして
障害時の動作確認をした
Slide 35
Slide 35 text
忘れてはいけないこと
- 無停止でバージョンアップが行えるわけではない
- 戦略的にメンテナンスを選択する気持ちを大切に
- 定期的にバージョンアップが行えるような組織文化を作る
- データベースも定期的に健康診断が必要
Slide 36
Slide 36 text
まとめ
Slide 37
Slide 37 text
まとめ
- Makuake を支える新基盤として Aurora を採用した
- MySQL 5.5 on EC2 から多段レプリを活用した
移行フローで, 完璧に移行ができた
- クエリパフォーマンスが2倍以上も改善した
- データドリブンな組織文化を築けたのも Aurora のスゴさ
Slide 38
Slide 38 text
詳しくは CyberAgent Developers Blog に！
https://developers.cyberagent.co.jp/blog/archives/6588/