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

Slide 1

Slide 1 text

Admin Night #5 - CrowdWorks / CrowdWorksを支える管理画面 CrowdWorks CTO 弓山彬 @akiray03 (Twitter, GitHub) 2017/08/21 管理画面チラ見せ♡ナイト #5

Slide 2

Slide 2 text

CrowdWorksについて

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

今日のテーマは...

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

ユーザーサポート管理画面サービスKPI管理画面

Slide 8

Slide 8 text

ユーザーサポート管理画面サービスKPI管理画面今日はこっちの話

Slide 9

Slide 9 text

CrowdWorksを支えるサービスKPI管理画面 2017/08/21 管理画面チラ見せ♡ナイト #5 歴史探訪

Slide 10

Slide 10 text

【初代KPI管理画面】をチラ見せ！

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

ユーザーが大量に増える前にすべきこと > サービス開発時のリソースの半分は、管理画面に割くこと。 http://www.attackers-school.com/startup_news/event/989/ サービスリリース前に管理画面上でKPIを200個ぐらい私が設計し、その全てのKPI をずっと監視していました。200個は非常に単純なファンネル（動線）です。クライアントが会員登録をして発注する仕事を登録し、その仕事に応募がどれだけ来て、契約率が何％で、単価が幾らで、リピート率がいくつで……という指標を追っていました。 https://ferret-plus.com/7612

Slide 13

Slide 13 text

初代KPI管理画面 ● サービス本体に同居していた ● CrowdWorksはRails+MySQLで作られている ○ KPI集計ロジックもActiveRecord + MySQL ● 構成 ○ #{RAILS_ROOT}/script 配下にバッチ起動スクリプトがあって ○ 集計モデルが呼び出され ○ いろんな Scope を使って、 Arel の DSL を駆使して、集計クエリを作り ○ 得られた結果をまとめてデータベースに保存する ○ 集計結果は管理画面で見えるようになっている

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

集計遅すぎ問題

Slide 16

Slide 16 text

初代KPI管理画面：課題 ● 集計遅すぎ問題 ○ 集計処理: 2時間弱 →(半年)→ 4時間超 ○ 1項目につき1つのクエリ実行 ○ クエリは Arel DSL を駆使して作られている（ SQLが想像できない...） ○ 項目によっては多段 JOIN したり、重いサブクエリが何度も実行されたりする ○ 集計時間が伸びすぎたので、 Thread を使ってクエリを並列実行してみたりしちゃった ○ クエリの一部分をRubyで再実装してみたり ■ （微妙な条件違いのクエリ多数だと早くなることもある、かも。） ○ ...

Slide 17

Slide 17 text

Slide 18

Slide 18 text

振り返る

Slide 19

Slide 19 text

初代KPI管理画面：振り返り ● サービスのリリース時点からKPI計測・改善サイクルを実現するのは大事 ● サービス初期にサービス本体とKPI用プロダクトの２つをメンテナンスするのも大変なので、１つにしたい気持ちもわかる。わかるけど。。 ● メンテナンス性、スケーラビリティの点では課題もあった ● ActiveRecord(のようなO/R Mapper)で集計処理を組むのは絶対やめよう ● 集計項目が頻繁に変化するからといって、YAMLシリアライズして1カラムにデータ突っ込むのはやっちゃダメ

Slide 20

Slide 20 text

【二代目KPI管理画面】をチラ見せ！

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

DWH (Amazon Redshift) + Google Spreadsheet

Slide 23

Slide 23 text

Amazon Redshift Amazon RDS (MySQL) 集計処理サーバ (EC2) Google Spreadsheet ● MySQLからRedshiftへ KPI集計に必要なデータを同期 ● 集計クエリは全て書き直し ● SQLバッチフレームワークを導入集計結果を定期的に Google Spreadsheet へエクスポート

Slide 24

Slide 24 text

Slide 25

Slide 25 text

二代目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 ○ → 依存関係も見通しよくなり、メンテナンス性を担保

Slide 26

Slide 26 text

二代目KPI画面：課題 ● Google Spreadsheetツライ ○ データ量が増えると処理時間伸びる ○ 処理可能なデータ量に上限がある（端末によってエラーが稀に起きる） ○ 関数を間違えて書き換えるとツライ ○ バージョン管理もツライ ● チーム／施策ごとのモニタリングがツライ ○ 事業共通のKPIに項目足すのが大変＆処理重くなる ○ クエリ実行→手作業でSpreadsheet貼り付け→グラフ化 … ○ チームごとに独自ツールが増えていく ...

Slide 27

Slide 27 text

【三代目KPI管理画面】をチラ見せ！

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

導入による変化

Slide 31

Slide 31 text

導入による変化 ● 多くのクエリ・グラフが作られるようになった ● 既存クエリの活用で広まっていった (30%がfork作成)

Slide 32

Slide 32 text

Redshift CPU使用率右肩上がり

Slide 33

Slide 33 text

Redshift CPU使用率右肩上がり CPU埋まりすぎてデータ同期が遅延するようになった... Redashのクエリが増えすぎて Redshift障害に(´・ω・｀)

Slide 34

Slide 34 text

三代目KPI管理画面：今後 ● 利用中は Re:dash 0.12 (Redash 2.0.0 への更新を計画中) ○ データソースの追加 (Google Analytics, Salesforce, …) ● 従来：利用者・用途ごとにRedashサーバを用意 ○ アドホックな分析用、 KPI定常モニタリング用、 ... ● 今後：MULTI_ORG機能を活用して、権限分離と利便性を両立していきたい ○ ORGごとに利用可能ユーザの制限＋データソースの区分で権限分離を実現 ○ 例：Salesforceや個人情報入りのDBへの接続ユーザは限定したい ○ 例：マスク済み情報に対しては、多くの社員に接続を許可したい

Slide 35

Slide 35 text

まとめ

Slide 36

Slide 36 text

まとめ ● 「CrowdWorksを支えるサービスKPI管理画面」の歴史を巡ってきました ● サービスの向こう側にいるユーザを知るためにも、さまざまな観点で分析可能な基盤を作っておくことは重要 ● データ量の増加に伴ってスケールしづらくなるので、（可能なら）早めに手を打っておきましょう :| ● サービスを成長させていく・変化させていくうえでの鍵になるのは、「どれだけ多くの人に対して、データにアクセスしやすい状況を提供できるか」 ○ 自分たちで作る管理画面と、 Redashなどのツールを適切に使っていきましょう :)

Slide 37

Slide 37 text

No content