Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CrowdWorksを支える管理画面 - 管理画面チラ見せ♡ナイト #5
Search
Akira Yumiyama
August 21, 2017
Technology
0
1.6k
CrowdWorksを支える管理画面 - 管理画面チラ見せ♡ナイト #5
管理画面チラ見せ♡ナイト #5
https://admin-chiramise-night.connpass.com/event/63870/
の「CrowdWorksを支える管理画面」登壇資料です
Akira Yumiyama
August 21, 2017
Tweet
Share
More Decks by Akira Yumiyama
See All by Akira Yumiyama
GAE/Python2 to Python3 Migration Journey
akiray03
0
1.6k
オブジェクト指向で考える アプリケーションアーキテクチャ設計 / Object-Oriented Conference 2020
akiray03
6
21k
Terraform Introduction
akiray03
0
94
Case Study of Machine Learning in CrowdWorks
akiray03
0
2k
DevSumi2015 19-D-2 IIJ社内におけるアジャイル開発、DevOpsへの取り組み
akiray03
0
430
mruby introduction -- jinbocho.rb #01
akiray03
9
1.2k
Other Decks in Technology
See All in Technology
FastMCPでSQLをチェックしてくれるMCPサーバーを自作してCursorから動かしてみた
nayuts
1
190
Slackひと声でブログ校正!Claudeレビュー自動化編
yusukeshimizu
3
150
会社員しながら本を書いてきた知見の共有
sat
PRO
3
680
Cloud Run を解剖して コンテナ監視を考える / Breaking Down Cloud Run to Rethink Container Monitoring
aoto
PRO
0
110
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.2k
Eight Engineering Unit 紹介資料
sansan33
PRO
0
3.2k
Houtou.pm #1
papix
0
650
LT:組込み屋さんのオシロが壊れた!
windy_pon
0
330
オープンソースのハードウェアのコンテストに参加している話
iotengineer22
0
510
RDRA3.0を知ろう
kanzaki
2
430
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
220
Streamline Cloud-Native App Development Using CDEs
saeedzf
0
690
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
298
21k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
The Cost Of JavaScript in 2023
addyosmani
49
8k
How to train your dragon (web standard)
notwaldorf
92
6k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
32
5.8k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Balancing Empowerment & Direction
lara
1
83
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Transcript
Admin Night #5 - CrowdWorks / CrowdWorksを支える 管理画面 CrowdWorks CTO
弓山彬 @akiray03 (Twitter, GitHub) 2017/08/21 管理画面チラ見せ♡ナイト #5
CrowdWorksについて
None
None
今日のテーマは...
None
ユーザーサポート管理画面 サービスKPI管理画面
ユーザーサポート管理画面 サービスKPI管理画面 今日はこっちの話
CrowdWorksを支える サービスKPI管理画面 2017/08/21 管理画面チラ見せ♡ナイト #5 歴史探訪
【初代KPI管理画面】 をチラ見せ!
None
ユーザーが大量に増える前にすべきこと > サービス開発時のリソースの半分は、管理画面に割く こと。 http://www.attackers-school.com/startup_news/event/989/ サービスリリース前に管理画面上でKPIを200個ぐらい私が設計し、その全てのKPI をずっと監視していました。200個は非常に単純なファンネル(動線)です。クライア ントが会員登録をして発注する仕事を登録し、その仕事に応募がどれだけ来て、契 約率が何%で、単価が幾らで、リピート率がいくつで……という指標を追っていまし た。
https://ferret-plus.com/7612
初代KPI管理画面 • サービス本体に同居していた • CrowdWorksはRails+MySQLで作られている ◦ KPI集計ロジックもActiveRecord + MySQL •
構成 ◦ #{RAILS_ROOT}/script 配下にバッチ起動スクリプトがあって ◦ 集計モデルが呼び出され ◦ いろんな Scope を使って、 Arel の DSL を駆使して、集計クエリを作り ◦ 得られた結果をまとめてデータベースに保存する ◦ 集計結果は管理画面で見えるようになっている
None
集計遅すぎ問題
初代KPI管理画面:課題 • 集計遅すぎ問題 ◦ 集計処理: 2時間弱 →(半年)→ 4時間超 ◦ 1項目につき1つのクエリ実行
◦ クエリは Arel DSL を駆使して作られている( SQLが想像できない...) ◦ 項目によっては多段 JOIN したり、重いサブクエリが何度も実行されたりする ◦ 集計時間が伸びすぎたので、 Thread を使ってクエリを並列実行してみたりしちゃった ◦ クエリの一部分をRubyで再実装してみたり ▪ (微妙な条件違いのクエリ多数だと早くなることもある、かも。) ◦ ...
初代KPI管理画面:課題 • 集計遅すぎ問題 ◦ 集計処理: 2時間弱 →(半年)→ 4時間超 ◦ 1項目につき1つのクエリ実行
◦ クエリは Arel DSL を駆使して作られている( SQLが想像できない...) ◦ 項目によっては多段 JOIN したり、重いサブクエリが何度も実行されたりする ◦ 集計時間が伸びすぎたので、 Thread を使ってクエリを並列実行してみたりしちゃった ◦ クエリの一部分をRubyで再実装してみたり ▪ (微妙な条件違いのクエリ多数だと早くなることもある、かも。) ◦ ... これ、もうメンテするの無理だよね?
振り返る
初代KPI管理画面:振り返り • サービスのリリース時点からKPI計測・改善サイクルを実現するのは大事 • サービス初期にサービス本体とKPI用プロダクトの2つをメンテナンスするのも大変 なので、1つにしたい気持ちもわかる。わかるけど。。 • メンテナンス性、スケーラビリティの点では課題もあった • ActiveRecord(のようなO/R
Mapper)で集計処理を組むのは絶対やめよう • 集計項目が頻繁に変化するからといって、YAMLシリアライズして1カラムにデータ 突っ込むのはやっちゃダメ
【二代目KPI管理画面】 をチラ見せ!
None
DWH (Amazon Redshift) + Google Spreadsheet
Amazon Redshift Amazon RDS (MySQL) 集計処理 サーバ (EC2) Google Spreadsheet
• MySQLからRedshiftへ KPI集計に必要なデータを同期 • 集計クエリは全て書き直し • SQLバッチフレームワークを導入 集計結果を定期的に Google Spreadsheet へエクスポート
Amazon Redshift Amazon RDS (MySQL) 集計処理 サーバ (EC2) Google Spreadsheet
• MySQLからRedshiftへ KPI集計に必要なデータを同期 • 集計クエリは全て書き直し • SQLバッチフレームワークを導入 集計結果を定期的に Google Spreadsheet へエクスポート 表形式、生の数値データを見れる レポート形式への強いこだわり
二代目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 ◦ → 依存関係も見通しよくなり、メンテナンス性を担保
二代目KPI画面:課題 • Google Spreadsheetツライ ◦ データ量が増えると処理時間伸びる ◦ 処理可能なデータ量に上限がある (端末によってエラーが稀に起きる) ◦
関数を間違えて書き換えるとツライ ◦ バージョン管理もツライ • チーム/施策ごとのモニタリングがツライ ◦ 事業共通のKPIに項目足すのが大変&処理重くなる ◦ クエリ実行→手作業でSpreadsheet貼り付け→グラフ化 … ◦ チームごとに独自ツールが増えていく ...
【三代目KPI管理画面】 をチラ見せ!
None
None
導入による変化
導入による変化 • 多くのクエリ・グラフが作られるよう になった • 既存クエリの活用で広まっていっ た (30%がfork作成)
Redshift CPU使用率 右肩上がり
Redshift CPU使用率 右肩上がり CPU埋まりすぎて データ同期が遅延 するようになった... Redashのクエリが増えすぎて Redshift障害に(´・ω・`)
三代目KPI管理画面:今後 • 利用中は Re:dash 0.12 (Redash 2.0.0 への更新を計画中) ◦ データソースの追加
(Google Analytics, Salesforce, …) • 従来:利用者・用途ごとにRedashサーバを用意 ◦ アドホックな分析用、 KPI定常モニタリング用、 ... • 今後:MULTI_ORG機能を活用して、権限分離と利便性を両立していきたい ◦ ORGごとに利用可能ユーザの制限 + データソースの区分で権限分離を実現 ◦ 例:Salesforceや個人情報入りのDBへの接続ユーザは限定したい ◦ 例:マスク済み情報に対しては、多くの社員に接続を許可したい
まとめ
まとめ • 「CrowdWorksを支えるサービスKPI管理画面」の歴史を巡ってきました • サービスの向こう側にいるユーザを知るためにも、 さまざまな観点で分析可能な基盤を作っておくことは重要 • データ量の増加に伴ってスケールしづらくなるので、 (可能なら)早めに手を打っておきましょう :|
• サービスを成長させていく・変化させていくうえでの鍵になるのは、 「どれだけ多くの人に対して、データにアクセスしやすい状況を提供できるか」 ◦ 自分たちで作る管理画面と、 Redashなどのツールを適切に使っていきましょう :)
None