JavaScriptは無効です。本文・図・リンクは読めます。問題の解説は「解答・解説を読む」を開いて確認できます。自動採点・検索・進捗保存はJavaScript有効時に使えます。

CHAPTER 07 / D4

監視・調査・最適化

メトリクス、ログ、トレースから原因を絞り込む。

一読の目安 25分図・具体例・確認問題

01 / メトリクス・ログ・トレースを使い分ける

情報	答えやすい問い	AWSの例
メトリクス	いつから、どの程度、悪化したか	CloudWatchのエラー数、Duration、Throttles、キューの滞留
ログ	その要求で何が起きたか	CloudWatch Logsの例外、業務イベント、リクエストID
トレース	複数サービスのうち、どこで時間がかかったか	X-Ray / OpenTelemetryによる分散トレース
監査イベント	誰が、いつ、どのAWS APIを操作したか	CloudTrail。アプリの業務ログとは役割が異なる

一つの遅いリクエストを追いかける — API全体の時間を、Lambdaの処理と外部呼び出しに分解します。メトリクスで悪化を見つけ、トレースで区間を特定し、関連ログで詳細を調べます。

平均値だけだと、一部の利用者の極端な遅延を見落とします。p95やp99は、それぞれ95%、99%の要求がその時間以下だったという目安です。エラー数はリクエスト総数に影響されるので、エラー率も合わせて見ます。

02 / 調べられるログを残す

JSONなどの構造化ログにすると、requestId、orderId、level、errorTypeなどのフィールドで絞り込めます。秘密のトークン、認証情報、個人情報を丸ごと記録するのは避け、必要な識別子を残します。

構造化ログの例（架空データ）

{"level":"ERROR","requestId":"req-123","orderId":"O123","errorType":"PaymentTimeout","durationMs":820}

CloudWatch Logs Insights QL：エラーを5分ごとに集計

fields @timestamp, level, errorType, requestId
| filter level = "ERROR"
| stats count(*) as errors by bin(5m), errorType
| sort errors desc

ロググループと対象時間を絞ると、調査対象とスキャン量を減らせます。特定の要求を調べる場合は、requestId等で検索し、関連するトレースへつなげます。

独自の業務指標はカスタムメトリクスやEmbedded Metric Formatなどで送れます。メトリクスのディメンションへ全リクエストの一意IDを入れると系列数が増えるため、一意IDは主にログやトレースで扱います。

公式資料：Logs Insights QL の構文

03 / X-RayとOpenTelemetry

X-Rayではリクエストをサービス間で追跡し、時間がかかった区間やエラーを探します。segment / subsegment、trace ID、サンプリング、検索に使うannotationと詳細情報を持つmetadataなどの概念を押さえます。

アプリに計測を加えるときは、OpenTelemetryやAWS Distro for OpenTelemetry（ADOT）も学びます。OpenTelemetryは計測・収集の標準で、X-Ray等はデータの送信先になれます。全要求が必ず記録されるとは限らないので、サンプリングや伝播設定も確認します。

公式資料：X-Ray の計測から OpenTelemetry への移行

04 / 症状から原因を絞り込む

症状	まず見る場所	考えられる次の一手
APIが429を返す	API Gatewayのスロットリング設定、使用量、バックエンドの容量	再試行にバックオフ。上限・実負荷・設計を見直す
APIが502を返す	API Gatewayのログ、Lambdaの例外と戻り値	プロキシ統合の形式や関数エラーを確認
LambdaのThrottlesが増える	同時実行数、Reserved concurrency、リージョンの枠	下流の容量も見ながら枠・負荷平準化を検討
LambdaのDurationが伸びる	トレースの下流区間、ログ、メモリ使用量	CPU・メモリ、接続の再利用、外部サービスを調査
SQSの滞留が増える	件数に加えApproximateAgeOfOldestMessage、処理エラー、DLQ	ワーカー容量、失敗メッセージ、下流の遅さを確認
Streamsの処理が遅れる	IteratorAge、バッチ失敗、シャードの偏り	詰まったレコード、再試行設定、キーや並列性を確認
DynamoDBでスロットリング	テーブル・GSIの容量、キーの偏り、例外の詳細	アクセス分散、Query化、容量の設定を検討
AccessDenied	呼び出し主体、対象ARN、各ポリシー、KMS	どのAPIとリソースが拒否されたかを特定

同じエラーコードでも複数の原因があり得ます。まず対象の時間、変更点、影響範囲を絞り、実際のログとメトリクスで仮説を確認します。設定を片端から大きくする方法では、原因と費用が見えにくくなります。

05 / アラームと最適化の考え方

CloudWatch Alarmは、評価期間・閾値・必要なデータポイント数・欠損データの扱いを決めて使います。通知にはSNSなどを連携できます。デプロイ時は「エラー率が増えたら切り戻す」など、判断と対応をつなげます。

改善案	何を測るか	代償・注意点
Lambdaのメモリを増やす	実行時間、料金、CPU待ち	性能とメモリ料金の両方が変わる。実測で判断
Provisioned concurrency	起動遅延、使用率	用意した環境に追加料金。必要な時間帯を評価
キャッシュを追加	ヒット率、p95、下流呼び出し数	古い値、失効、利用者ごとのデータ分離
DB接続の再利用・RDS Proxy	接続数、接続待ち、下流負荷	接続の寿命、認証、プールの設定
非同期化・バッチ化	キュー滞留、スループット、完了時間	応答時点と完了時点が離れる。再試行と冪等性が必要

調査練習：メモリを増やす前に

APIのp99が悪化したが、Lambda内の計算時間は変わっていない。トレースでは外部API区間だけが伸びている。どう調べる？

考え方・解答例

外部APIのレイテンシ・タイムアウト・接続再利用・再試行回数を確認します。必要なら依存先の縮退や非同期化を検討します。Lambdaのメモリを増やすだけで外部APIの処理が速くなるとは限りません。

06 / 確認問題

07 / この章の到達点

メトリクス・ログ・トレース・監査を問いに合わせて選べる
症状から見るべき指標とログを絞り込める
最適化の効果と、料金・鮮度・複雑さの代償を説明できる

上のチェックは、このページでの振り返り用です。章単位の進捗は下のボタンで記録できます。

公式資料

内容確認日：2026年11月8日。仕様の詳細や更新情報は、各公式資料で確認できます。

おつかれさまでした。

理解を確認できたら、章の進捗を記録できます。