OPS08-BP01 ワークロードメトリクスを分析する - AWS Well-Architected フレームワーク

OPS08-BP01 ワークロードメトリクスを分析する

アプリケーションテレメトリを実装したら、収集したメトリクスを定期的に分析します。レイテンシー、リクエスト、エラー、容量 (またはクォータ) はシステムパフォーマンスに関するインサイトを提供しますが、ビジネス成果メトリクスの確認を優先することが不可欠です。これにより、ビジネス目標に沿ったデータ主導の意思決定を確実に行うことができます。

期待される成果: ワークロードのパフォーマンスを正確に把握することで、データに基づいた意思決定ができるようになり、ビジネス目標と合致させることができます。

一般的なアンチパターン:

  • ビジネス成果への影響を考慮せずに、メトリクスを個別に分析している。

  • ビジネス上のメトリクスは重視せず、過度に技術メトリクスに頼っている。

  • メトリクスを見直す頻度が低く、リアルタイムの意思決定を行う機会を逃している。

このベストプラクティスを活用するメリット:

  • 技術的なパフォーマンスとビジネス成果の相関関係についてより詳しく把握できます。

  • リアルタイムのデータに基づいて意思決定プロセスが改善されます。

  • ビジネス成果に影響が及ぶ前に、問題を事前に特定して軽減できます。

このベストプラクティスを活用しない場合のリスクレベル:

実装のガイダンス

Amazon CloudWatch などのツールを活用してメトリクス分析を行います。特に静的なしきい値が不明な場合や動作パターンが異常検出に適している場合、CloudWatch 異常検出や Amazon DevOps Guru などの AWS サービスを異常検出に使用できます。

実装手順

  1. 分析とレビュー: ワークロードメトリクスを定期的に見直して分析します。

    1. 純粋に技術的なメトリクスよりもビジネス成果メトリクスを優先します。

    2. データ内のスパイク、ドロップ、パターンの重要性を理解します。

  2. Amazon CloudWatch を利用する: Amazon CloudWatch を使用して、一元化されたビューと詳細な分析を行います。

    1. メトリクスを可視化して時系列で比較できるように、CloudWatch ダッシュボードを設定します。

    2. CloudWatch でパーセンタイルを使用すると、メトリクスの分布を明確に把握できます。これは、SLA の定義や外れ値の理解に役立ちます。

    3. CloudWatch 異常検出を設定して、静的なしきい値に依存せずに異常なパターンを特定します。

    4. CloudWatch クロスアカウントオブザーバビリティを実装して、リージョン内の複数のアカウントにまたがるアプリケーションをモニタリングおよびトラブルシューティングします。

    5. CloudWatch Metric Insights を使用して、アカウントやリージョンのメトリクスデータをクエリして分析し、傾向や異常を特定します。

    6. CloudWatch Metric Math を適用すると、メトリクスの変換、集計、または計算を実行して、より深いインサイトを得られます。

  3. Amazon DevOps Guru の導入: 機械学習で強化された異常検出に Amazon DevOps Guru を組み込み、サーバーレスアプリケーションの運用上の問題の初期兆候を特定し、顧客に影響を与える前に修正します。

  4. インサイトに基づく最適化: メトリクス分析を基盤に情報に基づいた意思決定を行い、ワークロードを調整して改善します。

実装計画に必要な工数レベル:

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画:

関連する例: