Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Yoshiaki Yoshida

July 05, 2017
Tweet

More Decks by Yoshiaki Yoshida

Other Decks in Technology

Transcript

  1. 吉田 慶章 @kakakakakku - CyberAgent Crowd Funding, Inc. - 開発本部所属

    - DevOps エンジニア & サーバサイドエンジニア - エンジニアリングマネージャー - 趣味 : 技術ブログを毎週書くこと - http://kakakakakku.hatenablog.com/
  2. 課題感 - RDS ではなく MySQL 5.5 on EC2 を運用していた -

    サービスをリリースしてから, 1度も止まらずに稼働していた - uptime 1000 days 以上 ( ゚д゚)!!! - ボトルネックになる「アーキテクチャの課題」と「運用の課題」 - サービスの急成長を支える新基盤にリプレイスを検討していた
  3. 「アーキテクチャの課題」と「運用の課題」 - 「アーキテクチャの課題」 - フェールオーバーができなかった ( MHA などの考慮なし ) -

    バージョンアップが難しかった - 1TB 以上の EBS (Magnetic) がアタッチされていた - 「運用面の課題」 - 重い分析クエリが発行されてスレーブが高負荷になっていた - スロークエリを確認するために, 直接サーバに接続していた
  4. なぜ Aurora を採用したのか - クエリパフォーマンスの高さ - Auto Scaling ストレージ (10

    GB 単位) - 限りなくゼロに近い, Reader のレプリカラグ - 高速なフェイルオーバー - MySQL 5.6 完全互換
  5. データ削減 - 思っている以上に, 不要なデータが大量に残っている (はず) - データ削減をすると, データ見積もりが容易になる - さらに,

    データ移行時間を短くできるなど様々なメリットがある - 実績 - 約20テーブルを削除した - 不要なレポート系のデータを約1000万レコード削除した
  6. 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
  7. パラメータグループのコツ - 「適用タイプ : static」のパラメータを最優先に考える - 反映に再起動が必要になるため - 基本的にはデフォルト値のまま使う -

    Aurora Team がチューニングして厳選した値のため - default.aurora5.6 をコピーして環境ごとに用意しておく - 稼働中にどうしても変更したい場合に備えて
  8. 移行概要 - MySQL 5.5 on EC2 -> Aurora に移行 -

    データ量を削減した「レポート DB」を「メイン DB」に統合 - 移行を「5フェーズ」に分類した - システムメンテナンスあり
  9. 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
  10. app db (master) Read / Write batch db (report) Aurora

    Reader Read / Write Aurora Reader レプリ 同期 Read Read フェーズ2 多段レプリ Aurora Writer db (slave) レプリ
  11. app db (master) Read / Write batch db (report) db

    (slave) Read / Write Aurora Reader レプリ レプリ Read フェーズ3 Reader Read 同期 参照系を Aurora にする Aurora Writer Aurora Reader
  12. app db (master) batch db (report) db (slave) Aurora Reader

    Aurora Reader レプリ レプリ 同期 Read メンテナンス = 更新なし メンテナンス = 更新なし mysqldump を 直接流し込む (DB 統一) フェーズ4 Writer Read / Write Aurora Writer Read / Write
  13. app Read / Write batch Aurora Writer Aurora Reader Read

    / Write Aurora Reader 同期 Read Amazon ES + Kibana aggregator Redash スロークエリ集計 分析 フェーズ5 最終型
  14. データドリブンな意思決定ができるように - 分析用の Aurora Reader を立てたことにより,
 サービス影響を気にせずにクエリを発行できるようになった - 新しく Redash

    を導入したことにより,
 KPI など, データドリブンな意思決定ができるようになった ( ダッシュボード 27個 ) ( クエリ 146個 )
  15. まとめ - Makuake を支える新基盤として Aurora を採用した - MySQL 5.5 on

    EC2 から多段レプリを活用した
 移行フローで, 完璧に移行ができた - クエリパフォーマンスが2倍以上も改善した - データドリブンな組織文化を築けたのも Aurora のスゴさ