# OPS 8 ワークロードの正常性はどのように把握するのですか?
ワークロードメトリクスの定義、キャプチャ、分析をすると、適切なアクションを取れるようにワークロードイベントの可視性を高めることができます。
**Topics**
+ [OPS08-BP01 主要業績評価指標 (KPI) を特定する](ops_workload_health_define_workload_kpis.md)
+ [OPS08-BP02 ワークロードのメトリクスを定義する](ops_workload_health_design_workload_metrics.md)
+ [OPS08-BP03 ワークロードメトリクスを収集および分析する](ops_workload_health_collect_analyze_workload_metrics.md)
+ [OPS08-BP04 ワークロードメトリクスのベースラインを設定する](ops_workload_health_workload_metric_baselines.md)
+ [OPS08-BP05 ワークロードに対して予想されるアクティビティのパターンを知る](ops_workload_health_learn_workload_usage_patterns.md)
+ [OPS08-BP06 ワークロードの結果にリスクがある場合に警告する](ops_workload_health_workload_outcome_alerts.md)
+ [OPS08-BP07 ワークロードの異常が検出された場合に警告する](ops_workload_health_workload_anomaly_alerts.md)
+ [OPS08-BP08 KPI とメトリクスの成果の達成度と有効性を検証する](ops_workload_health_biz_level_view_workload.md)
# OPS08-BP01 主要業績評価指標 (KPI) を特定する
希望するビジネス上の業績 (注文率、顧客定着率、営業費用に対する利益など) と顧客に関する成果 (顧客満足度など) に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、ワークロードの成功を判別します。
**一般的なアンチパターン:**
+ あなたは、ビジネスリーダーから、ワークロードがビジネスニーズにどのように寄与したかを尋ねられますが、寄与度を判断するための基準となる枠組みがありません。
+ あなたは、組織で運用している商用オフザシェルフのアプリケーションの費用対効果が高いかどうかを判断することはできません。
**このベストプラクティスを活用するメリット:** ワークロードの正常性と成功のテストとして、主要業績評価指標を特定することで、ビジネス成果を達成できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 主要業績評価指標 (KPI) を特定する: ビジネスおよび顧客が求める成果に基づいて、主要業績評価指標 (KPI) を特定します。KPI を評価して、ワークロードの成功を判別します。
# OPS08-BP02 ワークロードのメトリクスを定義する
ワークロードの正常性を測定するため、ワークロードのメトリクスを定義します。ワークロードの正常性は、ビジネス成果 (KPI) の達成と、ワークロードコンポーネントおよびアプリケーションの状態によって測定されます。KPI の例には、放棄されたショッピングカート数、注文数、コスト、料金、配分されたワークロード費用があります。複数のコンポーネントからテレメトリーを収集することができるとはいえ、全体的なワークロードの正常性についてのインサイトを提供するサブセットを選択します。ビジネスニーズの変化に合わせ、ワークロードのメトリクスを時間と共に調整します。
**期待される成果:**
+ ビジネス上の成果を反映する KPI の達成を検証するメトリクスが特定されています。
+ ワークロードの正常性について一貫性あるビューを提供するメトリクスがあります。
+ ワークロードのメトリクスは、ビジネスニーズの変化に合わせて定期的に評価されます。
**一般的なアンチパターン:**
+ ワークロードのすべてのアプリケーションがモニタリングされていても、ワークロードがビジネス上の成果を達成しているかどうかを判断できません。
+ ワークロードのメトリクスは定義されていても、ビジネス KPI に関連付けられていません。
**このベストプラクティスを活用するメリット:**
+ ワークロードをビジネス上の成果の達成に対して測定することができます。
+ ワークロードが正常な状態なのか、介入が必要なのかを把握できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
このベストプラクティスの目標は、ワークロードの正常性を判断できることです。 ワークロードの正常性は、ビジネス成果の達成と、ワークロードのコンポーネントおよびアプリケーションの状態によって判断されます。ビジネス KPI からさかのぼって、メトリクスを特定します。コンポーネントとアプリケーションの主要なメトリクスを特定します。ビジネスニーズの変化に応じて、ワークロードのメトリクスを定期的に評価します。
**お客様事例**
AnyCompany Retail では、ワークロードの正常性をアプリケーションとコンポーネントのメトリクスのコレクションによって判断しています。ビジネス KPIから始まり、ビジネス上の成果を達成しているかを示す注文率などのメトリクスを特定しています。また、ページ応答率などの主要なアプリケーションのメトリクスと、データベースへのオープン接続数などのコンポーネントのメトリクスも使用しています。ワークロードのメトリクスは、ワークロードの正常性を決定するうえで有効であるかを確認するために、四半期ごとに再評価しています。
**実装手順**
1. ビジネス KPI から初めて、ビジネス上の成果を達成していることを示すメトリクスを特定します。メトリクスを伴わない KPI がある場合は、不足しているビジネス KPI すべてについて追加のメトリクスを使用して、ワークロードを測定します。
1. カスタムメトリクスは、アプリケーションから [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) にパブリッシュできます。
1. [AWS Distro for OpenTelemetry](https://aws-otel.github.io/) を使用すると、既存のアプリケーションのメトリクスを収集して、新しいメトリクスの追加に利用できます。
1. Enterprise Support を利用している場合は、テクニカルアカウントマネージャーに、[Building a Monitoring Strategy Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (モニタリング戦略策定ワークショップ) を申し込むことができます。このワークショップは、ワークロードのオブザーバビリティ戦略策定の支援となります。
1. ワークロードのアプリケーションとコンポーネントのメトリクスを特定します。個別のコンポーネントとアプリケーションの正常性を示す主要なメトリクスにはどのようなものがあるでしょうか。 アプリケーションとコンポーネントはさまざまなメトリクスを生成する可能性があるとはいえ、全体的な正常性を示す主要なメトリクスを 1～3 種類選択します。
1. ワークロードのメトリクスを定期的に評価するメカニズムを導入します。ビジネス KPI が変更された場合、ステークホルダーと協力してワークロードのメトリクスを更新します。ワークロードのコンポーネントとアプリケーションの進化に合わせて、ワークロードのメトリクスを調整します。
**実装計画に必要な工数レベル:** 中。アプリケーションにビジネス KPI のメトリクスを追加するには、ある程度の労力が必要になる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 アプリケーションテレメトリーを実装する](ops_telemetry_application_telemetry.md) - アプリケーションは、ビジネス上の成果をサポートするテレメトリーを生成する必要があります。
+ [OPS04-BP02 ワークロードテレメトリーを実装して設定する](ops_telemetry_workload_telemetry.md) - ビジネス上の成果をサポートするワークロードのメトリクスを定義する前に、テレメトリーを送信するワークロードを計測する必要があります。
+ [OPS08-BP01 主要業績評価指標 (KPI) を特定する](ops_workload_health_define_workload_kpis.md) - ワークロードのメトリクスを選択する前に、主要業績評価指標 (KPI) を特定する必要があります。
**関連するドキュメント:**
+ [ Adding metrics and traces to your application on Amazon EKS with AWS Distro for OpenTelemetry, AWS X-Ray, and Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/adding-metrics-and-traces-to-your-application-on-amazon-eks-with-aws-distro-for-opentelemetry-aws-x-ray-and-amazon-cloudwatch/)(AWS Distro for OpenTelemetry、AWS X-Ray、Amazon CloudWatch を使用して、Amazon EKS のアプリケーションにメトリクスとトレースを追加する)
+ [Amazon Builder’s Library の](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [ヘルスチェックを実装する](https://aws.amazon.com/builders-library/implementing-health-checks/)
+ [アプリケーションを効率的にモニタリングする方法](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [ How to better monitor your custom application metrics using Amazon CloudWatch Agent ](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/) (Amazon CloudWatch エージェントを使用してカスタムアプリケーションメトリクスのモニタリングを改善する方法)
**関連動画:**
+ [AWS re:Invent 2020: Monitoring production services at Amazon ](https://www.youtube.com/watch?v=hnPcf_Czbvw)(AWS re:Invent 2020: Amazon における本稼働サービスのモニタリング)
+ [AWS re:Invent 2022 - Building observable applications with OpenTelemetry (BOA310) ](https://www.youtube.com/watch?v=efk8XFJrW2c)(AWS re:Invent 2022 - OpenTelemetry を使用したオブザーバブルなアプリケーションの構築 (BOA310))
+ [How to Easily Setup Application Monitoring for Your AWS Workloads - AWS Online Tech Talks](https://www.youtube.com/watch?v=LKCth30RqnA) (AWS ワークロードのアプリケーションモニタリングを簡単に設定する方法 - AWS オンラインテックトーク)
+ [Mastering Observability of Your Serverless Applications - AWS Online Tech Talks](https://www.youtube.com/watch?v=CtsiXhiAUq8) (サーバーレスアプリケーションのオブザーバビリティをマスターする - AWS オンラインテックトーク)
**関連する例:**
+ [1 つの可観測性ワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
**関連サービス:**
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Distro for OpenTelemetry ](https://aws-otel.github.io/)
# OPS08-BP03 ワークロードメトリクスを収集および分析する
ワークロードのメトリクスを定期的にプロアクティブにレビューすることにより、傾向を特定し、対応が必要かどうかを判断し、ビジネス上の成果の達成を検証できます。ワークロードのアプリケーションとコンポーネントからのメトリクスを一元的に集約します。ダッシュボードと分析ツールを使用してテレメトリーを分析し、ワークロードの正常性を判断します。組織のステークホルダーと定期的にワークロードの正常性レビューを実施するメカニズムを導入します。
**期待される成果:**
+ ワークロードのメトリクスが、一元的な場所に収集されます。
+ ワークロードの正常性の傾向を、ダッシュボードと分析ツールを使用して分析します。
+ 組織で定期的なワークロードのメトリクスについてのレビューを実施します。
**一般的なアンチパターン:**
+ 組織内で 2 つの別々のオブザーバビリティプラットフォームでワークロードからメトリクスを収集しています。これらのプラットフォームには互換性がないため、ワークロードの正常性は判断できません。
+ ワークロードのコンポーネントのエラー率が徐々に増加しています。組織ではワークロードのメトリクスのレビューを定期的に実施していないため、このような傾向に気づきません。1 週間後、このコンポーネントでエラーが起こり、ワークロード障害が発生します。
**このベストプラクティスを活用するメリット:**
+ ワークロードの正常性とビジネス上の成果の達成に対する意識が向上します。
+ ワークロードの正常性の傾向が徐々に発展する可能性があります。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードのメトリクスを一元的な場所に収集します。ダッシュボードと分析ツールを使用して、ワークロード メトリクスを分析し、ワークロードの正常性に関するインサイトを獲得して、ワークロードの正常性の傾向を発展させ、ビジネス上の成果の達成を検証します。ワークロードのメトリクスの定期的なレビューを実施するメカニズムを導入します。
**お客様事例**
AnyCompany Retail では、毎週水曜日にワークロードメトリクスのレビューを実施しています。会社全体にわたるステークホルダーが集まり、前の週のメトリクスを確認します。このレビュー中には、分析ツールから収集した傾向とインサイトを中心に確認が行われます。主要なワークロードのメトリクスを提供する内部ダッシュボードは公開され、すべての従業員が確認し、検索できます。
**実装手順**
1. ワークロードの正常性に関連するワークロードのメトリクスを特定します。ビジネス KPI から始めて、ワークロードの正常性の全体像を提供するアプリケーション、コンポーネント、プラットフォームのメトリクスを特定します。
1. カスタムメトリクスは、[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) に公開できます。[Amazon CloudWatch エージェント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)を活用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集できます。
1. [AWS Distro for OpenTelemetry](https://aws-otel.github.io/) を使用すると、既存のアプリケーションのメトリクスを収集して、新しいメトリクスの追加に利用できます。
1. Enterprise Support を利用している場合は、テクニカルアカウントマネージャーに、[Building a Monitoring Strategy Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (モニタリング戦略策定ワークショップ) を申し込むことができます。このワークショップは、ワークロードのオブザーバビリティ戦略策定の支援となります。
1. ワークロードのメトリクスを一元的なプラットフォームに収集します。ワークロードのメトリクスが別のプラットフォームに分割されている場合は、傾向の分析と構築が困難となる場合があります。プラットフォームには、ダッシュボードと分析機能が必要です。
1. [Amazon CloudWatch](https://docs.aws.amazon.com/) を使用して、ワークロードのメトリクスを収集して保存できます。マルチアカウントトポロジの場合、ログアーカイブアカウントと呼ばれる[一元的なロギングとモニタリングアカウント](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/log-archive.html)の使用をお勧めします。**
1. ワークロードメトリクスの統合ダッシュボードを構築します。このビューをメトリクスのレビューと傾向の分析に使用します。
1. カスタム [CloudWatch ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)を作成して、ワークロードのメトリクスを統合ビューで収集できます。
1. ワークロードメトリクスのレビュープロセスを導入します。技術担当者および非技術担当者を含むステークホルダーと共に、毎週、隔週、または毎月の頻度でワークロードのメトリクスを確認します。このようなレビューセッションを使用すると、傾向を特定し、ワークロードの正常性に関するインサイトを獲得できます。
**実装計画に必要な工数レベル:** 高。ワークロードのメトリクスが一元的に収集されていない場合、単一のプラットフォームに統合するには多額の投資が必要になる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP01 主要業績評価指標 (KPI) を特定する](ops_workload_health_define_workload_kpis.md) - ワークロードのメトリクスを選択する前に、主要業績評価指標 (KPI) を特定する必要があります。
+ [OPS08-BP02 ワークロードのメトリクスを定義する](ops_workload_health_design_workload_metrics.md) - 収集と分析を行う前に、ワークロードのメトリクスを定義する必要があります。
**関連するドキュメント:**
+ [ Power operational insights with Amazon Quick ](https://aws.amazon.com/blogs/big-data/power-operational-insights-with-amazon-quicksight/) (Amazon QuickSight を使用して運用上のインサイトを活用する)
+ [ Using Amazon CloudWatch dashboards custom widgets ](https://aws.amazon.com/blogs/mt/introducing-amazon-cloudwatch-dashboards-custom-widgets/) (Amazon CloudWatch ダッシュボードでのカスタムウィジェットの使用)
**関連動画:**
+ [ Create Cross Account & Cross Region CloudWatch Dashboards ](https://www.youtube.com/watch?v=eIUZdaqColg)(クロスアカウントとクロスリージョンの CloudWatch ダッシュボードを作成する)
+ [ Monitor AWS Resources Using Amazon CloudWatch Dashboards ](https://www.youtube.com/watch?v=I7EFLChc07M) (Amazon CloudWatch ダッシュボードを使用して AWS リソースをモニタリングする)
**関連する例:**
+ [AWS 管理とガバナンスツールワークショップ - CloudWatch ダッシュボード](https://mng.workshop.aws/operations-2022/detect/cwdashboard.html)
+ [ Well-Architected Labs - Level 100: Monitoring with CloudWatch Dashboards ](https://www.wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/)(Well-Architected ラボ - レベル 100: Amazon CloudWatch ダッシュボードを使用したモニタリング)
**関連サービス:**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
# OPS08-BP04 ワークロードメトリクスのベースラインを設定する
ワークロードメトリクスのベースラインを設定すると、ワークロードの正常性とパフォーマンスの把握につながります。ベースラインを使用すると、パフォーマンスが低下しているか過剰になっているアプリケーションとコンポーネントを特定できます。ワークロードのベースラインを設定することにより、問題がインシデントになる前に軽減できるようになります。ベースラインは、アクティビティのパターンを開発し、メトリクスが期待値から逸脱した場合の異常検出を実装するための基盤となります。
**期待される成果:**
+ 通常の状況におけるワークロードのベースラインレベルのメトリクスが設定されており、
+ ワークロードが正常に機能しているかどうかを判断できます。
**一般的なアンチパターン:**
+ 新しい機能のデプロイ後、リクエストのレイテンシーの急激なドロップが発生しました。処理済みのリクエストと全体的なレイテンシーの複合メトリクスのベースラインは設定されておらず、変更により改善がみられたのか、エラーが発生したのかを判断することができません。
+ ユーザーアクティビティの突然なスパイクが発生しましたが、メトリクスのベースラインは設定されていません。このアクティビティのスパイクは、徐々にアプリケーションでのメモリーリークにつながり、最終的にワークロードがオフラインになってしまいます。
**このベストプラクティスを活用するメリット:**
+ 主要なコンポーネントとアプリケーションのメトリクスを使用して、ワークロードのアクティビティの通常のパターンを把握できます。
+ ワークロード、ワークロードのアプリケーションとコンポーネントが正常に動作しているか、介入が必要かどうかを判断できます。
**このベストプラクティスを確立しない場合のリスクレベル:** 中
## 実装のガイダンス
履歴データを使用して、ワークロードのアプリケーションとコンポーネントのワークロードメトリクスのベースラインを設定します。メトリクスのベースラインをメトリクスのレビューミーティングとトラブルシューティングで活用します。ワークロードのパフォーマンスを定期的に確認し、ベースラインをアーキテクチャの進化に合わせて調整します。
**お客様事例**
AnyCompany Retail では、すべてのコンポーネントとアプリケーションのベースラインが設定されています。AnyCompany Retail は、履歴データを使用して、2 か月のメトリクス期間にわたるワークロードメトリクスのベースラインを作成しました。AnyCompany Retail では、2 か月ごとにベースラインを再評価して、実際のデータに基づいて調整をおこなっています。
**実装手順**
1. 履歴データを使用して、ワークロードのメトリクスからさかのぼって、主要なコンポーネントとアプリケーションのメトリクスのベースラインを設定します。コンポーネントまたはアプリケーションごとのメトリクス数を制限して、モニタリング疲れを回避します。
1. [Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) を使用して、大規模なメトリクスをクエリして、傾向とパターンを特定します。
1. [Amazon CloudWatch 異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)は、機械学習アルゴリズムを使用して、メトリクスの動作パターンを特定し、ベースラインを決定し、異常を検出します。
1. [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) は、機械学習を使用して、ワークロードの運用上の問題を検出する機能を提供します。
1. Enterprise Support を利用している場合は、テクニカルアカウントマネージャーに、[Building a Monitoring Strategy Workshop](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) (モニタリング戦略策定ワークショップ) を申し込むことができます。このワークショップは、ワークロードのオブザーバビリティ戦略策定の支援となります。
1. 特に重要なビジネスイベントの前に、ワークロードのメトリクスのベースラインを定期的に確認するメカニズムを導入します。少なくとも四半期に 1 回、履歴データを使用してワークロードのメトリクスのベースラインを評価します。メトリクスレビューミーティングでは、このベースラインを使用します。
**実装計画に必要な工数レベル:** 低。ワークロードのメトリクスが定まったら、ベースラインを設定するうえで、通常の動作パターンを特定するために十分なデータを収集する必要がある場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS08-BP02 ワークロードのメトリクスを定義する](ops_workload_health_design_workload_metrics.md) - ベースラインを設定する前に、まずワークロードのメトリクスを決定する必要があります。
+ [OPS08-BP03 ワークロードメトリクスを収集および分析する](ops_workload_health_collect_analyze_workload_metrics.md) - メトリクスのベースラインを設定する前に、ワークロードのメトリクスを収集して分析する必要があります。
+ [OPS08-BP05 ワークロードに対して予想されるアクティビティのパターンを知る](ops_workload_health_learn_workload_usage_patterns.md) - このベストプラクティスは、ベースラインを基盤に構築され、使用傾向を明らかにします。
+ [OPS08-BP06 ワークロードの結果にリスクがある場合に警告する](ops_workload_health_workload_outcome_alerts.md) - しきい値の特定とアラートの作成には、メトリクスのベースラインが必要となります。
+ [OPS08-BP07 ワークロードの異常が検出された場合に警告する](ops_workload_health_workload_anomaly_alerts.md) - 異常検出には、メトリクスのベースラインが設定されている必要があります。
**関連するドキュメント:**
+ [AWS Observability Best Practices - Alarms ](https://aws-observability.github.io/observability-best-practices/tools/alarms/)(AWS のオブザーバビリティのベストプラクティス - アラーム)
+ [アプリケーションを効率的にモニタリングする方法](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [ How to set up CloudWatch Anomaly Detection to set dynamic alarms, automate actions, and drive online sales ](https://aws.amazon.com/blogs/mt/how-to-set-up-cloudwatch-anomaly-detection-to-set-dynamic-alarms-automate-actions-and-drive-online-sales/)(CloudWatch 異常検出をセットアップして、動的アラームを設定し、アクションを自動化し、オンライン販売を促進する方法)
+ [ Operationalizing CloudWatch Anomaly Detection ](https://aws.amazon.com/blogs/mt/operationalizing-cloudwatch-anomaly-detection/) (CloudWatch 異常検出を運用化する)
**関連動画:**
+ [AWS re:Invent 2020: Monitoring production services at Amazon ](https://www.youtube.com/watch?v=hnPcf_Czbvw)(AWS re:Invent 2020: Amazon における本稼働サービスのモニタリング)
+ [AWS re:Invent 2021- Get insights from operational metrics at scale with CloudWatch Metrics Insights ](https://www.youtube.com/watch?v=xKib0xvbIfo)(AWS re:Invent 2021- CloudWatch Metrics Insights を使用して、大規模に運用メトリクスからインサイトを取得する)
+ [AWS re:Invent 2022 - Developing an observability strategy (COP302) ](https://www.youtube.com/watch?v=Ub3ATriFapQ)(AWS re:Invent 2022 - オブザーバビリティ戦略を策定する (COP302))
+ [AWS Summit DC 2022 - Monitoring and observability for modern applications ](https://www.youtube.com/watch?v=AHiuyT0B5Gk)(AWS Summit DC 2022 - モダンアプリケーションのモニタリングとオブザーバビリティ)
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS (COP310) ](https://www.youtube.com/watch?v=or7uFFyHIX0)(AWS Summit DC 2022 - AWS を使用したフルスタックオブザーバビリティとアプリケーションモニタリング (COP310))
**関連する例:**
+ [AWS CloudTrail and Amazon CloudWatch Integration Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/2e48b9fc-f721-4417-b811-962b7f31b61c/en-US)(AWS CloudTrail と Amazon CloudWatch の統合ワークショップ)
**関連サービス:**
+ [ Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ Amazon DevOps Guru ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
# OPS08-BP05 ワークロードに対して予想されるアクティビティのパターンを知る
ワークロードアクティビティのパターンを確立して異常な動作を識別し、必要に応じて適切に対応できるようにします。
CloudWatch Anomaly Detection 機能を使用した [CloudWatch は、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 統計および機械学習アルゴリズムを適用して、通常のメトリクスの動作を表す予想値の範囲を生成します。
[Amazon DevOps Guru を使用して、](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html) イベントの関連性、ログ分析、ワークロードテレメトリー分析への機械学習の適用によって、異常な動作を検出できます。予期しない動作が検出された場合、 [当該動作に対処するためのレコメンデーションを含む](https://docs.aws.amazon.com/devops-guru/latest/userguide/understanding-insights-console.html) 関連メトリクスとイベントを提供します。
**一般的なアンチパターン:**
+ あなたは、ネットワーク使用率のログを確認しています。このとき、ネットワーク使用率が午前 11 時 30 分から午後 1 時 30 分まで増加し、午後 4 時 30 分から午後 6 時 00 分まで再び増加していることに気づきます。あなたには、これを正常とみなすべきかどうかがわかりません。
+ ウェブサーバーは、毎日午前 3 時に再起動します。あなたには、これが予期される動作であるかどうかがわかりません。
**このベストプラクティスを活用するメリット:** 動作パターンを学習することで、予期しない動作を認識し、必要に応じてアクションを実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードに対して予想されるアクティビティのパターンを知る: ワークロードアクティビティのパターンを確立すると、行動が期待値から外れるタイミングを把握し、必要に応じて適切に対応できるようになります。
## リソース
**関連するドキュメント:**
+ [Amazon DevOps Guru](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
# OPS08-BP06 ワークロードの結果にリスクがある場合に警告する
ワークロードの結果にリスクがある場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
理想的には、警告の対象となるメトリクスのしきい値、または自動応答をトリガーするために使用できるイベントを前もって指定しておきます。
AWS では、 [Amazon CloudWatch Synthetics を使用して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 顧客と同じアクションを実行することで、エンドポイントと API をモニタリングするための Canary スクリプトを作成できます。生成されたテレメトリーと [得られたインサイトを使用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_Details.html) 顧客が影響を受ける前に問題を特定できます。
また、 [CloudWatch Logs Insights を使用して、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 専用のクエリ言語によりログデータをインタラクティブに検索および分析することもできます。CloudWatch Logs Insights は、 [AWS のサービスおよび JSON のカスタムログイベントからの](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html) ログのフィールドを自動的に検出します。ログボリュームとクエリの複雑さに応じてスケールし、数秒で回答が得られるため、インシデントの原因となる要因の検索に役立ちます。
**一般的なアンチパターン:**
+ ネットワーク接続がありません。誰も気づいていません。理由を特定しようとしたり、接続を復元するためのアクションを採ろうとしたりする人はいません。
+ パッチの適用後、永続的なインスタンスが使用できなくなり、ユーザーの操作を中断します。ユーザーがサポートケースをオープンしました。誰にも通知されていません。アクションを採ろうとしている人はいません。
**このベストプラクティスを活用するメリット:** ビジネス上の成果にリスクがあることを特定し、アクションが実行されるべきことをアラートすることで、インシデントの影響を防止または軽減する機会を得られます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ワークロードの結果にリスクがある場合にアラートを出す: ワークロードの結果にリスクがある場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-BP07 ワークロードの異常が検出された場合に警告する
ワークロードの異常が検出された場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
時間をかけてワークロードメトリクスを分析すると、イベントを定義したり、それに応じてアラームを発生させるために十分に定量化できる行動パターンが確立されることがあります。
トレーニングが完了すると、 [CloudWatch Anomaly Detection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) 機能を使用して、 [検出された異常を警告したり、](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html) メトリクスデータのグラフに重ねて [予想値を渡して](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html#create-metric-graph) 継続的な比較を行うことができます。
**一般的なアンチパターン:**
+ 小売業のウェブサイトの売上が急激かつ劇的に増加しました。誰も気づいていません。誰もこの急増の原因を特定しようとしていません。負荷が増える中で、質の高いカスタマーエクスペリエンスを確保するための措置を講じている人はいません。
+ パッチの適用後、永続的なサーバーが頻繁に再起動し、ユーザーの操作を中断します。サーバーは通常、最大 3 回まで再起動しますが、それを超えては再起動しません。誰も気づいていません。これが生じている理由を誰も特定しようとしていません。
**このベストプラクティスを活用するメリット:** ワークロードの動作パターンを理解することで、予期しない動作を特定し、必要に応じてアクションを実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ ワークロードの異常が検出された場合にアラートを出す: ワークロードの異常が検出された場合、必要に応じて適切な対応ができるよう、アラートを発生させます。
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [Amazon SNS 通知を使用した Lambda 関数の呼び出し](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda.html)
+ [Amazon CloudWatch Events とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
# OPS08-BP08 KPI とメトリクスの成果の達成度と有効性を検証する
ワークロードオペレーションに対するビジネスレベルの視点を確立すると、ニーズを満足しているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。
また、AWS は、AWS のサービス API や SDK を介してサードパーティーのログ分析システム (Grafana、Kibana、Logstash など) やビジネスインテリジェンスツールもサポートしています。
**一般的なアンチパターン:**
+ これまで、ページの応答時間は、顧客満足度に対する貢献要因であると考えられたことはありません。あなたは、ページの応答時間のメトリクスまたはしきい値を確立したことがありません。顧客は、「遅さ」について苦情を申し立てています。
+ あなたは、最小応答時間の目標を達成したことはありません。あなたは、応答時間を短縮するために、アプリケーションサーバーをスケールアップしました。応答時間の目標を大幅に超過することになり、また、支払っている容量の未使用部分も大幅に増加しました。
**このベストプラクティスを活用するメリット:** KPI とメトリクスを確認して修正することで、ワークロードがビジネス成果の達成をどのようにサポートしているかを理解し、ビジネス目標を達成するために改善が必要な場所を特定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
+ KPI とメトリクスの成果の達成度と有効性を検証する: ワークロード運用に対するビジネスレベルの視点を確立すると、ニーズを満たしているかどうかを判断したり、ビジネス目標を達成するために改善が必要な領域を特定したりできます。KPI とメトリクスの有効性を検証し、必要に応じて修正します。
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ログ分析とは](https://aws.amazon.com/log-analytics/)
## リソース
**関連するドキュメント:**
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ログ分析とは](https://aws.amazon.com/log-analytics/)