CrowdWorksを支える管理画面 - 管理画面チラ見せ♡ナイト #5

管理画面チラ見せ♡ナイト #5 https://admin-chiramise-night.connpass.com/event/63870/ の「CrowdWorksを支える管理画面」登壇資料です

Transcript

1. Admin Night #5 - CrowdWorks / CrowdWorksを支える 管理画面 CrowdWorks CTO 弓山彬 @akiray03 (Twitter, GitHub) 2017/08/21 管理画面チラ見せ♡ナイト #5
2. CrowdWorksについて
5. 今日のテーマは...
7. ユーザーサポート管理画面 サービスKPI管理画面
8. ユーザーサポート管理画面 サービスKPI管理画面 今日はこっちの話
9. CrowdWorksを支える サービスKPI管理画面 2017/08/21 管理画面チラ見せ♡ナイト #5 歴史探訪
10. 【初代KPI管理画面】 をチラ見せ！
12. ユーザーが大量に増える前にすべきこと > サービス開発時のリソースの半分は、管理画面に割く こと。 http://www.attackers-school.com/startup_news/event/989/ サービスリリース前に管理画面上でKPIを200個ぐらい私が設計し、その全てのKPI をずっと監視していました。200個は非常に単純なファンネル（動線）です。クライア ントが会員登録をして発注する仕事を登録し、その仕事に応募がどれだけ来て、契 約率が何％で、単価が幾らで、リピート率がいくつで……という指標を追っていまし た。 https://ferret-plus.com/7612
13. 初代KPI管理画面 • サービス本体に同居していた • CrowdWorksはRails+MySQLで作られている ◦ KPI集計ロジックもActiveRecord + MySQL • 構成 ◦ #{RAILS_ROOT}/script 配下にバッチ起動スクリプトがあって ◦ 集計モデルが呼び出され ◦ いろんな Scope を使って、 Arel の DSL を駆使して、集計クエリを作り ◦ 得られた結果をまとめてデータベースに保存する ◦ 集計結果は管理画面で見えるようになっている
15. 集計遅すぎ問題
16. 初代KPI管理画面：課題 • 集計遅すぎ問題 ◦ 集計処理: 2時間弱 →(半年)→ 4時間超 ◦ 1項目につき1つのクエリ実行 ◦ クエリは Arel DSL を駆使して作られている（ SQLが想像できない...） ◦ 項目によっては多段 JOIN したり、重いサブクエリが何度も実行されたりする ◦ 集計時間が伸びすぎたので、 Thread を使ってクエリを並列実行してみたりしちゃった ◦ クエリの一部分をRubyで再実装してみたり ▪ （微妙な条件違いのクエリ多数だと早くなることもある、かも。） ◦ ...
17. 初代KPI管理画面：課題 • 集計遅すぎ問題 ◦ 集計処理: 2時間弱 →(半年)→ 4時間超 ◦ 1項目につき1つのクエリ実行 ◦ クエリは Arel DSL を駆使して作られている（ SQLが想像できない...） ◦ 項目によっては多段 JOIN したり、重いサブクエリが何度も実行されたりする ◦ 集計時間が伸びすぎたので、 Thread を使ってクエリを並列実行してみたりしちゃった ◦ クエリの一部分をRubyで再実装してみたり ▪ （微妙な条件違いのクエリ多数だと早くなることもある、かも。） ◦ ... これ、もうメンテするの無理だよね？
18. 振り返る
19. 初代KPI管理画面：振り返り • サービスのリリース時点からKPI計測・改善サイクルを実現するのは大事 • サービス初期にサービス本体とKPI用プロダクトの２つをメンテナンスするのも大変 なので、１つにしたい気持ちもわかる。わかるけど。。 • メンテナンス性、スケーラビリティの点では課題もあった • ActiveRecord(のようなO/R Mapper)で集計処理を組むのは絶対やめよう • 集計項目が頻繁に変化するからといって、YAMLシリアライズして1カラムにデータ 突っ込むのはやっちゃダメ
20. 【二代目KPI管理画面】 をチラ見せ！
22. DWH (Amazon Redshift) + Google Spreadsheet
23. Amazon Redshift Amazon RDS (MySQL) 集計処理 サーバ (EC2) Google Spreadsheet • MySQLからRedshiftへ KPI集計に必要なデータを同期 • 集計クエリは全て書き直し • SQLバッチフレームワークを導入 集計結果を定期的に Google Spreadsheet へエクスポート
24. Amazon Redshift Amazon RDS (MySQL) 集計処理 サーバ (EC2) Google Spreadsheet • MySQLからRedshiftへ KPI集計に必要なデータを同期 • 集計クエリは全て書き直し • SQLバッチフレームワークを導入 集計結果を定期的に Google Spreadsheet へエクスポート 表形式、生の数値データを見れる レポート形式への強いこだわり
25. 二代目KPI画面 • Amazon Redshift すごい！ ◦ Window関数最高！ ◦ WITH句便利！ ◦ MySQLにも早く！ (MySQL 8.0予定?) • 集計時間も短縮 ◦ before: 2〜3時間以上 ◦ after: 10〜20分程度 • SQLバッチフレームワーク: bricolage を導入 ◦ https://github.com/bricolages/bricolage ◦ ジョブ数: 212 / 集計クエリ総行数: 20,542 ◦ → 依存関係も見通しよくなり、メンテナンス性を担保
26. 二代目KPI画面：課題 • Google Spreadsheetツライ ◦ データ量が増えると処理時間伸びる ◦ 処理可能なデータ量に上限がある （端末によってエラーが稀に起きる） ◦ 関数を間違えて書き換えるとツライ ◦ バージョン管理もツライ • チーム／施策ごとのモニタリングがツライ ◦ 事業共通のKPIに項目足すのが大変＆処理重くなる ◦ クエリ実行→手作業でSpreadsheet貼り付け→グラフ化 … ◦ チームごとに独自ツールが増えていく ...
27. 【三代目KPI管理画面】 をチラ見せ！
30. 導入による変化
31. 導入による変化 • 多くのクエリ・グラフが作られるよう になった • 既存クエリの活用で広まっていっ た (30%がfork作成)
32. Redshift CPU使用率 右肩上がり
33. Redshift CPU使用率 右肩上がり CPU埋まりすぎて データ同期が遅延 するようになった... Redashのクエリが増えすぎて Redshift障害に(´・ω・｀)
34. 三代目KPI管理画面：今後 • 利用中は Re:dash 0.12 (Redash 2.0.0 への更新を計画中) ◦ データソースの追加 (Google Analytics, Salesforce, …) • 従来：利用者・用途ごとにRedashサーバを用意 ◦ アドホックな分析用、 KPI定常モニタリング用、 ... • 今後：MULTI_ORG機能を活用して、権限分離と利便性を両立していきたい ◦ ORGごとに利用可能ユーザの制限 ＋ データソースの区分で権限分離を実現 ◦ 例：Salesforceや個人情報入りのDBへの接続ユーザは限定したい ◦ 例：マスク済み情報に対しては、多くの社員に接続を許可したい
35. まとめ
36. まとめ • 「CrowdWorksを支えるサービスKPI管理画面」の歴史を巡ってきました • サービスの向こう側にいるユーザを知るためにも、 さまざまな観点で分析可能な基盤を作っておくことは重要 • データ量の増加に伴ってスケールしづらくなるので、 （可能なら）早めに手を打っておきましょう :| • サービスを成長させていく・変化させていくうえでの鍵になるのは、 「どれだけ多くの人に対して、データにアクセスしやすい状況を提供できるか」 ◦ 自分たちで作る管理画面と、 Redashなどのツールを適切に使っていきましょう :)