# REL 6. ワークロードのリソースをどのようにモニタリングするのですか。
ログやメトリクスは、ワークロードの状態に関するインサイトを得るための強力なツールです。ログやメトリクスをモニタリングし、しきい値を超えたときや、重要なイベントが発生したときに通知を送信するようにワークロードを設定することができます。モニタリングにより、ワークロードが低パフォーマンスのしきい値を超えたときや障害が発生したときにそれらを認識し、それに応じて自動的に復旧できます。
**Topics**
+ [
# REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)
](rel_monitor_aws_resources_monitor_resources.md)
+ [
# REL06-BP02 メトリクスを定義および計算する (集計)
](rel_monitor_aws_resources_notification_aggregation.md)
+ [
# REL06-BP03 通知を送信する (リアルタイム処理とアラーム)
](rel_monitor_aws_resources_notification_monitor.md)
+ [
# REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)
](rel_monitor_aws_resources_automate_response_monitor.md)
+ [
# REL06-BP05 ログの分析
](rel_monitor_aws_resources_storage_analytics.md)
+ [
# REL06-BP06 モニタリングの範囲とメトリクスを定期的に確認する
](rel_monitor_aws_resources_review_monitoring.md)
+ [
# REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
](rel_monitor_aws_resources_end_to_end.md)
# REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)
ワークロードのコンポーネントは、Amazon CloudWatch またはサードパーティーのツールを使ってモニタリングします。AWS サービスを AWS Health ダッシュボードでモニタリングします。
フロントエンド、ビジネスロジック、ストレージ層など、ワークロードのすべてのコンポーネントをモニタリングする必要があります。主要なメトリクスと、必要に応じてそれをログから抽出する方法を定義し、対応するアラームイベントを起動させるためのしきい値を設定します。メトリクスがワークロードの重要業績評価指標 (KPI) に関連していることを確認し、メトリクスとログを使用して、サービス低下の早期警告サインを識別します。例えば、1 分間に正常に処理されたオーダー数など、ビジネス成果に関するメトリクスは、CPU 使用率などの技術的メトリクスより早く、ワークロード問題を示すことができます。AWS Health ダッシュボードは、AWS リソースの基盤となる AWS のサービスのパフォーマンスと可用性をパーソナライズして表示するために使用します。
クラウドでのモニタリングは新しい機会をもたらします。ほとんどのクラウドプロバイダーは、カスタマイズ可能なフックを開発して、ワークロードの複数のレイヤーをモニタリングする際に役立つインサイトを提供しています。Amazon CloudWatch などの AWS サービスは、統計的な機械学習アルゴリズムを応用して、システムとアプリケーションのメトリクスを継続的に分析し、正常なベースラインを決定し、最小限のユーザー介入で異常を表面化します。異常検出アルゴリズムは、メトリクスの季節的な変化と傾向の変化を考慮します。
AWS では、豊富なモニタリングおよびログ情報を公開しており、これらを使用して、ワークロード固有のメトリクスと需要変化プロセスを定義し、機械学習の知識に関わらず、機械学習技法を適応させることができます。
さらに、すべての外部エンドポイントをモニタリングし、それらがベースとなる実装から独立していることを確認します。このアクティブモニタリングは、合成トランザクション (「ユーザー canary」ともいう。「カナリアデプロイ」と混同しないこと) で行うことができます。これは、ワークロードのクライアントが実行するアクションに相当する多くの共通タスクを定期的に実行するものです。これらのタスクは、短期間に保ち、テスト中にワークロードに負荷をかけすぎないようにしてください。Amazon CloudWatch Synthetics を使用すると、[Synthetic canaries を作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)してエンドポイントと API をモニタリングすることができます。合成 canary クライアントノードと AWS X-Ray コンソールを組み合わせて、選択した期間中にエラー、障害、スロットリング率で問題が発生している合成 canary を特定することもできます。
**期待される成果:**
ワークロードのすべてのコンポーネントから重要なメトリクスを収集して使用し、ワークロードの信頼性と最適なユーザーエクスペリエンスを確保します。ワークロードがビジネス成果を達成していないことを検出した場合は、障害を迅速に宣言して、インシデントから復旧できます。
**一般的なアンチパターン:**
+ ワークロードへの外部インターフェイスのみをモニタリングする。
+ ワークロード固有のメトリクスを生成せず、ワークロードが使用している AWS から提供されるメトリクスにのみ依存する。
+ ワークロードの技術的メトリクスを使用するだけで、ワークロードが貢献する非技術的な KPI に関するメトリクスをモニタリングしない。
+ 本番トラフィックとシンプルなヘルスチェックに依存して、ワークロード状態をモニタリングし、評価する。
**このベストプラクティスを活用するメリット:** ワークロードのすべての階層でモニタリングすることで、ワークロードを構成するコンポーネントの問題をより迅速に予測し、解決できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
1. **可能な限りログを有効にします。**ワークロードのすべてのコンポーネントからモニタリングデータを取得する必要があります。S3 Access Logs など、追加のロギングをオンにして、ワークロードがワークロード固有のデータをログに記録できるようにします。Amazon ECS、Amazon EKS、Amazon EC2、Elastic Load Balancing、AWS Auto Scaling、Amazon EMR などのサービスから、CPU、ネットワーク I/O、ディスク I/O の平均、に関するメトリクスを収集します。CloudWatch にメトリクスをパブリッシュする AWS のサービスの一覧については、「[CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)」を参照してください。
1. **デフォルトのメトリクスをすべてレビューし、データ収集にギャップがないか確認します。**すべてのサービスはデフォルトのメトリクスを生成します。デフォルトのメトリクスを収集することで、ワークロードのコンポーネント間の依存関係と、コンポーネントの信頼性とパフォーマンスがワークロードに及ぼす影響をより深く理解できます。メトリクスは、AWS CLI または API を使用して作成し、CloudWatch に[パブリッシュ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)することもできます。
1. **すべてのメトリクスを評価して、ワークロード内の各 AWS サービスに対してどのメトリクスでアラートを発するかを決定します。**ワークロードの信頼性に大きな影響を持つメトリクスのサブセットを選択することもできます。重要なメトリクスとしきい値に焦点を当てることで、[アラート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)の数を絞り込み、偽陽性を最小限に抑えることができます。
1. **アラートを定義し、アラートが起動した後のワークロードの復旧プロセスを定義します。**アラートを定義することで、通知とエスカレーションを迅速に行い、インシデントからの復旧に必要なステップに従い、所定の目標復旧時間 (RTO) を満たすことができます。[https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions) を使用すると、定義されたしきい値に基づいて自動ワークフローを呼び出し、回復手順を開始することができます。
1. **合成トランザクションを使用して、ワークロードの状態に関する関連データを収集することを検討しましょう。**合成モニタリングは、顧客と同じルートに従って同じアクションを実行するため、ワークロードに顧客のトラフィックがない場合でも、継続的にカスタマーエクスペリエンスを検証することが可能になります。[合成トランザクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)を使用すると、顧客が問題を検出する前に問題を検出できます。
## リソース
**関連するベストプラクティス:**
+ [REL11-BP03 すべてのレイヤーの修復を自動化する](rel_withstand_component_failures_auto_healing_system.md)
**関連ドキュメント:**
+ [AWS Health Dashboard の使用開始 – アカウントヘルスの確認](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)
+ [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Network Load Balancer のアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-access-logs.html)
+ [Application Load Balancer のアクセスログ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html)
+ [AWS Lambda での Amazon CloudWatch Logs の使用](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html)
+ [サーバーアクセスログによるリクエストのログ記録](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html)
+ [Classic Load Balancer のアクセスログの有効化](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html)
+ [Amazon S3 へのログデータのエクスポート](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [CloudWatch エージェントをインストールする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/install-CloudWatch-Agent-on-EC2-Instance.html)
+ [カスタムメトリクスを発行する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [合成モニタリング (canary)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
**ユーザーガイド:**
+ [証跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html)
+ [CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)
+ [Amazon ECS のモニタリングツール](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [VPC フローログ](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/flow-logs.html)
+ [Amazon DevOps Guru とは](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [What is AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
**関連ブログ:**
+ [Amazon CloudWatch Synthetics と AWS X-Ray でのデバッグ](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
**関連する例:**
+ [Amazon Builders' Library: 運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US)
# REL06-BP02 メトリクスを定義および計算する (集計)
ワークロードコンポーネントからメトリクスとログを収集し、そこから関連する集計メトリクスを計算します。これらのメトリクスは、ワークロードの広範で深いオブザーバビリティを提供し、耐障害性の態勢を大幅に改善できます。
オブザーバビリティは、ワークロードコンポーネントからメトリクスを収集し、それらを表示してアラートを発するだけではありません。これは、ワークロードの動作を全体的に理解することです。この動作情報は、ワークロード内のすべてのコンポーネントから取得されます。これには、ワークロードが依存するクラウドサービス、適切に作成されたログ、メトリクスが含まれます。このデータにより、ワークロードの全体的な動作を監督し、すべてのコンポーネントとすべての作業単位のやり取りを詳細に把握できます。
**期待される成果:**
+ ワークロードコンポーネントと AWS サービスの依存関係からログを収集し、簡単にアクセスして処理できる一元的な場所に公開します。
+ ログには、忠実度が高く正確なタイムスタンプが含まれています。
+ ログには、トレース識別子、ユーザーまたはアカウント識別子、リモート IP アドレスなど、処理コンテキストに関する関連情報が含まれています。
+ おおまかな視点からワークロードの動作を表す集計メトリクスをログから作成します。
+ 集約ログをクエリして、ワークロードに関する深く関連するインサイトを取得し、実際の問題と潜在的な問題を特定できます。
**一般的なアンチパターン:**
+ ワークロードが実行されるコンピューティングインスタンスや、ワークロードが使用するクラウドサービスから、関連するログやメトリクスを収集することはない。
+ ビジネスキーパフォーマンスインジケーター (KPI) に関連するログとメトリクスのコレクションは無視する。
+ ワークロード関連のテレメトリを集約や相関関係なしに個別に分析する。
+ メトリクスとログの有効期限が早すぎ、トレンド分析や問題の定期的な識別が妨げられる。
**これらのベストプラクティスを活用するメリット:** より多くの異常を検出し、ワークロードのさまざまなコンポーネント間でイベントとメトリクスを関連付けることができます。メトリクスだけでは利用できないことが多いログに含まれる情報に基づいて、ワークロードコンポーネントからインサイトを作成できます。大規模にログをクエリすることにより、障害の原因をより迅速に特定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードとそのコンポーネントに関連するテレメトリデータのソースを特定します。このデータは、オペレーティングシステム (OS) や Java などのアプリケーションランタイムなどのメトリクスを発行するコンポーネントだけでなく、アプリケーションやクラウドサービスのログからも取得されます。例えば、ウェブサーバーは通常、タイムスタンプ、処理レイテンシー、ユーザー ID、リモート IP アドレス、パス、クエリ文字列などの詳細情報を使用して各リクエストを記録します。これらのログの詳細レベルは、詳細なクエリを実行し、他の方法では利用できないメトリクスを生成するのに役立ちます。
適切なツールとプロセスを使用してメトリクスとログを収集します。Amazon EC2 インスタンスで実行されているアプリケーションによって生成されたログは、[Amazon CloudWatch Agent](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) などのエージェントによって収集され、[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) などの中央ストレージサービスに発行されます。[AWS Lambda](https://aws.amazon.com/lambda/) や [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) などの AWS マネージドコンピューティングサービスは、自動的に CloudWatch Logs にログを発行します。[Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[Amazon S3](https://aws.amazon.com/s3/)、[Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/)、[Amazon API Gateway](https://aws.amazon.com/api-gateway/) などのワークロードで使用される AWS ストレージおよび処理サービスのログ収集を有効にします。
動作パターンをより明確に把握し、相関する問題を関連するコンポーネントのグループに分離するのに役立つ*[ディメンション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)*でテレメトリデータを強化します。追加すると、コンポーネントの動作をより詳細なレベルで観察し、相関する障害を検出し、適切な修復手順を実行できるようになります。便利なディメンションの例としては、アベイラビリティーゾーン、EC2 インスタンス ID、コンテナタスクまたはポッド ID などがあります。
メトリクスとログを収集したら、クエリを記述し、それらから集計メトリクスを生成して、正常な動作と異常な動作の両方に関する有用なインサイトを提供できます。例えば、[Amazon CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) を使用してアプリケーションログからカスタムメトリクスを導き出し、[Amazon CloudWatch Metrics Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) を使用してメトリクスを大規模にクエリし、[Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) を使用してコンテナ化されたアプリケーションとマイクロサービスからメトリクスとログを収集、集約、要約でき、AWS Lambda 関数を使用している場合は [Amazon CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) を使用できます。集約エラーレートメトリクスを作成するには、コンポーネントログにエラーレスポンスやメッセージが見つかるたびにカウンターを増分したり、既存のエラーレートメトリクスの集約値を計算したりできます。このデータを使用して、パフォーマンスが最も低いリクエストやプロセスなどの*テール動作*を示すヒストグラムを生成できます。また、CloudWatch Logs の[異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)などのソリューションを使用して、このデータをリアルタイムでスキャンして異常パターンを検出することもできます。これらのインサイトはダッシュボードに配置して、ニーズや好みに応じて整理できます。
ログのクエリは、ワークロードコンポーネントによって特定のリクエストがどのように処理されたかを理解し、ワークロードの回復力に影響を与えるリクエストパターンやその他のコンテキストを明らかにするのに役立ちます。アプリケーションやその他のコンポーネントの動作に関する知識に基づいて、事前にクエリを調査して準備しておくと、必要に応じてクエリをより簡単に実行できるため便利です。例えば、[CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) を使用すると、CloudWatch Logs に保存されているログデータをインタラクティブに検索、分析できます。[Amazon Athena](https://aws.amazon.com/athena/) を使用すると、ペタバイト規模で、[多くの AWS のサービス](https://docs.aws.amazon.com/athena/latest/ug/querying-aws-service-logs.html)を含む複数のソースからのログをクエリすることもできます。
ログ保持ポリシーを定義するときは、履歴ログの価値を考慮してください。履歴ログは、ワークロードのパフォーマンスにおける長期的な使用状況と動作のパターン、リグレッション、改善を特定するのに役立ちます。完全に削除されたログは後で分析することはできません。ただし、履歴ログの価値は長期間にわたって低下する傾向があります。必要に応じてニーズのバランスを取り、適用される可能性のある法的または契約上の要件に準拠するポリシーを選択してください。
### 実装手順
1. オブザーバビリティデータの収集、ストレージ、分析、表示メカニズムを選択します。
1. ワークロードの適切なコンポーネント (Amazon EC2 インスタンスや[サイドカーコンテナ](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/)など) にメトリクスコレクターとログコレクターをインストールして設定します。これらのコレクターが予期せず停止した場合に自動的に再起動するように設定します。一時的な発行の失敗がアプリケーションに影響を与えたり、データが失われたりしないように、コレクターのディスクまたはメモリバッファリングを有効にします。
1. ワークロードの一部として使用する AWS のサービスのログオンを有効にし、必要に応じて選択したストレージサービスにそれらのログを転送します。詳細な手順については、各サービスのユーザーガイドまたはデベロッパーガイドを参照してください。
1. テレメトリデータに基づくワークロードに関連する運用メトリクスを定義します。これらは、ビジネス KPI 関連のメトリクスを含むワークロードコンポーネントから出力される直接メトリクスや、合計、レート、パーセンタイル、ヒストグラムなどの集計計算の結果に基づく場合があります。これらのメトリクスはログアナライザーを使用して計算し、必要に応じてダッシュボードに配置します。
1. 必要に応じて、ワークロードコンポーネント、リクエスト、またはトランザクションの動作を分析するための適切なログクエリを準備します。
1. コンポーネントログのログ保持ポリシーを定義して有効にします。ポリシーで許可されているよりも古いログは定期的に削除します。
## リソース
**関連するベストプラクティス:**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 通知を送信する (リアルタイム処理とアラーム)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_automate_response_monitor.html)
+ [REL06-BP05 ログの分析](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_storage_analytics.html)
+ [REL06-BP06 モニタリングの範囲とメトリクスを定期的に確認する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_review_monitoring.html)
+ [REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
**関連ドキュメント:**
+ [Amazon CloudWatch の仕組み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon Managed Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/what-is-Amazon-Managed-Service-Prometheus.html)
+ [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/what-is-Amazon-Managed-Service-Grafana.html)。
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Amazon CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html)
+ [Amazon CloudWatch Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html)
+ [CloudWatch Metrics Insights を使用して CloudWatch メトリクスをクエリする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
+ [AWS オープンテレメトリー用ディストロ](https://aws.amazon.com/otel/)
+ [Amazon CloudWatch Logs Insights のサンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Amazon CloudWatch Synthetics と AWS X-Ray でのデバッグ](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [ログデータの検索およびフィルタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon S3 に直接ログを送信する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Sending-Logs-Directly-To-S3.html)
+ [Amazon Builders' Library: 運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
**関連するワークショップ:**
+ [つのオブザーバビリティワークショップ](https://observability.workshop.aws/)
**関連ツール:**
+ [AWS Distro for OpenTelemetry (GitHub)](https://aws-otel.github.io/)
# REL06-BP03 通知を送信する (リアルタイム処理とアラーム)
組織は、潜在的な問題を検出すると、その問題に迅速かつ効果的に対応するために、適切な担当者とシステムにリアルタイムの通知とアラートを送信します。
**期待される成果:** サービスとアプリケーションのメトリクスに基づいて関連するアラームを設定することで、運用にかかわるイベントに迅速に対応できます。アラームのしきい値を超えると、適切な担当者とシステムに通知され、根本的な問題に対処できます。
**一般的なアンチパターン:**
+ アラームのしきい値を過度に高く設定し、重要な通知が送信されなくなる。
+ アラームのしきい値を低くしすぎたことにより、過剰な通知のノイズが原因で重要なアラートへの対処が行われなくなる。
+ 使用率が変わってもアラームとそのしきい値を更新しない。
+ 自動アクションで対処するのが最適なアラームに対して、自動アクションを生成する代わりに担当者に通知を送信することで、余計な通知が送信されてしまう。
**このベストプラクティスを活用するメリット:** 適切な担当者とシステムにリアルタイムの通知とアラートを送信することで、問題を早期に検出し、運用にかかわるインシデントに迅速に対応できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
アプリケーションの可用性に影響を与え、自動対応のトリガーとなる可能性のある問題を検出しやすくするために、ワークロードにはリアルタイム処理とアラーム機能が備わっている必要があります。組織は、重要なイベントが発生したり、メトリクスがしきい値を超えたりしたときに通知を受け取ることができるよう、定義されたメトリクスを使用してアラートを作成することで、リアルタイムの処理とアラームの発行を実施できます。
[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) では、静的しきい値、異常検出、およびその他の基準に基づく CloudWatch アラームを使用して、[メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)アラームと複合アラームを作成できます。CloudWatch を使用して設定できるアラームの種類の詳細については、[CloudWatch ドキュメントのアラームに関するセクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)を参照してください。
[CloudWatch ダッシュボード](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)を使用して、チーム向けに AWS リソースのメトリクスとアラートをカスタマイズ表示できます。CloudWatch コンソールのカスタマイズ可能なホームページでは、複数のリージョンのリソースを 1 つのビューでモニタリングできます。
アラームは、[Amazon SNS トピック](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)への通知の送信、[Amazon EC2](https://aws.amazon.com/ec2/) アクションまたは [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) アクションの実行、[OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) または AWS Systems Manager の[インシデント](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)の作成など、1 つまたは複数のアクションを実行できます。
Amazon CloudWatch は [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) を使用して、アラームの状態が変化したときに通知を送信し、パブリッシャー (プロデューサー) からサブスクライバー (コンシューマー) にメッセージを配信します。Amazon SNS 通知の設定の詳細については、「[Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html)」を参照してください。
CloudWatch アラームが作成、更新、削除されたり、状態が変更されたりするたびに、CloudWatch は [EventBridge](https://aws.amazon.com/eventbridge/) に[イベント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html)を送信します。こうしたイベントで EventBridge を使用して、アラームの状態が変わるたびに通知したり、[Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) を使用してアカウント内のイベントを自動的にトリガーしたりするなどのアクションを実行するルールを作成できます。
[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) で最新情報を入手してください。AWS Health は、AWS クラウド リソースの正常性に関する信頼できるソースです。AWS Health を使用して、確認されたサービスイベントの通知を受け取ることで、影響を軽減するための手順をすばやく実行できます。[AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) を通じて E メールやチャットチャネルに、目的に合った AWS Health イベント通知を作成し、[Amazon EventBridge を通じてモニタリングツールやアラートツールをプログラムで統合します](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)。AWS Organizations を使用する場合、アカウント間で AWS Health イベントを集約します。
**EventBridge を使うべき場合と Amazon SNS を使うべき場合**
EventBridge と Amazon SNS はどちらもイベント駆動型アプリケーションの開発に使用できます。どちらを選ぶかは、具体的なニーズによって異なります。
Amazon EventBridge は、独自のアプリケーション、SaaS アプリケーション、AWS サービスからのイベントに反応するアプリケーションを構築する場合に推奨されます。EventBridge は、サードパーティーの SaaS パートナーと直接統合する唯一のイベントベースのサービスです。EventBridge は、デベロッパーがアカウントにリソースを作成することなく、200 を超える AWS サービスからイベントを自動的に取り込みます。
EventBridge では、定義済みの JSON ベースの構造がイベントに使用されており、[ターゲット](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)に転送するイベントを選択する際にイベント本文全体に適用されるルールを作成できます。EventBridge は現在、[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)、[Amazon SQS](https://aws.amazon.com/sqs/)、Amazon SNS、Amazon [Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)、[Amazon Data Firehose](https://aws.amazon.com/kinesis/data-firehose/) など、20 を超える AWS サービスをターゲットとしてサポートしています。
Amazon SNS は、高いファンアウトを必要とするアプリケーション (数千または数百万のエンドポイント) に推奨されます。よく見られるパターンは、お客様が Amazon SNS をルールのターゲットとして使用し、必要なイベントをフィルタリングして複数のエンドポイントに分散させるというものです。
メッセージは構造化されておらず、任意の形式にすることができます。Amazon SNS では Lambda、Amazon SQS、HTTP/S エンドポイント、SMS、モバイルプッシュ、メールの 6 種類のターゲットへのメッセージ転送をサポートしています。Amazon SNS の[通常のレイテンシーは 30 ミリ秒未満です](https://aws.amazon.com/sns/faqs/)。AWS のさまざまなサービス (Amazon EC2、[Amazon S3](https://aws.amazon.com/s3/)、[Amazon RDS](https://aws.amazon.com/rds/) など 30 以上のサービス) で、Amazon SNS メッセージを送信するようにサービスを設定できます。
### 実装手順
1. [Amazon CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)を使用してアラームを作成します。
1. メトリクスアラームは、単一の CloudWatch メトリクス、または CloudWatch メトリクスに依存する式をモニタリングします。アラームは、メトリクスまたは式の値としきい値との比較に基づいて、複数の時間間隔にわたって 1 つまたは複数のアクションを開始します。アクションでは、[Amazon SNS トピック](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)に通知を送信したり、[Amazon EC2](https://aws.amazon.com/ec2/) アクションまたは [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) アクションを実行したりできます。また、AWS Systems Manager で [OpsItem](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) または[インシデント](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)を作成できます。
1. 複合アラームは、作成した他のアラームのアラーム条件を考慮するルール式で構成されます。複合アラームは、すべてのルール条件が満たされた場合にのみアラーム状態になります。複合アラームのルール式で指定されるアラームには、メトリクスアラームや追加の複合アラームを含めることができます。複合アラームは、状態が変更されたときに Amazon SNS 通知を送信できます。また、ALARM 状態になったときに Systems Manager の [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) または[インシデント](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)を作成できますが、EC2 アクションまたは Auto Scaling アクションを実行することはできません。
1. [Amazon SNS 通知](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)を設定します。CloudWatch アラームを作成する際には、アラームの状態が変化したときに通知を送信する Amazon SNS トピックを含めることができます。
1. 指定された CloudWatch アラームに一致する[ルールを EventBridge に作成します](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html)。各ルールは、Lambda 関数を含む複数のターゲットをサポートします。例えば、使用可能なディスク容量が少なくなったときに起動するアラームを定義できます。このアラームにより、領域をクリーンアップする Lambda 関数が EventBridge ルールを介してトリガーされます。EventBridge ターゲットの詳細については、「[EventBridge targets](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html)」を参照してください。
## リソース
**関連する Well-Architected のベストプラクティス:**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 メトリクスを定義および計算する (集計)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL12-BP01 プレイブックを使用して障害を調査する](rel_testing_resiliency_playbook_resiliency.md)
**関連ドキュメント:**
+ [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.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 CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [ Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon SNS 通知の設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/US_SetupSNS.html)
+ [CloudWatch 異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [CloudWatch Logs data protection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/protect-sensitive-log-data-types.html)
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon Simple Notification Service](https://aws.amazon.com/sns/)
**関連動画:**
+ [reinvent 2022 observability videos](https://www.youtube.com/results?search_query=reinvent+2022+observability)
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
**関連する例:**
+ [つのオブザーバビリティワークショップ](https://observability.workshop.aws/)
+ [Amazon EventBridge to AWS Lambda with feedback control by Amazon CloudWatch Alarms](https://serverlessland.com/patterns/cdk-closed-loop-serverless-control-pattern)
# REL06-BP04 レスポンスを自動化する (リアルタイム処理とアラーム)
自動化を使用して、イベントが検出されたときにアクションを実行します (例えば、障害が発生したコンポーネントを交換します)。
アラームの自動リアルタイム処理が実装されているため、アラームがトリガーされたときにシステムが迅速に是正措置を講じ、障害やサービスの低下を防ぐことができます。アラームへの自動対応には、障害が起きたコンポーネントの交換、コンピューティングキャパシティの調整、正常なホスト、アベイラビリティーゾーン、その他のリージョンへのトラフィックのリダイレクト、オペレーターへの通知などがあります。
**期待される成果:** リアルタイムのアラームが特定され、アラームの自動処理が設定され、サービスレベル目標とサービスレベルアグリーメント (SLA) を達成するための適切なアクションが呼び出されます。自動処理は、単一コンポーネントの自己修復アクティビティからサイト全体のフェイルオーバーまで多岐にわたります。
**一般的なアンチパターン:**
+ 主要なリアルタイムアラームの明確なインベントリまたはカタログがない。
+ 重大なアラームへの自動対応 (例えば、コンピューティングが枯渇しそうになると、オートスケーリングが行われる) が欠如している。
+ アラームへの対応が矛盾している。
+ オペレーターがアラート通知を受け取ったときに従うべき標準作業手順書 (SOP) がない。
+ 構成変更がモニタリングされていない。構成変更が検出されないと、ワークロードのダウンタイムが生じる可能性があります。
+ 意図しない構成変更を取り消す戦略がない。
**このベストプラクティスを活用するメリット:** アラーム処理を自動化することで、システムの回復力を向上させることができます。システムが自動的に是正措置を講じるため、人が介入することでミスが生じやすい手作業を減らすことができます。ワークロードの可用性の目標を達成し、サービスの中断を低減します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
アラートを効果的に管理し、対応を自動化するには、重要度と影響に基づいてアラートを分類し、対応手順を文書化し、対応計画を立ててからタスクをランク付けします。
特定のアクション (たいていはランブックに詳細が記載されている) が必要なタスクを特定し、ランブックとプレイブックをすべて調べて、どのタスクを自動化できるか判断します。アクションを定義できる場合、たいていは自動化できます。アクションを自動化できない場合は、手作業による手順を SOP に記録し、オペレーターにその手順の訓練をします。手作業のプロセスは継続的に見直し、アラートへの対応を自動化する計画を立て、実践できる余地がないか検討してください。
### 実装手順
1. **アラームのインベントリを作成する:** すべてのアラームのリストを取得するには、[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) コマンド `[describe-alarms](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html)` を使用して [AWS CLI](https://aws.amazon.com/cli/) を使用できます。設定したアラームの数によっては、ページ分割を使用して各呼び出しのアラームのサブセットを取得するか、または AWS SDK を使用して [API コール](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-describing-alarms.html)を使用してアラームを取得できます。
1. **すべてのアラームアクションを文書化する:** 手動か自動かにかかわらず、すべてのアラームとそのアクションでランブックを更新します。[AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/APIReference/Welcome.html) には、定義済みのランブックが用意されています。詳細については、「[ランブックの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)」を参照してください。ランブックコンテンツを表示する方法の詳細については、「[View runbook content](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html#view-automation-json)」を参照してください。
1. **アラームアクションを設定して管理する:** アクションが必要なアラームについては、[CloudWatch SDK を使用して自動アクションを指定](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/cw-example-using-alarm-actions.html)します。例えば、アラームに応じてアクションを作成して有効にする、またはアラームに応じてアクションを無効にする形で、CloudWatch アラームに基づいて Amazon EC2 インスタンスの状態を自動的に変更できます。
[Amazon EventBridge](https://aws.amazon.com/eventbridge/) を使用すると、アプリケーションの可用性の問題やリソースの変更などのシステムイベントに自動的に対応できます。ルールを作成して、注目しているイベントと、イベントがルールに一致した場合に実行するアクションを指定できます。自動的に開始できるアクションには、[AWS Lambda](https://aws.amazon.com/lambda/) 関数の呼び出し、[Amazon EC2](https://aws.amazon.com/ec2/) `Run Command` の呼び出し、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) へのイベントのリレー、「[EventBridge を使用して Amazon EC2 を自動化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html)」の表示が含まれます。
1. **標準作業手順書 (SOP):** アプリケーションコンポーネントに基づいて、[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) は複数の [SOP テンプレート](https://docs.aws.amazon.com/resilience-hub/latest/userguide/sops.html)を推奨します。これらの SOP を使用して、アラートが発生した場合にオペレーターが従うべきプロセスをすべて文書化できます。また、Resilience Hub のレコメンデーションに基づいて [SOP を作成](https://docs.aws.amazon.com/resilience-hub/latest/userguide/building-sops.html)することもできます。その場合は、回復ポリシーを関連付けた Resilience Hub のアプリケーションと、そのアプリケーションに対する回復力評価の履歴が必要です。SOP のレコメンデーションは、回復力の評価を受けて作成されます。
Resilience Hub は Systems Manager と連携して、SOP の基礎として使用できる多数の [SSM ドキュメント](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-custom-ssm-doc.html)を提供することで、SOP の手順を自動化します。例えば、Resilience Hub は既存の SSM 自動化ドキュメントに基づいてディスク容量を追加するための SOP を推奨する場合があります。
1. **Amazon DevOps Guru を使用して自動化アクションを実行する:** [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) を使用して、異常な動作についてアプリケーションリソースを自動的にモニタリングし、的を絞ったレコメンデーションを提供することにより、問題の識別を速めて修復時間を短縮できます。DevOps Guru を使用すると、Amazon CloudWatch メトリクス、[AWS Config](https://aws.amazon.com/config/)、[AWS CloudFormation](https://aws.amazon.com/cloudformation/)、[AWS X-Ray](https://aws.amazon.com/xray/) など、複数のソースからの運用データのストリームをほぼリアルタイムでモニタリングできます。また、DevOps Guru を使用して OpsCenter で [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-create-OpsItems-from-CloudWatch-Alarms.html) を自動的に作成し、イベントを [EventBridge に送信して追加の自動化を行う](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-eventbridge.html)こともできます。
## リソース
**関連するベストプラクティス:**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL06-BP02 メトリクスを定義および計算する (集計)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP03 通知を送信する (リアルタイム処理とアラーム)](rel_monitor_aws_resources_notification_monitor.md)
+ [REL08-BP01 デプロイなどの標準的なアクティビティにランブックを使用する](rel_tracking_change_management_planned_changemgmt.md)
**関連ドキュメント:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS リソースのイベントでトリガーされる EventBridge ルールの作成](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-rule.html)
+ [1 つのオブザーバビリティワークショップ](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon DevOps Guru とは](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
+ [オートメーションドキュメント (プレイブック) の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
**関連動画:**
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://www.youtube.com/watch?v=zZPzXEBW4P8)
+ [AWS re:Invent 2020: Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [Introduction to AWS Resilience Hub](https://www.youtube.com/watch?v=_OTTCOjWqPo)
+ [Create Custom Ticket Systems for Amazon DevOps Guru Notifications](https://www.youtube.com/watch?v=Mu8IqWVGUfg)
+ [Enable Multi-Account Insight Aggregation with Amazon DevOps Guru](https://www.youtube.com/watch?v=MHezNcTSTbI)
**関連する例:**
+ [Amazon CloudWatch and Systems Manager Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/a8e9c6a6-0ba9-48a7-a90d-378a440ab8ba/en-US)
# REL06-BP05 ログの分析
ログファイルとメトリクスの履歴を収集し、これらを分析して、幅広いトレンドとワークロードの洞察が得られます。
Amazon CloudWatch Logs Insights は、[シンプルかつ強力なクエリ言語](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)をサポートし、ログデータの分析に使用できます。Amazon CloudWatch Logs ではさらに、シームレスにデータを Amazon S3 に送ってデータを使用したり、または Amazon Athena に送ってデータをクエリしたりできるサブスクリプションもサポートしています。豊富な種類のフォーマットのクエリがサポートされています。詳細については、Amazon Athena ユーザーガイドで[サポートされる SerDes およびデータ形式](https://docs.aws.amazon.com/athena/latest/ug/supported-format.html)を参照してください。巨大なログファイルセットの分析では、Amazon EMR クラスターを実行してペタバイト規模の分析を実行できます。
集計、処理、保存、分析を実行できる多数のツールが AWS パートナーやサードパーティーによって提供されています。このようなツールには、New Relic、Splunk、Loggly、Logstash、CloudHealth、Nagios などがあります。ただし、システムやアプリケーションログの外で行うデータ生成は各クラウドプロバイダーに固有であり、また多くの場合サービスごとに固有です。
モニタリングプロセスで見落とされがちな点は、データ管理です。モニタリングのためのデータ保存要件を決定し、それに応じたライフサイクルポリシーを適用する必要があります。Amazon S3 は、S3 バケットレベルのライフサイクル管理をサポートしています。このライフサイクル管理には、バケット内のパスごとに異なる管理方法を適用できます。ライフサイクルの最終段階では、データを Amazon Glacier に移行して長期保存し、保存期間の終了後には期限切れにすることができます。S3 Intelligent-Tiering ストレージクラスは、パフォーマンスへの影響や運用のオーバーヘッドなしに、データを最も費用対効果の高いアクセス階層に自動的に移動することにより、コストを最適化できるように設計されています。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
+ CloudWatch Logs Insights を使用すると、Amazon CloudWatch Logs のログデータをインタラクティブに検索し分析することが可能になります。
+ [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Logs Insights のサンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ Amazon CloudWatch Logs を使用して、Amazon Athena でデータのクエリを実行できる Amazon S3 にログを送信します。
+ [Amazon Athena で Amazon S3 サーバーアクセスログを分析する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ サーバーアクセスログバケットの S3 ライフサイクルポリシーを作成します。ライフサイクルポリシーを設定して、定期的にログファイルを削除します。これにより、各クエリで Athena が分析するデータの量が減ります。
+ [S3 バケットのライフサイクルポリシーを作成する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
## リソース
**関連ドキュメント:**
+ [Amazon CloudWatch Logs Insights のサンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [CloudWatch Logs Insights を使用したログデータの分析](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html)
+ [Amazon CloudWatch Synthetics と AWS X-Ray でのデバッグ](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [S3 バケットのライフサイクルポリシーを作成する方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-lifecycle.html)
+ [Amazon Athena で Amazon S3 サーバーアクセスログを分析する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/analyze-logs-athena/)
+ [1 つのオブザーバビリティワークショップ](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
# REL06-BP06 モニタリングの範囲とメトリクスを定期的に確認する
ワークロードモニタリングの実装方法を頻繁に確認し、ワークロードとそのアーキテクチャの進化に合わせて更新します。モニタリングの定期的な監査は、障害インジケータの見逃しや見落としのリスクを低減し、ワークロードが可用性の目標を達成するのに役立ちます。
効果的なモニタリングは主要なビジネスメトリクスに根ざしており、ビジネスの優先順位が変化するにつれて進化します。監視レビュープロセスでは、サービスレベルインジケーター (SLI) を重視し、インフラストラクチャ、アプリケーション、クライアント、ユーザーからのインサイトを取り入れる必要があります。
**期待される成果:** 効果的なモニタリング戦略があり、重要なイベントや変更の後だけでなく、定期的にレビューおよび更新されます。ワークロードとビジネス要件が進化しても、主要なアプリケーションヘルスインジケータが依然として適切であることを確認します。
**一般的なアンチパターン:**
+ デフォルトのメトリクスのみを収集している。
+ モニタリング戦略は設定するが、確認することはない。
+ 主要な変更がデプロイされる際に、モニタリングについて話し合わない。
+ 古いメトリクスを信頼して、ワークロードの状態を判断している。
+ 運用チームは、古いメトリクスとしきい値が原因で誤検出アラートの対処に追われている。
+ モニタリングされていないアプリケーションコンポーネントのオブザーバビリティが不足している。
+ モニタリングでは低レベルの技術メトリクスのみに焦点を当て、ビジネスメトリクスを除外している。
**このベストプラクティスを活用するメリット:** モニタリングを定期的に確認すると、潜在的な問題を予測し、それらを検出できることを確認できます。また、以前のレビューで見逃した可能性のある死角を発見できるため、問題を検出する能力がさらに向上します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
[運用準備状況レビュー (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) プロセス中にモニタリングメトリクスと範囲を確認します。一貫したスケジュールで定期的な運用準備状況レビューを実行して、現在のワークロードと設定したモニタリングの間にギャップがあるかどうかを評価します。運用パフォーマンスのレビューと知識の共有を定期的に行うことで、運用チームのパフォーマンスを向上させることができます。既存のアラートのしきい値がまだ適切かどうかを検証し、運用チームが誤検出アラートを受信している状況や、モニタリングすべきアプリケーションのモニタリングされていない状況を確認します。
[耐障害性分析フレームワーク](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)は、プロセスの進行に役立つガイダンスを提供します。フレームワークの焦点は、潜在的な障害モードと、その影響を軽減するために使用できる予防および修正コントロールを特定することです。この知識は、モニタリングとアラートを行う適切なメトリクスとイベントを特定するのに役立ちます。
### 実装手順
1. ワークロードダッシュボードの定期的なレビューをスケジュールし、実施します。検査する深度に応じて異なる頻度にすることができます。
1. メトリクスの傾向を検査します。メトリクス値と履歴値を比較して、調査が必要なものを示唆している可能性がある傾向があるかどうかを確認します。これには、レイテンシーの増加、主要なビジネス機能の減少、失敗レスポンスの増加などがあります。
1. メトリクスの外れ値や異常を検査します。これは平均または中央値でマスキングできます。時間枠内の最高値と最低値を調べ、通常の境界をはるかに超えている観測結果の原因を調査します。これらの原因を引き続き削除すると、ワークロードパフォーマンスの一貫性の向上に応じて、期待されるメトリクスの境界を絞ることができます。
1. 行動の急変を探します。メトリクスの数量または方向性の突然の変化は、アプリケーションに変更があったこと、または追跡するためにさらなるメトリクスを追加する必要がある外部要因があることを示唆している可能性があります。
1. 現在のモニタリング戦略に、引き続きアプリケーションとの関連性があるかどうかを確認します。以前のインシデントの分析 (または耐障害性分析フレームワーク) に基づいて、モニタリングスコープに組み込む必要があるアプリケーションの追加の側面があるかどうかを評価します。
1. リアルユーザーモニタリング (RUM) メトリクスを確認して、アプリケーション機能のカバレッジにギャップがないかどうかを確認します。
1. 変更管理プロセスをレビューします。必要に応じて手順を更新し、変更を承認する前に実行する必要があるモニタリング分析ステップを含めます。
1. 運用準備状況の確認とエラープロセスの修正の一環として、モニタリングレビューを実装します。
## リソース
**関連するベストプラクティス**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP02 メトリクスを定義および計算する (集計)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_aggregation.html)
+ [REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_end_to_end.html)
+ [REL12-BP02 インシデント後の分析を実行する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_rca_resiliency.html)
+ [REL12-BP06 定期的にゲームデーを実施する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_game_days_resiliency.html)
**関連ドキュメント:**
+ [correction of error (COE) を開発すべき理由](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [運用を可視化するためのダッシュボードの構築](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/?did=ba_card&trk=ba_card)
+ [マルチ AZ の高度なレジリエンスパターン - グレー障害](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/gray-failures.html)
+ [Amazon CloudWatch Logs Insights のサンプルクエリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [Amazon CloudWatch Synthetics と AWS X-Ray でのデバッグ](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [つのオブザーバビリティワークショップ](https://observability.workshop.aws/)
+ [Amazon Builders' Library: 運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Amazon CloudWatch ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ [耐障害性分析フレームワーク](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/introduction.html)
+ [耐障害性分析フレームワーク - オブザーバビリティ](https://docs.aws.amazon.com/prescriptive-guidance/latest/resilience-analysis-framework/observability.html)
+ [運用準備状況レビュー - ORR](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
# REL06-BP07 システムを通じたリクエストのエンドツーエンドのトレースをモニタリングする
サービスコンポーネントで処理されるリクエストをトレースすることで、製品チームではより簡単に問題の分析とデバッグを行い、パフォーマンスを向上させることができます。
**期待される成果:** すべてのコンポーネントを網羅的にトレースできるワークロードは、デバッグが容易で、根本原因の発見を簡略化することで、エラーやレイテンシーの[解決までの平均時間](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html) (MTTR) を改善します。エンドツーエンドのトレースによって影響を受けるコンポーネントを検出し、エラーやレイテンシーの根本原因の詳細調査にかかる時間を短縮できます。
**一般的なアンチパターン:**
+ トレースは一部のコンポーネントに使用されますが、すべてのコンポーネントで使用されるわけではありません。例えば、AWS Lambda のトレースを行わない場合は、ワークロードの急増でのコールドスタートが原因で生じたレイテンシーを明確に把握できない可能性があります。
+ Synthetic Canaries やリアルユーザーモニタリング (RUM) には、トレースは設定されていません。Canary や RUM を使用しない場合、クライアントインタラクションのテレメトリがトレース分析から除外され、パフォーマンスプロファイルが不完全な状態になります。
+ ハイブリッドワークロードには、クラウドネイティブとサードパーティーのトレースツールの両方が含まれていますが、単一のトレースソリューションを選択し、完全に統合する手段は講じられていません。選択したトレースソリューションに基づいて、クラウドネイティブのトレース SDK を使用して、クラウドネイティブではないコンポーネントを測定するか、サードパーティーツールを使用してクラウドネイティブのトレーステレメトリを取り込むように設定する必要があります。
**このベストプラクティスを活用するメリット:** 開発チームでは、問題についてアラートを受けることで、ロギング、パフォーマンス、障害に対するコンポーネントごとの相関関係など、システムコンポーネントの相互作用の全体像を把握できます。トレースによって根本原因を視覚的に把握しやすくなるため、根本原因の究明に費やす時間を短縮できます。チームではコンポーネントの相互作用を詳細に理解することで、問題を解決する際に、より適切で迅速な意思決定を行うことができます。システムトレースの分析によって、ディザスタリカバリ (DR) フェイルオーバーの開始時期、自己修復戦略を実行する場所などの意思決定を改善することで、最終的にサービスに対する顧客満足度の向上につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
分散アプリケーションを運用するチームでは、トレースツールを使用して相関識別子を設定し、リクエストのトレースを収集して、接続されたコンポーネントのサービスマップを作成できます。サービスクライアント、ミドルウェアゲートウェイ、イベントバス、コンピューティングコンポーネント、キーバリューストアやデータベースを含むストレージなど、すべてのアプリケーションコンポーネントをリクエストトレースに含める必要があります。エンドツーエンドのトレース設定に Synthetic Canaries とリアルユーザーモニタリングを組み込んで、リモートクライアントとのやり取りやレイテンシーを測定することで、サービスレベル契約や目標に対するシステムのパフォーマンスを正確に評価できます。
[AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) および [Amazon CloudWatch アプリケーションモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)の測定サービスを使用して、アプリケーションを通過するリクエストの全体像を把握できます。X-Ray は、アプリケーションのテレメトリを収集し、ペイロード、関数、トレース、サービス、API 全般の可視化およびフィルター処理が可能で、ノーコードまたはローコードのシステムコンポーネントに対して有効にできます。CloudWatch アプリケーションのモニタリングには ServiceLens が含まれており、トレースをメトリクス、ログ、アラームと統合します。CloudWatch アプリケーションモニタリングには、エンドポイントと API をモニタリングするための Synthetics や、ウェブアプリケーションクライアントを測定するためのリアルユーザーモニタリングも含まれています。
## 実装手順
+ [Amazon S3、AWS Lambda、Amazon API Gateway](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html) など、サポートされているすべてのネイティブサービスで AWS X-Ray を使用します。これらの AWS サービスでは、インフラストラクチャをコードとして、AWS SDK、または AWS マネジメントコンソールを使用して設定を切り替え、X-Ray を有効にできます。
+ 測定アプリケーション [AWS Distro for Open Telemetry および X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html) またはサードパーティーの収集エージェント。
+ プログラミング言語固有の実装については、[AWS X-Ray 開発者ガイド](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)を参照してください。これらのドキュメントでは、HTTP リクエスト、SQL クエリ、アプリケーションのプログラミング言語固有のその他のプロセスを測定する方法について詳しく説明します。
+ [Amazon CloudWatch Synthetic の Canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) および [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) の X-Ray トレースを使用して、エンドユーザークライアントからダウンストリームの AWS インフラストラクチャを経由するリクエストパスを分析します。
+ リソースの健全性と Canary テレメトリに基づき CloudWatch メトリクスとアラームを設定することで、チームでは迅速に問題についてアラートを発し、ServiceLens でトレースやサービスマップを詳しく調査できます。
+ プライマリトレースソリューションにサードパーティー製ツールを使用している場合は、[Datadog](https://docs.datadoghq.com/tracing/guide/serverless_enable_aws_xray/)、[New Relic](https://docs.newrelic.com/docs/infrastructure/amazon-integrations/aws-integrations-list/aws-x-ray-monitoring-integration/)、[Dynatrace](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-cloud-platforms/amazon-web-services/amazon-web-services-integrations/aws-service-metrics) などのサードパーティートレースツールの X-Ray 統合を有効にします。
## リソース
**関連するベストプラクティス:**
+ [REL06-BP01 ワークロードのすべてのコンポーネントをモニタリングする (生成)](rel_monitor_aws_resources_monitor_resources.md)
+ [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](rel_withstand_component_failures_monitoring_health.md)
**関連ドキュメント:**
+ [ とはAWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [Amazon CloudWatch : アプリケーションモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)
+ [Amazon CloudWatch Synthetics と AWS X-Ray でのデバッグ](https://aws.amazon.com/blogs/devops/debugging-with-amazon-cloudwatch-synthetics-and-aws-x-ray/)
+ [Amazon Builders' Library: 運用の可視性を高めるために分散システムを装備する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [Integrating AWS X-Ray with other AWS services](https://docs.aws.amazon.com/xray/latest/devguide/xray-services.html)
+ [AWS Distro for OpenTelemetry と AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-adot.html)
+ [Amazon CloudWatch : 合成モニタリングを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon CloudWatch: CloudWatch RUM を使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [Set up Amazon CloudWatch synthetics canary and Amazon CloudWatch alarm](https://docs.aws.amazon.com/solutions/latest/devops-monitoring-dashboard-on-aws/set-up-amazon-cloudwatch-synthetics-canary-and-amazon-cloudwatch-alarm.html)
+ [可用性およびその他: AWS の分散システムの回復力の理解と向上](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US)
**関連動画:**
+ [AWS re:Invent 2022 - How to monitor applications across multiple accounts](https://www.youtube.com/watch?v=kFGOkywu-rw)
+ [How to Monitor your AWS Applications](https://www.youtube.com/watch?v=UxWU9mrSbmA)
**関連ツール**:
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon CloudWatch](https://aws.amazon.com/pm/cloudwatch/)
+ [Amazon Route 53](https://aws.amazon.com/route53/)