計測ことはじめ 〜アプリケーションを知るために〜 / Introduction to Measurement - To know the application

https://phperkaigi.jp/2022/

Transcript

1. 計測ことはじめ
 〜アプリケーションを知るために〜
 PHPerKaigi 2022
 2022.4.10
 清家史郎
 1

2. 推測するな、計測せよ
 データはすべてを決定づける
 推測による行動を行うのではなく、
 計測した「データ」を元に原因を特定して、対策を講じる
 2

3. 自己紹介
 清家 史郎
 @seike460
 - ID
 - GitHub：seike460
 - Twitter：@seike460
 - Work at
 - 株式会社 Fusic （フュージック）
 事業本部/技術開発第一部門
 - チームリーダー/エバンジェリスト/プリンシパルエンジニア 
 - Skill
 - PHP／Go／AWS
 - Personal
 - Fukuoka.php Organizer
 - 46fm パーソナリティ
 3

4. Yagula リリースしました！
 4

5. Agenda
 5
 1. 計測ことはじめ
 2. 計測対象
 3. 計測実践
 4. まとめ
 5. AppIndex

6. 01 計測ことはじめ

7. 計測ことはじめ
 7
 計測とは 対象をあらゆる尺度から数値化して、数値化したものをもとに判定をすること Webシステムにおける計測とは アプリケーションをあらゆる角度から数値化して、数値化したものをもとに判定をすること アプリケーションを理解し、改善に繋げる
8. 再現性のある計測
 8
 再現性 何度行っても同じ結果、判断が得られる事が重要 プログラマーにおける経験に頼らない対応を行う 可視化 自分たちが理解しやすい形に変換することで、 特に難しい判断の部分の負荷を下げる
9. 計測で解消すべき事象
 9
 パフォーマンス 正常系としてアプリケーションは動作するが、パフォーマンスの問題がある アプリケーションの価値に直結する リソース効率 必要以上にサーバーリソースを消費してしまい、高いスペックを必要としている サーバーリソースの柔軟性が高い昨今では、コストメリットに繋がる 問題の可視化・特定 データ量の多さから認識出来ていなかった問題を認識する エンジニアの知識量、経験に頼った判断の難易度を下げる
10. 02 計測対象

11. Webアプリケーションにおける計測対象
 11
 - Webサーバー
 - スループット
 - PHP（アプリケーションサーバー） 
 - データベースサーバー
 - フロントエンド

12. Webサーバー
 12
 Webサーバー
 - 静的ファイルへのリクエスト数からキャッシュすべきファイルの特定 
 アクセスされたURLのランキングや時間分布などから 
 認識が難しい対処すべき問題の優先度を判断が可能 

13. スループット
 13
 スループット
 - ネットワークの外側から、アプリケーションの応答速度の計測 
 バーストアクセス発生時のアプリケーションの限界や、 
 限界を決めるボトルネックになるサーバーの特定に繋がる 

14. PHP（アプリケーションサーバー）
 14
 PHP（アプリケーションサーバー） 
 - プロファイラを使うことでPHPの処理を計測して可視化 
 特に認識の難しい関数レベルでの処理効率を認識することで、 
 パフォーマンスとリソース効率両方の改善が可能 

15. データベースサーバー
 15
 データベースサーバー
 - スローログにて遅いSQLの特定後、
 対象SQLのEXPLAIN結果を計測することで、 DB Indexの不備やそもそものSQL改善に繋げる

16. フロントエンド
 16
 フロントエンド
 - 各種リソースの不適切な容量での配信やフロントエンドから検知可能な問題の特定
 - アクセシビリティやSEOなどのフロントエンドにおける適切な状態をチェック

17. 03 計測実践

18. サービス利用

19. SaaS
 19

20. クラウドサービス
 20

21. 今回は自分たちで出来ることを考える
 21

22. Webサーバー

23. アクセスログの解析
 23
 まずは実世界の事象に対する計測を行うため 
 実際のアクセスログに対する解析を行います 
 ここではApacheでもNginxでも簡単に可視化できる「GoAccess」を利用します。 
 https://goaccess.io
 

24. アクセスログの解析
 24
 状況理解に以下の指標を利用
 
 - リクエストされたURL
 - 静的ファイルリクエスト数 - 時間分布 - HTTPステータスコード リクエストの多い静的ファイルに対するファイルのキャッシュ戦略立案や、 システム利用が多い時間帯の特定などに利用します。 リクエストされたURLをもとに、負荷テストを行うべき URLも特定できます。
25. スループット計測

26. スループット計測
 26
 スループット計測はLocustを利用します。　 https://locust.io Python製ではありますが簡単なスクリプトでログインなどの処理も可能で 
 ネットワークの外側から少しづつ負荷を上昇させることが出来るます。 
 簡単にWebアプリケーションのスループットの閾値を測定することが出来ます。 

27. サーバーリソースの確認
 27
 リクエストを徐々に増やしてスループットの閾値に到達した際に、
 閾値を決定づけるボトルネックになっているサーバを探します。
 サーバーの特定には各サーバのリソース状況を参照します。
 可能ならAmazon CloudWatchなどのメトリクスを計測できる 外部サービスを利用します。今回はできる限り低負荷のコマンドを駆使します。
 
 - 処理待ち状況、CPUの負荷
 - ディスクの負荷
 - メモリの負荷

28. 処理待ち状況、CPUの負荷
 28
 サーバの処理待ちの状況を確認するにはLoad Averageを確認します。 
 初期アプローチとしては処理コストが少ない「uptime」を使うのが適切です。 
 
 CPU状況も合わせて確認するには「htop」を使うと便利です。 
 CPUのコア数以上の処理待ちがある場合、 
 そのサーバーがボトルネックになっている可能性が高いです。 

29. メモリの負荷
 29
 メモリを100%使い切っている場合、スワップメモリを利用することになります。 
 スワップメモリは、ディスクをメモリ領域として確保して利用する為、 
 実質ディスクI/Oを発生させる事になります。 
 ディスクは非常に低速なデータ領域なのでボトルネックになる可能性が高いです。 
 
 「htop」や「vmstat」でスワップメモリの状況を確認出来ます。 

30. ディスクI/Oの状況
 30
 ディスクはデータの読み書きをする上で、一番低速な機器となります。 
 ディスクI/Oが大きい時は、パフォーマンス劣化の原因になっている事が多いです。 
 
 「vmstat」でディスクの読み込み、書き込みを確認する事が出来ます（bi / bo） 

31. PHPプロファイリング

32. PHPのパフォーマンス測定
 32
 負荷が高そうなURLの特定ができた場合、URLにて動作する 
 PHPのどの関数で問題が発生しているのかをプロファイラーを用いて確認します。 
 OSSになっているXdebugが比較的気軽に導入することが出来ます。 
 https://xdebug.org

33. Xdebug x qcachegrind
 33
 Xdebugにてプロファイルcachegrind.outを取得します。
 具体的な利用方法はこちらの記事をご確認ください。[tech.fusic.co.jp xdebug]で検索
 こちらのプロファイルを「qcachegrind」に読み込ませます。
 すると右図の用に図が生成出来ます。 
 
 - どの関数から呼び出されているか 
 - 処理を専有している関数
 - 繰り返し実行されている回数

34. qcachegrind
 34
 Called
 呼出し回数
 
 Self
 自身の実行時間

35. データベース
 実行計画

36. 遅いSQLの特定
 36
 PHPプロファイリングにて時間がかかっているのがRDB操作の関数であったり、 
 DBサーバのリソース枯渇している場合、RDBにボトルネックがあることがわかります 
 その場合、まずはスロークエリログにて問題の特定を行います。 
 今回はPostgreSQLを使った流れを記述しますが、設定内容は以下の通りです。 
 
 - PostgreSQL
 - log_min_duration_statement - MySQL
 - slow_query_log、long_query_time、log_queries_not_using_indexes、slow_query_log_file

37. pgBadgerによるスロークエリ可視化
 37
 スロークエリが大量に発生する時は、pgBadgerなどのツールを使って可視化します。（MySQLはanemoeater）
 図のようにスロークエリの可視化が出来ます。
 必要な設定に本番運用時に負荷がかかる設定を含みますので
 難しい場合はlog_min_duration_statementにより長い値を入れて本当に遅いSQLのみを抽出後
 以下のログのような「duration: XxxxX ms」と記述されているログを探して対処します。
 user=postgres,db=postgres LOG: duration: 67.301 ms statement: create database phperkaigi;

38. SQLの実行計画
 38
 スロークエリログにより、遅いSQLの特定が行えたら 
 対象SQLに対して実行計画を見て計測していきます。 
 
 実行計画を見ていくのであれば、最終的にどこが問題になっているかを 
 自分で判断していく必要があります。 

39. SQLの実行計画
 39
 https://github.com/simon-engledew/gocmdpev 
 そこで実行計画の問題を可視化してくれるgocmdpevを使います。 
 こちらを利用すると、実際の問題点を可視化してくれる為 
 適切な対応が取りやすくなります。 

40. フロントエンド

41. Lighthouse
 41
 フロントエンドの測定には 
 Google Chromeの開発者ツール 
 標準の「Lighthouse」を利用 
 
 パフォーマンスの他にも、 
 アクセシビリティやSEOの 状況も計測出来ます。
42. 実際のパフォーマンス問題
 42
 実際に問題が…
 - 画像サイズ
 - widthとheight
 記述漏れ

43. 残存事象だけで判断しなければならないわけではない
 残された事象だけで、適切な判断を行うのは職人技
 全エンジニアが職人になどなれるはずがない
 何よりも頼りになる「データ」収集、計測して原因を特定し、
 適切な優先順位をもとに対策を講じる
 43

44. まとめ
 Point 3
 様々なOSSを利用することで、作業のコストだけで計測を始める事が出来ます。 
 44
 推測するな、計測せよ。再現性のある対策を行いましょう。
 Point 1
 Point 4
 データの収集と計測、適切なステップを踏んで対処を行う 
 
 鍵は可視化。難しい判断の部分の負荷を下げましょう。
 Point 2

45. ご清聴いただきありがとうございました
 Thank You We are Hiring !
 https://recruit.fusic.co.jp/

46. Appendix
 05
47. CloudWatch (リソース計測) 
 47
 メトリクスデータを取得
 負荷がかかっているサーバーの 
 負荷を増やさずに計測が可能 
 - CPUの使用率
 - ディスクのI/O

48. RDS Performance Insights（DB計測）
 48
 RDS(DB)パフォーマンス可視化
 どのオペレーションに
 時間がかかっているかを計測可能 
 - 各オペレーションコスト
 - Insert
 - Update
 - Delete
 - fetch

49. RDS Performance Insights 
 49
 スロークエリログのように特に負荷がかかっているSQLの抽出を行ってくれる 
 こちらをひたすら解決すれば、パフォーマンスの改善が見込める 

50. CloudWatch RUM(フロントエンド) ウェブバイタル
 50
 ウェブバイタル
 レイテンシー状況の可視化

51. ページロードのステップ(httpsサイト)
 51
 ページロードのステップ
 どこのステップで時間がかかっているかを可視化 

52. ユーザジャーニー
 52
 ユーザジャーニー
 ユーザーの行動の可視化