# PERF 5. 組織の慣行と文化は、ワークロードのパフォーマンス効率にどのように貢献していますか?
ワークロードを設計する際には、効率的で高性能なクラウドワークロードをより良く実行するために採用できる原則と慣行があります。クラウドワークロードのパフォーマンス効率を高める文化を採用するには、以下の重要な原則と慣行を検討します。
**Topics**
+ [PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する](perf_process_culture_establish_key_performance_indicators.md)
+ [PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する](perf_process_culture_use_monitoring_solutions.md)
+ [PERF05-BP03 ワークロードのパフォーマンス向上プロセスを定める](perf_process_culture_workload_performance.md)
+ [PERF05-BP04 ワークロードの負荷テストを実施する](perf_process_culture_load_test.md)
+ [PERF05-BP05 自動化でパフォーマンス関連の問題をプロアクティブに修正する](perf_process_culture_automation_remediate_issues.md)
+ [PERF05-BP06 ワークロードとサービスを最新の状態に保つ](perf_process_culture_keep_workload_and_services_up_to_date.md)
+ [PERF05-BP07 メトリクスを定期的に見直す](perf_process_culture_review_metrics.md)
# PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する
ワークロードのパフォーマンスを定量的および定性的に測定する KPI を特定します。KPI は、ビジネス目標に関連するワークロードの健全性とパフォーマンスを測定するのに役立ちます。
**一般的なアンチパターン:**
+ ワークロードについて把握するためだけにシステムレベルのメトリクスをモニタリングし、こうしたメトリクスがビジネスに与える影響を理解していない。
+ KPI が標準的なメトリクスデータとして既に発行され、共有されていると思っている。
+ 定量的で測定可能な KPI を定義していない。
+ KPI をビジネスの目標や戦略とすり合わせていない。
**このベストプラクティスを活用するメリット:** ワークロードの正常性とパフォーマンスを表す具体的な KPI を特定することで、チームの優先順位をすり合わせ、目指すべきビジネス成果とは何かを定義できます。これらのメトリクスをすべての部門と共有することで、しきい値、期待値、ビジネスへの影響が可視化され、調整を図ることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
KPI を使用すると、ビジネスチームとエンジニアリングチームが、目標と戦略の測定と、こうした要因がどのように組み合わさってビジネス成果を生み出すかについての認識をすり合わせることができます。例えば、ウェブサイトのワークロードには、ページの読み込み時間を全体的なパフォーマンスの指標として使用する場合があります。このメトリクスは、ユーザーエクスペリエンスを測定する複数のデータポイントのうちの 1 つとなります。ページの読み込み時間のしきい値を特定することに加えて、パフォーマンスが満たされない場合に期待される結果やビジネスリスクを文書化する必要があります。ページの読み込み時間が長いと、エンドユーザーに直接影響し、ユーザーエクスペリエンスの評価の低下、ひいては顧客の損失につながる可能性があります。KPI のしきい値を定義するときは、業界のベンチマークとエンドユーザーの期待値の両方を組み合わせます。例えば、現時点での業界のウェブページの読み込みベンチマークが 2 秒以内であっても、エンドユーザーが 1 秒以内での読み込みを期待する場合、KPI を設定する際にこれらのデータポイントの両方を考慮する必要があります。
チームは、リアルタイムの詳細なデータと参照用の履歴データを使用してワークロード KPI を評価し、KPI データにメトリクス計算を実行するダッシュボードを作成して、運用と使用状況に関する洞察を導き出す必要があります。KPI は文書化され、ビジネス目標と戦略をサポートするしきい値を含み、かつモニタリング対象のメトリクスに対応付けられている必要があります。ビジネスの目標および戦略、またはエンドユーザーの要件が変わった場合は、KPI を再検討する必要があります。
## 実装手順
+ **ステークホルダーを特定する:** 開発チームやオペレーションチームなど主要なビジネスステークホルダーを特定し、文書化します。
+ **目標を決める:** 特定したステークホルダーと一緒にワークロードの目標を決め、文書化します。スループット、応答時間、コストなど、ワークロードのパフォーマンス上重要となる側面に加え、ユーザー満足度などのビジネス目標も考慮に入れてください。
+ **業界のベストプラクティスを確認する:** 業界のベストプラクティスを確認して、ワークロードの目標に沿った関連 KPI を特定します。
+ **メトリクスの特定:** パフォーマンス目標とビジネス目標の測定に役立つ、ワークロードの目標に沿ったメトリクスを特定します。これらのメトリクスに基づいて KPI を設定します。メトリクスの例として、平均応答時間や同時ユーザー数などの測定値があります。
+ **KPI を定義し記録する:** 業界のベストプラクティスとワークロードの目標を使用して、ワークロード KPI のターゲットを設定します。この情報を使用して、重要度またはアラームレベルの KPI しきい値を設定します。KPI が満たされない場合のリスクと影響を特定して文書化します。
+ **モニタリングを実装する:** [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) や [AWS Config](https://aws.amazon.com/config/) などのモニタリングツールを使用して、メトリクスを収集し KPI を測定します。
+ **KPI を視覚的に伝える:** [Amazon Quick](https://aws.amazon.com/pm/quicksight/) などのダッシュボードツールを使用して KPI を視覚化し、ステークホルダーに伝えます。
+ **分析して最適化する:** KPI を定期的に確認、分析し、改善が必要なワークロードの領域を特定します。利害関係者と協力してこれらの改善を実装します。
+ **見直してブラッシュアップする:** メトリクスと KPI は定期的に、特にビジネス目標やワークロードのパフォーマンスに変更があったときなどは見直しを行ってその有効性を評価します。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Partner DevOps コンピテンシーパートナー - モニタリング、ログ記録、およびパフォーマンス](https://aws.amazon.com/devops/partner-solutions/#_Monitoring.2C_Logging.2C_and_Performance)
+ [AWS オブザーバビリティツール](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/aws-observability-tools.html)
+ [大規模なクラウド移行における重要業績評価指標 (KPI) の重要性](https://aws.amazon.com/blogs/mt/the-importance-of-key-performance-indicators-kpis-for-large-scale-cloud-migrations/)
+ [How to track your cost optimization KPIs with the KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [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 2023 - Optimize cost and performance and track progress toward mitigation](https://www.youtube.com/watch?v=keAfy8f84E0)
+ [AWS re:Invent 2023 - Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
+ [AWS re:Invent 2023 - Performance & efficiency at Pinterest: Optimizing the latest instances](https://www.youtube.com/watch?v=QSudpowE_Hs)
+ [AWS re:Invent 2022 - AWS optimization: Actionable steps for immediate results](https://www.youtube.com/watch?v=0ifvNf2Tx3w)
+ [AWS re:Invent 2023 - Building an effective observability strategy](https://www.youtube.com/watch?v=7PQv9eYCJW8)
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS](https://www.youtube.com/watch?v=or7uFFyHIX0)
+ [AWS re:Invent 2023 - Scaling on AWS for the first 10 million users ](https://www.youtube.com/watch?v=JzuNJ8OUht0)
+ [AWS re:Invent 2022 - How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA)
+ [ Creating an Effective Metrics Strategy for Your Business \$1 AWS Events ](https://www.youtube.com/watch?v=zBO-K4RvbtM)
**関連する例:**
+ [Quick でダッシュボードを作成する](https://github.com/aws-samples/amazon-quicksight-sdk-proserve)
# PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する
ワークロードのパフォーマンスの向上が効率性やカスタマーエクスペリエンスにプラスの影響を与える分野を理解し、特定します。例えば、カスタマーインタラクションが多いウェブサイトは、エッジサービスを使用してコンテンツ配信をお客様に近い場所へ移動させることでメリットを得ることができます。
**一般的なアンチパターン:**
+ パフォーマンスの問題を検出するには、CPU 使用率やメモリプレッシャーなどの標準的なコンピューティングメトリクスで十分であると考えている。
+ 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。
+ 問題が発生したときにだけメトリクスを確認している。
**このベストプラクティスを活用するメリット:** パフォーマンスの重要な領域を理解することで、ワークロードの所有者は KPI をモニタリングし、影響の大きいパフォーマンスの改善に優先順位をつけることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
エンドツーエンドの追跡を構築して、トラフィックパターン、レイテンシー、重要なパフォーマンス領域を特定します。データアクセスパターンをモニタリングして、低速なクエリや不十分にフラグメント化されパーティション化されたデータを検出します。負荷テストまたはモニタリングを使用して、ワークロードのボトルネックを特定します。
アーキテクチャ、トラフィックパターン、データアクセスパターンを理解し、レイテンシーと処理時間を特定することで、パフォーマンス効率を高めることができます。ワークロードが増加するにつれて、顧客エクスペリエンスに影響を及ぼす可能性のある潜在的なボトルネックを特定できます。この領域を調査したら、デプロイできるソリューションを調査し、パフォーマンスの懸念を取り除きます。
### 実装手順
+ エンドツーエンドのモニタリングを構築して、すべてのワークロードコンポーネントおよびメトリクスをキャプチャします。以下は、AWS のモニタリングソリューションの一部です。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/perf_process_culture_use_monitoring_solutions.html)
+ テストを実行してメトリクスを生成し、トラフィックパターン、ボトルネック、および重要なパフォーマンス領域を特定します。テストの実行方法の例として、次のようなものがあります。
+ [CloudWatch Synthetic Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) をセットアップして、Linux の cron ジョブまたは rate 式を使用してブラウザベースのユーザーアクティビティをプログラムで模倣するように設定し、長期にわたって一貫したメトリクスを生成します。
+ [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)のソリューションを使用して、ピークトラフィックを生成するか、予想される増加率でワークロードをテストします。
+ メトリクスとテレメトリを評価して、重要なパフォーマンス領域を特定します。これらの領域をチームと一緒にレビューして、モニタリングおよびボトルネックを防ぐためのソリューションについて話し合います。
+ パフォーマンスの改善をテストし、データを使用してこれらの変更を計測します。一例として、[CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html) を使用することで、ワークロードへの新たな改善とパフォーマンスへの影響をテストできます。
## リソース
**関連ドキュメント:**
+ [What's new in AWS Observability at re:Invent 2023](https://aws.amazon.com/blogs/mt/whats-new-in-aws-observability-at-reinvent-2023/)
+ [The Amazon Builders' Library](https://aws.amazon.com/builders-library)
+ [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)
+ [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)
**関連動画:**
+ [AWS re:Invent 2023 - [LAUNCH] Application monitoring for modern workloads](https://www.youtube.com/watch?v=T2TovTLje8w)
+ [AWS re:Invent 2023 - Implementing application observability](https://www.youtube.com/watch?v=IcTcwUSwIs4)
+ [AWS re:Invent 2023 - Building an effective observability strategy](https://www.youtube.com/watch?v=7PQv9eYCJW8)
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS](https://www.youtube.com/watch?v=or7uFFyHIX0)
+ [AWS re:Invent 2022 - AWS optimization: Actionable steps for immediate results](https://www.youtube.com/watch?v=0ifvNf2Tx3w)
+ [AWS re:Invent 2022 - The Amazon Builders’ Library: 25 years of Amazon operational excellence](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [AWS re:Invent 2022 - How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA)
+ [Visual Monitoring of Applications with Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=_PCs-ucZz7E)
**関連する例:**
+ [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)
+ [X-Ray SDK for Python](https://github.com/aws/aws-xray-sdk-python)
+ [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# PERF05-BP03 ワークロードのパフォーマンス向上プロセスを定める
新しいサービス、設計パターン、リソースの種類、設定が利用できるようになった時点で、これらを評価するプロセスを明確に定めます。例えば、新しいインスタンス製品で既存のパフォーマンステストを実行して、ワークロードを向上させる可能性を判断します。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが静的であり、今後更新されないと考えている。
+ メトリクスに基づく理由なしで、時間の経過とともにアーキテクチャの変更を導入する。
**このベストプラクティスを活用するメリット:** アーキテクチャの変更を行うためのプロセスを定義することで、ワークロード設計に経時的な影響を与えるために、収集されたデータを使用できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ワークロードのパフォーマンスには重要な制約がいくつかあります。その制約を文書化すれば、どのような種類のイノベーションがワークロードのパフォーマンス向上につながるかを把握できます。新しいサービスやテクノロジーが利用できるようになった場合、この情報を利用して、制約やボトルネックを軽減する方法を見つけます。
ワークロードの重要なパフォーマンス上の制約を特定します。どのようなイノベーションがワークロードパフォーマンスの向上につながるかを知ることができるように、ワークロードのパフォーマンスの制約を文書化します。
### 実装手順
+ **KPI を特定する:** 「[PERF05-BP01 ワークロードの状態とパフォーマンスを測定するための主要業績評価指標 (KPI) を設定する](perf_process_culture_establish_key_performance_indicators.md)」にあるように、ワークロードのパフォーマンス KPI を特定してワークロードのベースラインを定めます。
+ **モニタリングを実装する:** [AWS オブザーバビリティツール](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/aws-observability-tools.html)を使用してパフォーマンスメトリクスを収集し、KPI を測定します。
+ **分析を行う:** 「[PERF05-BP02 モニタリングソリューションを活用して、パフォーマンスが最も重要な分野について把握する](perf_process_culture_use_monitoring_solutions.md)」にあるように、詳細な分析を行って、、ワークロード内でパフォーマンスが低い領域 (設定やアプリケーションコードなど) を特定します。分析ツールとパフォーマンスツールを使用して、パフォーマンス改善戦略を特定します。
+ **改善を検証する:** サンドボックス環境または本番前環境を使用して、戦略の有効性を検証します。
+ **変更を実装する:** 変更を本番環境に実装し、ワークロードのパフォーマンスを継続的にモニタリングします。改善点を文書化し、利害関係者に変更点を報告します。
+ **見直してブラッシュアップする:** パフォーマンス改善プロセスを定期的に見直し、さらに改善できる部分がないか見きわめます。
## リソース
**関連ドキュメント:**
+ [AWSブログ](https://aws.amazon.com/blogs/)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected)
+ [AWS スキルビルダー](https://explore.skillbuilder.aws/learn)
**関連動画:**
+ [AWS re:Invent 2022 - Delivering sustainable, high-performing architectures](https://www.youtube.com/watch?v=FBc9hXQfat0)
+ [AWS re:Invent 2023 - Optimize cost and performance and track progress toward mitigation](https://www.youtube.com/watch?v=keAfy8f84E0)
+ [AWS re:Invent 2022 - AWS optimization: Actionable steps for immediate results](https://www.youtube.com/watch?v=0ifvNf2Tx3w)
+ [AWS re:Invent 2022 - Optimize your AWS workloads with best-practice guidance](https://www.youtube.com/watch?v=t8yl1TrnuIk)
**関連する例:**
+ [AWS GitHub](https://github.com/aws)
# PERF05-BP04 ワークロードの負荷テストを実施する
ワークロードの負荷テストを実施して、本番環境の負荷に対応できることを確認し、パフォーマンスのボトルネックを特定します。
**一般的なアンチパターン:**
+ あなたは、ワークロード全体ではなく、ワークロードの個々の部分について負荷テストを行います。
+ あなたは、本番環境とは異なるインフラストラクチャで負荷テストを行います。
+ あなたは、今後問題が発生する可能性を予測するのに役立てるため、予想される負荷に対してのみ、負荷テストを実施し、それを超える負荷に対しては負荷テストを実施しません。
+ 負荷テストを、[Amazon EC2 Testing Policy](https://aws.amazon.com/ec2/testing/) を実施したりシミュレーションイベント送信フォームを送信したりすることなく実行しています。これは、サービス妨害イベントとみなされ、テストの実行の失敗につながります。
**このベストプラクティスを活用するメリット:** 負荷テストでパフォーマンスを測定すると、負荷の増加に伴って影響を受ける場所が判明します。これにより、必要な変更がワークロードに影響を与える前に予測できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
クラウドでの負荷テストは、予想されるユーザー負荷を考慮して、現実的な条件下でクラウドワークロードのパフォーマンスを測定するプロセスです。このプロセスでは、本番環境と同様のクラウド環境をプロビジョニングし、負荷テストツールを使用して負荷を生成したうえで、メトリクスを分析してワークロードが現実的な負荷に対応できるかを評価します。ロードテストは、本番データの合成バージョンまたはサニタイズバージョン (機密情報または識別情報を削除) を使用して実行する必要があります。デリバリーパイプラインの一環として負荷テストを自動的に実行し、その結果を事前定義された KPI およびしきい値と比較します。このプロセスにより、必要なパフォーマンスを継続的に達成できます。
### 実装手順
+ **テスト目標を決める:** スループットや応答時間など、ワークロードで評価対象とするパフォーマンスの側面を特定します。
+ **テストツールを選択する:** ワークロードに適した負荷テストツールを選択して設定します。
+ **環境を設定する:** 本番環境に基づいてテスト環境を設定します。AWS のサービスを使用して、アーキテクチャをテストするための本番規模の環境を実行することができます。
+ **モニタリングを実装する:** [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) などのモニタリングツールを使用して、アーキテクチャ内のリソース全体でメトリクスを収集します。カスタムメトリクスを収集して発行することもできます。
+ **シナリオを定義する:** 負荷テストのシナリオとパラメータ (テスト期間やユーザー数など) を定義します。
+ **負荷テストを実施する:** テストシナリオを大規模に実施します。AWS クラウドを活用してワークロードをテストし、どこでスケールしないのか、あるいは非線形にスケールしているのかを発見してください 例えば、低コストで負荷を生成し、本番前にボトルネックを発見するには、スポットインスタンスを使用します。
+ **結果を分析する:** 結果を分析して、パフォーマンスのボトルネックおよび改善が必要な領域を特定します。
+ **結果を文書化して共有する:** 結果と推奨事項を文書化して報告します。この情報を利害関係者と共有して、パフォーマンスの最適化戦略に関して十分な情報に基づいた意思決定を行えるようにします。
+ **継続的に実行する:** 負荷テストは定期的に実行する必要があります。特に更新によりシステムが変更された後は必ず実行します。
## リソース
**関連ドキュメント:**
+ [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Distributed Load Testing on AWS](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/welcome.html)
**関連動画:**
+ [AWS Summit ANZ 2023: Accelerate with confidence through AWS Distributed Load Testing](https://www.youtube.com/watch?v=4J6lVqa6Yh8)
+ [AWS re:Invent 2022 - Scaling on AWS for your first 10 million users](https://www.youtube.com/watch?v=yrP3M4_13QM)
+ [Solving with AWS Solutions: Distributed Load Testing](https://www.youtube.com/watch?v=Y-2rk0sSyOM)
+ [AWS re:Invent 2021 - Optimize applications through end user insights with Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [Demo of Amazon CloudWatch Synthetics](https://www.youtube.com/watch?v=hF3NM9j-u7I)
**関連する例:**
+ [Distributed Load Testing on AWS](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)
# PERF05-BP05 自動化でパフォーマンス関連の問題をプロアクティブに修正する
主要業績評価指標 (KPI) をモニタリングおよびアラート発行システムと組み合わせて使用し、パフォーマンス関連の問題に積極的に対処します。
**一般的なアンチパターン:**
+ 運用スタッフのみに対して、ワークロードに運用上の変更を加えることを許可する。
+ プロアクティブな修復を行うことなく、すべてのアラームが運用チームに届くようにしている。
**このベストプラクティスを活用するメリット:** アラームアクションをプロアクティブに修正することで、サポートスタッフは自動的に実行できない項目に集中できます。これにより、運用スタッフがすべてのアラームの対応に忙殺されることがなくなり、代わりに重要なアラームのみに集中できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
アラームを使用して、可能な場合には自動的に問題を修正するアクションを呼び出します。自動化された対応が不可能な場合は、対応できるシステムにアラームをエスカレートします。例えば、期待される主要業績評価指標 (KPI) 値を予測し、それらが特定のしきい値を超えた場合にアラームを発行できるシステム、または KPI が期待される値の範囲外である場合に、デプロイメントを自動的に停止、またはロールバックできるツールなどが考えられます。
実行中のワークロードのパフォーマンスを目で見て確認できるようにするプロセスを実装します。モニタリングダッシュボードを構築し、パフォーマンス期待のベースラインとなる基準を確立して、ワークロードが最適に機能しているかどうかを判断します。
### 実装手順
+ **修正ワークフローを特定する:** 自動的に修正できるパフォーマンスの問題を特定して把握します。[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) や AWS X-Ray など、AWS のモニタリングソリューションを使用することで、問題の根本原因をよりよく理解できるようになります。
+ **オートメーションプロセスを定義する:** 問題の自動修正に使用できるステップバイステップの修正計画とプロセスを作成します。
+ **開始イベントを設定する:** 修正プロセスを自動的に開始するようにイベントを設定します。例えば、CPU 使用率が特定のしきい値に達したときにインスタンスを自動的に再起動するトリガーを定義できます。
+ **修正を自動化する:** AWS のサービスとテクノロジーを使用して修正プロセスを自動化します。例えば、[AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) を使用すると、安全かつスケーラブルに修正プロセスを自動化できます。問題がうまく解決されない場合は、必ず自己修復ロジックを使用して変更を元に戻してください。
+ **ワークフローをテストする:** 自動修正プロセスを本番前環境でテストします。
+ **ワークフローを実装する:** 自動修正を本番環境に実装します。
+ **プレイブックを作成する:** 開始イベント、修正ロジック、実行されたアクションなど、修正計画の手順を記したプレイブックを作成して文書化します。自動修正イベントに適切に対応できるように、必ず関係者へのトレーニングを行ってください。
+ **見直してブラッシュアップする:** 自動修正ワークフローの有効性を定期的に評価します。必要に応じて開始イベントと修正ロジックを調整します。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Partner Network DevOps コンピテンシーパートナー - モニタリング、ログ記録、およびパフォーマンス](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)
+ [CloudWatch でのアラームとアラームアクションの使用](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)
+ [クラウドオートメーションプラクティスを構築して運用上の優秀性を実現する: AWS Managed Services 提供のベストプラクティス](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Automate your Amazon Redshift performance tuning with automatic table optimization](https://aws.amazon.com/blogs/big-data/automate-your-amazon-redshift-performance-tuning-with-automatic-table-optimization/)
**関連動画:**
+ [AWS re:Invent 2023 - Strategies for automated scaling, remediation, and smart self-healing](https://www.youtube.com/watch?v=nlGyIa3UQYU)
+ [AWS re:Invent 2023 - [LAUNCH] Application monitoring for modern workloads](https://www.youtube.com/watch?v=T2TovTLje8w)
+ [AWS re:Invent 2023 - Implementing application observability](https://www.youtube.com/watch?v=IcTcwUSwIs4)
+ [AWS re:Invent 2021 - Intelligently automating cloud operations](https://www.youtube.com/watch?v=m0S8eAF0l54)
+ [AWS re:Invent 2022 - Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8)
+ [AWS re:Invent 2022 - Automating patch management and compliance using AWS](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [AWS re:Invent 2022 - How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents)
+ [AWS re:Invent 2023 - Take a load off: Diagnose & resolve performance issues with Amazon RDS](https://www.youtube.com/watch?v=Ulj88e5Aqzg)
+ [AWS re:Invent 2021 -\$1New Launch\$1 Automatically detect and resolve issues with Amazon DevOps Guru](https://www.youtube.com/watch?v=iwQNQHwoXfk)
+ [AWS re:Invent 2023 - Centralize your operations](https://www.youtube.com/watch?v=9-RBjmhDdaM)
**関連する例:**
+ [CloudWatch Logs Customize Alarms](https://github.com/awslabs/cloudwatch-logs-customize-alarms)
# PERF05-BP06 ワークロードとサービスを最新の状態に保つ
新しいクラウドサービスと機能の最新情報を入手し、効率的な機能を取り入れ、問題を取り除き、ワークロードの全体的なパフォーマンス効率を向上させます。
**一般的なアンチパターン:**
+ 現在のアーキテクチャが今後は静的なものとなり、しばらく更新されないと考えている。
+ 更新されたソフトウェアおよびパッケージがワークロードと互換性があるかどうかを評価するためのシステムまたは定期的な予定がない。
**このベストプラクティスを活用するメリット:** 新しいサービスやオファリングに関する最新情報を入手するプロセスを確立することで、新しい機能を取り入れ、問題を解決し、ワークロードパフォーマンスを向上させることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
新しいサービス、設計パターン、製品が利用可能になったら、パフォーマンスを向上させる方法を検討します。評価、社内でのディスカッション、または外部分析を通じて、これらのリリースとサービスのどれがワークロードのパフォーマンスまたは効率性を向上させるかを判断します。ワークロードに関連するアップデート、新しい機能、サービスを評価するプロセスを定義します。例えば、新テクノロジーを使用する PoC (概念実証) の構築や内部グループとの協議などのプロセスが考えられます。新しいアイデアやサービスを試す場合、パフォーマンステストを実施して、ワークロードのパフォーマンスへの影響を測定します。
## 実装手順
+ **ワークロードをインベントリに登録する:** ワークロードソフトウェアおよびアーキテクチャをインベントリに登録して、更新する必要があるコンポーネントを特定する。
+ **アップデートソースを特定する:** ワークロードコンポーネントに関連するニュースとアップデートソースを特定します。例えば、[AWS の最新情報ブログ](https://aws.amazon.com/new/)をサブスクライブすれば、ワークロードのコンポーネントに合った製品を確認できます。RSS フィードをサブスクライブするか[メールの購読](https://pages.awscloud.com/communication-preferences.html)を管理することで実行できます。
+ **更新スケジュールを定義する:** ワークロード用の新しいサービスと機能を評価するためのスケジュールを設定します。
+ [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)を使用すれば、Amazon EC2 インスタンスからオペレーティングシステム (OS)、アプリケーション、インスタンスのメタデータを収集し、どのインスタンスがソフトウェアポリシーで要求されるソフトウェアと設定を実行しているか、どのインスタンスがアップデートする必要があるかを迅速に把握することが可能です。
+ **新しい更新を評価する:** ワークロードのコンポーネントを更新する方法を理解します。クラウドの俊敏性を利用して、新しい機能によってワークロードがどのように改善するかをすばやくテストし、パフォーマンス効率を向上させます。
+ **自動化を使用する:** 更新プロセスにオートメーションを使用して、新しい機能をデプロイする労力のレベルを軽減し、手動プロセスに起因するエラーを抑制します。
+ [CI/CD](https://aws.amazon.com/blogs/devops/complete-ci-cd-with-aws-codecommit-aws-codebuild-aws-codedeploy-and-aws-codepipeline/) を使用すると、AMI、コンテナイメージなど、クラウドアプリケーションに関連するアーティファクトを自動的に更新できます。
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) などのツールを使用するとシステム更新のプロセスを自動化でき、[AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) を使用するとアクティビティをスケジュールできます。
+ **プロセスを文書化する:** 更新と新しいサービスとを評価するプロセスを文書化します。アップデートや新しいサービスを調査、テスト、実験、検証するために必要な時間と場所を所有者に提供します。文書化したビジネスの要件と KPI を参照して、どのアップデートがビジネスにメリットをもたらすかの優先順位を付けます。
## リソース
**関連ドキュメント:**
+ [AWSブログ](https://aws.amazon.com/blogs/)
+ [AWS の最新情報](https://aws.amazon.com/new/?ref=wellarchitected)
+ [Implementing up-to-date images with automated EC2 Image Builder pipelines](https://aws.amazon.com/blogs/compute/implementing-up-to-date-images-with-automated-ec2-image-builder-pipelines/)
**関連動画:**
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [All Things Patch: AWS Systems Manager \$1 AWS Events](https://www.youtube.com/watch?v=PhIiVsCEBu8)
**関連する例:**
+ [Inventory and Patch Management](https://mng.workshop.aws/ssm/use-case-labs/inventory_patch_management.html)
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US)
# PERF05-BP07 メトリクスを定期的に見直す
定期的なメンテナンスの一環として、またはイベントやインシデントに応じて、収集対象のメトリクスを見直します。この見直しを通じて、どのメトリクスが問題対応の鍵となったか、またどのメトリクスを追加で追跡すると問題の特定、対応、防止に役立つと思われるかを特定します。
**一般的なアンチパターン:**
+ メトリクスを長期間アラーム状態のままにする。
+ 自動システムによって実行できないアラームを作成する。
**このベストプラクティスを活用するメリット:** 収集されているメトリクスを継続的に見直し、問題について適切に識別、対応、または防止します。また、メトリクスは、長期間アラーム状態のままとなった場合にも、陳腐化することがあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
メトリクスの収集とモニタリングを継続的に改善します。インシデントやイベントへの対応の一環として、問題解決に役立ったメトリクスと、問題解決に役立った可能性があるものの、現在は追跡されていないメトリクスを評価します。この方法を使用して収集するメトリクスの品質を高め、今後のインシデントを防止、またはより迅速に解決できるようにします。
インシデントやイベントへの対応の一環として、問題解決に役立ったメトリクスと、問題解決に役立った可能性があるものの、現在は追跡されていないメトリクスを評価します。これを使用して収集するメトリクスの品質を高め、今後のインシデントを防止、またはより迅速に解決できるようにします。
### 実装手順
+ **メトリクスを定義する:** モニタリング対象となる主要なパフォーマンスメトリクス (応答時間やリソースの使用率などワークロード目標に沿ったもの) を定義します。
+ **ベースラインを設定する:** 各メトリクスのベースラインと目標値を設定します。ベースラインの設定により、逸脱や異常を特定するための基準点が明確になります。
+ **頻度を設定する:** 重要なメトリクスをレビューする頻度 (毎週、毎月など) を設定します。
+ **パフォーマンス上の問題を特定する:** 各レビューでは、傾向とベースライン値からの偏差を評価します。パフォーマンスのボトルネックや異常がないか調べます。特定された問題については、詳細な根本原因分析を実施して、問題の背後にある主な理由を把握します。
+ **是正措置を特定する:** 分析結果に基づいて是正措置を特定します。これには、パラメータの調整、バグの修正、リソースのスケーリングが含まれます。
+ **結果を文書化する:** 特定された問題、根本原因、是正措置など結果を文書化します。
+ **反復して改善する:** メトリクスのレビュープロセスを継続的に評価し改善します。前回のレビューで学んだ教訓を活かして、徐々にプロセスを強化します。
## リソース
**関連ドキュメント:**
+ [CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected)
+ [CloudWatch Metrics Insights を使用してメトリクスをクエリする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
+ [AWS Partner Network DevOps コンピテンシーパートナー - モニタリング、ログ記録、およびパフォーマンス](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)
**関連動画:**
+ [AWS re:Invent 2022 - Setting up controls at scale in your AWS environment](https://www.youtube.com/watch?v=NkE9_okfPG8)
+ [AWS re:Invent 2022 - How Amazon uses better metrics for improved website performance](https://www.youtube.com/watch?v=_uaaCiyJCFA&ab_channel=AWSEvents)
+ [AWS re:Invent 2023 - Building an effective observability strategy](https://www.youtube.com/watch?v=7PQv9eYCJW8)
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS](https://www.youtube.com/watch?v=or7uFFyHIX0)
+ [AWS re:Invent 2023 - Take a load off: Diagnose & resolve performance issues with Amazon RDS](https://www.youtube.com/watch?v=Ulj88e5Aqzg)
**関連する例:**
+ [Quick でダッシュボードを作成する](https://github.com/aws-samples/amazon-quicksight-sdk-proserve)
+ [CloudWatch Dashboards](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US/300-cloudwatch/340-cloudwatch-dashboards)