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.4k
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.5k
オブジェクト指向で考える アプリケーションアーキテクチャ設計 / Object-Oriented Conference 2020
akiray03
6
19k
Terraform Introduction
akiray03
0
78
Case Study of Machine Learning in CrowdWorks
akiray03
0
1.9k
DevSumi2015 19-D-2 IIJ社内におけるアジャイル開発、DevOpsへの取り組み
akiray03
0
390
mruby introduction -- jinbocho.rb #01
akiray03
9
1.1k
Other Decks in Technology
See All in Technology
「家族アルバム みてね」における運用管理・ オブザーバビリティの全貌 / Overview of Operation Management and Observability in FamilyAlbum
isaoshimizu
4
160
不動産 x AIことはじめ~データの真価を拓くために
estie
0
120
サーバレスでモバイルアプリ開発! NTTコム「ビジネスdアプリ」のアーキテクチャ / The architecture of business d app
nttcom
12
250
Segment Anything Model 2
tenten0727
3
720
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
140
可視化により内部品質をあげるAIドキュメントリバース/20240910 Hiromitsu Akiba
shift_evolve
0
230
DroidKaigi 2024 たすけて!ViewModel
mhidaka
5
960
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
46k
Creative UIs with Compose: DroidKaigi 2024
chrishorner
1
600
o1のAPIで実験してみたが 制限きつすぎて辛かった話
pharma_x_tech
0
220
公共交通データとアプリ制作 - Mini Tokyo 3D の初期制作過程を振り返る
nagix
0
100
AI活用したくてもできなかった不動産SaaSの今とこれから
nealle
0
340
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
41
6.5k
Pencils Down: Stop Designing & Start Developing
hursman
119
11k
Making the Leap to Tech Lead
cromwellryan
128
8.8k
Side Projects
sachag
451
42k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
43
2k
Navigating Team Friction
lara
183
13k
Scaling GitHub
holman
458
140k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
1
55
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
36
2.1k
What the flash - Photography Introduction
edds
67
11k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
158
15k
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