# REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する
ワークロードの状態を継続的にモニタリングすることで、お客様と自動化システムが障害やパフォーマンスの低下の発生をすみやかに把握できるようにします。ビジネス価値に基づいて主要業績評価指標 (KPI) をモニタリングします。
復旧および修復メカニズムはすべて、問題を迅速に検出する機能から開始する必要があります。技術的な障害を最初に検出して、解決できるようにするのです。ただし、可用性はワークロードがビジネス価値を提供する能力に基づいているため、これを測定する主要業績評価指標 (KPI) が検出および修正戦略の一部である必要があります。
**期待される成果:** ワークロードの重要なコンポーネントは個別にモニタリングされ、障害が発生したタイミングと場所で障害を検出してアラートを出します。
**一般的なアンチパターン:**
+ アラームが設定されていないため、停止は通知なしで発生する。
+ アラームは存在しますが、そのしきい値では対応するために十分な時間がない。
+ メトリクスは、目標復旧時間 (RTO) を満たすのに十分な頻度で収集されない。
+ ワークロードの顧客向けインターフェイスのみがアクティブにモニタリングされる。
+ 技術的なメトリクスのみ収集し、ビジネス関数のメトリクスは収集しない。
+ ワークロードのユーザーエクスペリエンスを測定するメトリクスがない。
+ 作成されたモニタが多すぎる。
**このベストプラクティスを活用するメリット:** すべてのレイヤーで適切なモニタリングを行うことで、検出までの時間を短縮して、復旧時間を短縮できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
モニタリングの対象となるすべてのワークロードを特定します。モニタリングする必要があるワークロードのすべてのコンポーネントを特定したら、次はモニタリングの間隔を決定します。モニタリングの間隔は、障害の検出にかかる時間に基づいた復旧を開始する速さに直接影響します。平均検出時間 (MTTD) は、障害が発生してから修理作業が開始されるまでの時間です。サービスのリストは広範囲かつ完全でなければなりません。
モニタリングは、アプリケーション、プラットフォーム、インフラストラクチャ、ネットワークを含むアプリケーションスタックのすべてのレイヤーを対象とする必要があります。
モニタリング戦略では、Gray failure の影響を考慮する必要があります。Gray failure の詳細については、ホワイトペーパー「Advanced Multi-AZ Resilience Patterns」の「[Gray failures](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)」を参照してください。
### 実装手順
+ モニタリング間隔は、どの程度迅速に復旧する必要があるかによって異なります。復旧時間は復旧にかかる時間によって決まるため、この時間と目標復旧時間 (RTO) を考慮して、収集の頻度を決定する必要があります。
+ コンポーネントとマネージドサービスの詳細なモニタリングを設定します。
+ [EC2 インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)と [Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) の詳細モニタリングが必要かどうかを判断します。詳細モニタリングは 1 分間隔メトリクスを提供し、デフォルトのモニタリングは 5 分間隔メトリクスを提供します。
+ RDS の[拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html)が必要かどうかを判断します。拡張モニタリングでは、RDS インスタンスのエージェントを使用して、さまざまなプロセスまたはスレッドに関する有益な情報を取得します。
+ [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html)、[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/monitoring_automated_manual.html)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html)、[Amazon ECS](https://catalog.workshops.aws/observability/en-US/aws-managed-oss/amp/ecs)、すべての[ロードバランサー](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-monitoring.html)のタイプに不可欠なサーバーレスコンポーネントの、モニタリング要件を決定します。
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html)、[Amazon FSx](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring_overview.html)、[Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/monitoring_overview.html)、[Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html) のストレージコンポーネントのモニタリング要件を決定します。
+ ビジネスの重要業績評価指標 (KPI) を測定する[カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を作成します。ワークロードには主要なビジネス機能が実装されており、いつ間接的な問題が発生したのかを特定するのに役立つ KPI として使用される必要があります。
+ ユーザー Canary を使用して、障害に対するユーザーエクスペリエンスをモニタリングします。顧客の行動を実行およびシミュレートできる[合成トランザクションテスト](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (「canary テスト」ともいう。「カナリアデプロイ」と混同しないこと) は、最も重要なテストプロセスの 1 つです。さまざまなリモートロケーションからワークロードエンドポイントに対してこれらのテストを常に実行します。
+ ユーザーのエクスペリエンスを追跡する[カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を作成します。顧客のエクスペリエンスを測定できる場合は、コンシューマーエクスペリエンスが低下するタイミングを判断できます。
+ ワークロードのいずれかの要素が正常に動作していない場合にこれを検出し、リソースを自動的にスケールする時期を示す、[アラームを設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)します。アラームは、ダッシュボードに視覚的に表示したり、Amazon SNS または E メールを介して送信したり、Auto Scaling と連携させてワークロードリソースをスケールアップ/スケールダウンするのに使用したりすることができます。
+ [ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)を作成してメトリクスを視覚化します。ダッシュボードは、傾向や異常値などの潜在的な問題の指標を視覚的に確認したり、調査対象となり得る問題の存在を示したりするために使用できます。
+ サービスに[分散トレースモニタリング](https://aws.amazon.com/xray/faqs/)を作成します。分散型モニタリングにより、アプリケーションと基盤となるサービスがどのように動作しているかを理解して、パフォーマンスの問題やエラーの根本原因を特定し、トラブルシューティングすることができます。
+ モニタリングシステム ([CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html) または [X-Ray](https://aws.amazon.com/xray/faqs/) を使用) のダッシュボードとデータ収集を別のリージョンとアカウントに作成します。
+ [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) でサービスの低下について最新情報を入手してください。[AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) を通じて E メールやチャットチャネルに、[目的に合った AWS Health イベント通知を作成](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)し、[Amazon EventBridge を通じてモニタリングツールやアラートツール](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)をプログラムで統合します。
## リソース
**関連するベストプラクティス:**
+ [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [REL11-BP06 イベントが可用性に影響する場合に通知を送信する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_notifications_sent_system.html)
**関連ドキュメント:**
+ [canary の使用 (Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [インスタンスの詳細モニタリングを有効または無効にする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Auto Scaling グループとインスタンスを Amazon CloudWatch でモニタリングする](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [クロスアカウントクロスリージョンダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_xaxr_dashboard.html)
+ [AWS X-Ray のよくある質問](https://aws.amazon.com/xray/faqs/)
+ [可用性について](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/understanding-availability.html)
**関連動画:**
+ [グレー障害の緩和](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
**関連する例:**
+ [つのオブザーバビリティワークショップ: X-Ray の探究](https://catalog.workshops.aws/observability/en-US/aws-native/xray/explore-xray)
**関連ツール:**
+ [CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [CloudWatch X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/security-logging-monitoring.html)