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.7k
オブジェクト指向で考える アプリケーションアーキテクチャ設計 / Object-Oriented Conference 2020
akiray03
6
21k
Terraform Introduction
akiray03
0
100
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
20250708オープンエンドな探索と知識発見
sakana_ai
PRO
5
1.2k
「Chatwork」のEKS環境を支えるhelmfileを使用したマニフェスト管理術
hanayo04
1
500
Semantic Machine Intelligence for Vision, Language, and Actions
keio_smilab
PRO
2
360
三視点LLMによる複数観点レビュー
mhlyc
0
260
MCP とマネージド PaaS で実現する大規模 AI アプリケーションの高速開発
nahokoxxx
1
1.2k
Autify Company Deck
autifyhq
2
44k
ClaudeCodeにキレない技術
gtnao
1
940
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
160
Data Engineering Study#30 LT資料
tetsuroito
1
480
スプリントゴール未達症候群に送る処方箋
kakehashi
PRO
1
160
LLM拡張解体新書/llm-extension-deep-dive
oracle4engineer
PRO
27
7.6k
機械学習を「社会実装」するということ 2025年夏版 / Social Implementation of Machine Learning July 2025 Version
moepy_stats
1
200
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
300
21k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Building Applications with DynamoDB
mza
95
6.5k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Optimizing for Happiness
mojombo
379
70k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Building an army of robots
kneath
306
45k
Designing for humans not robots
tammielis
253
25k
YesSQL, Process and Tooling at Scale
rocio
173
14k
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