Slide 1
Slide 1 text
俺たちの！パフォーマンス計測
2020.02.10 LLRエンジニア交流会 LT
Slide 2
Slide 2 text
遠藤 幹太 Mikita Endoh / @trunkatree
株式会社ROBOT PAYMENT / SRE Team
- 北の自然が好きです
Slide 3
Slide 3 text
もちろん
パフォーマンス
計測してます
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
レスポンスタイム
グラフ
あります
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
でも、
これって
本当にあてになるの？
Slide 10
Slide 10 text
なぜそう思うか →
Slide 11
Slide 11 text
- ユーザーの利用頻度は一定じゃない
- 月末月初が多い、など
- 機能によってバラツキがある
- よく使われるところ、たまにしか使われないところ
- パフォーマンス性能にもバラツキがある
- オプション機能がいろいろある
- 使う企業、使わない企業
Slide 12
Slide 12 text
- パフォーマンスの良くない機能が使われたからメトリクスが悪化した？
- 何かよくない原因があってメトリクスが悪化した？
- 一部機能を使った一部ユーザーに対してだけレスポンスが悪い？
- 全体的にレスポンスが悪い？
- パフォーマンス改善施策をリリースしたけど、結果どうなったの？
Slide 13
Slide 13 text
実際のところどうなの？
Slide 14
Slide 14 text
より
ユーザーに寄り添った
計測がしたい！
Slide 15
Slide 15 text
→
Slide 16
Slide 16 text
各webトランザクションごとのメトリクスを確認できる
Slide 17
Slide 17 text
今どういう状況か？
は、これを見ればいいね！
Slide 18
Slide 18 text
New Relic の細かいメトリクスは1週間ほどしか保存されない
Slide 19
Slide 19 text
では
中長期的な推移は？
Slide 20
Slide 20 text
じゃあ
自分たちで
保存しておこう
Slide 21
Slide 21 text
ということで、
簡単に
つくりました →
Slide 22
Slide 22 text
New Relic のAPIからメトリクスをとってきて RDS に保存
Slide 23
Slide 23 text
- monitorサーバで cron で日次でシェルスクリプトを動かしています
- 今はRDBに保存していますが、時系列DBなども考えていきたいです
Slide 24
Slide 24 text
日次で、各webトランザクションごとの
- リクエスト数
- Apdex（ユーザー満足度）
- レスポンスタイム
- 標準偏差
- 5パーセンタイル
- 50パーセンタイル
- 90パーセンタイル
- 95パーセンタイル
- 99パーセンタイル
をとってきて保存
Slide 25
Slide 25 text
今は で見れます
Slide 26
Slide 26 text
今後、うまいこと可視化していきたいですね
- ヒートマップをつくる？
- どこがよくないのか？ が視覚的にわかりやすい
- いい感じのパフォーマンス指標をつくる、算出する
- これを見ればわかる！ というような
Slide 27
Slide 27 text
etc.
- 全ユーザーが使う機能だけを対象にパフォーマンス指標を算出する
- 日常的に使われる機能だけを対象にパフォーマンス指標を算出する
- 中長期的な推移を観測し傾向を把握する
- パフォーマンス改善施策をリリースした際に、結果どうだったか
- どの機能にどう影響が出ているかを把握する
Slide 28
Slide 28 text
厳密に言えば、
「SLO」は
ユーザー体験を正確に表現
できていないと意味がない
Slide 29
Slide 29 text
こういった
細かい計測が必要
なのではないでしょうか？
Slide 30
Slide 30 text
Thank you.
We are hiring !