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

Webアプリケーションのパフォーマンス・チューニングの勘所 PHPカンファレンス沖縄2023 & PHP Conference Japan 2023

先に読んでおいてほしい      What is it?

https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo

https://speakerdeck.com/hanhan1978/web-application-tuning-guildline この資料は次のページにあります富所(@hanhan1978)さんがとても丁寧に説明している資料です。  • パフォーマンスチューニングに必要な概念、考え方  • パフォーマンスチューニングの基礎的なツールの説明 
でこの２つを見ておくとより理解が深まるのでオススメです。 

https://speakerdeck.com/soudai/basic-of-rdb

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

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

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

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

前述の資料を見たら    仕事で必要なことは全部書いてあります！  What is it?

ただし、少しだけ古いので    最新事情に合わせて話をします  What is it?

前述の資料を見たら    仕事で必要なことは全部書いてあります！  What is it?

1. 自己紹介  2. 計測の順番と勘所  3. スロークエリの勘所と対応  4. キャッシュの勘所と使い方  5. まとめ 
あじぇんだ

自己紹介  曽根壮大（38歳）  Have Fun Tech LLC 代表社員  株式会社リンケージ CTO 
  そ  • 日本PostgreSQLユーザ会勉強会分科会担当  • 3人の子供がいます（長女、次女、長男）  • 技術的にはWeb/LL言語/RDBMSが好きです  • コミュニティが好きたけ  ね  とも 

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

あじぇんだ

推測するな、計測せよ      計測の順番と勘所

推測するな、計測せよ  ↓  どこから計測すればいいの？  計測の順番と勘所

まず、計測に必要な情報を    整理することが最初  計測の順番と勘所

• アクセスログなどのWebサーバのログ  ◦ レイテンシーやリクエストされた回数など実際に思いエンドポイントを   見つけるために必要  ◦ LTSVやJSONなどの使いやすい形にフォーマットを指定することも重要   •
CPUやメモリなどのシステムメトリックの可視化  ◦ 最初はプラットフォームの提供サービスで十分   ◦ もう少し踏み込みたくなったらSaaS   • スロークエリログなどデータベースのログ  ◦ デフォルトでは吐き出さないので設定が大事   ◦ 集計ツールの都合に合わせる必要もあるので集計方法は先に決める   計測するために必要な情報

実際にどうやってみるかは前述の    資料たちを参考に  計測の順番と勘所

もう一歩踏み出すなら    Application Performance Monitoring  計測の順番と勘所

自分でやるなら    Open Telemetry Trace  計測の順番と勘所

楽がしたいなら    New RelicかDatadogのAPM  計測の順番と勘所

楽がしたいなら    New RelicかDatadogのAPM  計測の順番と勘所ドキュメントも豊富なのでまず SaaSのAPMから始めるのがおすすめ Spanをしっかり設定しましょう

ログの検索のアプローチ      計測の順番と勘所

定期的に検索して集計    または必要な時に検索  計測の順番と勘所

• ERRORやCRITICALの文字列を検索してalertを飛ばす  ◦ SaaSやクラウドサービスには仕組みが用意されている  ◦ AWSならEC2のsyslogをCloud Watch Logsに送る  • VPSの場合などにアクセスログを集計してリクエストされた回数や
レスポンスステータスを集計する  ◦ AWSならALBのメトリックを見ればアクセス数がわかるが、ない場合は自分で用意する必要がある  ◦ Mackerelだと mackerel-plugin-accesslog が便利  定期的に検索して集計の例

定期的に検索して集計    または必要な時に検索  計測の順番と勘所

• 障害対応のときに特定のキーワードによる検索  ◦ Linuxならgrepやlessで良かったがフルマネージドな  サービスの場合などは無いので代替が必要  ◦ AWSの場合は CloudWatch Logs Insights
が便利  ◦ 生ログで似たようなことがやりたい場合はtrdsqlが便利  • todo  必要な時に検索の例

計測したい理由を整理する      計測の順番と勘所

計測したい理由を整理する  ↓  無くても最低限は準備したほうが良い  計測の順番と勘所

ログやメトリックは    過去のデータはロストすると追加できない  計測の順番と勘所

いざ！計測！！      計測の順番と勘所

いざ！計測！！  ↓  どこから？  計測の順番と勘所ここが推測になっちゃうというジレンマ

最初にOSのメトリックを見るのが    全体を知れてよい  計測の順番と勘所

https://speakerdeck.com/soudai/linuxos-for-system-metrics

https://blog.a-know.me/entry/2017/02/02/215641 @a_knowさんが前述のシステムメトリックの項目の説明をブログにまとめてくれています。   まずは入門編としてはとても良いブログなので読んでみてください。   システムメトリックの詳細を知りたいなら『詳解システムパフォーマンス』が詳しく書いてありますが、1000ページ近いので高い
and 気合が必要です。内容は申し分なく充実しているので興味があれば。   もっと踏み込んで監視も学びたい！という人は『Webエンジニアのための監視システム実装ガイド』を読むと良いです。      

OSの状況を見て    CPUの振る舞いを確認しましょう  計測の順番と勘所

あじぇんだ

DBの負荷には色々ある      スロークエリの勘所と対応

DBの負荷には色々ある  ↓  どんなクエリが流れているか探る  スロークエリの勘所と対応

• 実行に数秒以上かかるようなスロークエリ  • N+1なINSERTでDisk I/Oなどが起因のクエリ  • 単発のクエリは早いがN+1な検索クエリ  • ロックが競合して待たされているクエリ  •
デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例

デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例最初以外のクエリはスロークエリログには出てこない！

デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例スロークエリログを見る

デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例 CPU、Disk i/o統計情報やテーブルのデータ量から類推できる。

デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例統計情報で類推できる。数が純粋に多い場合はスロークエリログの閾値を0秒にして出てきたクエリをカウントしてソートするとわかる

デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例ロック待ちは実行時間に含まれない timeoutする場合はエラーログに出るロックが頻発するとCPUも跳ねるテーブルロックの場合はUPDATEにWHEREのINDEXが足りていないことがほとんど

デッドロックで頻繁にkillされるクエリ  …etc  DBに負荷がかかる例アプリケーションやDBのログからkillされたことはわかるが、デッドロックの条件を見つけることが難しい。 SHOW ENGINE INNODB STATUSやpg_stat_activityで地道な検証と対応が必要になる。デッドロックのtimeoutを短くしてアプリケーション側でリトライすることで解決することも多い

DBのパフォーマンス改善の勘所      スロークエリの勘所と対応

DBのパフォーマンス改善の勘所  ↓  仕様を変えたほうが早いことが多い  スロークエリの勘所と対応

https://speakerdeck.com/soudai/release-small 不要なクエリを減らせるなら仕様を削ったほうが早い。  例えば一覧表示の総ページ数など  

DBのパフォーマンス改善の勘所 2      スロークエリの勘所と対応

DBのパフォーマンス改善の勘所 2  ↓  テーブル設計が悪い  スロークエリの勘所と対応

朝起きたら、改善する問題ではないので    これは頑張って直していくしかない  スロークエリの勘所と対応

あじぇんだ

キャッシュは麻薬      キャッシュの勘所と使い方

キャッシュは麻薬  ↓  使わなくて済むなら使わない！  キャッシュの勘所と使い方

https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching

それでもキャッシュを使うと言うんだね…      キャッシュの勘所と使い方

それでもキャッシュを使うと言うんだね…  ↓  最小限に抑えましょう  キャッシュの勘所と使い方

• キャッシュの多段、ダメゼッタイ！！  ◦ あくまで元のデータから常に取り出す  • キャッシュが消えてサービスも落ちる  • 間違ったキャッシュが保存されて、間違ったデータが表示される  ◦
ユーザ情報の場合はインシデント…  • データが壊れたときにどこで壊れたかわからない  …etc  キャッシュの地獄

キャッシュを作る勘所      キャッシュの勘所と使い方

クライアント  インターネット  サーバサイド  通信  DNS  BGP  ISP  サーバ  ネットワーク  アプリケーション 
キャッシュの勘所と使い方

クライアント  インターネット  サーバサイド  通信  DNS  BGP  ISP  サーバ  ネットワーク  アプリケーション 
キャッシュの勘所と使い方クライアントに近いところでキャッシュしたほうが効果は高いしかし、更新コストや難易度は上がる

• データの公開、参照の範囲が広いほうが良い  ◦ よく使われるし、出し分けもシンプル  ◦ 例えば全ユーザが表示する記事内容  • データが更新されにくい、または更新タイミングをコントロールできるようなデータ  ◦
例えば商品説明の内容  • 更新の反映が遅れてよいデータ  ◦ 実はリアルタイムじゃなくて良いことも多い  キャッシュと相性が良いデータ

逆のパターンは危険      キャッシュの勘所と使い方

逆のパターンは危険  ↓  仕様から見直しましょう  キャッシュの勘所と使い方

キャッシュは麻薬      キャッシュの勘所と使い方

1. 自己紹介  2. 計測の順番と勘所  3. スロークエリログの勘所と対応  4. キャッシュの勘所と使い方  5. まとめ 
あじぇんだ

良い資料が沢山あるので読みましょう      まとめ

まずは準備が大事    サービスを監視できるようにしましょう  まとめ

仕組みで問題を解決する      まとめ

まとめ

目の前のコードを直すことができるのは    自分たちだけ  まとめ

リリースして価値を提供しましょう      まとめ

ご清聴ありがとうございました      まとめ

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

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

More Decks by soudai sone

Other Decks in Technology

Featured

Transcript