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
22k
Terraform Introduction
akiray03
0
110
Case Study of Machine Learning in CrowdWorks
akiray03
0
2k
DevSumi2015 19-D-2 IIJ社内におけるアジャイル開発、DevOpsへの取り組み
akiray03
0
440
mruby introduction -- jinbocho.rb #01
akiray03
9
1.2k
Other Decks in Technology
See All in Technology
ZOZOのAI活用実践〜社内基盤からサービス応用まで〜
zozotech
PRO
0
150
From Prompt to Product @ How to Web 2025, Bucharest, Romania
janwerner
0
110
Pythonによる契約プログラミング入門 / PyCon JP 2025
7pairs
5
2.5k
DataOpsNight#8_Terragruntを用いたスケーラブルなSnowflakeインフラ管理
roki18d
1
320
AI ReadyなData PlatformとしてのAutonomous Databaseアップデート
oracle4engineer
PRO
0
150
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
10
4.3k
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
290
インサイト情報からどこまで自動化できるか試してみた
takas0522
0
140
pprof vs runtime/trace (FlightRecorder)
task4233
0
150
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
5.4k
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
330
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
54
3k
How to Think Like a Performance Engineer
csswizardry
27
2k
Mobile First: as difficult as doing things right
swwweet
224
9.9k
Designing Experiences People Love
moore
142
24k
We Have a Design System, Now What?
morganepeng
53
7.8k
The World Runs on Bad Software
bkeepers
PRO
71
11k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
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