Laravelで学ぶ Webアプリケーションチューニング入門/web_application_tuning_101

PHPカンファレンスJAPAN2026の登壇資料

Transcript

1. Laravelで学ぶ Webアプリケーションチューニングの基本 PHP Conference Japan 2026 hanhan1978
2. Name : hanhan1978 / Ryo Tomidokoro From : 横浜市 Job : Backend Expert @ kaonavi inc Podcast : Yokohama North AM
3. 本トークの内容 2019年の登壇内容を2025年バージョンに改訂 したものです。 基本思想は全く変わっていません。 https://speakerdeck.com/hanhan1978/web-application-tuning-guildline
4. 注 Webアプリケーション ↓ Webアプリ 長いので、以後省略して書きます
5. 質問です
6. パフォーマンスチューニング したことありますか？
7. 未経験者の方へ チューニングは職人芸ではありません たんたんと順を追って確認する作業です
8. 本トークの目指すところ 特にチューニングの経験が浅い方にとって まず何をどうしてよいか分からない！？ 解像度を上げましょう AIへの指示も明確になります
9. よくない指示
10. よくない指示 あまりにも人間側が頭を使ってない
11. よい指示
12. よい指示 ボトルネックに対する具体的な指示
13. 再掲 本トークの目指すところ 特にチューニングの経験が浅い方にとって まず何をどうしてよいか分からない！？ 解像度を上げましょう AIへの指示も明確になります
14. ついでに Laravelが持つ基本的な機能がどのようなケース で役立つのかを紹介します
15. アウトライン 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処
16. 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処
17. 1. 全体を見る
18. 遅いとは？
19. 遅いとは？ 曖昧な言葉。 私の「遅い」と あなたの「遅い」は比較出来ない 主観であり、個人差がある。
20. 曖昧な表現 なんか、この画面遅くない？
21. 議論の開始としては悪くないが、作業をスター トするには情報が足りない このような「遅い」では改善が行えない。
22. 具体的な表現 「メトリクスを確認すると、該当時間帯は 通常よりも500msecレスポンスが遅かった」
23. コンテキストや数値が説明されることで、具体 的な状況が浮彫になってくる こういう「遅い」は改善につながる
24. 定性的な表現を定量的な表現に変換しましょう 「推測するな計測せよ」の世界です。
25. 状況が分かっても「遅い」の原因は分かりません。 原因究明のために、Webアプリをもっと俯瞰してみ る必要があります。
26. Webアプリは どのようにしてブラウザに表示されるのか？
27. Webアプリの全体像 ネットワークはなぜつながるのか？第2版 - 戸根勤（日経BP社）
28. Webアプリケーションの全体像 自分たちの領域は意外と小さい ネットワークはなぜつながるのか？第2版 - 戸根勤（日経BP社）
29. アンコントローラブルな領域 Webアプリだけでは改善できない領域が沢山ある Webアプリが「遅い」の原因なのかも分からない
30. 遅いの原因をつきとめる なんとなくアタリをつけてはいけない エンジニアとして理詰めで突き止める必要があ るが‥どうしよう？
31. 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処
32. 2. Webアプリの責任？
33. 「遅い」の考え方
34. レイテンシー 任意の状態から、任意の状態まで 待つためにかかった時間を計測した値 例） HTTPのリクエストからレスポンスまで DBのクエリ送信からデータ受信まで 詳解システム・パフォーマンス Brendan Gregg 西脇靖紘 長尾高弘（オライリー・ジャパン）
35. Webアプリ全体のレイテンシー サーバー側 ネットワーク 光ファイバー等 プロバイダ ユーザー側 ネットワーク
36. レイテンシーの中身をみて、Webアプリ単体の レスポンスタイムがボトルネックで無い場合 Webアプリ以外で対処する方が効率が良い
37. Webアプリ以外の遅さ 例えば大陸間のネットワーク通信 速度制限のかかった格安SIM VPNの輻輳
38. 例1 Time To First Byte 2秒 WebサーバーのResponse Time 150ミリ秒 サーバー側 ネットワーク インターネット プロバイダ ２秒 150ミリ秒 ユーザー側 ネットワーク
39. 例1 Time To First Byte 2秒 WebサーバーのResponse Time 150ミリ秒 サーバー側 ネットワーク インターネット プロバイダ ユーザー側 ネットワーク ２秒 150ミリ秒 Webアプリはボトルネックではない （全体の 7.5%）
40. 例２ Time To First Byte 2秒 WebサーバーのResponse Time 1.5秒 サーバー側 ネットワーク イン ター ネット ２秒 1.5秒 プロバイダ ユーザー側 ネットワーク
41. 例２ Time To First Byte 2秒 WebサーバーのResponse Time 1.5秒 サーバー側 ネットワーク イン ター ネット プロバイダ ユーザー側 ネットワーク ２秒 1.5秒 Webアプリがボトルネックの可能性 （全体の 75%）
42. AWSで試してみる
43. Tokyo Region Ubuntu 26.04 LTS N. Virginia Region Ubuntu 26.04 LTS
44. 東京のブラウザからアクセス Tokyo N. Virginia
45. Webアプリの全体像 160ms ネットワークはなぜつながるのか？第2版 - 戸根勤（日経BP社）
46. 大陸間のネットワークでかかる時間 アメリカ大陸から +160msec Webアプリでは改善できない！ CDN等のソリューションが必要
47. おまけ Tokyo Osaka 東京のブラウザからアクセス
48. レイテンシーの話にもどる
49. 全体のレイテンシーの中でWebアプリのレスポンス タイムが支配的な場合 Webアプリをチューニングすることでレイテンシー を改善することが可能 サーバー側 ネットワーク イン ター ネット プロバイダ ユーザー側 ネットワーク ２秒 1.5秒 Webアプリがボトルネックの可能性 （全体の 75%）
50. レスポンスタイム 各ウェブサーバーはログにレスポンスタイムを出力す ることが出来る。 Apache : %D Nginx : $request_time
51. Webアプリ単体のレイテンシー サーバー側ネットワーク ウェブサーバーのレスポンスタイム その他通信
52. ここまでで、Webアプリのレスポンスタイムがボ トルネックであることが分かった。 じゃあ、Webアプリのチューニングを開始...
53. まだ、ちょっと情報が足りてない その「遅さ」はWebアプリの責任？
54. Webアプリ以外の原因 • サーバー内の他処理の影響 • 連携しているAPIの障害 • 利用しているデータベースの障害
55. 原因を探るための手がかり IaaS, SaaS のステータス情報、Xのざわつき メモリ使用量、CPU使用率、ディスクIO、ネットワー クIO etc…
56. 実際の事例 https://aws.amazon.com/jp/message/56489/
57. 頼れるツール類 • IaaS, PasSが提供するツール (CloudWatch) • サーバー監視ツール (Mackerel) • 統合型監視ツール（Datadog, New Relic）
58. 測定ツール（Laravel 特化） • Laravel Cloud （専用モニタリング） • Nightwatch
59. Mackerel
60. Datadog https://www.datadoghq.com/ja/blog/real-user-monitoring-with-datadog/
61. Laravel Nightwatch https://nightwatch.laravel.com/docs/start-guide
62. 手に入る情報全てを使って、何がボトルネック になっているのかを特定する 一個ずつ一個ずつ、原因を絞り込んでいく
63. ついにWebアプリが原因らしいことが分かった じゃあ、次は何をしたらいい？
64. 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処
65. 3. Webアプリの処理を特定する
66. この段階では 「PHPのプログラムが原因らしい」 としか分かっていない。 具体的にどこを直せばいいのか、どうやって 特定するのか？
67. ツールの利用 一部の監視ツールには、自動で性能問題を検出 する機能が備わっています
68. Datadog さすがの高機能....
69. Observabilityの進化 2019年頃に比べて、遥かに強力になっていて、 どのエンドポイントが遅いのかまでは、すでに ランキングで可視化できてたりする
70. 現代のパワープレイ 経験の浅い業務は手伝ってもらいましょう
71. プロファイラー コード実行時にどの処理にどのくらいの時間がかかっ ているのかを計測するもの と、言葉で言われてもピンとこないので実例を見たほ うが早い
72. プロファイラーの例1 https://docs.datadoghq.com/dashboards/widgets/profiling_flame_graph/
73. プロファイラーの例2 https://github.com/reliforp/reli-prof
74. その他のツール New Relic Xdebug Xhprof Blackfire Nightwatch
75. プロファイルは、性能問題を抱える処理を特定 する強力なツール 利用できれば、非常に効率的
76. プロファイラーが使えない場合の策
77. プロファイラーが使えない場合の策 ログに処理時を出す
78. 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処
79. 4. 改善ループ
80. ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec
81. ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec これ？
82. ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec 絶対コレ
83. ボトルネックから 目を逸らすな！！！
84. 大切なことなのでもう一度
85. ボトルネックから 目を逸らすな！！！
86. ボトルネックは ボトルネックだからボトルネック
87. ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec 絶対コレ
88. 改善１ Library読込 Routing DB クエリー APIコール DB クエリー2 300msec 250msec 1700msec 200msec
89. ボトルネックどこ？ Library読込 Routing DB クエリー APIコール DB クエリー2 300msec 250msec 1700msec 200msec 絶対コレ
90. 改善２ Library読込 Routing コール DB クエリー2 150 250msec API DB クエリー 1550msec 200msec
91. ボトルネックどれ？ Library読込 Routing コール DB クエリー2 150 250msec API DB クエリー 1550msec 200msec 絶対コレ
92. 改善３ Library読込 Routing API DB クエリー コール DB クエリー2 1400msec 200msec 150 100
93. 特定 ▶ 改善 ▶ 特定 シンプルなループ
94. 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処
95. 5. よくある問題とその対処
96. その前に...
97. 武器を手に入れておこう
98. https://speakerdeck.com/hanhan1978/complexity101-for-phper
99. https://speakerdeck.com/hanhan1978/study-cache-with-php
100. https://speakerdeck.com/hanhan1978/how-to-slow-laravel-php-con-2022
101. https://speakerdeck.com/hanhan1978/laravel-collection-time-complexity-2023
102. Webを支える技術 https://gihyo.jp/book/2010/978-4-7741-4204-3
103. サーバー/インフラを支える技術 https://gihyo.jp/book/2008/978-4-7741-3566-3
104. データ構造の知識 https://www.lambdanote.com/products/opendatastructures
105. ISUCON本 https://gihyo.jp/book/2022/978-4-297-12846-3
106. 5. よくある問題とその対処
107. HTTPのAPIコール改善
108. HTTPのAPIコール改善
109. HTTPのAPIコール改善 性能以前の問題
110. HTTPのAPIコール改善 せめてタイムアウトを設定
111. HTTPのAPIコール改善 テストもやりやすくなる
112. HTTPのAPIコール改善 Cacheをつかうのも場合によってはアリ
113. メール送信の改善
114. メール送信の改善
115. メール送信の改善 SMTPが詰まる
116. メール送信の改善 キューで非同期送信
117. 単純なデータ量の増加
118. 単純なデータ量の増加
119. 単純なデータ量の増加 徐々に処理速度が劣化していく
120. N+1クエリ
121. N+1クエリ
122. N+1クエリ relation経由でクエリ発行
123. N+1クエリ eager loading
124. N+1 Collection操作
125. N+1コレクション操作
126. N+1コレクション操作 O(n) x O(n)
127. N+1コレクション操作 O(n) x O(1)
128. Attribute Castingの負荷
129. Attribute Castingの負荷
130. Attribute Castingの負荷 この瞬間に Carbonが生成
131. Attribute Castingの負荷 生成処理を行わない
132. どれだけ手札を持っているかがチューニング成 功のカギです。知識こそパワー！ • データ構造・アルゴリズムの変更 • キャッシュ • 非同期化 • スケールアップ・スケールアウト
133. 仕様変更も強力な手段であることを忘れずに • 求められてない情報の演算 • 画面遷移の工夫による負荷分散 • 処理全体をバッチ化 あまりにも難しい処理は根本から無くす
134. 最後に… チューニングとは、全体を見ながら少しずつ少 しずつ原因を特定していくプロセスです。 泥臭く追い込んでいく一連の作業をやってみる と、Webアプリの理解がさらに深まります。
135. 最後に大切なことなのでもう一度だけ...
136. ボトルネックから 目を逸らすな！！！