Webアプリケーションのパフォーマンス・チューニングの勘所 / web tuningperformance

# 参考資料
- https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo
- https://speakerdeck.com/hanhan1978/web-application-tuning-guildline
- https://speakerdeck.com/soudai/basic-of-rdb
- https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua
- https://fortee.jp/phpcon-2021/proposal/1e11a6b1-08d9-4044-9909-4c90105ea726
- https://fortee.jp/phperkaigi-2021/proposal/1d6859e3-26e4-4918-8603-44ecc3c61666
- https://speakerdeck.com/soudai/isucon10
- https://speakerdeck.com/soudai/linuxos-for-system-metrics
- https://blog.a-know.me/entry/2017/02/02/215641
- https://speakerdeck.com/soudai/release-small
- https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching

Transcript

1. Webアプリケーションの パフォーマンス・チューニングの勘所 PHPカンファレンス沖縄2023 & PHP Conference Japan 2023
2. 先に読んでおいてほしい
 
 
 What is it?
3. https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo
4. https://speakerdeck.com/hanhan1978/web-application-tuning-guildline この資料は次のページにあります 富所(@hanhan1978)さんがとても丁寧に説明し ている資料です。
 • パフォーマンスチューニングに必要な概 念、考え方
 • パフォーマンスチューニングの基礎的な ツールの説明
 でこの２つを見ておくとより理解が深まるので オススメです。

5. https://speakerdeck.com/soudai/basic-of-rdb
6. https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua MySQLもPostgreSQLも公式やコミュニティが実 行計画の素晴らしい資料があるのでそちらを参 考にしてください。
 特にPostgreSQLはコミュニティの動画がとても 参考になるので見てください。 
 もっと色々知りたい人は中国地方DB勉強会の 過去のスライドや動画を見るのがオススメで す。
 スライドの概要欄にURLリンクがあります。 

7. https://fortee.jp/phpcon-2021/proposal/1e11a6b1-08d9-4044-9909-4c90105ea726 清家(@seike460)さんがPHPカンファレンスで PHPの場合のツールやLinuxのコマンドによるプ ロファイリングついて説明しているのでこちらも とても参考になります。 

8. https://fortee.jp/phperkaigi-2021/proposal/1d6859e3-26e4-4918-8603-44ecc3c61666 清家(@seike460)さんが類似の内容で PHPerKaigi2021でも喋っているのでこちらも参 考になります。
 なんと清家さんは会場にいるので気になったら 本人に聞いて見ましょう。 
 優しく教えてくれます。 

9. https://speakerdeck.com/soudai/isucon10 前述の中国地方DB勉強会の中でSQLの改善 についても話をしています。 
 こちらも基礎的なSQLの改善について紹介して いるのでご参考ください。 

10. 前述の資料を見たら
 
 仕事で必要なことは全部書いてあります！
 What is it?
11. ただし、少しだけ古いので
 
 最新事情に合わせて話をします
 What is it?
12. 前述の資料を見たら
 
 仕事で必要なことは全部書いてあります！
 What is it?
13. 1. 自己紹介
 2. 計測の順番と勘所
 3. スロークエリの勘所と対応
 4. キャッシュの勘所と使い方
 5. まとめ
 あじぇんだ
14. 1. 自己紹介
 2. 計測の順番と勘所
 3. スロークエリの勘所と対応
 4. キャッシュの勘所と使い方
 5. まとめ
 あじぇんだ
15. 自己紹介
 曽根 壮大（38歳）
 Have Fun Tech LLC 代表社員
 株式会社リンケージ CTO
 
 そ
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます（長女、次女、長男）
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き たけ
 ね
 とも

16. 突然の宣伝
 
予防医療のリンケージ
 
 
 • リモートワークの不安を数値にするストレスチェック • 女性の健康課題をサポートする • リモートワーク、ちょっとした心配を相談できる安心をご提供 

17. 1. 自己紹介
 2. 計測の順番と勘所
 3. スロークエリの勘所と対応
 4. キャッシュの勘所と使い方
 5. まとめ
 あじぇんだ
18. 推測するな、計測せよ
 
 
 計測の順番と勘所
19. 推測するな、計測せよ
 ↓
 どこから計測すればいいの？
 計測の順番と勘所
20. まず、計測に必要な情報を
 
 整理することが最初
 計測の順番と勘所
21. • アクセスログなどのWebサーバのログ
 ◦ レイテンシーやリクエストされた回数など実際に思いエンドポイントを 
 見つけるために必要
 ◦ LTSVやJSONなどの使いやすい形にフォーマットを指定することも重要 
 • CPUやメモリなどのシステムメトリックの可視化
 ◦ 最初はプラットフォームの提供サービスで十分 
 ◦ もう少し踏み込みたくなったらSaaS 
 • スロークエリログなどデータベースのログ
 ◦ デフォルトでは吐き出さないので設定が大事 
 ◦ 集計ツールの都合に合わせる必要もあるので集計方法は先に決める 
 計測するために必要な情報
22. 実際にどうやってみるかは前述の
 
 資料たちを参考に
 計測の順番と勘所
23. もう一歩踏み出すなら
 
 Application Performance Monitoring
 計測の順番と勘所
24. 自分でやるなら
 
 Open Telemetry Trace
 計測の順番と勘所
25. 楽がしたいなら
 
 New RelicかDatadogのAPM
 計測の順番と勘所
26. 楽がしたいなら
 
 New RelicかDatadogのAPM
 計測の順番と勘所 ドキュメントも豊富なのでまず SaaSのAPMから始めるのがおすすめ Spanをしっかり設定しましょう
27. ログの検索のアプローチ
 
 
 計測の順番と勘所
28. 定期的に検索して集計
 
 または必要な時に検索
 計測の順番と勘所
29. 定期的に検索して集計
 
 または必要な時に検索
 計測の順番と勘所
30. • ERRORやCRITICALの文字列を検索してalertを飛ばす
 ◦ SaaSやクラウドサービスには仕組みが用意されている
 ◦ AWSならEC2のsyslogをCloud Watch Logsに送る
 • VPSの場合などにアクセスログを集計してリクエストされた回数や レスポンスステータスを集計する
 ◦ AWSならALBのメトリックを見ればアクセス数がわかるが、ない 場合は自分で用意する必要がある
 ◦ Mackerelだと mackerel-plugin-accesslog が便利
 定期的に検索して集計の例
31. 定期的に検索して集計
 
 または必要な時に検索
 計測の順番と勘所
32. • 障害対応のときに特定のキーワードによる検索
 ◦ Linuxならgrepやlessで良かったがフルマネージドな
 サービスの場合などは無いので代替が必要
 ◦ AWSの場合は CloudWatch Logs Insights が便利
 ◦ 生ログで似たようなことがやりたい場合はtrdsqlが便利
 • todo
 必要な時に検索の例
33. 計測したい理由を整理する
 
 
 計測の順番と勘所
34. 計測したい理由を整理する
 ↓
 無くても最低限は準備したほうが良い
 計測の順番と勘所
35. ログやメトリックは
 
 過去のデータはロストすると追加できない
 計測の順番と勘所
36. いざ！計測！！
 
 
 計測の順番と勘所
37. いざ！計測！！
 ↓
 どこから？
 計測の順番と勘所 ここが推測になっちゃうというジレンマ
38. 最初にOSのメトリックを見るのが
 
 全体を知れてよい
 計測の順番と勘所
39. https://speakerdeck.com/soudai/linuxos-for-system-metrics
40. https://blog.a-know.me/entry/2017/02/02/215641 @a_knowさんが前述のシステムメトリックの項 目の説明をブログにまとめてくれています。 
 まずは入門編としてはとても良いブログなの で読んでみてください。 
 システムメトリックの詳細を知りたいなら『詳解 システムパフォーマンス』が詳しく書いてあり ますが、1000ページ近いので高い and 気合 が必要です。内容は申し分なく充実している ので興味があれば。 
 もっと踏み込んで監視も学びたい！という人 は『Webエンジニアのための監視システム実 装ガイド』を読むと良いです。 
 
 

41. OSの状況を見て
 
 CPUの振る舞いを確認しましょう
 計測の順番と勘所
42. 1. 自己紹介
 2. 計測の順番と勘所
 3. スロークエリの勘所と対応
 4. キャッシュの勘所と使い方
 5. まとめ
 あじぇんだ
43. DBの負荷には色々ある
 
 
 スロークエリの勘所と対応
44. DBの負荷には色々ある
 ↓
 どんなクエリが流れているか探る
 スロークエリの勘所と対応
45. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例
46. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例 最初以外のクエリはスロークエリログには出てこない！
47. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例 スロークエリログを見る
48. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例 CPU、Disk i/o統計情報やテーブルの データ量から類推できる。
49. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例 統計情報で類推できる。 数が純粋に多い場合はスロークエリログの 閾値を0秒にして出てきたクエリをカウントしてソート するとわかる
50. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例 ロック待ちは実行時間に含まれない timeoutする場合はエラーログに出る ロックが頻発するとCPUも跳ねる テーブルロックの場合はUPDATEにWHEREのINDEXが足 りていないことがほとんど
51. • 実行に数秒以上かかるようなスロークエリ
 • N+1なINSERTでDisk I/Oなどが起因のクエリ
 • 単発のクエリは早いがN+1な検索クエリ
 • ロックが競合して待たされているクエリ
 • デッドロックで頻繁にkillされるクエリ
 …etc
 DBに負荷がかかる例 アプリケーションやDBのログからkillされたことはわかるが、 デッドロックの条件を見つけることが難しい。 SHOW ENGINE INNODB STATUSやpg_stat_activityで 地道な検証と対応が必要になる。 デッドロックのtimeoutを短くしてアプリケーション側でリトラ イすることで解決することも多い
52. DBのパフォーマンス改善の勘所
 
 
 スロークエリの勘所と対応
53. DBのパフォーマンス改善の勘所
 ↓
 仕様を変えたほうが早いことが多い
 スロークエリの勘所と対応
54. https://speakerdeck.com/soudai/release-small 不要なクエリを減らせるなら仕様を削ったほう が早い。
 例えば一覧表示の総ページ数など 

55. DBのパフォーマンス改善の勘所 2
 
 
 スロークエリの勘所と対応
56. DBのパフォーマンス改善の勘所 2
 ↓
 テーブル設計が悪い
 スロークエリの勘所と対応
57. 朝起きたら、改善する問題ではないので
 
 これは頑張って直していくしかない
 スロークエリの勘所と対応
58. 1. 自己紹介
 2. 計測の順番と勘所
 3. スロークエリの勘所と対応
 4. キャッシュの勘所と使い方
 5. まとめ
 あじぇんだ
59. キャッシュは麻薬
 
 
 キャッシュの勘所と使い方
60. キャッシュは麻薬
 ↓
 使わなくて済むなら使わない！
 キャッシュの勘所と使い方
61. https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching
62. それでもキャッシュを使うと言うんだね…
 
 
 キャッシュの勘所と使い方
63. それでもキャッシュを使うと言うんだね…
 ↓
 最小限に抑えましょう
 キャッシュの勘所と使い方
64. • キャッシュの多段、ダメゼッタイ！！
 ◦ あくまで元のデータから常に取り出す
 • キャッシュが消えてサービスも落ちる
 • 間違ったキャッシュが保存されて、間違ったデータが表 示される
 ◦ ユーザ情報の場合はインシデント…
 • データが壊れたときにどこで壊れたかわからない
 …etc
 キャッシュの地獄
65. キャッシュを作る勘所
 
 
 キャッシュの勘所と使い方
66. クライアント
 インターネット
 サーバサイド
 通信
 DNS
 BGP
 ISP
 サーバ
 ネットワーク
 アプリケーション
 キャッシュの勘所と使い方
67. クライアント
 インターネット
 サーバサイド
 通信
 DNS
 BGP
 ISP
 サーバ
 ネットワーク
 アプリケーション
 キャッシュの勘所と使い方 クライアントに近いところで キャッシュしたほうが効果は高い しかし、更新コストや難易度は上がる
68. • データの公開、参照の範囲が広いほうが良い
 ◦ よく使われるし、出し分けもシンプル
 ◦ 例えば全ユーザが表示する記事内容
 • データが更新されにくい、または更新タイミングをコントロールで きるようなデータ
 ◦ 例えば商品説明の内容
 • 更新の反映が遅れてよいデータ
 ◦ 実はリアルタイムじゃなくて良いことも多い
 キャッシュと相性が良いデータ
69. 逆のパターンは危険
 
 
 キャッシュの勘所と使い方
70. 逆のパターンは危険
 ↓
 仕様から見直しましょう
 キャッシュの勘所と使い方
71. キャッシュは麻薬
 
 
 キャッシュの勘所と使い方
72. 1. 自己紹介
 2. 計測の順番と勘所
 3. スロークエリログの勘所と対応
 4. キャッシュの勘所と使い方
 5. まとめ
 あじぇんだ
73. 良い資料が沢山あるので読みましょう
 
 
 まとめ
74. まずは準備が大事
 
 サービスを監視できるようにしましょう
 まとめ
75. 仕組みで問題を解決する
 
 
 まとめ
76. まとめ
77. 目の前のコードを直すことができるのは
 
 自分たちだけ
 まとめ
78. リリースして価値を提供しましょう
 
 
 まとめ
79. ご清聴ありがとうございました
 
 
 まとめ