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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Fu-ga
October 27, 2023
Technology
7.2k
18
Share
初めてのパフォーマンス改善
2023.10.27 Kaigi on Rails 2023 Day1
Fu-ga
October 27, 2023
More Decks by Fu-ga
See All by Fu-ga
OSSから学んだPR Descriptionの書き方
fugakkbn
4
560
入社数ヶ月のnewbieが 稼働7年超のプロジェクトに 型を導入して見えた世界
fugakkbn
4
4.3k
オンライン時代のペアプログラミング
fugakkbn
1
1.1k
Types teaches success, what will we do?
fugakkbn
1
12k
What I can do to get the job smoothly
fugakkbn
0
410
introduction-to-rindokurb
fugakkbn
0
530
fbc-lt-code-review
fugakkbn
0
1.3k
Learn "QUIC" Quickly!
fugakkbn
0
410
タスクの洗い出しという壁 /fjord-lt-slide-fuga
fugakkbn
2
960
Other Decks in Technology
See All in Technology
"うちにはまだ早い"は本当? ─ 小さく始めるPlatform Engineering入門
harukasakihara
6
520
【関西製造業祭り2026春】現場を変える技術はここまで来た〜世界最大の製造業見本市から持って帰ってきたもの〜
tanakaseiya
0
130
毎日の作業を Claude Code 経由にしたら、 ノウハウがコードになった
kossykinto
1
1.3k
要件定義の精度を高めるための型と生成AIの活用 / Using Types and Generative AI to Improve the Accuracy of Requirements Definition
haru860
0
320
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.5k
みんなの考えた最強のデータ基盤アーキテクチャ'26前期〜前夜祭〜ルーキーズ_資料_遠藤な
endonanana
0
310
Purview 勉強会報告 Microsoft Purview 入門しようとしてみた
masakichixo
1
370
AI時代に、 データアナリストがデータエンジニアに異動して
jackojacko_
0
770
データモデリング通り #5オンライン勉強会: AIに『ビジネスの文脈』を教え込むデータモデリング
datayokocho
0
260
「QA=テスト」「シフトレフト=スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記 #scrumniigata
nihonbuson
PRO
5
1.2k
変化の激しい時代をゴキゲンに生き抜くために 〜ストレスマネジメントのススメ〜
kakehashi
PRO
5
1.3k
ボトムアップの改善の火を灯し続けろ!〜支援現場で学んだ、消えないための3つの打ち手〜 / 20260509 Kazuki Mori
shift_evolve
PRO
2
670
Featured
See All Featured
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
300
Chasing Engaging Ingredients in Design
codingconduct
0
190
For a Future-Friendly Web
brad_frost
183
10k
GitHub's CSS Performance
jonrohan
1032
470k
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.2k
The Cult of Friendly URLs
andyhume
79
6.9k
Darren the Foodie - Storyboard
khoart
PRO
3
3.3k
The Limits of Empathy - UXLibs8
cassininazir
1
320
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.1k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
560
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
510
Transcript
初めての パフォーマンス改善 ~君たちはどう計測するか~ ふーが@fugakkbn はかる @浅草橋ヒューリックホール&カンファレンス 2023.10.27(Fri) - Kaigi on
Rails 2023 Day1
ふーが 永和システムマネジメント Rails エンジニア 2 年生 Asakusa.rbメンバー Kaigi on Rails
Organizer @fugakkbn
None
ESM members in venue
Rubyメソッド Rubyメソッド キーホルダー キーホルダー 専用のコインを永和メンバーから受 け取って、ブースでガチャガチャを 回してGET! おひとりさま一回まで
初めての パフォーマンス改善 ~君たちはどう計測するか~ ふーが@fugakkbn はかる @浅草橋ヒューリックホール&カンファレンス 2023.10.27(Fri) - Kaigi on
Rails 2023 Day1
初めての パフォーマンス改善 ~君たちはどう計測するか~ ふーが@fugakkbn はかる @浅草橋ヒューリックホール&カンファレンス 2023.10.27(Fri) - Kaigi on
Rails 2023 Day1
前提、目的 ここではアプリケーションの応答速度を改善するための 取り組み全般を「パフォーマンス改善」と呼称します。 一連の改善を通してやったこと、考えたことなどを共有 主にパフォーマンス改善の経験がない、少ない人が取り 組む時に見るべきポイントや気に掛けるべきポイントを お伝えできれば
きっかけ 1
「レスポンスが悪そうなページと原因を調査して、いい感じに改善 して欲しい」とのオーダー 8年ほど稼働しているプロダクト 事業成長に伴い、利用者が右肩上がりに増加 レスポンスに影響が出始め、利用者からの問い合わせ増 ちょうど手が空くタイミングだったのとやったことがな い領域だったのでチャレンジも含めて挙手
流れ 2
「いい感じに」という オーダーにどう応えるか
クリティカルな部分があるかもしれない まずは現状を把握したい パフォーマンス劣化は一か所ではないはず リストアップして優先順位を決める必要がありそう
全体の調査 まずはどのページが遅いのか を洗い出して全体像を把握す る。 優先順位付け 遅いページが判明したら、ど こから対応していくべきかを 検討する。 経過観察 リリース後に想定通り速くな
っているのか、または劣化し てしまっていないかを確認。 本格調査、改善 個別に原因を調査して改善案 を模索する。改善が見込めれ ばリリースする。 改善までの道のり
全体の調査 3
APMはNew Relic RDBMSはOracle アダプターは activerecord-oracle_enhanced-adapter ツールについて
まずは全体像を把握したい どのページ、アクションが遅いのか? 問い合わせがあったページはどれくら い遅いのか? 遅い部分は何が原因っぽいのか?
まずは全体像を把握したい どのページ、アクションが遅いのか? 遅い部分は何が原因っぽいのか? 問い合わせがあったページはどれくら い遅いのか?
APMを活用する 全体として特に遅いもの create index index
ページ、アクション毎の確認
ページ、アクション毎の確認
まずは全体像を把握したい どのページ、アクションが遅いのか? 遅い部分は何が原因っぽいのか? 問い合わせがあったページはどれくら い遅いのか?
個別に確認する
個別に確認する
個別に確認する
まずは全体像を把握したい どのページ、アクションが遅いのか? 遅い部分は何が原因っぽいのか? 問い合わせがあったページはどれくら い遅いのか?
原因の詳細まではこの段階でわからなくても良い
原因の詳細まではこの段階でわからなくても良い
詳細までは追わない DBの場合は「クエリが遅い」と想像つく 原因がよくわからないケース 優先順位が決まっていない状態で深追い すると時間だけが溶けていく
まずは全体像を把握したい どのページ、アクションが遅いのか? クレームが来ているページはどれくらい 遅いのか 遅い部分は何が原因っぽいのか? 調べたこと、 調べたこと、 わかったことは わかったことは まとめておくと
まとめておくと 実際に改善するときに 実際に改善するときに べんり べんり
プロダクトオーナーの考えは? 開発目線での優先順位は? サーバダウンに繋がるクリティカルなもの 等 対応の優先順位を決める 実現可能性や難易度は?
本格調査、改善 4
調査 検討 計測
調査 検討 計測
改善案を出すため の材料を増やす 目的
ボトルネックは単一なのか複数なのか ボトルネックは何か 改善に必要な情報を調査していく 原因は何か 全体調査のときにわかったことを取っ掛かりとして進 めるとやりやすかったです。
調査した項目とその結果、内容 GitHub Issue などを活用 調査結果はまとめておく 試したこととその結果 調査や試行からの考察 その瞬間の脳内をDumpしておくとPRを書くのが楽になったり 行き詰まったときにアドバイスをもらうのに役立ちました。
調査結果
調査結果 SQL
調査結果 実行計画 SQL
考察
試した内容と結果 考察
クエリの内容 どこで発行されているクエリか 調査で見ていたこと 実行計画 親の顔より見た #explain ローカルと本番では違ったりする 大きいテーブル同士のJOIN IN句内のクエリの結果はどれくらいか 等
None
調査 検討 計測
調査 検討 計測
調査 検討 計測
検討、計測
テストを書いておく 改善後もふるまいが変わらないことを担保 しておく 安心かつ安全に改善を進めていけて、testable にすることで リファクタリングにもなり一石二鳥
調査結果をもとに 改善案を検討、計測する “推測するな、計測せよ” …? 推測は必要 “推測したら、計測せよ” 計測してダメなら次、次とどんどん試す
実例
募集者…Recruiter バンドメンバー募集サービス 応募者…Applicant メッセージ…Message 一連のやり取り…Room
None
パフォーマンス劣化していたクエリ
パフォーマンス劣化していたクエリ
処理の流れを追ってみる
SQL 処理の流れを追ってみる
SQL Array 処理の流れを追ってみる
SQL Array Ruby 処理の流れを追ってみる
この式で最終的に欲しい結果は、「募集者 に紐づくRoomのうち、特定の応募者との Roomが存在するか?」 改善案の検討 現状は「募集者に紐づくRoomの応募者ID を全て取得して配列にし」、「その配列に 特定の応募者IDが含まれているかを確認」 という流れ
全部SQLでやった方が 速いのでは?
改善案
None
計測してみる
計測してみる
計測してみる
調査 検討 計測
調査 検討 計測 All Completed! All Completed!
Pull Requestを開く “コードにしたものとコードにしなかったこ とがプログラミング” 改善前の状態、改善に至るまでに調査した こと試したことをDescriptionにもれなく書く
調査
re ap 検討 計測
None
None
マージされたら リリースを待つ
マージ、リリースされて マージ、リリースされて から結果が出るまでの間 から結果が出るまでの間 のワクワクでしか得られ のワクワクでしか得られ ない栄養がある。 ない栄養がある。
経過観察 5
リリース直後は数時間単位で状況を確認 極端なパフォーマンス劣化がないか あれば切り戻しの判断 など 初動に問題がなさそうなら数日単位で状況を確認 3日、7日経過後 など リリース前後の同一期間で比較する 速くなっていれば改善は成功!
紹介した実例の経過観察結果
パフォーマンス劣化してしまった例
落ち込んでいる暇はない! パフォーマンス劣化があった場合 その方法ではダメだということがわかった 試したからこそわかること リリースしてみないとわからないこともある 早めに切り戻す
本番環境は 本番環境は 計測環境より 計測環境より 奇なり 奇なり
まとめ 6
全体の状況を把握して優先順位を決めて対 応したことで、意識があっちこっち行かず に済んでよかった 調査、計測時は丁寧すぎるくらいにログを 残しておいてよかった “推測したら、計測せよ” 本番環境は計測時には起きなかったことが 起こると知ったことでうまくいかなくても 不必要に落ち込まずに済んだ
調査の流れや計測方法がわかったら怖くなく なった 感想、所感 頭で考えるだけじゃなく、思いついたこと はどんどん試す、というマインド SQLに詳しいメンバーから学ぶと引き出し が増えてもっとSQLを知りたくなった もっと引き出しを増やしていきたい
” ” 勝負(に挑むために 勝負(に挑むために 必要なこと)とは、 必要なこと)とは、 ①頭で考える ①頭で考える ②見つける ②見つける
③試す ③試す -野村克也