Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Fu-ga
October 27, 2023

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

2023.10.27 Kaigi on Rails 2023 Day1

Fu-ga

October 27, 2023
Tweet

More Decks by Fu-ga

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

  3. ESM members in venue

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  8. きっかけ
    1

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  13. 全体の調査
    3

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. 個別に確認する

    View full-size slide

  22. 個別に確認する

    View full-size slide

  23. 個別に確認する

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. 本格調査、改善
    4

    View full-size slide

  31. 調査
    検討 計測

    View full-size slide

  32. 調査
    検討 計測

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. 調査結果

    View full-size slide

  37. 調査結果
    SQL

    View full-size slide

  38. 調査結果
    実行計画
    SQL

    View full-size slide

  39. 試した内容と結果
    考察

    View full-size slide

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

    View full-size slide

  41. 調査
    検討 計測

    View full-size slide

  42. 調査
    検討 計測

    View full-size slide

  43. 調査
    検討 計測

    View full-size slide

  44. 検討、計測

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  50. 処理の流れを追ってみる

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  55. 全部SQLでやった方が
    速いのでは?

    View full-size slide

  56. 計測してみる

    View full-size slide

  57. 計測してみる

    View full-size slide

  58. 計測してみる

    View full-size slide

  59. 調査
    検討 計測

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  62. re
    ap
    検討
    計測

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  65. 経過観察
    5

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide



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

    View full-size slide