これは何？
個人的に最近業務で、サービスの性能改善効果を計測するために、Webシステムのパフォーマンス監視を導入することになりました。
そこでパフォーマンス監視ツールについて有名なものを比較検討したので、この記事でまとめてみました。
対象読者
- 現場にパフォーマンス監視を導入したいと考えているひと
- 各監視ツールのメリデメを知りたいひと
比較表
最初に、今回取り上げるツールの比較を表でまとめてみます。
| 方法（ツール） | 導入コスト | 運用コスト | UX評価可能 | 要改善箇所の具体性 |
|---|---|---|---|---|
| LBログ | ◯ | ◯ | × | △ |
| Lighthouse | △ | ◯ | ◯ | × |
| WebPageTest API | △ | × | △ | × |
| Datadog RUM | × | △ | ◯ | × |
| Datadog APM | × | △ | × | ◯ |
【各項目の観点】
-
導入コスト: ツールの導入や自動化構成の構築に必要な工数。 -
運用コスト: 運用の金銭的コスト 及び Datadog上への指標表示を自動化できるか。
※ 指標をどこに表示したいかはプロジェクトによると思います。自分はすでに監視ツールとして導入していたDatadog上に出したかったため、今回はDatadogとしました。 -
UX評価可能: Core Web Vitals（後述） をはじめとするユーザ体験指標を計測可能か。 -
修正箇所の具体性: 計測結果を見て、どの機能を修正するべきかの分かりやすさ。（コードレベルやフロントエンド・バックエンドレベルかも分かれば◯）
評価は独断でつけたものです。プロジェクトによって導入・運用しやすさなど大きく変わるので、参考値として見てください。
以下で各監視ツールのメリット・デメリットなど、詳しく説明していきます。
方法1: LBアクセスログからのレイテンシ取得
構成
- GoogleCloud 外部LB（以下、GCLB）アクセスログをDatadogに送信
- ログ中のレイテンシを数値形式にパース
- パースしたものをカスタムメトリクスとし、Datadog上でダッシュボード化する。
メリット
- インフラ側の対応のみで導入できる（開発チームの工数不要）ため、比較的工数かけずに実現できる。
- マイクロサービス別 または 詳細なパス別 でレイテンシ表示できる。
- 平均 or パーセンタイル値でのレイテンシ取得可能
- Datadogが既に導入されている現場であれば、その他新しいツールの導入が必要ないので、運用コストを抑えられる。
デメリット
- サーバレスポンス時間の計測である（ターンアラウンドタイムの計測ではない）ため、実際の描画時間など・ユーザ体験の評価はできない。
- 具体的にどのリソース（ファイル）の読み込み・描画に時間かかっているかは分からない。
【補足】レイテンシの種類について
性能を表すレイテンシの指標は一般的に、下記2種類に分けられます。
-
レスポンスタイム: プロキシがサーバにリクエストを投げてから「処理を行い、レスポンスが返ってくるまで」の合計時間。 -
ターンアラウンドタイム: ユーザ（ブラウザ）がシステムにリクエストを投げてからサーバが処理を行い、レスポンスが返ってきて、それが描画されるまでの合計時間。
つまり、2.は1.を含むので必然的に、ターンアラウンドタイム > レスポンスタイム となる。
↓こちらご参考にさせていただきました。
そして、GCLBのアクセスログ中に出力されるレイテンシは、以下定義されています。
Average latency of request sent by the proxy to backend until proxy receives last byte of response from backend.
上記より、
GCLBのレイテンシ = プロキシ（LB）がバックエンド（k8s Service）にリクエストを送信してから最後のレスポンスが返されるまでの時間平均であることを考えると、GCLBのレイテンシは「1. レスポンスタイム」を指すもののようです。
方法2: Lighthouse
Google Lighthouseを利用し、主にWebページのCore Web Vitalsを計測する。
構成
以下2つが考えられる。
- Chrome拡張機能のLighthouseで手動計測
-
Lighthouse CI + GithubActions定期実行 + Datadogダッシュボードで自動計測
導入事例もご紹介されていました↓
メリット
- ページのパフォーマンス評価、アクセシビリティ、セキュリティ、SEOなど、Core Web Vitalsの計測が可能。
- 上述のLBログベース計測よりも、ユーザ視点の指標を計測することができる。
- 例えば、「サーバレスポンスが同じでも、画面描画は遅いケース」や「サイトの読み込みは早くても、ユーザの操作に対する反応が遅いケース」などであっても、それを含んだ指標計測が可能。
【手動計測の場合】
- 環境構築など必要なく、だれでも（非エンジニアでも）簡単に分析できる。
【自動計測の場合】
- インフラ側の対応のみで導入できる（開発チームの工数不要）ため、比較的工数かけずに実現できる。
- Datadogダッシュボードにより監視ツール一元化できる。
- 計測タイミング・計測項目をカスタマイズ可能。
デメリット
- システム全体（バックエンド・DB）のパフォーマンス監視はできず、フロントエンド画面上での分析となる。そのためボトルネックの調査が別途必要、
- Lighthouseはラボ環境での計測であるため、実際にアクセスしてくるユーザの条件（デバイススペック・ネットワーク・地理など）と乖離している可能性がある。そのためLighthouse計測が正確にユーザ体験を表しているとは限らない点が注意。
【手動計測の場合】
- 毎回手動で計測することになるので、運用負荷が高い。
【自動計測の場合】
- CI実装工数が必要。
方法3: WebPageTest API
Lighthouse同様、Webページのパフォーマンスを計測するツール。ただしCoreWebVitalsは計測されない。
Webサービス版（無料）とAPI版（有料）がある。
構成
以下2つが考えられる。
- Webサービスバージョンで手動計測
-
WebPageTest API + スプレッドシート + GoogleDataStudioで自動計測
実装例↓
※ 手動・自動計測のメリデメはLighthouseと同様。
メリット
- インフラ側の対応のみで導入できる（開発チームの工数不要）ため、比較的工数かけずに実現できる。
- 計測テスト中に各ページを複数回測定され、テスト条件の設定を変更できるなど柔軟な設定ができる。
- Waterfall図表示や、読み込み時間、レンダリング速度、ネットワーク使用量などを含む包括的な分析データを取得可能。
- 計測タイミング・計測項目をカスタマイズ可能。
デメリット
- システム全体（バックエンド・DB）のパフォーマンス監視はできず、フロントエンド画面上での分析となる。そのためボトルネックの調査が別途必要。
- Core Web Vitalsの計測は不可。
- 自動計測にはAPIが必要であり、APIは有料プラン。
- Datadogにダッシュボード化できるかは不明。（調べた範囲では事例ヒットしなかった）
方法4: Datadog RUM
RUM = リアルユーザモニタリング
フロントエンドのパフォーマンスに重点を置いた方法であるため、後述のDatadog APMよりもユーザー目線の計測ができる。
構成
各アプリケーションコードにSDKを埋め込む。
Datadog側でRUM有効化・ダッシュボード作成。
メリット
- Core Web Vitalsに関するユーザ目線の測定が可能。
- パフォーマンス改善
- Webページ、ユーザーアクション、フロントエンドコードのパフォーマンス追跡
- エラー原因特定
- アプリケーションバグの監視、検知
- ユーザー分析
- サイト利用者の位置情報、デバイスなどの収集、監視ページ訪問、クリック数の分析
- サポート
- ユーザー問い合わせ対応に必要なセッション時間、リソースエラーの収集
- パフォーマンス改善
- Datadogの機能に乗っかることができるので、既にDatadog導入されていればスムーズに導入できる。
デメリット
- コードの実装・Datadog側の設定が必要なため、導入コストは比較的高い。
- システム全体（バックエンド・DB）のパフォーマンス監視はできず、フロントエンド画面上での分析となる。そのためボトルネックの調査が別途必要。
- 運用時にDatadogコストが増加する。
方法5: Datadog APM
APM = アプリケーションパフォーマンスモニタリング
システム全体の監視に焦点を当てたパフォーマンスモニタリング。
各マイクロサービスからDatadogにトレースを送信することで実現する。
構成
各アプリケーションコンポーネントにAPMエージェント組み込み（コードやDBに組み込み）。
Datadog側でAPM有効化・ダッシュボード作成。
メリット
- サーバーサイドやデータベースといったバックエンドのパフォーマンス監視が可能。そのためボトルネックの調査・早期解決ができる。
- Datadogの機能に乗っかることができるので、既にDatadog導入されていればスムーズに導入できる。
デメリット
- ユーザ体験の評価ができない。画面描画速度や各ファイルの読み込み速度、Core Web Vitalsの分析はできない。
- 運用時にDatadogコストが増加する。
【補足】Core Web Vitalsについて
Googleが提唱する、Webサイトにおけるユーザ体験の質を評価するための中心となる指標。
現在は「読み込み、インタラクティビティ、視覚的な安定性」（後述）の3つの側面に焦点を当てているが、年々進化しており今後変化する可能性あり。
-
LCP（Largest Contentful Paint）
- 読み込み
- ページ内の最も大きい画像の描写時間の読み込み時間。つまり重要なコンテンツがどれだけ早く描画されるか。
- 2.5秒以下が目標値
-
FID（First Input Delay）
- インタラクティビティ
- ユーザーがサイト内で最初の操作（例えばリンクのクリック・フォーム入力など）を起こしてからの反応時間。
- 100ミリ秒以下が目標値
-
CLS（Cumulative Layout Shift）:
- 視覚的な安定性
- コンテンツ表示によりレイアウトのズレが発生する頻度。
- 0.1以下が目標値
Coreと書かれている通り、他にもWeb Vitals（ユーザ体験に関わるサイトの健全性を示す指標）は存在する。
例えば以下のような指標。
- Time to First Byte（TTFB）
- リソースをリクエストしてから、レスポンスの最初のバイトが到着し始めるまでの時間
- First Contentful Paint（FCP）
- ユーザーが最初にページに移動してから、ページのコンテンツのいずれかの部分が画面にレンダリングされるまでの時間
- Total Blocking Time（TBT）
- FCPとTTI の間のメインスレッドがブロックされている時間の合計
最後に
パフォーマンス監視について、代表的なツールを例に出して比較検討してみました。
ただ、今回挙げたもの以外にもツールは本当に多くありますし（例えばAWSならX-Ray, GoogleCloudならCloud Traceなど）。
何を導入すべきかは、現場の既存ツール構成やチーム体制などによって大きく異なります。
個人的には、最初は小さく始めるのが適切だと考えています（多くの工数かけて導入したわりに、実際は使わないデータが大半ということは極力避けたい）。
ハードルの低いものから導入して、パフォーマンス監視が浸透してきたら、何が必要かを見定めて増強させていくのが無駄もなく良いと思います。