Amazon DOP-C02: モニタリング、ロギング、可観測性 — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS DevOps Engineer Professional DOP-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

AWSにおけるモニタリング、ロギング、オブザーバビリティは、メトリクス、ログ、トレース、イベント、ヘルステレメトリを実用的なシグナルに統合する必要があります。効果的なアーキテクチャでは、メトリクス、アラーム、ダッシュボードのためにAmazon CloudWatchを、ログの取り込みと分析のためにCloudWatch LogsとLogs Insightsを、分散トレーシングのためにAWS X-Rayを、監査と整合性のためにAWS CloudTrailを、イベント駆動の検出と自動化のためにAmazon EventBridgeを、アカウント固有のサービスイベントのためにAWS Healthを、そして大規模な検索と相関分析のために一元化されたパイプライン（Kinesis Data FirehoseとOpenSearch）を使用します。以下のパターンでは、ノイズの削減、正確なシグナルルーティング、自動化、マルチアカウント/マルチリージョンでの運用を重視します。

CloudWatchメトリクス、アラーム、ダッシュボード、複合アラーム

CloudWatchメトリクスは、SLO、スケーリング、アラートの基盤です。シグナルを分離するために、きめ細かなディメンション（例: apiOperation, appVersion, statusCode）を持つカスタムメトリクスを発行します。構造化ログとともにCloudWatch Embedded Metric Format (EMF) を使用して、Lambda、コンテナ、EC2から高カーディナリティのディメンションを効率的に出力し、PutMetricData APIのオーバーヘッドを回避します。

堅牢な評価でアラームを設定します:

• データの粒度とSLOウィンドウに合わせて期間を選択します。
• 一時的なノイズに対する回復力のためにdatapointsToAlarm (n個中m個) を設定します。
• デプロイ中や一時停止中の誤検知を避けるためにTreatMissingDataを使用します。
• ベースラインが季節性によって変動する場合は異常検出バンドを活用し、派生指標（p95レイテンシー、エラー率、飽和率など）にはメトリクス数式を使用します。
• アラームにアクションをアタッチします: SNS経由で通知する、OpsCenter OpsItemsを作成する、SSM Automationを実行する、またはEC2インスタンスを復旧する。スケーリングポリシーはアクションのためにアラーム状態を参照できますが、複合アラームは直接スケーリングをトリガーすることはできません。

複合アラームは、複数の基盤となるアラームをAND/ORロジックで組み合わせることで、アラーム疲れを軽減します。例えば、p95レイテンシーが高く、かつ5xxレートがしきい値を超え、かつCPU飽和が持続する場合にのみアラートを発生させることで、ユーザーへの影響に沿った対応が可能になります。複合アラームは、クロスアカウントオブザーバビリティや中央アカウントへのメトリクスストリームを介して、リージョン/アカウントをまたがる子アラームからの状態更新を受け入れます。

ダッシュボードは、サービス全体の主要な指標を可視化します。メトリクス、Logs Insightsクエリ結果、アラームステータスのウィジェットを使用します。ダッシュボードの規約（命名、時間範囲、SLOのオーバーレイ）を標準化し、CloudWatch Observability Access Manager (OAM) を使用してクロスリージョン/クロスアカウントのビューを活用します。アドホックな相関分析のために、Logs InsightsとX-Ray ServiceLensのウィジェットを、サービスマップウィジェットやKinesis Firehoseのエラー率と並べてピン留めします。

CloudWatch Logs: ロググループ、メトリクスフィルター、サブスクリプションフィルター、Logs Insights

ロググループをアプリケーション/コンポーネントおよびライフサイクルステージごとに構成します。明示的な保持ポリシーを設定し（「失効しない」に依存しない）、必要な場合はKMS暗号化を有効にします。リソースポリシーときめ細かなIAMを使用して、プロデューサーとサブスクライバーを制御します。高スループットの取り込みには、十分なログストリームの同時実行性とバッチ処理を確保します。

メトリクスフィルターは、ログパターンをメトリクスに変換します。抽出されたトークン（JSONまたはスペース区切り）を持つフィルターパターンを定義し、トークンをメトリクスのディメンションにマッピングします。これにより、プロデューサーを変更することなくログから直接発行される、APIごと、バージョンごと、レスポンスコードごとのメトリクスといったユースケースがサポートされます。単位とデフォルト値が正しいことを確認し、イベントごとに1を優先し、メトリクス数式でレートを導出します。これらのメトリクスをSLOのアラートやダッシュボードに使用します。

サブスクリプションフィルターは、ほぼリアルタイムでログを以下にストリーミングします:

• Kinesis Data Firehose: 変換してS3/OpenSearchに配信するため。
• Kinesis Data Streams: カスタムコンシューマーのため。
• Lambda: カスタムルーティング、PIIの墨消し、またはイベント駆動の通知のため。 クロスアカウントのサブスクリプションには、IAMロールを持つCloudWatch Logsの送信先を使用します。再試行とバックプレッシャーを計画します。LambdaとFirehoseは、それぞれ組み込みの再試行とDLQ/エラーS3バケットを提供します。

CloudWatch Logs Insightsは、ログに対するインタラクティブなサーバーレスクエリを提供します。主要な演算子には、fields、filter、parse、stats、sort、limit、dedup、時間バケットのためのbinが含まれます。JSONフィールドをパースするか、テキストログにはgrokのようなパースを使用します。例:

• filter status >= 500 | stats count() by apiOperation, appVersion
• parse @message /duration=(?\d+)/ | stats pct(@ms,95) by service 頻繁に使用するクエリはQueryDefinitionで保存してチームで再利用し、クエリウィジェットとしてダッシュボードに埋め込みます。自動化のためには、EventBridge経由でLambdaをスケジュール実行し、StartQuery/GetQueryResultsを実行して概要をSNSやOpsCenterに発行します。コストを管理するために、クエリの範囲を特定のロググループと時間枠に制限します。

AWS X-Ray: トレース、サンプリングルール、サービスマップ、アノテーション

X-Rayは、サービス間の分散トレースをキャプチャし、レイテンシーの要因や障害の境界を特定します。AWS Distro for OpenTelemetry (ADOT) または X-Ray SDK を使用してサービスを計装し、トレースヘッダー（例: X-Amzn-Trace-Id）を伝播させ、必要な場所（ECS/EKS/EC2）で X-Ray デーモン/エージェントを実行します。多くのマネージドサービスはネイティブに統合されています（API Gateway、アクセスログ経由でトレースをプロキシするALB、アクティブトレースが有効なLambda、サブセグメント経由のStep Functionsなど）。

サンプリングルールは、データ量とシグナルの忠実度を制御します。以下を含む一元的なサンプリングルールセットを使用します:

• サービスごとのベースライントレースのための、秒間固定リザーバー。
• スループットに応じてスケールするための、レートベースのサンプリング率。
• ホットパスやエラーシナリオのための、ルールの優先度とサービス/URLのマッチング。 インシデント発生時やカナリアトラフィックに対してはサンプリングを増やし、コストを管理しながらオブザーバビリティを確保します。

サービスマップはコールグラフを可視化し、レイテンシー、エラーレート、スロットリングのインジケーターを持つエッジを表示します。トレースをドリルダウンしてセグメントとサブセグメントを調査し、ダウンストリームの依存関係を確認します。customerTier、apiOperation、appVersion、AWSリクエストIDなどの高カーディナリティのフィルタリングには、アノテーション（インデックス化されたキーバリューペア）を使用します。インデックスの肥大化を避けるため、冗長でインデックス化されないコンテキストにはメタデータを使用します。X-Ray のトレースグループを CloudWatch ServiceLens と組み合わせることで、ログ、メトリクス、トレースを単一のビューで関連付けます。フィルター式（例: annotation.appVersion = “2.3.1” and fault = true）を作成してリグレッションを特定し、ターゲットを絞ったログ検索のためにトレースIDをエクスポートします。

ガバナンスとイベント: CloudTrail、EventBridge、AWS Health

CloudTrailは、ガバナンスとフォレンジック分析のためにAPIアクティビティを記録します。すべてのアカウントとすべてのリージョンにまたがる組織の証跡を有効にし、SSE-KMSで暗号化された一元的なS3バケットに配信し、ログファイルの検証を有効にし、CloudWatch Logsと統合してほぼリアルタイムの検出を実現します。イベントクラスを区別します:

• 管理イベント: コントロールプレーンの操作（例: CreateUser, RunInstances）。必要に応じて読み取り専用および書き込み専用のイベントを含めるように設定します。
• データイベント: S3オブジェクトレベルのアクセス、LambdaのInvoke、DynamoDBのアイテムAPI、EKS APIサーバーの呼び出しなど、大量のデータプレーン操作。コストを制御するために、データイベントの範囲を選択的に（バケット/関数/テーブル単位で）絞ります。 CloudTrail Insightsを使用して異常なAPIスパイクを検出し、CloudTrailイベントをEventBridgeに送信して自動修復を行います。監査時には、ダイジェストファイルとAWS CLIのcloudtrail validate-logsコマンドを使用してログの整合性を検証します。

EventBridgeは、検出と自動化のためのイベントファブリックを提供します。AWSサービスイベントにはデフォルトのイベントバスを使用し、アプリケーションドメインのイベントにはカスタムバスを作成します。source、detail-type、detailフィールド、プレフィックス、数値範囲、および「anything-but」に一致するイベントパターンを定義します。入力トランスフォーマーを適用してイベントを再形成し、クロスアカウントでの発行のためにリソースベースのポリシーをアタッチし、ターゲットに再試行/DLQを設定します。一般的なターゲットには、Lambda（修復）、Step Functions（オーケストレーション）、SQS（デカップリング）、Systems Manager Automation（運用アクション）、CodePipeline（CIトリガー）、SNS（通知）などがあります。コンシューマーの障害から回復するためにイベントをアーカイブおよびリプレイし、スキーマレジストリを使用して厳密に型指定されたイベントモデルを生成します。

AWS Healthは、アカウント固有のサービスイベント、スケジュールされた変更、運用上の問題を通知します。EventBridgeを介してsourceがaws.health、detail-typeがAWS Health Eventのイベントと統合し、インシデントチャネルへのルーティング、OpsCenter OpsItemsのオープン、またはメンテナンスウィンドウのための安全なシャットダウン/スケールアクションのトリガーを行います。委任された管理者アカウントで組織ビューを使用して、すべてのアカウントのHealthイベントを集約し、AWS Health APIまたはAWS Health Awareソリューションを利用して、キュレーションされた通知をオンコールシステムにプッシュすることを検討します。

Kinesis Data Firehose と OpenSearch によるログの一元管理

マルチアカウント、マルチリージョンでのログ戦略は、取り込みと検索を標準化します。各プロデューサーアカウントで、CloudWatch Logs のサブスクリプションフィルターを、中央の Kinesis Data Firehose をバックエンドとするクロスアカウントのログ送信先に設定します。以下の Firehose の機能を有効にします。

• 正規化（JSON）、PII（個人を特定できる情報）のリダクション、AWS アカウント、リージョン、VPC、サービスメタデータによるエンリッチのための Lambda によるデータ変換。
• Athena でのクエリパフォーマンスを最適化するための、S3 への配信時の圧縮（GZIP）と動的パーティショニング。
• プライベートエンドポイントのための KMS による暗号化と VPC 配信。 低レイテンシーな検索と Kibana/OpenSearch Dashboards での可視化のために、Amazon OpenSearch Service に配信します。インデックスのロールオーバーと保持期間のためのインデックステンプレート、ILM/ISM ポリシー、およびユーザーをインデックスパターン（例：アカウント/チーム/サービス）にマッピングするきめ細かなアクセスポリシーを使用します。失敗したドキュメントのために S3 へのエラー出力を設定し、Firehose の配信と OpenSearch の取り込みメトリクス（DeliveryToElasticsearch.Success、ElasticsearchFailedRequests）を監視します。非常に大量のトラフィックがある場合は、Firehose を介してすべてのログを S3 に集約し、そのサブセットを OpenSearch にストリーミングすることを検討します。そして、コストを抑制するために、長期的な調査には S3 上のデータに対してオンデマンドで Athena クエリを実行します。

このパイプラインを、高速で低コストなカウンターのための CloudWatch メトリクスフィルターや、アドホックな詳細クエリのための Logs Insights と組み合わせます。Firehose/OpenSearch の異常や CloudWatch アラームによってトリガーされる EventBridge ルールを使用して、修復を開始したり、インシデントを起票したりします。

実践的な問題シナリオ

Airbnb では、EKS と Lambda にデプロイされたマイクロサービス全体で、API エラーとレイテンシーの断続的な急増が発生しており、複数のモバイルアプリバージョンが本番環境で利用されています。運用チームは、API オペレーション、レスポンスコード、アプリバージョンごとのほぼリアルタイムの検知、トレースとログを横断した迅速な根本原因分析、既知の障害パターンに対する自動修復、そしてガバナンスレベルの監査証跡を必要としています。

1. 構造化ログの標準化

• サービス（EKS、Lambda）に、apiOperation、statusCode、appVersion、tenantId、latencyMs などのフィールドを含む EMF 構造化 JSON ログを実装します。
• 理由: EMF により、低オーバーヘッドかつ高カーディナリティのディメンションで CloudWatch で直接メトリクスを抽出でき、正確なアラームが可能になります。

2. CloudWatch Logs メトリクスフィルターの作成

• 各サービスのロググループに対して、apiOperation、statusCode、appVersion ごとにカウンターをインクリメントするメトリクスフィルターを定義します。
• 理由: 追加のコードパスなしでディメンションごとのメトリクスを生成し、API やクライアントバージョンごとのダッシュボードと実用的なアラームを可能にします。

3. 階層化された CloudWatch アラームと複合アラームの構築

• p95 レイテンシー、5xx レート、および飽和度（CPU、メモリ、同時実行数/スロットリング）でアラームを設定します。複合アラームを作成します：3 回中 2 回、LatencyHigh AND ErrorsHigh が発生した場合。
• 理由: ノイズを削減し、ユーザーに影響を与えるインシデントに集中できます。

4. ターゲットサンプリングを用いた X-Ray トレーシングのデプロイ

• EKS では ADOT コレクターを使用し、Lambda ではアクティブトレースを使用します。すべてのエラートレースと成功した呼び出しの代表的なサンプルをキャプチャするサンプリングルールを定義し、新しいアプリバージョンではサンプリング率を高く設定します。
• 理由: コストを抑制しつつ、障害への可視性を保証し、パフォーマンスのホットスポットを十分にカバーできます。

5. ServiceLens と Logs Insights での相関分析

• メトリクスウィジェット、X-Ray サービスマップ、Logs Insights クエリ（例：filter status >= 500 | stats count() by apiOperation, appVersion）を組み合わせたダッシュボードを作成します。
• 理由: 単一画面での相関分析により、どのオペレーションとクライアントバージョンでリグレッションが発生したかの診断が迅速化されます。

6. Firehose を介した OpenSearch と S3 へのログの一元化

• 正規化、PII のリダクション、アカウント/リージョン情報でのエンリッチを行う Lambda 変換を持つ中央の Firehose へのサブスクリプションフィルターを設定します。7 日間のホット検索のために OpenSearch へ、永続的な保持と Athena クエリのために S3 へ配信します。
• 理由: 現在の問題に対するチーム横断での高速な検索と、低コストでの履歴分析が可能です。

7. EventBridge による検知と修復の自動化

• CloudWatch アラームの状態変化や、選択された CloudTrail の書き込み API イベント（例：セキュリティグループの変更）に対して EventBridge ルールを作成します。ターゲットとして、安全なロールバック（例：機能フラグの差し戻し）のための Lambda や、複数ステップの修復のための Step Functions を指定します。
• 理由: イベント駆動のコントロールループにより、MTTR（平均修復時間）が短縮され、ガードレールが強制されます。

8. AWS Health とメンテナンス対応の統合

• EC2、EKS、またはネットワーキングに影響を与える aws.health イベントに対する EventBridge ルールを追加します。ターゲットとして SSM Automation を指定し、ノードの cordon/drain やトラフィックのシフトを行います。
• 理由: 計画された、または運用上の問題に対するプロアクティブな緩和策により、ダウンタイムが削減されます。

9. CloudTrail の組織の証跡と整合性検証によるガバナンスの強化

• S3 と Lambda のデータイベント、SSE-KMS 暗号化、ログファイルの検証を含む、組織のマルチリージョン証跡を有効にします。異常検知と調査のために CloudWatch Logs と OpenSearch にストリーミングします。
• 理由: 完全で改ざん検出可能な監査は、コンプライアンス要件を満たし、RCA（根本原因分析）を迅速化します。

10. 通知と運用（Ops）の統合

• 重要なイベントを SNS とオンコールシステムにルーティングし、ランブックが添付された OpsCenter の OpsItems を起票し、所有権と重要度を示すためにアラームにタグを付けます。
• 理由: 明確な所有者と自動化されたランブックにより、対応の質と速度が向上します。

この設計は、低レイテンシーでディメンションが豊富なメトリクス（CloudWatch + EMF）、詳細なトレースの相関分析（X-Ray + ServiceLens）、大規模な検索（OpenSearch + S3/Athena）、イベント駆動の修復（EventBridge + Lambda/SSM/Step Functions）、そして監査可能なガバナンス（整合性検証付きの CloudTrail）を組み合わせるために選択されました。サンプリング、保持期間の階層化、および実際のユーザー影響を反映したターゲットアラームにより、コストと忠実度のバランスを取っています。

← Infrastructure as Codeと構成管理 · すべてのドメイン · セキュリティ、コンプライアンス、ガバナンス →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Amazonを閲覧 →