俺たちの！パフォーマンス計測

20200210 LLRエンジニア交流会 LT資料

Transcript

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