Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ryo Tomidokoro
February 16, 2019

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

Laravel Jp Conferenceの資料です。

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

Ryo Tomidokoro

February 16, 2019
Tweet

More Decks by Ryo Tomidokoro

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. はじめに

    View Slide

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

    View Slide

  6. いきなりですが質問です

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. 1. 全体を見る

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  21. まず、曖昧な「遅い」を数値で表せる「遅い」に変換
    する必要があります。
    「推測するな計測せよ」の世界です。

    View Slide

  22. 状況が分かったとして、何が原因で「遅い」発生して
    いるかは分かりません。
    原因究明のために、ウェブアプリに関わる全体をみ
    る必要があります。

    View Slide

  23. ウェブアプリケーションは
    どのようにしてブラウザに表示されるのか?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. 「遅い」の考え方

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. EC2で試してみる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. 3. ウェブアプリの責任?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  53. Mackerel

    View Slide

  54. netdata

    View Slide

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

    View Slide

  56. ついにウェブアプリが原因らしいということが分かっ

    じゃあ、次は何をしたらいい?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  61. alpの例

    View Slide

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

    View Slide

  63. New Relicの例

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  67. blackfire.ioの例

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  71. 7. 改善ループを回す

    View Slide

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

    View Slide

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

    View Slide

  74. 改善ループ1

    View Slide

  75. 改善ループ1

    View Slide

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

    View Slide

  77. 改善ループ2

    View Slide

  78. 改善ループ2

    View Slide

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

    View Slide

  80. 改善ループ3

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide