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

by Ryo Tomidokoro

Embed

Start on current slide

Slide 1

Slide 1 text

Laravelで学ぶ Webアプリケーションチューニングの基本 PHP Conference Japan 2026 hanhan1978

Slide 2

Slide 2 text

Name : hanhan1978 / Ryo Tomidokoro From : 横浜市 Job : Backend Expert @ kaonavi inc Podcast : Yokohama North AM

Slide 3

Slide 3 text

本トークの内容 2019年の登壇内容を2025年バージョンに改訂したものです。基本思想は全く変わっていません。 https://speakerdeck.com/hanhan1978/web-application-tuning-guildline

Slide 4

Slide 4 text

注 Webアプリケーション ↓ Webアプリ長いので、以後省略して書きます

Slide 5

Slide 5 text

質問です

Slide 6

Slide 6 text

パフォーマンスチューニングしたことありますか？

Slide 7

Slide 7 text

未経験者の方へチューニングは職人芸ではありませんたんたんと順を追って確認する作業です

Slide 8

Slide 8 text

本トークの目指すところ特にチューニングの経験が浅い方にとってまず何をどうしてよいか分からない！？解像度を上げましょう AIへの指示も明確になります

Slide 9

Slide 9 text

よくない指示

Slide 10

Slide 10 text

よくない指示あまりにも人間側が頭を使ってない

Slide 11

Slide 11 text

よい指示

Slide 12

Slide 12 text

よい指示ボトルネックに対する具体的な指示

Slide 13

Slide 13 text

再掲本トークの目指すところ特にチューニングの経験が浅い方にとってまず何をどうしてよいか分からない！？解像度を上げましょう AIへの指示も明確になります

Slide 14

Slide 14 text

ついでに Laravelが持つ基本的な機能がどのようなケースで役立つのかを紹介します

Slide 15

Slide 15 text

アウトライン 1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処

Slide 16

Slide 16 text

1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処

Slide 17

Slide 17 text

1. 全体を見る

Slide 18

Slide 18 text

遅いとは？

Slide 19

Slide 19 text

遅いとは？曖昧な言葉。私の「遅い」とあなたの「遅い」は比較出来ない主観であり、個人差がある。

Slide 20

Slide 20 text

曖昧な表現なんか、この画面遅くない？

Slide 21

Slide 21 text

議論の開始としては悪くないが、作業をスタートするには情報が足りないこのような「遅い」では改善が行えない。

Slide 22

Slide 22 text

具体的な表現「メトリクスを確認すると、該当時間帯は通常よりも500msecレスポンスが遅かった」

Slide 23

Slide 23 text

コンテキストや数値が説明されることで、具体的な状況が浮彫になってくるこういう「遅い」は改善につながる

Slide 24

Slide 24 text

定性的な表現を定量的な表現に変換しましょう「推測するな計測せよ」の世界です。

Slide 25

Slide 25 text

状況が分かっても「遅い」の原因は分かりません。原因究明のために、Webアプリをもっと俯瞰してみる必要があります。

Slide 26

Slide 26 text

Webアプリはどのようにしてブラウザに表示されるのか？

Slide 27

Slide 27 text

Webアプリの全体像ネットワークはなぜつながるのか？第2版 - 戸根勤（日経BP社）

Slide 28

Slide 28 text

Webアプリケーションの全体像自分たちの領域は意外と小さいネットワークはなぜつながるのか？第2版 - 戸根勤（日経BP社）

Slide 29

Slide 29 text

アンコントローラブルな領域 Webアプリだけでは改善できない領域が沢山ある Webアプリが「遅い」の原因なのかも分からない

Slide 30

Slide 30 text

遅いの原因をつきとめるなんとなくアタリをつけてはいけないエンジニアとして理詰めで突き止める必要があるが‥どうしよう？

Slide 31

Slide 31 text

1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処

Slide 32

Slide 32 text

2. Webアプリの責任？

Slide 33

Slide 33 text

「遅い」の考え方

Slide 34

Slide 34 text

レイテンシー任意の状態から、任意の状態まで待つためにかかった時間を計測した値例） HTTPのリクエストからレスポンスまで DBのクエリ送信からデータ受信まで詳解システム・パフォーマンス Brendan Gregg 西脇靖紘長尾高弘（オライリー・ジャパン）

Slide 35

Slide 35 text

Webアプリ全体のレイテンシーサーバー側ネットワーク光ファイバー等プロバイダユーザー側ネットワーク

Slide 36

Slide 36 text

レイテンシーの中身をみて、Webアプリ単体のレスポンスタイムがボトルネックで無い場合 Webアプリ以外で対処する方が効率が良い

Slide 37

Slide 37 text

Webアプリ以外の遅さ例えば大陸間のネットワーク通信速度制限のかかった格安SIM VPNの輻輳

Slide 38

Slide 38 text

例1 Time To First Byte 2秒 WebサーバーのResponse Time 150ミリ秒サーバー側ネットワークインターネットプロバイダ２秒 150ミリ秒ユーザー側ネットワーク

Slide 39

Slide 39 text

例1 Time To First Byte 2秒 WebサーバーのResponse Time 150ミリ秒サーバー側ネットワークインターネットプロバイダユーザー側ネットワーク２秒 150ミリ秒 Webアプリはボトルネックではない（全体の 7.5%）

Slide 40

Slide 40 text

例２ Time To First Byte 2秒 WebサーバーのResponse Time 1.5秒サーバー側ネットワークインターネット２秒 1.5秒プロバイダユーザー側ネットワーク

Slide 41

Slide 41 text

例２ Time To First Byte 2秒 WebサーバーのResponse Time 1.5秒サーバー側ネットワークインターネットプロバイダユーザー側ネットワーク２秒 1.5秒 Webアプリがボトルネックの可能性（全体の 75%）

Slide 42

Slide 42 text

AWSで試してみる

Slide 43

Slide 43 text

Tokyo Region Ubuntu 26.04 LTS N. Virginia Region Ubuntu 26.04 LTS

Slide 44

Slide 44 text

東京のブラウザからアクセス Tokyo N. Virginia

Slide 45

Slide 45 text

Webアプリの全体像 160ms ネットワークはなぜつながるのか？第2版 - 戸根勤（日経BP社）

Slide 46

Slide 46 text

大陸間のネットワークでかかる時間アメリカ大陸から +160msec Webアプリでは改善できない！ CDN等のソリューションが必要

Slide 47

Slide 47 text

おまけ Tokyo Osaka 東京のブラウザからアクセス

Slide 48

Slide 48 text

レイテンシーの話にもどる

Slide 49

Slide 49 text

全体のレイテンシーの中でWebアプリのレスポンスタイムが支配的な場合 Webアプリをチューニングすることでレイテンシーを改善することが可能サーバー側ネットワークインターネットプロバイダユーザー側ネットワーク２秒 1.5秒 Webアプリがボトルネックの可能性（全体の 75%）

Slide 50

Slide 50 text

レスポンスタイム各ウェブサーバーはログにレスポンスタイムを出力することが出来る。 Apache : %D Nginx : $request_time

Slide 51

Slide 51 text

Webアプリ単体のレイテンシーサーバー側ネットワークウェブサーバーのレスポンスタイムその他通信

Slide 52

Slide 52 text

ここまでで、Webアプリのレスポンスタイムがボトルネックであることが分かった。じゃあ、Webアプリのチューニングを開始...

Slide 53

Slide 53 text

まだ、ちょっと情報が足りてないその「遅さ」はWebアプリの責任？

Slide 54

Slide 54 text

Webアプリ以外の原因 ● サーバー内の他処理の影響 ● 連携しているAPIの障害 ● 利用しているデータベースの障害

Slide 55

Slide 55 text

原因を探るための手がかり IaaS, SaaS のステータス情報、Xのざわつきメモリ使用量、CPU使用率、ディスクIO、ネットワークIO etc…

Slide 56

Slide 56 text

実際の事例 https://aws.amazon.com/jp/message/56489/

Slide 57

Slide 57 text

頼れるツール類 ● IaaS, PasSが提供するツール (CloudWatch) ● サーバー監視ツール (Mackerel) ● 統合型監視ツール（Datadog, New Relic）

Slide 58

Slide 58 text

測定ツール（Laravel 特化） ● Laravel Cloud （専用モニタリング） ● Nightwatch

Slide 59

Slide 59 text

Mackerel

Slide 60

Slide 60 text

Datadog https://www.datadoghq.com/ja/blog/real-user-monitoring-with-datadog/

Slide 61

Slide 61 text

Laravel Nightwatch https://nightwatch.laravel.com/docs/start-guide

Slide 62

Slide 62 text

手に入る情報全てを使って、何がボトルネックになっているのかを特定する一個ずつ一個ずつ、原因を絞り込んでいく

Slide 63

Slide 63 text

ついにWebアプリが原因らしいことが分かったじゃあ、次は何をしたらいい？

Slide 64

Slide 64 text

1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処

Slide 65

Slide 65 text

3. Webアプリの処理を特定する

Slide 66

Slide 66 text

この段階では「PHPのプログラムが原因らしい」としか分かっていない。具体的にどこを直せばいいのか、どうやって特定するのか？

Slide 67

Slide 67 text

ツールの利用一部の監視ツールには、自動で性能問題を検出する機能が備わっています

Slide 68

Slide 68 text

Datadog さすがの高機能....

Slide 69

Slide 69 text

Observabilityの進化 2019年頃に比べて、遥かに強力になっていて、どのエンドポイントが遅いのかまでは、すでにランキングで可視化できてたりする

Slide 70

Slide 70 text

現代のパワープレイ経験の浅い業務は手伝ってもらいましょう

Slide 71

Slide 71 text

プロファイラーコード実行時にどの処理にどのくらいの時間がかかっているのかを計測するものと、言葉で言われてもピンとこないので実例を見たほうが早い

Slide 72

Slide 72 text

プロファイラーの例1 https://docs.datadoghq.com/dashboards/widgets/proﬁling_ﬂame_graph/

Slide 73

Slide 73 text

プロファイラーの例2 https://github.com/reliforp/reli-prof

Slide 74

Slide 74 text

その他のツール New Relic Xdebug Xhprof Blackﬁre Nightwatch

Slide 75

Slide 75 text

プロファイルは、性能問題を抱える処理を特定する強力なツール利用できれば、非常に効率的

Slide 76

Slide 76 text

プロファイラーが使えない場合の策

Slide 77

Slide 77 text

プロファイラーが使えない場合の策ログに処理時を出す

Slide 78

Slide 78 text

1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処

Slide 79

Slide 79 text

4. 改善ループ

Slide 80

Slide 80 text

ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec

Slide 81

Slide 81 text

ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec これ？

Slide 82

Slide 82 text

ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec 絶対コレ

Slide 83

Slide 83 text

ボトルネックから目を逸らすな！！！

Slide 84

Slide 84 text

大切なことなのでもう一度

Slide 85

Slide 85 text

ボトルネックから目を逸らすな！！！

Slide 86

Slide 86 text

ボトルネックはボトルネックだからボトルネック

Slide 87

Slide 87 text

ボトルネックどれ？ Library読込 Routing DBクエリー APIコール DB クエリー2 300msec 250msec 3000msec 1500msec 絶対コレ

Slide 88

Slide 88 text

改善１ Library読込 Routing DB クエリー APIコール DB クエリー2 300msec 250msec 1700msec 200msec

Slide 89

Slide 89 text

ボトルネックどこ？ Library読込 Routing DB クエリー APIコール DB クエリー2 300msec 250msec 1700msec 200msec 絶対コレ

Slide 90

Slide 90 text

改善２ Library読込 Routing コール DB クエリー2 150 250msec API DB クエリー 1550msec 200msec

Slide 91

Slide 91 text

ボトルネックどれ？ Library読込 Routing コール DB クエリー2 150 250msec API DB クエリー 1550msec 200msec 絶対コレ

Slide 92

Slide 92 text

改善３ Library読込 Routing API DB クエリーコール DB クエリー2 1400msec 200msec 150 100

Slide 93

Slide 93 text

特定 ▶ 改善 ▶ 特定シンプルなループ

Slide 94

Slide 94 text

1. 全体を見る 2. Webアプリの責任？ 3. Webアプリの処理を特定する 4. 改善ループ 5. よくある問題処理とその対処

Slide 95

Slide 95 text

5. よくある問題とその対処

Slide 96

Slide 96 text

その前に...

Slide 97

Slide 97 text

武器を手に入れておこう

Slide 98

Slide 98 text

https://speakerdeck.com/hanhan1978/complexity101-for-phper

Slide 99

Slide 99 text

https://speakerdeck.com/hanhan1978/study-cache-with-php

Slide 100

Slide 100 text

https://speakerdeck.com/hanhan1978/how-to-slow-laravel-php-con-2022

Slide 101

Slide 101 text

https://speakerdeck.com/hanhan1978/laravel-collection-time-complexity-2023

Slide 102

Slide 102 text

Webを支える技術 https://gihyo.jp/book/2010/978-4-7741-4204-3

Slide 103

Slide 103 text

サーバー/インフラを支える技術 https://gihyo.jp/book/2008/978-4-7741-3566-3

Slide 104

Slide 104 text

データ構造の知識 https://www.lambdanote.com/products/opendatastructures

Slide 105

Slide 105 text

ISUCON本 https://gihyo.jp/book/2022/978-4-297-12846-3

Slide 106

Slide 106 text

5. よくある問題とその対処

Slide 107

Slide 107 text

HTTPのAPIコール改善

Slide 108

Slide 108 text

HTTPのAPIコール改善

Slide 109

Slide 109 text

HTTPのAPIコール改善性能以前の問題

Slide 110

Slide 110 text

HTTPのAPIコール改善せめてタイムアウトを設定

Slide 111

Slide 111 text

HTTPのAPIコール改善テストもやりやすくなる

Slide 112

Slide 112 text

HTTPのAPIコール改善 Cacheをつかうのも場合によってはアリ

Slide 113

Slide 113 text

メール送信の改善

Slide 114

Slide 114 text

メール送信の改善

Slide 115

Slide 115 text

メール送信の改善 SMTPが詰まる

Slide 116

Slide 116 text

メール送信の改善キューで非同期送信

Slide 117

Slide 117 text

単純なデータ量の増加

Slide 118

Slide 118 text

単純なデータ量の増加

Slide 119

Slide 119 text

単純なデータ量の増加徐々に処理速度が劣化していく

Slide 120

Slide 120 text

N+1クエリ

Slide 121

Slide 121 text

N+1クエリ

Slide 122

Slide 122 text

N+1クエリ relation経由でクエリ発行

Slide 123

Slide 123 text

N+1クエリ eager loading

Slide 124

Slide 124 text

N+1 Collection操作

Slide 125

Slide 125 text

N+1コレクション操作

Slide 126

Slide 126 text

N+1コレクション操作 O(n) x O(n)

Slide 127

Slide 127 text

N+1コレクション操作 O(n) x O(1)

Slide 128

Slide 128 text

Attribute Castingの負荷

Slide 129

Slide 129 text

Attribute Castingの負荷

Slide 130

Slide 130 text

Attribute Castingの負荷この瞬間に Carbonが生成

Slide 131

Slide 131 text

Attribute Castingの負荷生成処理を行わない

Slide 132

Slide 132 text

どれだけ手札を持っているかがチューニング成功のカギです。知識こそパワー！ ● データ構造・アルゴリズムの変更 ● キャッシュ ● 非同期化 ● スケールアップ・スケールアウト

Slide 133

Slide 133 text

仕様変更も強力な手段であることを忘れずに ● 求められてない情報の演算 ● 画面遷移の工夫による負荷分散 ● 処理全体をバッチ化あまりにも難しい処理は根本から無くす

Slide 134

Slide 134 text

最後に… チューニングとは、全体を見ながら少しずつ少しずつ原因を特定していくプロセスです。泥臭く追い込んでいく一連の作業をやってみると、Webアプリの理解がさらに深まります。