# PERF 7 リソースが稼働していることを確認するには、リソースをどのようにモニタリングすればよいですか?
システムのパフォーマンスは徐々に低下することがあります。劣化を特定し、オペレーティングシステムまたはアプリケーション負荷などの内部および外部の要因を修正するために、システムのパフォーマンスをモニタリングします。
**Topics**
+ [PERF07-BP01 パフォーマンスに関連するメトリクスを記録する](perf_monitor_instances_post_launch_record_metrics.md)
+ [PERF07-BP02 イベントやインシデントが発生したときにメトリクスを分析する](perf_monitor_instances_post_launch_review_metrics.md)
+ [PERF07-BP03 ワークロードのパフォーマンスを測定するための重要業績評価指標 (KPI) を設定する](perf_monitor_instances_post_launch_establish_kpi.md)
+ [PERF07-BP04 モニタリングを使用してアラームベースの通知を生成する](perf_monitor_instances_post_launch_generate_alarms.md)
+ [PERF07-BP05 メトリクスを定期的に見直す](perf_monitor_instances_post_launch_review_metrics_collected.md)
+ [PERF07-BP06 モニタリングしてプロアクティブに警告する](perf_monitor_instances_post_launch_proactive.md)
# PERF07-BP01 パフォーマンスに関連するメトリクスを記録する
モニタリングとオブザーバビリティサービスを使用して、パフォーマンス関連のメトリクスを記録します。メトリクスの例としては、データベーストランザクションの記録、低速クエリ、I/O レイテンシー、HTTP リクエストスループット、 サービスレイテンシー、その他の重要なデータなどがあります。
ワークロードにとって重要なパフォーマンスメトリクスを特定して記録します。このデータは、ワークロードの全体的なパフォーマンスや効率性に影響するコンポーネントを特定するための重要な要素です。
再度カスタマーエクスペリエンスを元に、重要なメトリクスを特定します。メトリクスごとに、ターゲット、測定アプローチ、および優先順位を特定します。これらを使用してアラームと通知を構築し、パフォーマンス関連の問題に積極的に対応します。
**一般的なアンチパターン:**
+ ワークロードに関する洞察を得るために、オペレーティングシステムレベルのメトリクスのモニタリングのみを行う。
+ ピーク時のワークロード要件に合わせてコンピューティングニーズを設計する。
**このベストプラクティスを確立するメリット:** パフォーマンスとリソース使用率を最適化するには、主要業績評価指標の統合された運用ビューが必要です。ダッシュボードを作成して、データに関するメトリクスの計算を実行して運用と利用に関する洞察を得ることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードに関連するパフォーマンスメトリクスを特定し、それらを記録します。このデータは、どのコンポーネントがワークロードの全体的なパフォーマンスまたは効率性に影響しているかを特定するのに役立ちます。
パフォーマンスメトリクスを特定する: カスタマーエクスペリエンスを使用して、最も重要なメトリクスを特定します。メトリクスごとに、ターゲット、測定アプローチ、および優先順位を特定します。これらのデータポイントを使用してアラームと通知を構築し、パフォーマンス関連の問題に積極的に対応します。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected)
+ [カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html?ref=wellarchitected)
+ [モニタリング、ログ記録、パフォーマンス APN パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
**関連動画:**
+ [Cut through the chaos: Gain operational visibility and insight (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0)
+ [Application Performance Management on AWS (AWS でのアプリケーションパフォーマンス管理)](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected)
+ [Build a Monitoring Plan](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
**関連サンプル:**
+ [Level 100: Monitoring with CloudWatch Dashboards (レベル 100: CloudWatch ダッシュボードを使ったモニタリング)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/)
+ [Level 100: Monitoring Windows EC2 instance with CloudWatch Dashboards (レベル 100: ダッシュボードを使った Windows EC2 インスタンスのモニタリング)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/)
+ [Level 100: Monitoring an Amazon Linux EC2 instance with CloudWatch Dashboards (レベル 100: CloudWatch ダッシュボードを使った Amazon Linux EC2 インスタンスのモニタリング)](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/)
# PERF07-BP02 イベントやインシデントが発生したときにメトリクスを分析する
イベントやインシデントが発生した後 (または発生中) に、モニタリングダッシュボードやレポートを使用してその影響を把握して診断します。これらのビューは、ワークロードのどの部分が期待通りに機能していないかに関するインサイトを提供します。
アーキテクチャに重要なユーザーストーリーを記述するときは、パフォーマンス要件を含めるようにし、それぞれの重要なストーリーをどの程度迅速に実行する必要があるかといった点を明記します。これらの重要なストーリーには、要件に対してこれらのストーリーがどのように実行されるかを知ることができるように、スクリプト化されたユーザージャーニーを追加で実装します。
**一般的なアンチパターン:**
+ パフォーマンスイベントが一度限りのもので、異常にのみ関連するものであると考えている。
+ パフォーマンスイベントに対応する場合にのみ、既存のパフォーマンスメトリクスを評価する。
**このベストプラクティスを活用するメリット:** ワークロードが想定レベルで動作しているかどうかを判断するには、分析のために追加のメトリクスデータを収集してパフォーマンスイベントに対応する必要があります。このデータは、パフォーマンスイベントの影響を理解し、ワークロードのパフォーマンスを改善するための変更を提案するために使用されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
アーキテクチャに重要なユーザーストーリーを記述するときは、パフォーマンス要件を含めるようにし、それぞれの重要なストーリーをどの程度迅速に実行する必要があるかといった点を明記します。これらの重要なストーリーには、要件に対してユーザーストーリーがどのように実行されるかを知ることができるように、スクリプト化されたユーザージャーニーを追加で実装してください。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [モニタリング、ログ記録、パフォーマンス APN パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**関連動画:**
+ [Cut through the chaos: Gain operational visibility and insight (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0)
+ [Optimize applications through Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [Amazon CloudWatch Synthetics のデモ](https://www.youtube.com/watch?v=hF3NM9j-u7I)
**関連サンプル:**
+ [Measure page load time with Amazon CloudWatch Synthetics](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
+ [Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web)
# PERF07-BP03 ワークロードのパフォーマンスを測定するための重要業績評価指標 (KPI) を設定する
ワークロードのパフォーマンスを定量的および定性的に測定する KPI を特定します。KPI は、ビジネス目標に関連するワークロードの状態を測定するのに役立ちます。KPI を使用すると、ビジネスチームとエンジニアリングチームが、目標と戦略の測定と、それらがどのように組み合わさってビジネス成果を生み出すかについての認識をすり合わせることができます。ビジネスの目標および戦略、またはエンドユーザーの要件が変わった場合は、KPI を再検討する必要があります。
例えば、ウェブサイトのワークロードには、ページの読み込み時間を全体的なパフォーマンスの指標として使用する場合があります。このメトリクスは、エンドユーザーエクスペリエンスを測定する複数のデータポイントのうちの 1 つとなります。ページの読み込み時間のしきい値を特定することに加えて、パフォーマンスが満たされない場合に期待される結果やビジネスリスクを文書化する必要があります。ページの読み込み時間が長いと、エンドユーザーに直接影響し、ユーザーエクスペリエンスの評価の低下、ひいては顧客の損失につながる可能性があります。KPI のしきい値を定義するときは、業界のベンチマークとエンドユーザーの期待値の両方を組み合わせます。例えば、現時点での業界のウェブページの読み込みベンチマークが 2 秒以内であっても、エンドユーザーが 1 秒以内での読み込みを期待する場合、KPI を設定する際にこれらのデータポイントの両方を考慮する必要があります。KPI の別の例として、内部パフォーマンスのニーズを満たすことに焦点を当てることもできます。本番データが生成されてから 1 営業日以内に売上レポートが作成されると、KPI のしきい値が設定される場合があります。これらのレポートは、日々の意思決定やビジネス成果に直接影響する可能性があります。
**期待される成果:** KPI の設定には、さまざまな部門やステークホルダーが関与します。チームは、リアルタイムの詳細なデータと参照用の履歴データを使用してワークロード KPI を評価し、KPI データにメトリクス計算を実行するダッシュボードを作成して、運用と使用状況に関する洞察を導き出す必要があります。KPI は、ビジネス目標や戦略をサポートするために合意された KPI としきい値を説明し、モニタリング対象のメトリクスに対応付け、文書化する必要があります。KPI は、パフォーマンス要件を特定し、意図的に見直され、すべてのチームと頻繁に共有され、理解されています。リスクとトレードオフが明確に特定され、KPI のしきい値が満たされない場合にビジネスにどのような影響があるかが理解されています。
**一般的なアンチパターン:**
+ ワークロードについての洞察を得るためだけにシステムレベルのメトリクスをモニタリングし、これらのメトリクスがビジネスに与える影響を理解していない。
+ KPI が標準的なメトリクスデータとして既に発行され、共有されていると思っている。
+ KPI を定義したのにすべてのチームと共有していない。
+ 定量的で測定可能な KPI を定めていない。
+ KPI をビジネスの目標や戦略とすり合わせていない。
**このベストプラクティスを確立するメリット:** ワークロードの状態を表す具体的なメトリクスを特定することは、チームの優先事項を調整し、成功に向けたビジネス成果を定義するのに役立ちます。これらのメトリクスをすべての部門と共有することで、しきい値、期待値、ビジネスへの影響が可視化され、調整を図ることができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
KPI の設定には、ワークロードの状態によって影響を受けるすべての部門とビジネスチームが貢献する必要があります。組織の KPI に関するコラボレーション、タイムライン、ドキュメント、情報伝達の推進は 1 人の人物が担当するべきです。多くの場合、この人物が所有者となり、ビジネスの目標と戦略を共有し、ビジネスのステークホルダーにそれぞれの部門の KPI を策定するタスクを割り当てます。KPI が定義されたら、多くの場合、運用チームがさまざまな KPI を支援し、成功を示すメトリクスの定義をサポートします。KPI は、ワークロードを支えるチームの全員が KPI を認識している場合にのみ効果があります。
**実装手順**
1. ビジネスのステークホルダーを特定して文書化します。
1. 会社の目標と戦略を特定します。
1. 会社の目標と戦略と一致する一般的な業界 KPI を確認します。
1. ワークロードに対するエンドユーザーの期待を確認します。
1. 会社の目標と戦略をサポートする KPI を定義し、文書化します。
1. KPI を満たすための承認済みのトレードオフ戦略を特定し、文書化します。
1. KPI を表すメトリクスを特定し、文書化します。
1. 重大度またはアラームレベルの KPI しきい値を特定して文書化します。
1. KPI が満たされない場合のリスクと影響を特定して文書化します。
1. KPI ごとにレビューの頻度を特定します。
1. ワークロードをサポートするすべてのチームに KPI 関連の文書について連絡します。
** 実装ガイドに必要な工数レベル:** KPI の定義と伝達にかかる労力は *低* レベルです。これは通常、ビジネス関係者と数週間にわたってミーティングを行い、目標、戦略、ワークロードのメトリクスを確認することで達成できます。
## リソース
**関連ドキュメント:**
+ [CloudWatch documentation (CloudWatch ドキュメント) ](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Monitoring, Logging, and Performance APN Partners (モニタリング、ログ記録、パフォーマンス APN パートナー)](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray Documentation (X-Ray ドキュメント) ](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html?ref=wellarchitected)
+ [Quick KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
**関連動画:**
+ [AWS re:Invent 2019: Scaling up to your first 10 million users (ARC211-R) (最初の 1,000 万ユーザーまでのスケールアップ)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected)
+ [Cut through the chaos: Gain operational visibility and insight (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected)
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
**関連サンプル:**
+ [Creating a dashboard with Quick (Quick でダッシュボードを作成する)](https://github.com/aws-samples/amazon-quicksight-sdk-proserve)
# PERF07-BP04 モニタリングを使用してアラームベースの通知を生成する
モニタリングシステムを使用し、定義したパフォーマンス関連の主要業績評価指標 (KPI) の測定値が予想された境界線の外側にある場合に自動的にアラームを生成します。
Amazon CloudWatch では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch またはサードパーティーのモニタリングサービスを使用して、しきい値を超えたことを示すアラームを設定します。このアラームは、メトリクスが期待される限度を超えたことを知らせます。
**一般的なアンチパターン:**
+ メトリクスのモニタリングと、問題が発生したときの対応をスタッフに頼っている。
+ 同じタスクを達成するためにサーバーレスワークフローがトリガーできるにもかかわらず、運用ランブックのみに頼っている。
**このベストプラクティスを活用するメリット:** 事前定義されたしきい値、またはメトリクスの異常な動作を識別する機械学習アルゴリズムに基づいて、アラームを設定してアクションを自動化できます。これらの同じアラームは、サーバーレスワークフローをトリガーし、ワークロードのパフォーマンス特性を変更することもできます (例えば、コンピューティング性能の増加、データベース設定の変更など)。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
メトリクスをモニタリングする: Amazon CloudWatch では、アーキテクチャ内のリソース全体のメトリクスを収集できます。カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することができます。CloudWatch またはサードパーティーのモニタリングサービスを使用して、しきい値を超過したことを示すアラームを設定します。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [モニタリング、ログ記録、パフォーマンス APN パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Using Alarms and Alarm Actions in CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)
**関連動画:**
+ [AWS re:Invent 2019: Scaling up to your first 10 million users (ARC211-R)](https://www.youtube.com/watch?v=kKjm4ehYiMs&ref=wellarchitected)
+ [Cut through the chaos: Gain operational visibility and insight (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0&ref=wellarchitected)
+ [Build a Monitoring Plan](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
+ [Using AWS Lambda with Amazon CloudWatch Events](https://www.youtube.com/watch?v=WDBD3JmpLqs)
**関連サンプル:**
+ [Cloudwatch Logs Customize Alarms](https://github.com/awslabs/cloudwatch-logs-customize-alarms)
# PERF07-BP05 メトリクスを定期的に見直す
定期的なメンテナンスとして、またはイベントやインシデントに応じて、収集対象のメトリクスを見直します。これらのレビューを使用して、どのメトリクスが問題対応の鍵となったか、またどのメトリクスを追加すると、それらが追跡される場合に問題の特定、対応、または防止に役立つと思われるかを特定します。
インシデントやイベントへの対応の一環として、問題解決に役立ったメトリクスと、問題解決に役立った可能性があるものの、現在は追跡されていないメトリクスを評価します。これを使用して、収集するメトリクスの品質を高め、今後のインシデントを防止、またはより迅速に解決できるようにします。
**一般的なアンチパターン:**
+ メトリクスを長期間アラーム状態のままにする。
+ 自動システムによって実行できないアラームを作成する。
**このベストプラクティスを活用するメリット:** 収集されているメトリクスを継続的に見直し、問題を適切に識別、対応、または防止します。また、メトリクスは、長期間アラーム状態のままとなった場合にも、陳腐化することがあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
メトリクスの収集とモニタリングを継続的に改善する: インシデントまたはイベント対応の一環として、問題への対応に役立ったメトリクス、および現在は追跡されていないが役に立ったであろうと思われるメトリクスを評価します。この方法を使用して収集するメトリクスの品質を高め、今後のインシデントを防止、またはより迅速に解決できるようにします。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected)
+ [モニタリング、ログ記録、パフォーマンス APN パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**関連動画:**
+ [Cut through the chaos: Gain operational visibility and insight (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0)
+ [Application Performance Management on AWS](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected)
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
**関連サンプル:**
+ [Creating a dashboard with Quick](https://github.com/aws-samples/amazon-quicksight-sdk-proserve)
+ [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/)
# PERF07-BP06 モニタリングしてプロアクティブに警告する
主要業績評価指標 (KPI) をモニタリングおよびアラート発行システムと組み合わせて使用し、パフォーマンス関連の問題に積極的に対処します。アラームを使用して、可能な場合に問題を修正する自動化されたアクションをトリガーします。自動化された対応が不可能な場合は、対応できるシステムにアラームをエスカレートします。たとえば、期待される主要業績評価指標 (KPI) 値を予測し、それらが特定のしきい値を超えた場合にアラームを発行できるシステム、または KPI が期待される値の範囲外である場合に、デプロイメントを自動的に停止、またはロールバックできるツールなどが考えられます。
実行中のワークロードのパフォーマンスを目で見て確認できるようにするプロセスを実装します。モニタリングダッシュボードを構築し、パフォーマンス期待のベースラインとなる基準を確立して、ワークロードが最適に機能しているかどうかを判断します。
**一般的なアンチパターン:**
+ 運用スタッフのみに対して、ワークロードに運用上の変更を加えることを許可する。
+ プロアクティブな修復を行うことなく、すべてのアラームが運用チームに届くようにしている。
**このベストプラクティスを活用するメリット:** アラームアクションをプロアクティブに修正することで、サポートスタッフは自動的に実行できない項目に集中できます。これにより、運用スタッフがすべてのアラームの対応に忙殺されることがなくなり、代わりに重要なアラームのみに集中できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
運用中にパフォーマンスをモニタリングする: 実行中のワークロードのパフォーマンスを目で見て確認できるプロセスを実装します。モニタリングダッシュボードを構築し、期待されるパフォーマンスのベースラインを確立します。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [モニタリング、ログ記録、パフォーマンス APN パートナー](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [X-Ray ドキュメント](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Using Alarms and Alarm Actions in CloudWatch](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)
**関連動画:**
+ [Cut through the chaos: Gain operational visibility and insight (MGT301-R1)](https://www.youtube.com/watch?v=nLYGbotqHd0)
+ [Application Performance Management on AWS](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected)
+ [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected)
+ [Using AWS Lambda with Amazon CloudWatch Events](https://www.youtube.com/watch?v=WDBD3JmpLqs)
**関連サンプル:**
+ [Cloudwatch Logs Customize Alarms](https://github.com/awslabs/cloudwatch-logs-customize-alarms)