Amazon DevOps Guru

解決する課題

本番システムの障害は、CPU 使用率の急増、レイテンシの悪化、エラー率の上昇、リソース枯渇など、さまざまな兆候として現れます。これらを CloudWatch アラームのしきい値だけで捉えようとすると、ワークロードごとに適切な値を設計・調整し続ける必要があり、設定漏れや過剰なアラートに悩まされがちです。Amazon DevOps Guru を使うと、こうした運用上の異常検知を機械学習で自動化できます。

• 普段の振る舞いをベースラインとして自動学習し、そこから外れた異常を検知
• レイテンシ悪化やエラー増、リソース枯渇などを障害化する前の予兆として把握
• 検知した異常を、関連するメトリクス・イベント・推奨アクションとともにインサイトとして提示
• どのリソースで何が起きているかを横断的に示し、原因究明にかかる時間を短縮

しきい値を一つひとつ設計・運用する負担を抱えずに、運用の異常検知を始められる点が中心的な価値です。他クラウドでは Azure Monitor の異常検知や Google Cloud の運用系インサイトが近い位置づけにあります。

主要概念と用語

• インサイト（Insight）: DevOps Guru が検知した運用上の問題のまとまり。関連する異常やイベント、推奨アクションを束ねた単位
• リアクティブインサイト: 既に進行中・発生した問題に対するインサイト。複数の異常が同時に起きている状況などを示す
• プロアクティブインサイト: このままだと将来問題になりそうな兆候を、発生前に知らせるインサイト
• 異常（Anomaly）: 学習したベースラインから外れたメトリクスの振る舞い。インサイトを構成する要素
• カバレッジ（対象範囲）: 解析対象とするリソースの指定方法。アカウント全体、特定の CloudFormation スタック、タグ、AWS リソースコレクションなどで絞り込む
• リソースコレクション: 解析対象リソースをまとめて定義する仕組み。スタック単位やタグ単位でグルーピングする
• 推奨アクション（Recommendation）: インサイトに添えられる、是正のための具体的な対処の提案
• 重要度（Severity）: インサイトの深刻度の区分。トリアージの優先順位付けに使う
• データソース: 解析に使う入力。CloudWatch メトリクスを中心に、設定変更やデプロイなどのイベント情報を取り込む

仕様・制限・クォータ

• 主なデータソースは CloudWatch メトリクスで、対象リソースの稼働状況からベースラインを学習する
• 解析対象はリソースコレクションで指定し、アカウント全体・CloudFormation スタック・タグなどの単位で範囲を絞れる
• Aurora／RDS や Lambda、DynamoDB、S3、ECS など多くの AWS サービスのメトリクスに対応し、データベース向けにはより詳細な解析を行う機能もある
• ベースラインの学習にはある程度の稼働実績データが必要で、導入直後はインサイトが出るまで時間がかかる
• 検知したインサイトは、関連メトリクス・イベント・推奨アクションを含む構造化情報として参照・通知できる
• 解析対象リソース数や保持されるインサイトなどにアカウント単位のクォータが設定される場合がある

具体的な対応サービス・データ要件・クォータ値は更新されるため、最新の公式ドキュメントで確認してください。

内部の仕組み

利用者から見ると、対象リソースを指定するだけで、AWS 側のマネージドな機械学習が継続的にメトリクスを解析し、異常をインサイトとして返す仕組みです。

• ベースライン学習: 対象リソースの過去メトリクスから、時間帯や曜日の傾向を含めた「普段の振る舞い」を機械学習で学習する
• 異常検知: 取り込んだメトリクスをベースラインと比較し、統計的に外れた振る舞いを異常として検出する。しきい値を人手で設定する必要はない
• 相関付けとグルーピング: 同時期に発生した複数の異常や、デプロイ・設定変更などのイベントを関連付け、一つのインサイトとしてまとめる
• 推奨アクションの提示: 検知パターンに対し、確認・是正につながる推奨アクションを添えて提示する
• プロアクティブ検知: リソース枯渇に向かう傾向などを早期に捉え、問題が顕在化する前に知らせる

学習基盤やスケーリング、モデルの管理はすべて AWS 側が担い、利用者はモデルを構築・運用する必要がありません。

設計パターン / ベストプラクティス

• 対象範囲を段階的に広げる: いきなりアカウント全体を対象にせず、重要なスタックやタグから始めてノイズを抑えつつ運用に慣れる
• タグ・スタックで整理する: リソースコレクションをタグや CloudFormation スタックで定義し、サービス単位・チーム単位でインサイトを切り分ける
• 通知をワークフローに接続する: インサイトの発生を SNS で受け取り、チケット起票やチャット通知など既存の運用フローへ流す
• デプロイ情報と突き合わせる: 異常の発生時刻と直近のデプロイ・設定変更を照合し、変更起因の劣化を素早く切り分ける
• アラームの補完として使う: 重要指標は CloudWatch アラームで明示的に監視しつつ、DevOps Guru は想定外の異常を拾う補完層として位置づける

運用・監視

• 検知されたインサイトの発生を Amazon SNS で受け取り、メール通知やチケット起票につなげる
• インサイトのイベントを EventBridge で受け、Lambda などの後続処理へ流して運用を自動化する
• 既存のインシデント管理（Systems Manager Incident Manager など）と連携し、重大なインサイトからインシデント対応を起動する
• API 操作の監査証跡は CloudTrail に記録される
• 検出されたインサイトを定期的にレビューし、推奨アクションの妥当性や誤検知の傾向を運用にフィードバックする

コスト

• 課金は基本的に、解析対象リソースのメトリクスを処理した量や時間に応じた従量制で構成される
• 対象範囲を広げるほど解析対象が増え、費用も増える傾向がある
• 通常は無料利用枠や試用期間が用意されるが、内容は変動するため事前確認が必要

具体的な単価や課金単位は変動するため、料金は公式の料金ページで確認してください。まず限定した範囲で試し、費用感を把握してから対象を広げるのが安全です。

セキュリティ

• アクセス制御は IAM で行い、DevOps Guru の操作やインサイト参照に必要な最小権限のみを付与する
• 解析は AWS が管理する CloudWatch メトリクスを入力とし、利用者のアプリケーションデータそのものを直接扱うわけではない
• インサイトや推奨アクションには運用上の構成情報が含まれうるため、参照できる担当者を限定する
• 通知先となる SNS トピックや EventBridge の連携先にも、最小権限と適切な暗号化を適用する

関連サービス・比較

CloudWatch も異常検知（Anomaly Detection）を備えますが、対象の粒度と運用の組み立て方が異なるため比較します。

ハンズオン / CLI例

# 解析対象となるリソースコレクション（CloudFormation スタック）を登録する
aws devops-guru update-resource-collection \
  --action ADD \
  --resource-collection '{"CloudFormation":{"StackNames":["my-prod-stack"]}}'

# 直近に検知された進行中のインサイト一覧を取得する
aws devops-guru list-insights \
  --status-filter '{"Ongoing":{"Type":"REACTIVE"}}'