初めてのパフォーマンス改善

by Fu-ga

Slide 1

Slide 1 text

初めてのパフォーマンス改善～君たちはどう計測するか～ふーが@fugakkbn はかる＠浅草橋ヒューリックホール&カンファレンス 2023.10.27(Fri) - Kaigi on Rails 2023 Day1

Slide 2

Slide 2 text

ふーが永和システムマネジメント Rails エンジニア 2 年生 Asakusa.rbメンバー Kaigi on Rails Organizer @fugakkbn

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

ESM members in venue

Slide 5

Slide 5 text

Rubyメソッド Rubyメソッドキーホルダーキーホルダー専用のコインを永和メンバーから受け取って、ブースでガチャガチャを回してGET! おひとりさま一回まで

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

前提、目的ここではアプリケーションの応答速度を改善するための取り組み全般を「パフォーマンス改善」と呼称します。一連の改善を通してやったこと、考えたことなどを共有主にパフォーマンス改善の経験がない、少ない人が取り組む時に見るべきポイントや気に掛けるべきポイントをお伝えできれば

Slide 9

Slide 9 text

きっかけ 1

Slide 10

Slide 10 text

「レスポンスが悪そうなページと原因を調査して、いい感じに改善して欲しい」とのオーダー 8年ほど稼働しているプロダクト事業成長に伴い、利用者が右肩上がりに増加レスポンスに影響が出始め、利用者からの問い合わせ増ちょうど手が空くタイミングだったのとやったことがない領域だったのでチャレンジも含めて挙手

Slide 11

Slide 11 text

流れ 2

Slide 12

Slide 12 text

「いい感じに」というオーダーにどう応えるか

Slide 13

Slide 13 text

クリティカルな部分があるかもしれないまずは現状を把握したいパフォーマンス劣化は一か所ではないはずリストアップして優先順位を決める必要がありそう

Slide 14

Slide 14 text

全体の調査まずはどのページが遅いのかを洗い出して全体像を把握する。優先順位付け遅いページが判明したら、どこから対応していくべきかを検討する。経過観察リリース後に想定通り速くなっているのか、または劣化してしまっていないかを確認。本格調査、改善個別に原因を調査して改善案を模索する。改善が見込めればリリースする。改善までの道のり

Slide 15

Slide 15 text

全体の調査 3

Slide 16

Slide 16 text

APMはNew Relic RDBMSはOracle アダプターは activerecord-oracle_enhanced-adapter ツールについて

Slide 17

Slide 17 text

まずは全体像を把握したいどのページ、アクションが遅いのか？問い合わせがあったページはどれくらい遅いのか？遅い部分は何が原因っぽいのか？

Slide 18

Slide 18 text

まずは全体像を把握したいどのページ、アクションが遅いのか？遅い部分は何が原因っぽいのか？問い合わせがあったページはどれくらい遅いのか？

Slide 19

Slide 19 text

APMを活用する全体として特に遅いもの create index index

Slide 20

Slide 20 text

ページ、アクション毎の確認

Slide 21

Slide 21 text

ページ、アクション毎の確認

Slide 22

Slide 22 text

Slide 23

Slide 23 text

個別に確認する

Slide 24

Slide 24 text

個別に確認する

Slide 25

Slide 25 text

個別に確認する

Slide 26

Slide 26 text

Slide 27

Slide 27 text

原因の詳細まではこの段階でわからなくても良い

Slide 28

Slide 28 text

原因の詳細まではこの段階でわからなくても良い

Slide 29

Slide 29 text

詳細までは追わない DBの場合は「クエリが遅い」と想像つく原因がよくわからないケース優先順位が決まっていない状態で深追いすると時間だけが溶けていく

Slide 30

Slide 30 text

まずは全体像を把握したいどのページ、アクションが遅いのか？クレームが来ているページはどれくらい遅いのか遅い部分は何が原因っぽいのか？調べたこと、調べたこと、わかったことはわかったことはまとめておくとまとめておくと実際に改善するときに実際に改善するときにべんりべんり

Slide 31

Slide 31 text

プロダクトオーナーの考えは？開発目線での優先順位は？サーバダウンに繋がるクリティカルなもの等対応の優先順位を決める実現可能性や難易度は？

Slide 32

Slide 32 text

本格調査、改善 4

Slide 33

Slide 33 text

調査検討計測

Slide 34

Slide 34 text

調査検討計測

Slide 35

Slide 35 text

改善案を出すための材料を増やす目的

Slide 36

Slide 36 text

ボトルネックは単一なのか複数なのかボトルネックは何か改善に必要な情報を調査していく原因は何か　全体調査のときにわかったことを取っ掛かりとして進　　めるとやりやすかったです。

Slide 37

Slide 37 text

調査した項目とその結果、内容 GitHub Issue などを活用調査結果はまとめておく試したこととその結果調査や試行からの考察　その瞬間の脳内をDumpしておくとPRを書くのが楽になったり　行き詰まったときにアドバイスをもらうのに役立ちました。

Slide 38

Slide 38 text

調査結果

Slide 39

Slide 39 text

調査結果 SQL

Slide 40

Slide 40 text

調査結果実行計画 SQL

Slide 41

Slide 41 text

考察

Slide 42

Slide 42 text

試した内容と結果考察

Slide 43

Slide 43 text

クエリの内容どこで発行されているクエリか調査で見ていたこと実行計画親の顔より見た #explain ローカルと本番では違ったりする大きいテーブル同士のJOIN IN句内のクエリの結果はどれくらいか等

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

調査検討計測

Slide 46

Slide 46 text

調査検討計測

Slide 47

Slide 47 text

調査検討計測

Slide 48

Slide 48 text

検討、計測

Slide 49

Slide 49 text

テストを書いておく改善後もふるまいが変わらないことを担保しておく　安心かつ安全に改善を進めていけて、testable にすることで　リファクタリングにもなり一石二鳥

Slide 50

Slide 50 text

調査結果をもとに改善案を検討、計測する “推測するな、計測せよ” …？推測は必要 “推測したら、計測せよ” 計測してダメなら次、次とどんどん試す

Slide 51

Slide 51 text

実例

Slide 52

Slide 52 text

募集者…Recruiter バンドメンバー募集サービス応募者…Applicant メッセージ…Message 一連のやり取り…Room

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

パフォーマンス劣化していたクエリ

Slide 55

Slide 55 text

パフォーマンス劣化していたクエリ

Slide 56

Slide 56 text

処理の流れを追ってみる

Slide 57

Slide 57 text

SQL 処理の流れを追ってみる

Slide 58

Slide 58 text

SQL Array 処理の流れを追ってみる

Slide 59

Slide 59 text

SQL Array Ruby 処理の流れを追ってみる

Slide 60

Slide 60 text

この式で最終的に欲しい結果は、「募集者に紐づくRoomのうち、特定の応募者との Roomが存在するか？」改善案の検討現状は「募集者に紐づくRoomの応募者ID を全て取得して配列にし」、「その配列に特定の応募者IDが含まれているかを確認」という流れ

Slide 61

Slide 61 text

全部SQLでやった方が速いのでは？

Slide 62

Slide 62 text

改善案

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

計測してみる

Slide 65

Slide 65 text

計測してみる

Slide 66

Slide 66 text

計測してみる

Slide 67

Slide 67 text

調査検討計測

Slide 68

Slide 68 text

調査検討計測 All Completed! All Completed!

Slide 69

Slide 69 text

Pull Requestを開く “コードにしたものとコードにしなかったことがプログラミング” 改善前の状態、改善に至るまでに調査したこと試したことをDescriptionにもれなく書く

Slide 70

Slide 70 text

調査

Slide 71

Slide 71 text

re ap 検討計測

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

マージされたらリリースを待つ

Slide 75

Slide 75 text

マージ、リリースされてマージ、リリースされてから結果が出るまでの間から結果が出るまでの間のワクワクでしか得られのワクワクでしか得られない栄養がある。ない栄養がある。

Slide 76

Slide 76 text

経過観察 5

Slide 77

Slide 77 text

リリース直後は数時間単位で状況を確認極端なパフォーマンス劣化がないかあれば切り戻しの判断など初動に問題がなさそうなら数日単位で状況を確認 3日、7日経過後などリリース前後の同一期間で比較する速くなっていれば改善は成功！

Slide 78

Slide 78 text

紹介した実例の経過観察結果

Slide 79

Slide 79 text

パフォーマンス劣化してしまった例

Slide 80

Slide 80 text

落ち込んでいる暇はない！パフォーマンス劣化があった場合その方法ではダメだということがわかった試したからこそわかることリリースしてみないとわからないこともある早めに切り戻す

Slide 81

Slide 81 text

本番環境は本番環境は計測環境より計測環境より奇なり奇なり

Slide 82

Slide 82 text

まとめ 6

Slide 83

Slide 83 text

全体の状況を把握して優先順位を決めて対応したことで、意識があっちこっち行かずに済んでよかった調査、計測時は丁寧すぎるくらいにログを残しておいてよかった “推測したら、計測せよ” 本番環境は計測時には起きなかったことが起こると知ったことでうまくいかなくても不必要に落ち込まずに済んだ

Slide 84

Slide 84 text

調査の流れや計測方法がわかったら怖くなくなった感想、所感頭で考えるだけじゃなく、思いついたことはどんどん試す、というマインド SQLに詳しいメンバーから学ぶと引き出しが増えてもっとSQLを知りたくなったもっと引き出しを増やしていきたい

Slide 85

Slide 85 text

” ” 勝負(に挑むために勝負(に挑むために必要なこと)とは、必要なこと)とは、 ①頭で考える ①頭で考える ②見つける ②見つける ③試す ③試す－野村克也