SAP-C02-104 · セクション 12 / タスク 3.1

Monitoring / Logging Strategyを改善する

Amazon CloudWatch / メトリクス / ログ / ログ集約 / 可観測性 / シグナル / ノイズ / 監視戦略

既存環境の運用を評価すると、「監視しているつもりでも必要な状態を把握できない」「ログは存在するが障害調査に時間がかかる」といった問題が見つかることがあります。

重要なのは、収集できるデータを無条件に増やすことではありません。

知りたい状態
↓
必要なテレメトリ
↓
収集
↓
集約
↓
関連付け
↓
判断

ゴール

既存ワークロードについて、何を監視すべきか、どのテレメトリを収集・集約・関連付けるべきかを判断できる状態を目指します。

何を監視すべきか判断できる
メトリクスとログの役割を使い分けられる
不足しているテレメトリを特定できる
分散したログを集約する理由を説明できる
可観測性と単なるデータ収集の違いを説明できる
有用なシグナルとノイズを区別できる
業務成果と技術上の状態を結び付けられる

1. 監視戦略は「取得できるデータ」から始めない

既存環境を改善するとき、CloudWatchで取得できるものを全部取ることから始めると、目的のないデータが増えやすくなります。

先に確認するのは、

何が正常なら
このワークロードは期待どおり動いていると言えるか

です。例えば注文サービスなら、注文成功率、処理件数、処理時間、依存先の正常性、エラー発生状況などが候補になります。

さらに、注文や決済が正常に完了しているかなど、技術上の状態だけではなく業務成果も考慮します。

2. メトリクスは「状態の変化」を継続して見る

メトリクスは、時間とともに変化する数値を扱うのに適しています。

CPU使用率
メモリ使用量
リクエスト数
エラー数
レイテンシー
キューの深さ

Amazon CloudWatchはAWSサービスが提供するメトリクスだけでなく、カスタムメトリクスも扱えます。

メトリクスは「いつから増えたか」「どの程度増えたか」「通常時との差はどれくらいか」「現在は悪化傾向か」といった問いに向きます。

ただし、エラー率が増えたことが分かっても、個々のリクエストがなぜ失敗したかまでメトリクスだけで説明できるとは限りません。

3. ログは「そのとき何が起きたか」を詳しく残す

ログは個々のイベントや処理内容を調査するために使います。

処理結果
エラーコード
例外
ユーザー操作
リクエスト識別子
対象リソース
処理時刻

Amazon CloudWatch Logsでは、AWSサービスやアプリケーションから送信されたログをロググループやログストリームに格納し、検索・分析できます。

ログは「どの処理が失敗したか」「どのエラーが発生したか」「どのリクエストに関係するか」「失敗直前に何が起きたか」といった詳細調査に向きます。

4. メトリクスとログは競合するものではない

エラー率が上昇
        ↓
メトリクスで発生時刻を特定
        ↓
同じ時刻のログを確認
        ↓
失敗した処理・原因候補を特定

メトリクスは広く状態を見て、ログは詳細を掘るために使います。片方だけを選ぶのではなく、目的に応じて組み合わせます。

5. AWSサービスの標準メトリクスだけでは足りないことがある

Amazon EC2ではCPU使用率やネットワークなどのメトリクスをCloudWatchへ送信できます。一方、ゲストOS内部のメモリ使用量、アプリケーションログ、独自アプリケーションのメトリクスなど、標準の監視だけでは不足する情報があります。

その場合はCloudWatch エージェントを利用できます。

Amazon EC2
   │
   ├─ 標準CloudWatchメトリクス
   │
   └─ CloudWatch エージェント
         ├─ メモリ
         ├─ ディスク
         ├─ アプリケーションメトリクス
         └─ アプリケーションログ

重要なのはエージェント導入そのものではなく、正常性判断に不足しているテレメトリを特定し、必要な情報を補うことです。

6. 重要なのは「監視されていない部分」をなくすこと

既存環境では、一部だけ監視されていることがあります。

ウェブサーバー
CPU監視あり

アプリケーション
監視なし

データベース
接続数だけ監視

外部API
監視なし

このように状態を判断できない範囲は、観測上の盲点になります。

入口
↓
アプリケーション
↓
依存サービス
↓
データストア
↓
外部依存

まで見て、主要コンポーネントの状態を判断できるかを確認します。

7. 可観測性は「データが存在すること」ではない

可観測性は、メトリクスやログが存在するだけでは成立しません。それらの外部出力から、システム内部で何が起きているかを理解できることが重要です。

メトリクス
   ┐
ログ
   ├─ 関連付け → ワークロード状態の理解
トレース
   ┘

ここでは個別のトレースサービスや性能分析方法を掘り下げるのではなく、異なるテレメトリを関連付けられる状態を監視戦略として持つことが重要です。

8. ログ同士も関連付けられるようにする

複数コンポーネントにまたがる処理では、それぞれにログがあっても、どのログが同じリクエストなのか分からなければ調査に時間がかかります。

そのためログには、必要に応じてタイムスタンプ、リクエストID、トランザクションID、対象サービス、処理結果など、関連付けに利用できる情報を持たせます。

request-id = abc123

ウェブ
└─ abc123

アプリケーション
└─ abc123

決済
└─ abc123

これにより、同一処理を複数ログから追いやすくなります。

9. 分散したログは集約を検討する

ログが複数アカウント・複数リージョンに分散し、障害調査のたびに複数環境を移動するなら、ログ集約を検討します。

アカウントA / リージョンA ─┐
アカウントB / リージョンB ─┼→ 中央ログリポジトリ
アカウントC / リージョンC ─┘

CloudWatch Logsには、AWS Organizationsと連携し、複数アカウント・複数リージョンから中央アカウントへログをレプリケートするクロスアカウント・クロスリージョンログの一元化があります。

10. 「中央から見える」と「中央へログを複製する」は分けて考える

CloudWatchのクロスアカウントオブザーバビリティでは、監視アカウントから送信元アカウントのテレメトリを統合的に確認できます。

一方、CloudWatch Logsの一元化では、ログデータ自体を中央の送信先へレプリケートします。

中央から参照
≠
中央へログデータを複製

調査・保存・分析要件に応じて、ログを物理的に集約する必要があるかを判断します。

11. CloudWatch Logsの一元化では既存履歴を自動移行しない

CloudWatch Logsの一元化ルールを作成した場合、対象になるのはルール作成後に到着した新しいログデータです。

ルール作成前から存在する過去ログは、その一元化ルールによって自動的には中央化されません。

将来ログの中央化
と
既存履歴ログの移行
は分けて判断

12. 集める量ではなくシグナルの質を見る

大量のデータを集めるほど監視が良くなるとは限りません。

分類	例
シグナル	注文成功率の低下、エラー率の上昇、キュー滞留、依存サービス失敗
ノイズ	大量の重複ログ、不要なデバッグ出力、判断に寄与しない高頻度イベント

運用判断につながる情報を優先し、重要な情報が大量の不要データに埋もれないようにします。

13. ノイズを減らすことは「ログを消すこと」ではない

ノイズ削減とは、データをとにかく減らすことではありません。

障害検知に必要か
原因調査に必要か
業務成果確認に必要か
監査や保持要件に必要か

を基準にし、必要な詳細と有用なシグナルを残しつつ、不要な重複を減らします。

14. 技術指標と業務KPIを関連付ける

CPU使用率だけでは業務上重大なのか判断できないことがあります。一方、注文成功率や決済失敗率なら業務影響を直接把握できます。

業務KPI
        ↕
アプリケーションメトリクス
        ↕
インフラストラクチャメトリクス
        ↕
ログ / トレース

技術上の状態と業務成果を関連付け、ワークロードが期待する成果を提供できているかを判断します。

15. ダッシュボードは「表示すること」が目的ではない

ダッシュボードには、判断に必要な情報をまとめます。

サービス成功率
リクエスト量
エラー率
主要依存先の状態
関連する業務KPI

データが多い画面ではなく、「現在正常か」「どこを調べるべきか」を判断しやすい画面にします。

16. 監視戦略を改善する判断順序

1. 業務成果・正常状態を定義
        ↓
2. 必要なシグナルを決める
        ↓
3. メトリクス / ログ / トレースを選ぶ
        ↓
4. テレメトリ不足を補う
        ↓
5. 分散データを集約する
        ↓
6. データ同士を関連付ける
        ↓
7. シグナル / ノイズを見直す
        ↓
8. ダッシュボードで状態を判断できるようにする

ここまでが監視・ログ記録戦略です。

17. 代表的なアンチパターン

アンチパターン	なぜ問題か
取得できるメトリクスを全部監視すればよい	業務成果との関係が不明なままデータだけ増える
ログ量が多いほど可観測性が高い	量ではなく内部状態を理解できるかが重要
CPUが正常ならサービスも正常	アプリケーション、依存先、業務KPIまで確認する必要がある
ログは各サーバーにあるので中央化不要	多数の環境を巡回しなければ調査できない構成は運用効率を下げる
ログ一元化ルールを作れば既存履歴も自動移行される	現在のCloudWatch Logs一元化ではルール作成後の新しいログデータが対象
監視戦略を決めたので、すぐ自動修復まで同時に設計する	まず正常性シグナルを完成させ、その後にアラート条件や復旧アクションを設計する

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

既存環境で障害検知が遅く、ログが分散し、原因調査に時間がかかるなら、いきなり自動修復へ進みません。

何を知る必要があるか
        ↓
必要なメトリクスは何か
        ↓
必要なログは何か
        ↓
不足テレメトリは何か
        ↓
ログ集約が必要か
        ↓
相互に関連付けられるか
        ↓
ノイズが判断を妨げていないか

決定打は次のように整理できます。

要件・症状	判断
時間的な状態変化を追いたい	メトリクス
個別イベントの詳細原因を調べたい	ログ
EC2 / オンプレミスからOS内部メトリクスやログも収集したい	CloudWatch エージェント
複数アカウント・リージョンのログを中央リポジトリへ複製したい	CloudWatch Logsの一元化
データはあるが内部状態を理解できない	可観測性の改善
大量データで重要情報が埋もれる	シグナル / ノイズの見直し

まとめ

監視 / ログ記録戦略の改善では、データ量ではなく、必要な状態を理解できるかを中心に設計します。

業務成果
↓
正常性
↓
必要なシグナル
↓
メトリクス / ログ / トレース
↓
収集
↓
集約
↓
関連付け
↓
判断

Amazon CloudWatchは中心的な監視・ログ基盤として利用できます。ただし、CloudWatchを使っているだけで監視戦略が完成しているわけではありません。

何を観測し、なぜ収集し、どう関連付けて判断するのかまで設計します。

主要AWS公式資料

AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 3.1
AWS Well-Architected Framework — Operational Excellence Pillar
AWS Well-Architected Framework — Implement observability
AWS Well-Architected Framework — Utilize workload observability
Amazon CloudWatch — CloudWatch エージェントでメトリクス、ログ、トレースを収集
Amazon CloudWatch Logs — クロスアカウント・クロスリージョンログの一元化
Amazon CloudWatch — クロスアカウントオブザーバビリティ