Laravelで学ぶ Webアプリケーションチューニングの基本 / Web Application Tuning Guildline

by Ryo Tomidokoro

Slide 1

Slide 1 text

Laravelで学ぶ Webアプリケーションチューニングの基本 Laravel Jp Conference 2019/02/16

Slide 2

Slide 2 text

自己紹介名前 : 富所亮 | Ryo Tomidokoro 職業 : Web Application Engineer 職歴 : SIer > 事業会社 > 受託 > 受託所属 : Innovator Japan Inc. 主な出現場所 : PHP界隈の各種勉強会

Slide 3

Slide 3 text

諸注意スライドはSpeakerDeckにアップ済みです。写真はご自由に。でも周りに気をつけて…

Slide 4

Slide 4 text

はじめに

Slide 5

Slide 5 text

本トークの内容自分がいつもやっていることをまとめました現場や個人開発でやったこと、本で読んで学んだことがベースになっています

Slide 6

Slide 6 text

いきなりですが質問です

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

経験者の方へご自身のやり方と比べて見てください改善のヒントになったら幸いです

Slide 9

Slide 9 text

未経験者の方へチューニングは職人芸ではないやることが分かれば怖くない

Slide 10

Slide 10 text

本トークの目指すところ特にチューニングの経験が浅い方にとってまず何をどうしてよいか分からない！？という状態を解消することに重点を置いています。

Slide 11

Slide 11 text

基本的なことを再確認することでパフォーマンスチューニングでやるべきことが明確になることを期待しています。

Slide 12

Slide 12 text

ついでに Laravelが持つ基本的な機能がどのようなケースで役立つのかを紹介します必要十分な機能がすでに備わっています

Slide 13

Slide 13 text

アウトライン 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処

Slide 14

Slide 14 text

1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処

Slide 15

Slide 15 text

1. 全体を見る

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

曖昧な意見「うちのウェブアプリケーション遅くない？」

Slide 18

Slide 18 text

問題を提起しているように見えて何もかもが曖昧で分からないこのような「遅い」では改善が行えない。

Slide 19

Slide 19 text

具体的な意見「弊社のウェブアプリは　平日18:00〜19:00の時間帯で　通常よりも500msec応答速度が遅い」

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

ウェブアプリケーションの全体像ネットワークはなぜつながるのか？ - 戸根勤（日経BP社） P10

Slide 25

Slide 25 text

自分の領域の狭さを知る Laravel

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

遅いの原因をつきとめるなんとなくアタリをつけてはいけないエンジニアとして科学的に突き止める必要があるが ‥どうする？

Slide 28

Slide 28 text

Slide 29

Slide 29 text

2. パフォーマンスを科学する

Slide 30

Slide 30 text

「遅い」の考え方

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

例えば大陸間のネットワーク通信速度制限のかかった格安SIM 共有LAN内の輻輳ウェブアプリ以外の遅さ

Slide 35

Slide 35 text

EC2で試してみる

Slide 36

Slide 36 text

Tokyo vs USA Tokyo Region Ubuntu 16.06 LTS N. Virginia Region Ubuntu 16.06 LTS

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

大陸間の移動でかかる時間アメリカ大陸まで +200msec ウェブアプリケーションでは改善できない！ CDN等のソリューションが必要

Slide 39

Slide 39 text

Slide 40

Slide 40 text

3. ウェブアプリの責任？

Slide 41

Slide 41 text

全体のレイテンシーの中でサーバー側ネットワークの占める割合が大きい場合ウェブアプリをチューニングすることで得られる可能性が高いユーザー側ネットワークプロバイダプロバイダ光ファイバー等サーバー側ネットワーク

Slide 42

Slide 42 text

レイテンシーにおけるウェブアプリ単体の占める時間は、ウェブサーバーが記録する「レスポンスタイム」で知ることが出来る

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

ウェブアプリ全体のレイテンシーを確認して、ウェブアプリ単体の応答時間に原因があると分かって、はじめてウェブアプリのチューニングを開始できる。

Slide 46

Slide 46 text

しかし、ウェブアプリ単体のレスポンスが悪かったとして、本当にウェブアプリが悪いのでしょうか？その「遅さ」はウェブアプリの責任？

Slide 47

Slide 47 text

Slide 48

Slide 48 text

4. サーバーメトリクスを見る

Slide 49

Slide 49 text

ウェブアプリ以外の原因同一サーバー上で動く他のプロセスがリソースを消費しているケースがある例）誰かが閉じ忘れたemacsのプロセスが100%で張り付いてた…とか

Slide 50

Slide 50 text

原因を探るための指標メモリ使用量、CPU使用率、ディスクIO、ネットワーク IO etc… 継続的な測定が基本。中長期の傾向値が無いと判断がしづらい

Slide 51

Slide 51 text

測定ツール sysstatパッケージホスティングが提供するツール (CloudWatch) SaaSの監視ツール (Mackerel) インストール型の測定ツール (netdata)

Slide 52

Slide 52 text

sysstatパッケージ sar, pidstat, dstat ...

Slide 53

Slide 53 text

Mackerel

Slide 54

Slide 54 text

netdata

Slide 55

Slide 55 text

ボトルネックを特定するこの段階では、プロセス単位でのCPU使用率、メモリ使用量などから、どのプロセスがボトルネックになっているのかを特定一個ずつ一個ずつ、原因を絞り込んでいく

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Slide 58

Slide 58 text

5. ウェブアプリの処理を特定する

Slide 59

Slide 59 text

ウェブアプリのどの処理が原因なのか？どうやったら分かるのか？この段階では「PHPのプログラムが原因らしい」としか分かっていない。

Slide 60

Slide 60 text

レスポンスタイムから探すウェブサーバーのログから、レスポンスタイムが遅いURLを探す awk, alp, kataribe等を使って簡単に解析できる

Slide 61

Slide 61 text

alpの例

Slide 62

Slide 62 text

ウェブ系ツールを頼る自分はNew Relicしか使ったことないのですが、簡単にボトルネックのURLや処理を特定することができます。

Slide 63

Slide 63 text

New Relicの例

Slide 64

Slide 64 text

Slide 65

Slide 65 text

6. プロファイリングする

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

blackfire.ioの例

Slide 68

Slide 68 text

その他のツール Xdebug Xhprof tideways 他にもありそうです…

Slide 69

Slide 69 text

処理が特定できて、プロファイラーの結果が取得できたら、チューニングの準備がようやく整ったことになるここから、ウェブアプリ単体のレイテンシーについて考えていく段階になる

Slide 70

Slide 70 text

Slide 71

Slide 71 text

7. 改善ループを回す

Slide 72

Slide 72 text

ウェブアプリ単体のレイテンシーレスポンス出力 APIコール Routing DBクエリー Library読込例）

Slide 73

Slide 73 text

この先は、レイテンシーの中でボトルネックになっている処理をチューニングしていくこの先は 1. レイテンシー確認 2. ボトルネック改善 3. レイテンシー確認... を延々と繰り返す

Slide 74

Slide 74 text

改善ループ１

Slide 75

Slide 75 text

改善ループ１

Slide 76

Slide 76 text

理論上400msec程度のパフォーマンス改善が見込める →仮に上手に改善できたとすると…

Slide 77

Slide 77 text

改善ループ２

Slide 78

Slide 78 text

改善ループ２

Slide 79

Slide 79 text

ボトルネックが他の処理に移ったことがわかるここも改善することでさらに200msec →上手く改善すると...

Slide 80

Slide 80 text

改善ループ３

Slide 81

Slide 81 text

処理の特定さえ出来てしまえば、あとはTry&Errorを繰り返すことでチューニングは達成することが出来る。処理の特定はプロファイラがやってくれる

Slide 82

Slide 82 text

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

この先は、個別の象徴的なケースを例にとって、その対処法を説明します。 →Laravelにちょうどよい解決法があるものは[L] マークがついています！

Slide 85

Slide 85 text

HTTPのAPIコール一回のリクエストで複数APIをコールするようになると、途端に処理が遅くなる →更新頻度によってはCache [L] →自前APIであれば、専用APIにまとめてコール回数を減らす →フロントのJSに移譲する

Slide 86

Slide 86 text

メール送信 SMTPとの通信は体感1secくらいかかる。複数メール送信がリクエストに同期的に書いてあると絶望的に遅い →Queue [L]

Slide 87

Slide 87 text

Slack通知これもメール送信と同じ。同期的な処理にしているとびっくりするほど遅くなります。 →Queue [L]

Slide 88

Slide 88 text

SQLクエリー実行 @soudai1025 のスライド見れば多分解決… 単発のクエリーが遅い場合は適切なDB設計と、インデックス設計が効きます。 →SELECTであればCacheという手もあります。あまりオススメしませんが…[L]

Slide 89

Slide 89 text

リスト形式の表示で問題になるやつです。Laravelの relationをbladeから呼び出すと、カジュアルに大量のクエリを発生させられます。 →eager loading [L] N+1クエリ

Slide 90

Slide 90 text

入れ子のLoopとか、1万件とかのforeachとか、常識を外れた蛮行によるもの… Laravel Collectionの乱用なども… →レビューや内部勉強会で防ぐしかない… 計算量が無駄に多いプログラム

Slide 91

Slide 91 text

こちらにも詳しく書きました https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita

Slide 92

Slide 92 text

色々、見てきましたが処理の遅いプログラムのチューニング方法は対処方法が２つくらいしか無い。・アルゴリズムの変更・非同期化

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

参考資料詳解システム・パフォーマンス Brendan Gregg 西脇靖紘長尾高弘オライリー・ジャパンネットワークはなぜつながるのか？戸根勤日経BP社サーバー・インフラを支える技術伊藤直也, 勝見祐己, 田中慎司, ひろせまさあき, 安井真伸, 横川和哉 WEB+DB PRESS plus