← AWSサービスの内部原理 コース
75. 可観測性は3本柱の地図である — 数える・記録する・つなぐ、そしてこのコースの答え合わせ
1つの遅いリクエストの調査を題材に、可観測性の3本柱(メトリクス・トレース・ログ)がどう繋がって「いつから・どこで・何が」を突き止めるのかを図で追っていきます。そして最後に、このコース全編で見てきた「マネージドサービスの中身はコンピュータの基礎でできている」を1枚の地図で答え合わせします。
① 数える — メトリクスは時系列、p99が跳ねたと気づく
アプリが値を出すリクエストごとのレイテンシ(生の数値)
期間(period)で集計 → 統計量を選ぶ
メトリクス時刻順に並んだデータ点の集合
各データ点にタイムスタンプが1つp99でグラフを描く
Average異常が薄まる
Maximum1点で歪む
p99裾(遅い数%)を見る
異常の開始時刻と規模が読める
p99グラフ横軸=時間 縦軸=99パーセンタイル値
15:00を境に線が跳ね上がるいつから・どれくらいまだ「どこで・何が」は分からない
- メトリクスは「時刻順に並んだデータ点の集合(a time-ordered set of data points)」。名前・ネームスペース・0個以上のディメンションで一意に定まり、各データ点はタイムスタンプを1つ持つ。
- パーセンタイルの定義:「95パーセンタイルとは、データの95%がこの値より低く、5%が高いこと」。p95.0123456789 のように小数10桁まで指定可。API Gateway・Lambda・ALB などがパーセンタイル統計をサポート。
- 集計は「期間(period)」ごと。有効な period は 1, 5, 10, 30、または60の倍数。既定は60秒。標準解像度=1分粒度、高解像度=1秒粒度。
- 保持は解像度ごとに段階的:period 60秒→15日、300秒→63日、3600秒→455日(15か月)。古い点はロールアップされ粗い解像度に集約。
- 根拠: cloudwatch_concepts.html(Metrics / Percentiles / Periods / Resolution / Metrics retention)
メトリクスは「変数を時間軸で数えたもの」。平均や最大では隠れる遅さを、p99という裾の統計が拾い上げる。ここで分かるのは「いつから・どれくらい」まで——調査の入口。
② 状態機械が人を呼ぶ — アラーム
p99メトリクス数値の流れ
状態が変化し、指定期間ぶん維持された時だけ
INSUFFICIENT_DATAデータ不足
OK平常
ALARM違反が継続
3状態を遷移する状態機械通知が届く
アクション発火SNSトピックへ通知 / Auto Scaling ポリシー
人間が調査開始ノイズでなく持続した変化だけが人を呼ぶ
- アラームは「単一のメトリクスを、しきい値との相対で、時間をかけて監視する」。取りうる状態は OK / ALARM / INSUFFICIENT_DATA。
- 「アラームは持続的な状態変化に対してのみアクションを起こす(invoke actions for sustained state changes only)。ある状態に居るというだけでは発火しない」——単なる閾値超えではなく「変化 × 継続」。
- 公式が明記する例外が1つ:Auto Scalingアクションだけは、新しい状態に留まる間、毎分繰り返し実行される。
- 評価回数を3にすると3データ点の窓で比較。「最古の点が違反し、残りが違反または欠測」の時に通知。
- 基礎への接続:メッセージング編の可視性タイムアウト(見えない↔見える)と同じ有限オートマトン。数値の流れを、人間の注意という離散イベントに変換している。
- 根拠: cloudwatch_concepts.html(Alarms / Periods)、3状態と Auto Scaling の例外は「Using Amazon CloudWatch alarms」(AlarmThatSendsEmail.html)
アラームは「時系列という連続量」を「呼ぶ/呼ばない という離散状態」に変換する状態機械。だからノイズで鳴りっぱなしにならず、変化が続いた時だけ人を起こす。
③ どこで — トレースは因果の鎖、サービスマップとセグメント
トレースID付与最初に触れたX-Ray対応サービスが付与し下流へ伝播
X-Amzn-Trace-Id: Root=1-5759e988-…;Parent=53995c3f…;Sampled=1全トレースを重ね合わせて集計
トレース同じIDのセグメントを1本に集約
遅いセグメントのタイムラインを開く
クライアント
API GW
Lambda遅い!
このノード/エッジが赤くレイテンシ大DynamoDB推論セグメント
どこで遅いか判明1ノードに絞れた。でも「何が」起きたかはまだ
- 「X-Ray はサービスからデータを セグメント として受け取り、共通のリクエストを持つセグメントを トレース にまとめ、処理して サービスグラフ を生成する」。コンソールはサービスグラフからサービスマップを描く。
- 「最初に触れたX-Ray対応サービス(the first X-Ray-integrated service)がトレースIDヘッダを付け、下流へ伝播してレイテンシ・結果などを追跡」。ヘッダ名 X-Amzn-Trace-Id。
- サブセグメントは「下流呼び出しのより細かいタイミング情報」。DynamoDB のようにトレースを送らない先へは推論セグメント(inferred segment)を生成——それでもマップに下流依存が見える。
- セグメントドキュメントは最大64kB。グラフ/トレースデータの保持は30日。
- エッジは上流から見た往復レイテンシ、ノードは下流サービス自身が測った時間——両方の視点が並ぶ。トレースIDは分散サービスを跨いで1リクエストを縫い合わせる「相関ID」。
- 根拠: xray-concepts.html(Segments / Subsegments / Service graph / Traces / Tracing header)
トレースは「因果の鎖」。メトリクスが教えた「いつ」に対して、サービスマップとセグメントのタイムラインが「どこで」遅いかを1ノードまで絞る。
④ 何が — ログはイベントの記録、該当ストリームへ
遅かったノード特定の関数/ホスト
ソースごとの列を選ぶ
ロググループ保持・監視・アクセス制御の単位
該当時刻のイベントを読む
ログストリーム同じソースを共有するイベントの列
「何が」起きたかが文章で分かる
ログイベントタイムスタンプ+生メッセージの2要素
15:00:03 ERROR downstream timeout / retry 1/3 …メトリクスいつ・どれくらい
トレースどこで
ログ何が
- ログイベントは「監視対象が記録した活動の記録」で、プロパティは2つ:「イベント発生時刻のタイムスタンプ」と「生のイベントメッセージ」。メッセージは UTF-8。
- ログストリームは「同じソースを共有するログイベントの列(a sequence of log events that share the same source)」。ログストリームは1つのロググループに属する。
- ロググループは「保持・監視・アクセス制御の設定を共有するログストリームの集まり」。1ロググループ内のログストリーム数に上限なし。
- 基礎への接続:「タイムスタンプ+メッセージをソースごとの列に追記していく」——DynamoDB編・メッセージング編で繰り返し出てきた追記ログ(append-only log)そのもの。可観測性の「ログ」は、その追記ログを人間が読む用途に開いたもの。
- 根拠: CloudWatchLogsConcepts.html(Log events / Log streams / Log groups / Retention settings)
ログは「イベントの記録」。トレースが絞った1ノードの、該当ストリームだけを開けば「何が」起きたかが文章で読める。3本柱で「いつ・どこで・何が」が揃い、調査が閉じる。
⑤ 3本柱は独立でなく「変換」で繋がっている
ログイベントの記録
メトリクスフィルタ/EMFで数値を抽出トレース因果の鎖
X-Rayグループが一致トレース数を毎分集計さらにログ↔トレースはトレースIDで突合できる
メトリクス時系列の数値
同じ事実の3投影①→④の調査動線が滑らかに繋がる理由
- ログ→メトリクス:「メトリクスフィルタを使って、取り込んだイベントからメトリクスの観測値を抽出し、CloudWatchメトリクスのデータ点に変換できる」。メトリクスフィルタはロググループに割り当てられ、そのログストリーム全体に適用される。(EMF=Embedded Metric Format も、構造化ログを埋め込むことでログから非同期にメトリクスを生成する同系統の仕組み。)
- トレース→メトリクス:「グループは独自のサービスグラフ・トレースサマリー・CloudWatchメトリクスを生成できる。各条件に一致したトレース数のメトリクスが毎分(every minute)CloudWatchに発行される」。
- ログ↔トレース:トレースはヘッダ X-Amzn-Trace-Id の Root=… を全サービスへ伝播するので、ログにそのIDを載せておけば両者を結べる。
- 根拠: CloudWatchLogsConcepts.html(Metric filters)、cloudwatch_concepts.html(EMF / PutMetricData)、xray-concepts.html(Groups / Tracing header)
3本柱は別々の道具ではなく、同じ事実の3つの投影。ログを数えればメトリクスに、トレースを数えてもメトリクスに、ログとトレースはIDで縫える——だから①→④の調査動線が滑らかに繋がる。
⑥ 卒業制作 — マネージドサービスの中身は、知っている基礎でできている
DynamoDBハッシュ+B木+追記ログ
Lambdaプロセス分離+イベントループ
S3冗長化+階層化
API Gatewayリバースプロキシ+関門
そして可観測性は、全サービスを「観測する側」でもある
メッセージングat-least-once+追記ログの汎用化
認証/暗号デフォルト拒否+HMAC+鍵階層
可観測性時系列+状態機械+相関ID+サンプリング
中身を分解すると
入れ子構造観測ツール自身もまた同じ基礎でできている
CloudWatch Logs追記ログ(タイムスタンプ+メッセージ)
メトリクス時系列DB(ロールアップ付き)
X-Rayグループpub/subと毎分集計
- 追記ログの再登場:ログイベント=「タイムスタンプ+生メッセージ」の列(CloudWatchLogsConcepts.html)——DynamoDB編・メッセージング編と同じ構造。
- 時系列DB:メトリクス=「時刻順のデータ点集合」、古い点はロールアップして粗く保持(cloudwatch_concepts.html)。
- pub/sub と毎分集計:X-Rayグループはマッチしたトレース数を毎分CloudWatchへ発行(xray-concepts.html)。アラームのアクションはSNSトピックへ通知(cloudwatch_concepts.html)=メッセージング編のpub/sub。
- サンプリング:X-Ray既定は「毎秒最初の1リクエスト+追加分の5%」(xray-concepts.html)——全数記録しないことでコストと代表性を両立。
- 根拠: 3ソースすべて(上記各項)
このコースの答え合わせ:DynamoDBもLambdaもS3もAPI Gatewayもメッセージングも認証暗号も、中身はハッシュ・追記ログ・プロセス分離・冗長化・リバースプロキシ・状態機械・相関IDといった知っている基礎の組み合わせだった。そして可観測性はそれら全部を観測する側でありながら、自分自身もまた追記ログ・pub/sub・時系列DBという同じ基礎でできている——新しいサービスに出会っても、中身はきっと知っている基礎の組み合わせだ。