変更要約: in-scope サービス網羅(是正): §4.3 にベストプラクティス横断点検の Trusted Advisor 節を追加（参考書で未説明だった軸B欠落を解消）
4.3トレースと可観測性の統合
可観測性の統合——X-Ray（分散トレース）、ServiceLens、Synthetics（外形監視）、Container/Lambda Insights、CloudTrail——を理解します。メトリック・ログ・トレースを横断して原因を素早く特定します。
メトリック・ログ・トレースの 3 本柱を統合すると、障害の原因特定が速くなります。X-Ray と CloudWatch がこれを支えます。
4.3.1可観測性の統合
- X-Ray：分散トレースでサービス間の遅延・エラーを可視化し、ボトルネックを特定。
- ServiceLens：メトリック・ログ・トレースを相関付けして一画面で分析。
- Synthetics：カナリアで外形監視。ユーザー視点でエンドポイントを常時テスト。
- Container/Lambda Insights：コンテナ/サーバーレスの詳細メトリックを収集。CloudTrailは API 監査。
「分散トレース＝X-Ray」「3 本柱の相関＝ServiceLens」「ユーザー視点の外形監視＝Synthetics カナリア」「コンテナ/Lambda の詳細メトリック＝Container/Lambda Insights」「API 監査＝CloudTrail」 は DOP-C02 で頻出です。メトリック・ログ・トレースを統合して MTTR（平均復旧時間）を短縮します。
可観測性の統合は「障害時にメトリック・ログ・トレースを行き来して MTTR を短縮する」ことが目的です。X-Ray はトレースヘッダ（trace ID）を伝播させてサービスマップを描き、各セグメント/サブセグメントの所要時間とエラーを示します。アプリには SDK か、ベンダー中立の OpenTelemetry（AWS Distro for OpenTelemetry, ADOT）で計装し、サンプリングルールで取得量を制御します。ServiceLens はトレースを CloudWatch のメトリック/ログと相関付けして 1 画面で原因を辿れます。Synthetics は外部からエンドポイントを定期テストするカナリアで、実ユーザーのアクセスが無い時間帯でも劣化を検知でき（アウトサイドイン）、RUM（Real User Monitoring）は実ユーザーのブラウザ体験（インサイドアウト）を補完します。Container Insights/Lambda Insights はそれぞれ ECS/EKS とサーバーレスの詳細メトリック（コールドスタート、メモリ、スロットルなど）を収集します。CloudTrail は「誰が・いつ・どの API を呼んだか」を監査し、EventBridge と組み合わせれば不審な操作の検知・自動対応もできます。これらは個別に使うより、ダッシュボードとアラームを通じて相関して使うことで真価を発揮し、DevOps の運用フィードバックループ（観測→改善）を回します。
| 知りたいこと | サービス | 視点 |
|---|---|---|
| サービス間のどこが遅いか | X-Ray | 分散トレース・サービスマップ |
| 3 本柱を相関して原因特定 | ServiceLens | メトリック/ログ/トレースを一画面 |
| ユーザー視点で落ちていないか | Synthetics / RUM | 外形監視（外）／実ユーザー（内） |
| 誰が API を操作したか | CloudTrail | API 監査・EventBridge 連携 |
シナリオ：「決済が遅い」というユーザー報告。原因が Web か API か DB か外部依存か分からない。→ X-Ray のサービスマップで遅いセグメント（例: 外部決済 API 呼び出し）を特定し、ServiceLens で同時刻の該当 Lambda のログ/メトリックを相関表示して根本原因を確認。再発検知のため Synthetics カナリアで決済フローを 1 分間隔で外形監視し、閾値超過で SNS 通知＋自動対応につなげます。
FAQ：Synthetics と RUM はどう違う？ Synthetics は合成監視（カナリア）で、実ユーザーがいなくてもスクリプトが定期的にエンドポイントをテストします（アウトサイドイン・SLA 監視向き）。RUM は実ユーザーのブラウザ計測で、実際の体感パフォーマンスやエラーを収集します（インサイドアウト）。両者は補完関係で、可用性は Synthetics、実体験は RUM が得意です。
ひっかけ：「サービス間のレイテンシのボトルネックを特定」に CloudTrail を選ぶのは誤り。CloudTrail は API 操作の監査であり、リクエストの経路や遅延の可視化は X-Ray の役割です。また「メトリック/ログ/トレースを 1 画面で相関」は ServiceLens——個別サービス名と役割を取り違えないこと。
4.3.2マネージドなオープンソース可観測性（Grafana / Prometheus）
CloudWatch ネイティブだけでなく、OSS の可観測性スタックをマネージドで使う選択肢もあります。Amazon Managed Service for Prometheus（AMP）は Prometheus 互換のメトリック収集/保存で、EKS/ECS などコンテナ環境のメトリックを PromQL でクエリでき、スケールや長期保持を AWS に任せられます。Amazon Managed Grafana は CloudWatch・Prometheus・X-Ray など複数データソースのメトリック/ログ/トレースを 1 つのダッシュボードで可視化・アラートします。選定の勘所は「既存の Prometheus/Grafana 資産や PromQL を活かしたい」「マルチクラウド/OSS 標準でダッシュボードを揃えたい」「Kubernetes 中心の監視を標準ツールで行いたい」なら AMP＋Managed Grafana を、AWS ネイティブで完結するなら標準の CloudWatch メトリック/ダッシュボードで十分、という住み分けです。いずれも基盤の運用（スケール・パッチ・可用性）は AWS が担うため、DevOps チームは監視内容の設計に集中できます。
| やりたいこと | サービス | 使いどころ |
|---|---|---|
| Prometheus 互換のメトリックを PromQL でクエリ | Amazon Managed Service for Prometheus | EKS/ECS など Kubernetes 中心の監視 |
| 複数ソースを 1 つのダッシュボードで可視化 | Amazon Managed Grafana | OSS 標準/マルチクラウドの統合ダッシュボード |
4.3.3ベストプラクティスの自動点検（Trusted Advisor）
個別メトリックの監視に加え、環境全体をベストプラクティスの観点で横断点検するのが AWS Trusted Advisor です。コスト最適化・パフォーマンス・セキュリティ・耐障害性・サービス上限（Service Quotas）の5カテゴリで推奨事項を提示します。DevOps 文脈では、Trusted Advisor のチェック結果を EventBridge 経由で受け取り、Lambda/SSM で自動是正したり、サービス上限の逼迫を上限引き上げ申請につなげたりと、運用自動化のトリガーとして使います。Business/Enterprise サポートで全チェックが有効になります。「自分の環境への改善助言＝Trusted Advisor」「AWS 側の稼働/障害状況＝Health Dashboard」と取り違えないようにします。
4.3.4この節のまとめ
- トレース＝X-Ray／相関＝ServiceLens／外形監視＝Synthetics
- 詳細＝Container/Lambda Insights／監査＝CloudTrail
- OSS 可観測性＝Managed Service for Prometheus（PromQL）＋Managed Grafana（統合ダッシュボード）
- 横断点検＝Trusted Advisor（コスト/性能/セキュリティ/耐障害性/上限・EventBridgeで自動是正）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. マイクロサービス間でどのサービスがレイテンシのボトルネックかを、トレースで可視化したい。何を使いますか？
Q2. ユーザー視点で重要なエンドポイントが正常に応答しているかを、定期的に外形監視したい。何を使いますか？
Q3. メトリック・ログ・トレースを 1 つの画面で相関させて根本原因を素早く特定したい。何を使いますか？