Makuake の急成長を支える Aurora 移行事例 / AWS Solution Days 2017

Transcript

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