OPS08-BP01 ワークロードメトリクスを分析する - AWS Well-Architected Framework
実装のガイダンスリソース

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

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

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

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

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

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

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

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

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

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

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

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

実装のガイダンス

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

実装手順

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

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

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

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

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

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

    3. 静的なしきい値に依存せずに異常パターンを特定するように AWS Cost Anomaly Detection を設定します。

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

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

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

  3. Amazon DevOps Guru の採用: Amazon DevOps Guru の機械学習を強化した異常検出機能と連携して、サーバーレスアプリケーションの運用上の問題の兆候を早期に特定し、顧客に影響が及ぶ前に修正します。

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

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

リソース

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

関連するドキュメント:

関連動画:

関連する例: