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
俺たちの!パフォーマンス計測
Search
trunkatree
February 10, 2020
Programming
0
870
俺たちの!パフォーマンス計測
20200210 LLRエンジニア交流会 LT資料
trunkatree
February 10, 2020
Tweet
Share
More Decks by trunkatree
See All by trunkatree
Terraform Workspacesの弱点をcountやmovedでカバーしつつ開発を進めた話
trunkatree
0
150
Other Decks in Programming
See All in Programming
Parallel Socket Communication in Swift
s_shimotori
0
260
Data Contracts In Practice With Debezium and Apache Flink (Kafka Summit London)
gunnarmorling
2
280
WebComponentsで フレームワークを1ページに共存させる
webuilder240
0
150
The Future of C++ Interoperability: Insights from Porting a Game to Swift
teamhimeh
0
290
CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection
hiro_y
25
15k
PHPerKaigi 2024〜10年以上動いているレガシーなバッチシステムを Kubernetes(Amazon EKS) に移行する取り組み〜
tshinowpub
1
220
イベントストーミングによるオブジェクトモデリング・オブジェクト指向プログラミングの適用・開発プロセスの変遷・アーキテクチャの変革 / Object modeling with Event Storming.
nrslib
12
3.2k
htmx is fun!
codehex
2
190
TCA魔法学入門🪄
dazy
0
280
チームでモデリングを育てるうえで 考えたこと・気づいたこと / Cultivating Modeling in Teams: Thoughts and Insights
mackey0225
5
2.5k
孤独のCTOグルメという やや奇抜な企画をやった目的と効果
shoheimitani
3
1k
Enhancing Applications with Accessibility API
kishikawakatsumi
3
1k
Featured
See All Featured
A better future with KSS
kneath
230
16k
jQuery: Nuts, Bolts and Bling
dougneiner
57
7.1k
Mobile First: as difficult as doing things right
swwweet
215
8.5k
Web development in the modern age
philhawksworth
201
10k
In The Pink: A Labor of Love
frogandcode
137
21k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
6
950
YesSQL, Process and Tooling at Scale
rocio
160
13k
KATA
mclloyd
14
11k
Fontdeck: Realign not Redesign
paulrobertlloyd
75
4.8k
Pencils Down: Stop Designing & Start Developing
hursman
115
11k
How To Stay Up To Date on Web Technology
chriscoyier
781
250k
How GitHub (no longer) Works
holman
301
140k
Transcript
俺たちの!パフォーマンス計測 2020.02.10 LLRエンジニア交流会 LT
遠藤 幹太 Mikita Endoh / @trunkatree 株式会社ROBOT PAYMENT / SRE
Team - 北の自然が好きです
もちろん パフォーマンス 計測してます
None
None
None
レスポンスタイム グラフ あります
None
でも、 これって 本当にあてになるの?
なぜそう思うか →
- ユーザーの利用頻度は一定じゃない - 月末月初が多い、など - 機能によってバラツキがある - よく使われるところ、たまにしか使われないところ - パフォーマンス性能にもバラツキがある
- オプション機能がいろいろある - 使う企業、使わない企業
- パフォーマンスの良くない機能が使われたからメトリクスが悪化した? - 何かよくない原因があってメトリクスが悪化した? - 一部機能を使った一部ユーザーに対してだけレスポンスが悪い? - 全体的にレスポンスが悪い? - パフォーマンス改善施策をリリースしたけど、結果どうなったの?
実際のところどうなの?
より ユーザーに寄り添った 計測がしたい!
→
各webトランザクションごとのメトリクスを確認できる
今どういう状況か? は、これを見ればいいね!
New Relic の細かいメトリクスは1週間ほどしか保存されない
では 中長期的な推移は?
じゃあ 自分たちで 保存しておこう
ということで、 簡単に つくりました →
New Relic のAPIからメトリクスをとってきて RDS に保存
- monitorサーバで cron で日次でシェルスクリプトを動かしています - 今はRDBに保存していますが、時系列DBなども考えていきたいです
日次で、各webトランザクションごとの - リクエスト数 - Apdex(ユーザー満足度) - レスポンスタイム - 標準偏差 -
5パーセンタイル - 50パーセンタイル - 90パーセンタイル - 95パーセンタイル - 99パーセンタイル をとってきて保存
今は で見れます
今後、うまいこと可視化していきたいですね - ヒートマップをつくる? - どこがよくないのか? が視覚的にわかりやすい - いい感じのパフォーマンス指標をつくる、算出する - これを見ればわかる!
というような
etc. - 全ユーザーが使う機能だけを対象にパフォーマンス指標を算出する - 日常的に使われる機能だけを対象にパフォーマンス指標を算出する - 中長期的な推移を観測し傾向を把握する - パフォーマンス改善施策をリリースした際に、結果どうだったか -
どの機能にどう影響が出ているかを把握する
厳密に言えば、 「SLO」は ユーザー体験を正確に表現 できていないと意味がない
こういった 細かい計測が必要 なのではないでしょうか?
Thank you. We are hiring !