運用管理

ML ベースの運用異常検知 - Amazon DevOps Guru で障害を予兆段階で発見する

Amazon DevOps Guru を使った ML ベースの運用異常検知を解説。CloudWatch メトリクスの自動分析、異常の予兆検知、推奨アクション、CloudFormation スタック単位の監視を紹介します。

約 3 分で読めます

運用監視の課題と DevOps Guru の役割

クラウド環境の運用監視では、CloudWatch メトリクス、アラーム、ダッシュボードを設定して異常を検知するのが一般的です。しかし、監視対象のメトリクスが数百〜数千に及ぶ大規模環境では、すべてのメトリクスに適切な閾値を設定し維持することが困難です。また、個別メトリクスの閾値では検知できない複合的な異常 (CPU は正常だがレイテンシが徐々に増加し、同時にエラー率も微増している、など) も存在します。Amazon DevOps Guru は ML モデルで CloudWatch メトリクス、CloudTrail イベント、Config の設定変更を自動分析し、運用上の異常を予兆段階で検知するサービスです。個別メトリクスの閾値設定は不要で、DevOps Guru が過去のパターンを学習して動的にベースラインを構築します。複数メトリクスの相関分析により、単一メトリクスでは見逃す複合的な異常も検知できます。

監視対象の設定と異常検知

DevOps Guru の監視対象は 2 つの方法で指定します。CloudFormation スタック単位で指定する方法では、特定のスタック (アプリケーション) に含まれるリソースのみを監視します。アプリケーション境界に沿った監視が可能で、異常の影響範囲を特定しやすくなります。AWS アカウント全体を監視する方法では、アカウント内の全リソースを対象にします。DevOps Guru は対象リソースの CloudWatch メトリクスを自動的に収集・分析します。Lambda 関数であれば呼び出し回数、エラー率、実行時間、コールドスタート回数、DynamoDB であれば読み書きキャパシティ使用率、スロットリング回数、RDS であれば CPU 使用率、接続数、ディスク I/O など、サービス固有のメトリクスを自動的に監視します。異常が検知されると Insight (インサイト) として報告され、関連するメトリクスの異常、推定される根本原因、推奨アクションが提示されます。

根本原因分析と推奨アクション

DevOps Guru の Insight には、異常の根本原因の推定と具体的な推奨アクションが含まれます。たとえば、 Lambda 関数のエラー率が増加した場合、同時期に発生した CloudFormation のデプロイイベントや Config の設定変更と相関分析し、「直近のデプロイが原因の可能性がある」と推定します。 DynamoDB のスロットリングが検知された場合、「プロビジョンドキャパシティの増加」や「オンデマンドモードへの切り替え」を推奨します。 Insight は Reactive (既に影響が出ている異常) と Proactive (まだ影響は出ていないが予兆が見られる異常) の 2 種類に分類されます。 Proactive Insight は障害が発生する前に対処できるため、ダウンタイムの予防に直結します。 SNS 通知で Insight の発生を即座にアラートし、 EventBridge 統合で PagerDuty や Slack などの既存のインシデント管理ワークフローに組み込めます。 DevOps 自動化の運用ノウハウを深めるには、専門書籍 (Amazon)が役立ちます。

CloudWatch Anomaly Detection との使い分け

DevOps Guru と CloudWatch Anomaly Detection はどちらも ML ベースの異常検知ですが、スコープが異なります。CloudWatch Anomaly Detection は個別メトリクスに対して異常検知バンド (期待値の範囲) を設定し、バンドを逸脱した場合にアラームを発火します。メトリクスごとに設定が必要で、複数メトリクスの相関分析は行いません。DevOps Guru はアプリケーション全体を対象に、複数メトリクスの相関分析と根本原因推定まで自動的に行います。設定は監視対象の指定のみで、個別メトリクスの閾値設定は不要です。両者は併用可能で、重要な個別メトリクス (API のレイテンシ、エラー率など) には CloudWatch Anomaly Detection で明示的なアラームを設定し、アプリケーション全体の包括的な監視には DevOps Guru を使用するアプローチが効果的です。料金はリソース分析 1 時間あたり 0.0028 USD で、100 リソースを監視する場合は月額約 20 USD です。

DevOps Guru の料金

DevOps Guru の料金は分析対象の AWS リソース数で課金されます。CloudFormation スタックベースの分析は 1 リソースあたり月額約 0.0028 ドル、タグベースの分析は約 0.0042 ドルです。100 リソースの環境で月額約 0.28〜0.42 ドルと低コストです。Proactive Insights (予兆検知) と Reactive Insights (障害分析) の両方が含まれます。分析対象を本番環境のリソースに限定し、開発・テスト環境は除外することでコストを最適化します。

まとめ - DevOps Guru の活用指針

Amazon DevOps Guru は、ML ベースの自動分析で運用上の異常を予兆段階で検知するサービスです。CloudWatch メトリクスの自動分析、複数メトリクスの相関分析、根本原因の推定、推奨アクションの提示が主な強みです。CloudFormation スタック単位の監視でアプリケーション境界に沿った異常検知が可能で、個別メトリクスの閾値設定が不要なため導入が容易です。本番環境のサーバーレスアプリケーションやマイクロサービスの監視に特に効果を発揮します。

関連するサービス

Amazon DevOps Guru機械学習でアプリケーションの運用上の問題を自動検出・診断するサービスAmazon CloudWatchAWS リソースとアプリケーションの監視・ログ管理・アラームを提供するサービスAWS CloudFormationテンプレートで AWS リソースをコードとして定義・プロビジョニングする IaC サービス

関連する記事

運用監視の実践 - CloudWatch によるフルスタック可観測性の実現AWS CloudWatch を中心とした運用監視の設計手法を解説し、メトリクス収集、ログ分析、アラーム設定による包括的な可観測性の実現方法を紹介します。AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。AWS CDK でプログラミング言語による IaC - コンストラクトとスタックの設計CDK による TypeScript/Python でのインフラ定義、L1/L2/L3 コンストラクトの使い分け、テスト手法を解説します。

同じテーマの記事

AWS の内部時刻同期の仕組み - Amazon Time Sync Service とうるう秒スミアリングの設計AWS が独自に運用する Amazon Time Sync Service の仕組み、GPS と原子時計による高精度時刻源、うるう秒をスミアリングで吸収する設計判断、分散システムにおける時刻同期の重要性を解説します。AWS AppFabric で SaaS 監査ログを集約 - OCSF 標準化と Security Lake 統合AppFabric による SaaS アプリケーションの監査ログ収集、OCSF 形式への標準化、分析パイプラインの構築を解説します。AWS AppConfig で実装するフィーチャーフラグ - 安全な設定デプロイとロールバックコードデプロイとは独立した設定変更を、Linear・Exponential 戦略で段階的にロールアウトする。CloudWatch アラーム連動の自動ロールバックで安全性を確保します。アーキテクチャレビュー - AWS Well-Architected Tool でワークロードを体系的に評価するAWS Well-Architected Tool を使ったワークロードのアーキテクチャレビューを解説。6 つの柱に基づく評価、改善計画の策定、カスタムレンズの活用を紹介します。監査ログの設計と運用 - CloudTrail による API アクティビティの完全記録AWS CloudTrail を活用した監査ログの設計手法を解説し、API アクティビティの記録、S3 への長期保存、Config との連携によるコンプライアンス対応を紹介します。AWS の障害報告書 (COE) から学ぶ分散システムの教訓 - 過去の大規模障害が変えた設計原則AWS が公開した Correction of Errors (COE) と障害報告書から、S3 障害、us-east-1 の DNS 障害、Kinesis 障害など過去の大規模インシデントの根本原因と、それが AWS の設計原則をどう変えたかを解説します。タグの設計が運用を決める - AWS リソースタグ戦略の雑学と実践的な命名規則AWS リソースタグが単なるラベルではなくコスト配分、アクセス制御、自動化の基盤である理由、タグキーの命名規則、タグの上限 50 個の使い方、タグポリシーによるガバナンスを解説します。AWS のサービスクォータはなぜ存在するのか - 共有インフラを守るマルチテナント設計AWS のサービスクォータ (旧サービス制限) が単なる制約ではなく、マルチテナント環境で他の顧客を守るための設計であることを、ノイジーネイバー問題、ソフトリミットとハードリミットの違い、引き上げ申請の裏側から解説します。

内容が近い記事・サービス

Amazon DevOps Guru機械学習で CloudWatch メトリクスやログの異常パターンを自動検知し、根本原因の推定と改善推奨を提供する AIOps サービス運用監視の実践 - CloudWatch によるフルスタック可観測性の実現AWS CloudWatch を中心とした運用監視の設計手法を解説し、メトリクス収集、ログ分析、アラーム設定による包括的な可観測性の実現方法を紹介します。Amazon CloudWatchAWS リソースとアプリケーションのメトリクス、ログ、イベントを統合的に監視・分析するフルマネージドなモニタリングサービスコスト異常検知 - AWS Cost Anomaly Detection で予期しない支出を早期発見するAWS Cost Anomaly Detection を使ったコスト異常の自動検知を解説。ML ベースの異常検出、モニター設定、SNS/Slack 通知、Budgets との使い分けを紹介します。