性能問題の調査を任されるたびに、「まず何を見ればいいのか」から毎回考え直すのは非効率だと感じていました。この記事ではWeb・APL・DBの3層構成を前提に、性能評価の目的と3ステップアプローチを整理しています。
性能評価の目的
図1: Webシステム3層性能評価 — クライアント・Web・AP・DBサーバの監視ポイント
Webシステムの性能評価とは、システムが「どのくらいの負荷まで安定して動作するか」「ボトルネックはどこにあるか」を定量的に把握することです。定性的な感覚や経験則ではなく、データに基づいた判断を行うことが重要です。
主な目的は次の3点です。
- 本番リリース前の性能要件への適合確認
- 障害・性能劣化が発生した際の原因調査
- キャパシティプランニング（将来のリソース見積もり）
3ステップアプローチ
性能評価は次の3段階で進めます。「まず全体を見てから詳細を掘り下げる」トップダウン分析が基本の流れです。
STEP 1 — データ収集
- 各サーバーに SSH 接続
- mpstat / free / iostat / vmstat を同時実行
- アクセスログを保存
STEP 2 — データ分析
- 各メトリクスをしきい値と比較
- 時系列で傾向を把握
- 問題が起きた時刻を特定
STEP 3 — ボトルネック特定
- 問題のあるサーバーを絞り込む
- 原因リソースを特定する
- 改善策を立案・実施
まず全体から異常を探し、次に詳細を掘り下げる「トップダウン分析」が基本です。
対象サーバーの役割と注目ポイント
一般的な Web システムは Web サーバー → APL サーバー → DB サーバー の3層構成です。それぞれ役割が異なるため、注目すべきメトリクスも異なります。
WEB — Web サーバー
| 項目 | 内容 |
|---|---|
| 主な役割 | HTTP リクエストの受付・SSL 終端、静的コンテンツの配信、APL サーバーへのプロキシ |
| 注目ポイント | 同時接続数・レスポンスタイム、ネットワーク帯域、CPU 使用率 |
APL — APL サーバー
| 項目 | 内容 |
|---|---|
| 主な役割 | ビジネスロジックの処理、DB へのクエリ発行、動的コンテンツ生成 |
| 注目ポイント | CPU 使用率・メモリ使用量、処理スレッド数、GC（ガベージコレクション）頻度 |
DB — DB サーバー
| 項目 | 内容 |
|---|---|
| 主な役割 | データの永続化・検索、SQL クエリの実行、キャッシュ管理 |
| 注目ポイント | ディスク I/O（最重要）、メモリ（バッファプール）、CPU・ロック競合 |
トップダウン分析の考え方
性能問題を調査する際は「症状 → サーバー → リソース」の順に絞り込みます。最初から特定のリソースを深掘りすると、根本原因を見逃しやすくなります。
- アクセスログで「いつ・どの URL が遅いか」を確認する（出発点）
- vmstat でシステム全体を俯瞰し、問題のある層を絞り込む
- 絞り込んだ層の詳細ツール（mpstat / iostat / free）で原因リソースを特定する
全体から細部へ。この順序を守ることで調査の迷走を防げます。
性能調査でよくある誤りと落とし穴
| 誤り | 何が起きるか | 正しいアプローチ |
|---|---|---|
| CPU使用率が高いのでサーバースペックアップを提案する | 原因がSQL非効率や不要なDB接続数超過の場合、スペックを上げても改善しない | vmstatのus/sy/waの内訳とプロセスごとのCPU消費を確認して原因を特定する |
| WEBサーバーのレスポンスタイムだけを見て「遅い」と判断する | APLサーバーでのビジネスロジック処理時間やDBクエリ時間を切り分けないと原因層が特定できない | アクセスログのURL別レスポンスタイムとDBスローログを突き合わせてボトルネック層を特定する |
| ピーク時間帯外にデータ収集して「問題なし」と判断する | 性能問題の多くはピーク負荷時にのみ発生する。閑散期の計測では再現できない | 問題が発生した時刻帯のメトリクスを確認し、ピーク時に合わせて収集スケジュールを設定する |
| 1台のサーバーだけ調査して完結させる | マルチサーバー構成ではボトルネックがWEB/APL/DBをまたぐことが多い | vmstatを全サーバーで同時実行して「どの層で処理時間が増えているか」を並列に比較する |