本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第8章　既存システムの改善①：運用・可観測性・信頼性　·　レッスン42

可観測性の3本柱 ― メトリクス・ログ・トレース

導入

「既存システムを改善してください」と言われても、まず今の状態が見えていなければ何も直せません。改善の第一歩は、システムの状態を数値・記録・因果関係の3つの角度から把握できる状態にすることです。

説明

可観測性（Observability） は、一般に メトリクス・ログ・トレース の3本柱で構成されると言われます。それぞれAWSでは対応するサービスがあります。

柱何がわかるかAWSサービス
メトリクスCPU使用率・リクエスト数など時系列の数値CloudWatch Metrics / Alarms
ログいつ・何が・どんなエラーで起きたかの記録CloudWatch Logs（Logs Insightsで検索・分析）
トレース1リクエストが複数サービスをどう通ったか、どこで遅いかAWS X-Ray
flowchart LR
    U["リクエスト"] --> ALB["ALB"] --> L1["Lambda A"] --> L2["Lambda B"] --> DB["DynamoDB"]
    ALB -.メトリクス.-> CW["CloudWatch Metrics"]
    L1 & L2 -.ログ.-> CWL["CloudWatch Logs"]
    ALB -.トレース.-> XR["X-Ray"]
    L1 -.トレース.-> XR
    L2 -.トレース.-> XR
  • CloudWatch Alarm: メトリクスが閾値を超えたらSNS通知やAuto Scalingのアクションをトリガーする。「異常を検知したら自動で対処する」の起点。
  • CloudWatch Logs Insights: 大量のログをクエリ言語で横断検索・集計できる。障害調査の際に「エラーが増え始めた時刻」を素早く特定する。
  • X-Ray: マイクロサービス構成で、1リクエストがどのサービスをどれだけの時間で通過したかをサービスマップとして可視化する。「どこがボトルネックか」がひと目でわかる。

3本柱は互いに補完関係にあります。メトリクスの異常アラームで「何かがおかしい」に気づき、ログで「何が起きたか」を調べ、トレースで「どこで起きたか」を特定する、という流れです。

読んでみよう

分散アーキテクチャ（マイクロサービス・Lambda連携）で「レイテンシーの原因となっているサービスを特定したい」という要件はX-Rayを指す典型的なサインです。単に「異常を検知して通知したい」だけならCloudWatch Alarm、「大量のログから特定のエラーパターンを探したい」ならLogs Insightsというように、要件の粒度でサービスを使い分けてください。