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

Laravel Jp Conferenceの資料です。

どのようにウェブアプリケーションのパフォーマンスチューニングを考えていくのか、基本をまとめました。

Transcript

1. Laravelで学ぶ Webアプリケーションチューニングの基本 Laravel Jp Conference 2019/02/16
2. 自己紹介 名前 : 富所 亮 | Ryo Tomidokoro 職業 : Web Application Engineer 職歴 : SIer > 事業会社 > 受託 > 受託 所属 : Innovator Japan Inc. 主な出現場所 : PHP界隈の各種勉強会
3. 諸注意 スライドはSpeakerDeckにアップ済みです。 写真はご自由に。でも周りに気をつけて…
4. はじめに
5. 本トークの内容 自分がいつもやっていることをまとめました 現場や個人開発でやったこと、本で読んで学んだこ とがベースになっています
6. いきなりですが質問です
7. パフォーマンスチューニング したことありますか？
8. 経験者の方へ ご自身のやり方と比べて見てください 改善のヒントになったら幸いです
9. 未経験者の方へ チューニングは職人芸ではない やることが分かれば怖くない
10. 本トークの目指すところ 特にチューニングの経験が浅い方にとって まず何をどうしてよいか分からない！？という状態 を解消することに重点を置いています。
11. 基本的なことを再確認することで パフォーマンスチューニングでやるべきことが明確 になることを期待しています。
12. ついでに Laravelが持つ基本的な機能がどのようなケースで 役立つのかを紹介します 必要十分な機能がすでに備わっています
13. アウトライン 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
14. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
15. 1. 全体を見る
16. 遅いとは？ とても曖昧な言葉。 私の「遅い」と あなたの「遅い」は比較出来ない 「遅い」は主観、個人差がある。
17. 曖昧な意見 「うちのウェブアプリケーション遅くない？」
18. 問題を提起しているように見えて何もかもが曖昧で 分からない このような「遅い」では改善が行えない。
19. 具体的な意見 「弊社のウェブアプリは 　平日18:00〜19:00の時間帯で 　通常よりも500msec応答速度が遅い」
20. コンテキストや数値が説明されることで、具体的な 状況が浮彫になってくる こういう「遅い」は改善につながる
21. まず、曖昧な「遅い」を数値で表せる「遅い」に変換 する必要があります。 「推測するな計測せよ」の世界です。
22. 状況が分かったとして、何が原因で「遅い」発生して いるかは分かりません。 原因究明のために、ウェブアプリに関わる全体をみ る必要があります。
23. ウェブアプリケーションは どのようにしてブラウザに表示されるのか？
24. ウェブアプリケーションの全体像 ネットワークはなぜつながるのか？ - 戸根勤（日経BP社） P10
25. 自分の領域の狭さを知る Laravel
26. アンコントローラブルな領域 ウェブアプリだけでは改善できない領域が沢山ある そもそもウェブアプリが「遅い」の原因なのかも分か らない
27. 遅いの原因をつきとめる なんとなくアタリをつけてはいけない エンジニアとして科学的に突き止める必要があるが ‥どうする？
28. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
29. 2. パフォーマンスを科学する
30. 「遅い」の考え方
31. レイテンシー 任意の状態から、任意の状態まで 待つためにかかった時間を計測した値 例） HTTPのリクエストからレスポンスまで DBのクエリ送信からデータ受信まで 詳解システム・パフォーマンス Brendan Gregg 西脇靖紘 長尾高弘（オライリー・ジャパン）
32. ウェブアプリ全体のレイテンシー ユーザー側 ネットワーク プロバ イダ プロバ イダ 光ファイバー等 サーバー側 ネットワーク
33. レイテンシーの中身をみて、ウェブアプリ単体のレス ポンスタイムがボトルネックで無い場合 ウェブアプリ以外で対処する方が効率が良い
34. 例えば大陸間のネットワーク通信 速度制限のかかった格安SIM 共有LAN内の輻輳 ウェブアプリ以外の遅さ
35. EC2で試してみる
36. Tokyo vs USA Tokyo Region Ubuntu 16.06 LTS N. Virginia Region Ubuntu 16.06 LTS
37. 東京のブラウザからアクセス Tokyo N. Virginia
38. 大陸間の移動でかかる時間 アメリカ大陸まで +200msec ウェブアプリケーションでは改善できない！ CDN等のソリューションが必要
39. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
40. 3. ウェブアプリの責任？
41. 全体のレイテンシーの中でサーバー側ネットワーク の占める割合が大きい場合 ウェブアプリをチューニングすることで得られる可能 性が高い ユーザー側 ネットワーク プロバ イダ プロバ イダ 光ファイ バー等 サーバー側 ネットワーク
42. レイテンシーにおけるウェブアプリ単体の占める時 間は、ウェブサーバーが記録する「レスポンスタイ ム」で知ることが出来る
43. レスポンスタイム 各ウェブサーバーはログにレスポンスタイムを出力 することが出来る。 Apache : %D Nginx : $request_time H2O : duration
44. ウェブアプリ単体のレイテンシー サーバー側ネットワーク ウェブサーバーのレスポンスタイム その他通信
45. ウェブアプリ全体のレイテンシーを確認して、ウェブ アプリ単体の応答時間に原因があると分かって、は じめて ウェブアプリのチューニングを開始できる。
46. しかし、ウェブアプリ単体のレスポンスが悪かったと して、本当にウェブアプリが悪いのでしょうか？ その「遅さ」はウェブアプリの責任？
47. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
48. 4. サーバーメトリクスを見る
49. ウェブアプリ以外の原因 同一サーバー上で動く他のプロセスがリソースを消 費しているケースがある 例）誰かが閉じ忘れたemacsのプロセスが100%で張 り付いてた…とか
50. 原因を探るための指標 メモリ使用量、CPU使用率、ディスクIO、ネットワーク IO etc… 継続的な測定が基本。中長期の傾向値が無いと判 断がしづらい
51. 測定ツール sysstatパッケージ ホスティングが提供するツール (CloudWatch) SaaSの監視ツール (Mackerel) インストール型の測定ツール (netdata)
52. sysstatパッケージ sar, pidstat, dstat ...
53. Mackerel
54. netdata
55. ボトルネックを特定する この段階では、プロセス単位でのCPU使用率、メモ リ使用量などから、どのプロセスがボトルネックに なっているのかを特定 一個ずつ一個ずつ、原因を絞り込んでいく
56. ついにウェブアプリが原因らしいということが分かっ た じゃあ、次は何をしたらいい？
57. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
58. 5. ウェブアプリの処理を特定する
59. ウェブアプリのどの処理が原因なのか？ どうやったら分かるのか？ この段階では 「PHPのプログラムが原因らしい」 としか分かっていない。
60. レスポンスタイムから探す ウェブサーバーのログから、レスポンスタイムが遅 いURLを探す awk, alp, kataribe等を使って簡単に解析できる
61. alpの例
62. ウェブ系ツールを頼る 自分はNew Relicしか使ったことないのですが、簡単 にボトルネックのURLや処理を特定することができ ます。
63. New Relicの例
64. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
65. 6. プロファイリングする
66. プロファイリング？ コード実行時にどの処理にどのくらいの時間がか かっているのかを計測したもの と、言葉で言われてもピンとこないので実例を見た ほうが早い
67. blackfire.ioの例
68. その他のツール Xdebug Xhprof tideways 他にもありそうです…
69. 処理が特定できて、プロファイラーの結果が取得で きたら、チューニングの準備がようやく整ったことに なる ここから、ウェブアプリ単体のレイテンシーについて 考えていく段階になる
70. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
71. 7. 改善ループを回す
72. ウェブアプリ単体のレイテンシー レスポンス出力 APIコール Routing DBクエリー Library読込 例）
73. この先は、レイテンシーの中でボトルネックになって いる処理をチューニングしていく この先は 1. レイテンシー確認 2. ボトルネック改善 3. レイテンシー確認... を延々と繰り返す
74. 改善ループ１
75. 改善ループ１
76. 理論上400msec程度のパフォーマンス改善が見込 める →仮に上手に改善できたとすると…
77. 改善ループ２
78. 改善ループ２
79. ボトルネックが他の処理に移ったことがわかる ここも改善することでさらに200msec →上手く改善すると...
80. 改善ループ３
81. 処理の特定さえ出来てしまえば、あとはTry&Errorを 繰り返すことでチューニングは達成することが出来 る。 処理の特定はプロファイラがやってくれる
82. 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任？ 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
83. 8. よくある問題とその対処
84. この先は、個別の象徴的なケースを例にとって、そ の対処法を説明します。 →Laravelにちょうどよい解決法があるものは[L] マークがついています！
85. HTTPのAPIコール 一回のリクエストで複数APIをコールするようになる と、途端に処理が遅くなる →更新頻度によってはCache [L] →自前APIであれば、専用APIにまとめてコール回 数を減らす →フロントのJSに移譲する
86. メール送信 SMTPとの通信は体感1secくらいかかる。複数メー ル送信がリクエストに同期的に書いてあると絶望的 に遅い →Queue [L]
87. Slack通知 これもメール送信と同じ。同期的な処理にしていると びっくりするほど遅くなります。 →Queue [L]
88. SQLクエリー実行 @soudai1025 のスライド見れば多分解決… 単発のクエリーが遅い場合は適切なDB設計と、イ ンデックス設計が効きます。 →SELECTであればCacheという手もあります。あま りオススメしませんが…[L]
89. リスト形式の表示で問題になるやつです。Laravelの relationをbladeから呼び出すと、カジュアルに大量 のクエリを発生させられます。 →eager loading [L] N+1クエリ
90. 入れ子のLoopとか、1万件とかのforeachとか、常識 を外れた蛮行によるもの… Laravel Collectionの乱用なども… →レビューや内部勉強会で防ぐしかない… 計算量が無駄に多いプログラム
91. こちらにも詳しく書きました https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita
92. 色々、見てきましたが処理の遅いプログラムの チューニング方法は対処方法が２つくらいしか無 い。 ・アルゴリズムの変更 ・非同期化
93. チューニングとは、全体を見ながら少しずつ少しず つ原因を特定していくプロセスです。 泥臭く追い込んでいく一連の作業をやってみると、 ウェブアプリの理解がさらに深まります。 最後に…
94. 参考資料 詳解システム・パフォーマンス Brendan Gregg 西脇靖紘 長尾高弘 オライリー・ジャパン ネットワークはなぜつながるのか？ 戸根勤 日経BP社 サーバー・インフラを支える技術 伊藤 直也, 勝見 祐己, 田中 慎司, ひろせ まさあき, 安井 真伸, 横川 和哉 WEB+DB PRESS plus