Performance MonitoringとBottleneck分析

ゴール

パフォーマンス目標を定義しても、

p95レイテンシー
≤ 300ミリ秒

という条件だけでは、目標を満たせない原因は分かりません。

例えば実測値が、

p95レイテンシー
800ミリ秒

だったとしても、

コンピューティング不足
データベース待ち
ストレージI/O
外部API
ネットワーク
アプリケーションコード

のどこが制約になっているかは別途調べる必要があります。

パフォーマンス分析では、

パフォーマンス目標
↓
実測
↓
基準値との比較
↓
症状の範囲を絞る
↓
メトリクス
↓
トレース
↓
必要ならプロファイリング
↓
ボトルネック候補を特定

と進めます。

目標は、「遅いから大きいリソースへ変える」のではなく、測定結果から実際に性能を制限している箇所を特定できることです。

1. 目標・実測・ベースラインを分ける

最初に3つを分けます。

例えば、新規ソリューションの代表負荷で、

目標
p95 ≤ 300ミリ秒

正常状態のベースライン
p95 = 220ミリ秒

別の試験実行
p95 = 420ミリ秒

だった場合、

目標未達
+
正常状態からも逸脱

と判断できます。

一方、

ベースライン
=
パフォーマンス要件

ではありません。

ベースラインは観測した基準値であり、目標は達成する必要がある条件です。

2. ベースラインは代表負荷の「正常状態」を記録する

新規ソリューションの性能試験では、代表的な負荷条件で正常に動作している状態を基準として記録します。

例えば、

5,000リクエスト/秒

p95レイテンシー
220ミリ秒

CPU使用率
55%

DB接続数
300

という状態です。

別の試験実行で、

同じ5,000リクエスト/秒

p95レイテンシー
700ミリ秒

CPU使用率
56%

DB接続数
950

となった場合、

負荷条件
→ 同じ

CPU
→ ほぼ変化なし

DB接続数
→ 大幅に増加

レイテンシー
→ 悪化

という差を確認できます。

比較時には、

代表的な負荷条件
測定範囲
統計方法

を揃えます。

目的は変更前後の改善効果を評価することではなく、同じワークロード条件で正常状態から外れた測定値を見つけ、調査対象を絞ることです。

3. Amazon CloudWatchで時系列の状態を見る

Amazon CloudWatchでは、AWSリソースやアプリケーションのメトリクスを時系列で確認できます。

例えば、

CPU使用率
メモリ使用率
リクエスト数
レイテンシー
エラー率
ディスクI/O
ネットワーク量
キューの深さ

などです。

CloudWatchを使うと、

負荷増加
↓
CPU上昇
↓
レイテンシー上昇

のような時間的な関係を確認できます。

あるいは、

レイテンシー上昇
↓
CPUは変化なし
↓
別の制約を調査

という判断もできます。

重要なのは、1つのメトリクスだけで原因を決めないことです。

4. 高い利用率＝必ずボトルネックではない

例えば、

CPU使用率
95%

だからといって、CPUが必ず性能問題の原因とは限りません。

逆に、

CPU使用率
30%

だからといって、性能問題が存在しないとも限りません。

アプリケーションが、

データベース応答待ち
外部API応答待ち
ストレージI/O待ち
ロック待ち

になっていれば、CPUに余裕があっても利用者のレイテンシーは悪化します。

したがって、

パフォーマンス目標未達
↓
関連する複数の測定値を確認
↓
どの値が負荷増加とともに制約へ近づくか

を見ます。

5. メトリクスは傾向を示すが、1リクエストの経路までは分からない

例えばCloudWatchで、

API
p95 = 800ミリ秒

と分かっても、

利用者
↓
API
↓
注文サービス
↓
決済サービス
↓
不正検知サービス
↓
データベース

のどこで時間を消費したかまでは、集約メトリクスだけでは分からない場合があります。

そこで分散トレースを利用します。

6. AWS X-Rayでリクエスト経路を追う

AWS X-Rayのトレースでは、分散アプリケーションを通過したリクエストを追跡できます。

例えば、

注文API          80ms
  ↓
決済サービス    650ms
  ↓
不正検知        520ms
  ↓
DB               30ms

と分かれば、

エンドツーエンド
800ms

という症状から、

不正検知サービスへの呼び出し

へ調査対象を絞れます。

X-Rayのトレースマップでは、高レイテンシーの接続やエラーが発生しているサービスを識別できます。

つまり、

メトリクス
→ いつ・どの指標が悪化しているか

トレース
→ 1つのリクエストがどこで時間を使ったか

という役割の違いがあります。

7. 現在のX-Ray計装ではOpenTelemetryを意識する

AWS X-Rayによるトレース分析は現在も利用できます。

一方、X-Ray SDKとX-Rayデーモンは、2026年2月25日からメンテナンスモードに入っています。

AWSは、新しい計装についてOpenTelemetryへの移行を推奨しています。

したがって新規設計では、

アプリケーション
↓
OpenTelemetryによる計装
↓
トレース
↓
AWS X-Ray

という構成を優先的に評価します。

ここで区別するのは、

X-Rayによるトレース分析

と、

旧X-Ray SDK / X-Rayデーモンを
新規計装の標準として採用すること

です。

同じものではありません。

8. CloudWatch Application Signalsもアプリケーション性能を関連付ける

現在のAmazon CloudWatchにはApplication Signalsがあり、

呼び出し量
可用性
レイテンシー
障害
エラー

などのアプリケーション指標とトレースを関連付けて確認できます。

また、アプリケーションマップから、

サービス
↓
依存関係
↓
関連メトリクス
↓
関連トレース

へ掘り下げることもできます。

SAP-C02では個々の画面操作を覚えるより、メトリクスだけで原因が分からない場合に、依存関係とトレースへ調査範囲を広げるという判断を押さえます。

9. Amazon Managed Service for PrometheusはPrometheus互換メトリクスを扱う

Amazon EKSやKubernetes環境などで、

/metrics

からPrometheus互換メトリクスを公開するワークロードがあります。

大量のPrometheusメトリクスを扱いたいが、

Prometheusサーバー
ストレージ
可用性
スケーリング

を自前で管理したくない場合、Amazon Managed Service for Prometheusを利用できます。

コンテナワークロード
↓
Prometheus互換メトリクス
↓
Amazon Managed Service for Prometheus
↓
PromQL
↓
集計・分析

という役割です。

重要な決定条件は、

Prometheus互換
+
PromQL
+
大規模なメトリクス
+
基盤管理を減らしたい

です。

10. Amazon Managed Grafanaは可視化・相関のレイヤー

Amazon Managed Grafanaは、

Amazon CloudWatch
Amazon Managed Service for Prometheus
AWS X-Ray

などをデータソースとして利用できます。

例えば、

CloudWatch
→ AWSリソース / アプリケーションメトリクス

Amazon Managed Service for Prometheus
→ Prometheus互換メトリクス

AWS X-Ray
→ トレース

             ↓

Amazon Managed Grafana
→ ダッシュボード
→ 横断可視化
→ 相関分析

という使い方ができます。

ここで重要なのは、

Grafana
=
すべてのテレメトリを保存する場所

ではないことです。

主責任は、複数のデータソースをクエリし、可視化・相関分析することです。

11. メトリクス → トレース → プロファイリングと深くする

調査粒度は段階的に細かくします。

例えば、

利用者レイテンシー悪化

を確認したら、

メトリクス
↓
どのコンポーネントと相関しているか

を確認します。

次に、

トレース
↓
どのサービス / 依存関係で時間を消費しているか

を調べます。

それでも、

価格計算サービス内部
700ミリ秒

までしか分からず、

そのサービスの
どのコード経路が重いのか

を調べる必要がある場合は、プロファイリングへ進みます。

メトリクス
→ コンポーネントの状態

トレース
→ サービス間の処理経路

プロファイリング
→ プロセス / コード内部のホットスポット

と調査粒度が変わります。

12. ボトルネックは「性能を制限している箇所」

ボトルネックは、ワークロード全体の性能向上を現在制限している箇所です。

例えば、

ウェブ層CPU
30%

アプリケーション層CPU
40%

データベース
接続数 上限付近
待ち時間 急増

なら、ウェブ層を増やしても全体性能が改善しない可能性があります。

ただし、

最も利用率が高い
=
必ずボトルネック

と機械的に判断しません。

負荷を増やしたときに、

どのリソースが制約へ達するか
どの待ち時間が増えるか
どこでスループットが頭打ちになるか

を測定結果から確認します。

13. ボトルネック分析では症状から段階的に絞る

例えば、

目標
5,000リクエスト/秒
p95 ≤ 300ms

実測
5,000リクエスト/秒
p95 = 800ms

だったとします。

まず、

目標未達

を確認します。

次にメトリクスを見ると、

ウェブ層CPU              25%
アプリケーション層CPU    35%
データベースCPU          40%

であり、CPUだけでは原因が分かりません。

X-Rayのトレースを見ると、

注文API        800ms
└─ 決済        650ms
   └─ 不正検知 520ms

でした。

この時点では、

全サーバーを増やす

のではなく、

不正検知への依存

を現在のボトルネック候補として、さらにその処理時間や関連メトリクスを確認します。

14. ベースラインは「正常時の物差し」として使う

現在値だけでは、

CPU 65%

が高いのか正常なのか判断できない場合があります。

例えば代表負荷での正常状態が、

CPU 60〜70%
p95 180〜220ms

なら、CPU 65%自体は異常ではありません。

一方、

正常時
DB接続数 300

同じ代表負荷で性能悪化時
DB接続数 950
上限 1,000

なら、重要な変化です。

ベースラインによって、

通常の範囲

と、

正常状態から外れた値

を分けやすくなります。

15. ベースラインと代表負荷を対応させる

ベースラインを作るときは、代表的な負荷条件を記録します。

例えば、

5,000リクエスト/秒
↓
p95 220ms
CPU 55%
DB接続数 300

という基準値があります。

同じ5,000リクエスト/秒で、

p95 700ms
CPU 56%
DB接続数 950

となったなら、

負荷条件は同じ
↓
CPUはほぼ変化なし
↓
DB接続数が上限へ接近
↓
レイテンシー悪化

という関係が見えてきます。

単一の瞬間値ではなく、同一の代表負荷に対する複数の測定値の関係を見ることが重要です。

16. サービスを選ぶ前にボトルネックを特定する

性能が悪いからといって、

より大きいEC2
高速なストレージ
別のデータベース
キャッシュ追加

を先に選びません。

まず、

目標
↓
測定
↓
ベースライン比較
↓
メトリクス
↓
トレース
↓
必要ならプロファイリング
↓
ボトルネック特定

まで進めます。

その後で初めて、

どのコンピューティングを選ぶか
どのストレージを選ぶか
どのデータベースを選ぶか
キャッシュやバッファを使うか

を判断します。

17. サービス・測定方法の使い分け

1つのサービスですべてを解決するのではなく、知りたい情報の粒度に合わせて測定方法を選択します。

18. よくある誤判断

19. SAP-C02での判断フロー

パフォーマンス目標
        ↓
代表的な負荷で測定
        ↓
目標を満たす？
├─ はい
│   ↓
│  正常状態のベースラインとして記録
│
└─ いいえ
    ↓
    業務KPI / エンドツーエンド指標を確認
    ↓
    コンポーネントメトリクスを比較
    ↓
    原因範囲を特定できる？
    ├─ はい
    │   ↓
    │  ボトルネック候補
    │
    └─ いいえ
        ↓
        分散トレース
        ↓
        遅いサービス / 依存関係を特定
        ↓
        サービス内部まで調べる必要がある？
        ├─ いいえ
        │   ↓
        │  ボトルネック候補
        │
        └─ はい
            ↓
            プロファイリング
            ↓
            コード内部の制約を特定

まとめ

パフォーマンス問題は、

遅い
↓
リソースを増やす

では解きません。

まず、

パフォーマンス目標
+
代表負荷
↓
測定
↓
ベースライン比較

を行います。

その後、

メトリクス
→ 状態と傾向

トレース
→ リクエスト経路と依存関係

プロファイリング
→ コード内部

へ段階的に掘り下げます。

Amazon CloudWatch、AWS X-Ray、Amazon Managed Service for Prometheus、Amazon Managed Grafanaは同じ役割ではありません。

SAP-C02では、「どの監視サービスを使うか」だけでなく、「性能目標未達という症状から、どの測定データを使って制約箇所まで絞り込むか」を判断できることが重要です。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド — タスク 2.5 パフォーマンスモニタリングテクノロジー
• PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する
• Amazon CloudWatch — メトリクス・アプリケーションパフォーマンスモニタリング
• AWS X-Ray トレースマップ — 分散トレース・高レイテンシー接続の特定
• X-Ray SDK とデーモンのサポートタイムライン — OpenTelemetryへの移行
• Amazon Managed Service for Prometheus — Prometheus互換メトリクス・PromQL
• Amazon Managed Grafana — 複数データソースの可視化・相関分析