# OPS 4. オブザーバビリティをワークロードに実装するにはどうすればよいでしょうか?
ワークロードにオブザーバビリティを実装することで、ワークロードの状態を把握し、ビジネス要件に基づいてデータ主導の意思決定を行うことができます。
**Topics**
+ [
# OPS04-BP01 主要業績評価指標を特定する
](ops_observability_identify_kpis.md)
+ [
# OPS04-BP02 アプリケーションテレメトリを実装する
](ops_observability_application_telemetry.md)
+ [
# OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する
](ops_observability_customer_telemetry.md)
+ [
# OPS04-BP04 依存関係のテレメトリを実装する
](ops_observability_dependency_telemetry.md)
+ [
# OPS04-BP05 分散トレースを実装する
](ops_observability_dist_trace.md)
# OPS04-BP01 主要業績評価指標を特定する
ワークロードにオブザーバビリティを実装するには、まずワークロードの状態を理解し、ビジネス要件に基づいてデータ主導の意思決定を行います。モニタリングアクティビティとビジネス目標を合致させる最も効果的な方法の 1 つは、主要業績評価指標 (KPI) を定義してモニタリングすることです。
**期待される成果:** ビジネス目標と緊密に連携した効率的なオブザーバビリティを実践することにより、モニタリングアクティビティが常に具体的なビジネス成果につながります。
**一般的なアンチパターン:**
+ 未定義の KPI: 明確な KPI がないまま作業を進めると、過度なモニタリングやモニタリング不足になり、重要なシグナルを見逃してしまう可能性がある。
+ 静的 KPI: ワークロードやビジネス目標が変化しても KPI を再検討したり調整したりしていない。
+ ビジネスの成果と直接の相互関係がない、または実際の問題との関連性が明らかでない技術的なメトリクスに重点が置かれている。
**このベストプラクティスを活用するメリット:**
+ 問題の特定が容易: 多くの場合、技術的なメトリクスと比較して、ビジネス KPI はより明確に問題を検出します。ビジネス KPI の低下は、多数の技術的メトリクスを細かく検証するよりも効果的に問題を特定できます。
+ ビジネスとの連携: モニタリングアクティビティがビジネス目標を直接サポートしていることが確認できます。
+ 効率性: モニタリングリソースに優先順位を付けて重要なメトリクスに注目できます。
+ 積極性: 問題がビジネスに及ぼす影響が拡大する前に、問題を認識して対処できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロード KPI を効果的に定義する方法:
1. **ビジネス成果を理解する:** メトリクスの詳細に取り掛かる前に、望ましいビジネス成果を理解しておきます。売上の増加、ユーザーエンゲージメントの向上、または応答時間の短縮などがあります。
1. **技術メトリクスをビジネス目標と関連付ける:** すべての技術メトリクスがビジネス成果に直接影響するわけではありません。直接影響するようなメトリクスを特定します。ただし、多くの場合、ビジネス KPI を使用して問題を特定する方が簡単です。
1. **[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) を使用する:** CloudWatch を使用して、KPI と関連するメトリクスを定義およびモニタリングします。
1. **KPI を定期的にレビュー、更新する:** ワークロードとビジネスが進化するにつれて、KPI も関連性があるものを維持します。
1. **関係者を参画する**: KPI の定義とレビューには、技術チームと業務チームの両方の関与が必要です。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
+ [OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリを実装する](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 分散トレースを実装する](ops_observability_dist_trace.md)
**関連ドキュメント:**
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ [CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Skill Builder - AWS Observability (Japanese) 日本語吹き替え版](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
**関連動画:**
+ [Developing an observability strategy](https://www.youtube.com/watch?v=Ub3ATriFapQ)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 アプリケーションテレメトリを実装する
アプリケーションテレメトリは、ワークロードオブザーバビリティの基盤です。アプリケーションの状態や、技術的およびビジネス上の成果の達成に関する実践的なインサイトを提供するテレメトリを送出することが重要です。トラブルシューティングから新機能の影響の測定、ビジネスの主要業績評価指標 (KPI) との整合性の確認まで、アプリケーションテレメトリを使用することで、ワークロードのビルド、運用、展開の仕方に関する情報を得ることができます。
メトリクス、ログ、トレースは、オブザーバビリティの 3 つの主要な柱となります。この 3 つの柱は、アプリケーションの状態を説明する診断ツールとして機能し、徐々にベースラインの作成や異常の特定に役立つようになります。ただし、モニタリングアクティビティとビジネス目標の整合性を確保するには、主要業績評価指標 (KPI) を定義してモニタリングすることが非常に重要です。多くの場合、ビジネス KPI を使用すると、技術的なメトリクスのみの場合よりも問題を特定しやすくなります。
リアルユーザーモニタリング (RUM) や合成トランザクションなどのその他の種類のテレメトリは、これらの主要なデータソースを補完します。RUM はリアルタイムのユーザーの操作に関するインサイトを提供します。合成トランザクションは潜在的なユーザー行動のシミュレーションを行い、実際のユーザーがボトルネックに直面する前にボトルネックを検出するのに役立ちます。
**期待される成果:** ワークロードのパフォーマンスに関する実践的なインサイトを導き出します。このようなインサイトを活用すると、パフォーマンスの最適化に関する積極的な意思決定、ワークロードの安定性の向上、CI/CD プロセスの合理化、リソースの効果的な活用につながります。
**一般的なアンチパターン:**
+ **不完全なオブザーバビリティ:** ワークロードのあらゆるレイヤーにオブザーバビリティを組み込むことを怠ると、死角が生じ、システムのパフォーマンスや動作に関する重要なインサイトが明らかにされない可能性があります。
+ **断片化されたデータビュー:** データが複数のツールやシステムに分散している場合、ワークロードの状態とパフォーマンスを包括的に把握することが困難になります。
+ **ユーザーから報告された問題:** これは、テレメトリとビジネス KPI のモニタリングによる積極的な問題検出ができていないという兆候です。
**このベストプラクティスを活用するメリット:**
+ **情報に基づいた意思決定:** テレメトリとビジネス KPI から得られるインサイトを活用して、データ主導の意思決定を行うことができます。
+ **運用効率の向上:** データ主導型のリソース利用は、高いコスト効率をもたらします。
+ **ワークロードの安定性の向上:** 問題をより迅速に検出して解決し、稼働時間を改善します。
+ **CI/CD プロセスの効率化:** テレメトリデータから得られるインサイトにより、プロセスの改善と信頼性の高いコードの配信が容易になります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードのアプリケーションテレメトリを実装するには、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) および [AWS X-Ray](https://aws.amazon.com/xray/) などの AWS サービスを使用します。Amazon CloudWatch が提供する包括的なモニタリングツールのスイートを使用して、AWS 内やオンプレミス環境のリソースやアプリケーションをモニタリングできます。メトリクスを収集、追跡、分析して、ログデータの統合とモニタリングを行い、リソースの変化に対応して、ワークロードがどのように運用されているかの詳細を明らかにします。これと連携して AWS X-Ray を使用すると、アプリケーションをトレース、分析、デバッグできるため、ワークロードの動作を詳しく把握できます。サービスマップ、レイテンシー分布、トレースタイムラインなどの機能を提供する AWS X-Ray を使用すると、ワークロードのパフォーマンスとパフォーマンスに影響を及ぼすボトルネックに関するインサイトが得られます。
### 実装手順
1. **収集するデータを特定する:** ワークロードの状態、パフォーマンス、動作に関する重要なインサイトを提供する主要なメトリクス、ログ、トレースを確認します。
1. **[CloudWatch エージェント](https://aws.amazon.com/cloudwatch/)をデプロイする:** CloudWatch エージェントを使用すると、ワークロードと基盤となるインフラストラクチャからシステムとアプリケーションのメトリクスとログを取得できます。CloudWatch エージェントを使用すると、OpenTelemetry や X-Ray トレースを収集して、X-Ray に送信することもできます。
1. **ログとメトリクスの異常検出を実装する:** [CloudWatch Logs の異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)と [CloudWatch メトリクスの異常検出](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)を使用して、アプリケーション動作における異常アクティビティを自動的に特定します。これらのツールは、機械学習アルゴリズムを使用して異常を検出して警告するのでモニタリング機能が強化され、潜在的な混乱やセキュリティ脅威への対応時間が短縮できます。これらの機能を設定すると、アプリケーションヘルスとセキュリティをプロアクティブに管理できます。
1. **機密ログデータを保護する:** [Amazon CloudWatch Logs のデータ保護](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)を使用して、ログ内の機密情報をマスクします。この機能は、アクセス前に機密データを自動的に検出してマスキングするのでプライバシーとコンプライアンスの維持に役立ちます。データマスキングを実装して、個人を特定できる情報 (PII) などの機密情報を安全に処理し保護します。
1. **ビジネス KPI を定義、モニタリングする:** [ビジネス成果](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/)に合わせた[カスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を確立します。
1. **AWS X-Ray を使用してアプリケーションを計測する:** CloudWatch エージェントをデプロイするだけでなく、トレースデータを生成するために[アプリケーションを計測](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)することが重要です。このプロセスにより、ワークロードの動作とパフォーマンスをさらに詳細に把握できます。
1. **アプリケーション全体でデータ収集を標準化する:** アプリケーション全体でデータ収集のプラクティスを標準化します。均一性を確立することで、データの関連付けと分析が容易になり、アプリケーションの動作を包括的に把握しやすくなります。
1. **クロスアカウントオブザーバビリティを実装する:** [Amazon CloudWatch クロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)を使用して、複数の AWS アカウントにわたってモニタリング効率を向上させます。この機能を使用すると、さまざまなアカウントのメトリクス、ログ、アラームを 1 つのビューに統合できます。これにより、組織の AWS 環境全体で特定された問題の管理が容易になり、対応時間を短縮できます。
1. **データを分析して対応する:** データ収集と正規化が完了したら、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) にメトリクスとログの分析、トレース分析に [AWS X-Ray](https://aws.amazon.com/xray/features/) を使用します。このような分析を行うことで、ワークロードの状態、パフォーマンス、動作に関する重要なインサイトを入手し、意思決定プロセスの指針とすることができます。
**実装計画に必要な工数レベル:** 高
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 ワークロード KPI の定義](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP04 依存関係のテレメトリを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dependency_telemetry.html)
+ [OPS04-BP05 トランザクショントレーサビリティを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
**関連ドキュメント:**
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ [CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS X-Ray デベロッパーガイド](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [運用の可視性を高めるために分散システムに計測を実装する](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS Skill Builder - AWS Observability (Japanese) 日本語吹き替え版](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [Amazon CloudWatch の最新情報](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [AWS X-Ray の最新情報](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)
**関連動画:**
+ [AWS re:Invent 2022 - Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Developing an observability strategy](https://youtu.be/Ub3ATriFapQ)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability)
+ [AWS ソリューションライブラリ: Amazon CloudWatch を使用したアプリケーションモニタリング](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)
# OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する
カスタマーエクスペリエンスやアプリケーション操作について詳細なインサイトを取得することは、非常に重要です。リアルユーザーモニタリング (RUM) と合成トランザクションは、この目的のための強力なツールとなります。RUM は、実際のユーザーの操作に関するデータを提供し、ユーザーの満足度を生で把握できます。一方、合成トランザクションはユーザーの操作のシミュレーションを行います。これにより、実際のユーザーに影響が及ぶ前に潜在的な問題を検出できます。
**期待される成果:** カスタマーエクスペリエンスの包括的な確認、積極的な問題の検出、ユーザー操作の最適化により、シームレスなデジタルエクスペリエンスを提供できます。
**一般的なアンチパターン:**
+ リアルユーザーモニタリング (RUM) をしないアプリケーション:
+ 問題検出の遅延: RUM を行わない場合、ユーザーからの苦情があるまでパフォーマンスのボトルネックや問題に気付かない可能性があります。このような事後対応型のアプローチは、お客様の不満につながる可能性があります。
+ ユーザーエクスペリエンスに関するインサイトの欠如: RUM を採用しない場合、実際のユーザーがアプリケーションをどのように操作したかを示す重要なデータが得られず、ユーザーエクスペリエンスの最適化の面で限界があります。
+ 合成トランザクションを行わないアプリケーション:
+ 細部を見逃すケース: 合成トランザクションは、一般的なユーザーには頻繁に使用されてない可能性があるにしろ、特定の業務部門にとっては重要であるパスや機能のテストに役立ちます。合成トランザクションを行わないと、このようなパスが誤動作しても検出されない場合があります。
+ アプリケーション非使用時の問題の確認: 定期的に合成テストを実行して、実際のユーザーがアプリケーションを積極的に操作していない時間のシミュレーションを行うことで、システムが常に適正に機能することを確認できます。
**このベストプラクティスを活用するメリット:**
+ 積極的な問題検出: 実際のユーザーに影響が及ぶ前に、潜在的な問題を特定して対処できます。
+ ユーザーエクスペリエンスの最適化: RUM からの継続的なフィードバックを利用すると、ユーザーエクスペリエンス全体の改善と向上につながります。
+ デバイスとブラウザのパフォーマンスに関するインサイト: アプリケーションがさまざまなデバイスやブラウザでどのように動作するかを把握して、さらなる最適化を実現します。
+ 検証済みのビジネスワークフロー: 定期的な合成トランザクションにより、コア機能とクリティカルパスの運用と効率性を確実に維持できます。
+ アプリケーションのパフォーマンスの強化: 実際のユーザーデータから収集したインサイトを活用して、アプリケーションの応答性と信頼性を向上できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS では RUM および合成トランザクションをユーザーアクティビティテレメトリに活用するため、[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) などのサービスを提供します。メトリクス、ログ、トレースをユーザーアクティビティデータと組み合わせることで、アプリケーションの動作のステータスとユーザーエクスペリエンスの両方を包括的に把握できます。
### 実装手順
1. **Amazon CloudWatch RUM をデプロイする**: アプリケーションを CloudWatch RUM と統合して、実際のユーザーデータを収集、分析、提示します。
1. [CloudWatch RUM JavaScript ライブラリ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)を使用して、RUM をアプリケーションと統合します。
1. ダッシュボードを設定して、実際のユーザーデータを可視化してモニタリングします。
1. **CloudWatch Synthetics を設定する**: ユーザーのアプリケーション操作をシミュレートする Canary、つまりスクリプト化したルーチンを作成します。
1. 重要なアプリケーションのワークフローとパスを定義します。
1. [CloudWatch Synthetics スクリプト](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)で Canary を設計し、重要なパスのユーザーインタラクションをシミュレートします。
1. Canary を指定した間隔で実行するようにスケジュールを設定してモニタリングを実行し、着実にパフォーマンスチェックを実行します。
1. **データの分析と対処を実施する:** RUM と合成トランザクションからのデータを活用してインサイトを取得し、異常が検出された場合は是正措置を講じます。CloudWatch ダッシュボードとアラームを使用して常に情報を入手します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリを実装する](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 分散トレースを実装する](ops_observability_dist_trace.md)
**関連ドキュメント:**
+ [CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [合成モニタリング (canary)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**関連動画:**
+ [Optimize applications through end user insights with Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS On Air ft. Real-User Monitoring for Amazon CloudWatch](https://www.youtube.com/watch?v=r6wFtozsiVE)
**関連する例:**
+ [1 つのオブザーバビリティワークショップ](https://catalog.workshops.aws/observability/en-US/intro)
+ [Git Repository for Amazon CloudWatch RUM Web Client](https://github.com/aws-observability/aws-rum-web)
+ [Using Amazon CloudWatch Synthetics to measure page load time](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
# OPS04-BP04 依存関係のテレメトリを実装する
依存関係のテレメトリは、ワークロードが依存する外部サービスやコンポーネントのヘルスとパフォーマンスをモニタリングするうえで不可欠です。依存関係のテレメトリにより、DNS、データベース、サードパーティー API などの依存関係に関連する到達可能性、タイムアウト、その他の重要なイベントに関する貴重なインサイトが得られます。このような依存関係に関するメトリクス、ログ、トレースを出力するようにアプリケーションをインストルメント化することで、ワークロードに影響を及ぼす可能性のある潜在的なボトルネック、パフォーマンスの問題、または障害をより明確に把握できます。
**期待される成果:** ワークロードを支える依存関係が期待どおりに機能し、積極的に問題に対処して、最適なワークロードパフォーマンスを確保できます。
**一般的なアンチパターン:**
+ **外部依存の見落し:** 内部アプリケーションメトリクスのみを重視し、外部の依存関係に関連するメトリクスはおろそかにしています。
+ **積極的なモニタリングの不履行:** 依存関係のヘルスとパフォーマンスを継続的にモニタリングするのではなく、問題が発生するまで待機しています。
+ **サイロ化したモニタリング:** 複数の異なるモニタリングツールを使用することにより、依存関係のヘルスについての断片的かつ一貫性のないビューの生成につながっている場合があります。
**このベストプラクティスを活用するメリット:**
+ **ワークロードの信頼性の向上:** 外部依存を常に利用可能にして最適なパフォーマンスを発揮できるようにすることで実現できます。
+ **問題の検出と解決の迅速化:** ワークロードに影響が及ぶ前に、依存関係のある問題を事前に特定して対処できます。
+ **包括的なビュー:** ワークロードのヘルスに影響を及ぼす内部コンポーネントと外部コンポーネントの両方を全体的に把握できます。
+ **ワークロードのスケーラビリティ強化:** 外部依存のスケーラビリティの限界とパフォーマンス特性を把握することにより実現できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードが依存しているサービス、インフラストラクチャ、プロセスを特定することから始めて、依存関係のテレメトリを実装します。これらの依存関係が期待どおりに機能している場合の良好な状態を定量化して、測定するためにどのようなデータが必要かを判断します。その情報を使用して、依存関係のヘルスに関するインサイトを運用チームに提供するダッシュボードとアラートを作成できます。AWS ツールを使用して、依存関係が必要となるとおり機能しない場合の影響を検出して定量化します。優先事項、目標、取得したインサイトの変化に応じて、戦略を継続的に見直します。
### 実装手順
依存関係のテレメトリを効果的に実装する方法:
1. **外部依存関係を特定する:** 関係者と協力して、ワークロードが依存している外部依存関係を特定します。外部依存関係には、外部データベース、サードパーティー API、その他の環境へのネットワーク接続ルート、DNS サービスなどのサービスが含まれます。効果的な依存関係のテレメトリを得る第一歩は、依存関係を包括的に把握することです。
1. **モニタリング戦略を策定する:** 外部依存を明確に把握した後、それに応じたモニタリング戦略を構築します。これには、各依存関係の重要度、予想される動作、関連するサービスレベルアグリーメントまたは目標 (SLA または SLT) を把握することなどがあります。ステータスの変化やパフォーマンスの逸脱を通知する積極的なアラートを設定します。
1. **[ネットワークモニタリング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Network-Monitoring-Sections.html)を使用する:** [Internet Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html) および [Network Monitor](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html) を使用して、グローバルなインターネットとネットワークの状態を包括的に把握します。これらのツールは、外部の依存関係に影響を与える機能停止、中断、またはパフォーマンスの低下を把握し、それに対応するために役立ちます。
1. **[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) で最新情報を入手する:** AWS Health は、AWS クラウド リソースの正常性に関する信頼できるソースです。AWS Health を使用して、現在のサービスイベントや今後の変更 (計画されたライフサイクルイベントなど) を視覚化して通知を受け取ることで、影響を軽減するための措置を講じることができます。
1. [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)し、[AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) または [Amazon EventBridge を通じてモニタリングツールやアラートツール](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)をプログラムで統合します。
1. Amazon EventBridge または AWS Health API で既に使用している可能性のある変更管理や ITSM ツール ([Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html)、[ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html) など) と統合することで、アクションを必要とするヘルスイベントの進捗状況を計画および追跡します。
1. AWS Organizations を使用する場合は、[AWS Health の組織ビュー](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html)を有効にして、アカウント間をまたいで AWS Health イベントを集約します。
1. **[AWS X-Ray](https://aws.amazon.com/xray/) でアプリケーションを計測する:** AWS X-Ray を使用すると、アプリケーションとアプリケーションの基盤となる依存関係のパフォーマンスに関するインサイトが得られます。リクエストを開始から終了までトレースすることにより、アプリケーションが依存している外部サービスや外部コンポーネントのボトルネックや障害を特定できます。
1. **[Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) を使用する:** この機械学習ベースのサービスは、運用上の問題を特定し、重大な問題が発生する可能性のあるタイミングを予測して、実行すべき具体的な対応措置を推奨します。依存関係のインサイトを得て、その関係性が運用上の問題の原因ではないことを突き止めるために、非常に有益です。
1. **定期的にモニタリングする:** 外部依存に関するメトリクスとログを継続的にモニタリングします。予期しない動作やパフォーマンスの低下についてのアラートを設定します。
1. **変更後の検証をする:** 外部依存のいずれかが更新されたり変更されたりした場合は、そのパフォーマンスを検証して、アプリケーションの要件との整合性を確認します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 ワークロード KPI の定義](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_application_telemetry.html)
+ [OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP05 トランザクショントレーサビリティを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
+ [OPS08-BP04 実践的なアラートを作成する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_alerts.html)
**関連ドキュメント:**
+ [Amazon Personal Health Dashboard ユーザーガイド](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [AWS Internet Monitor ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)
+ [AWS X-Ray デベロッパーガイド](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [AWS DevOps Guru ユーザーガイド](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
**関連動画:**
+ [アプリケーションのパフォーマンスに影響を及ぼすインターネットの問題の可視化](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [Amazon DevOps Guru の概要](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [AWS Health を使用してリソースライフサイクルイベントを大規模に管理する](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**関連する例:**
+ [AWS Health 対応](https://github.com/aws-samples/aws-health-aware/)
+ [タグベースのフィルタリングを使用した大規模な AWS Health モニタリングとアラートの管理](https://aws.amazon.com/blogs/mt/using-tag-based-filtering-to-manage-health-monitoring-and-alerting-at-scale/)
# OPS04-BP05 分散トレースを実装する
分散トレースを使用すると、分散システムのさまざまなコンポーネントを通過するリクエストをモニタリングし、可視化できます。複数のソースからトレースデータを収集して統合されたビューで分析することで、チームはリクエストの流れ、ボトルネックが発生している場所、重点的に最適化に取り組むべき個所をより正確に把握できます。
**期待される成果:** 分散システムを通過するリクエストを包括的に把握できるため、正確なデバッグ、パフォーマンス最適化、ユーザーエクスペリエンスの向上が実現します。
**一般的なアンチパターン:**
+ 一貫性に欠けた計測: 分散システム内のすべてのサービスがトレースを目標に計測されているわけではない。
+ レイテンシーの考慮なし: エラーのみに注目し、レイテンシーや徐々にパフォーマンスが低下していることが考慮されていない。
**このベストプラクティスを活用するメリット:**
+ 包括的なシステムの全体像: リクエストの入力から終了まで、リクエストのパス全体にわたり可視化できます。
+ デバッグの強化: 障害やパフォーマンスの問題が発生した個所を迅速に特定できます。
+ ユーザーエクスペリエンスの向上: モニタリングを行い、実際のユーザーデータに基づいて最適化を行うことで、確実にシステムが実際の需要を満たせます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
計測が必要となるすべてのワークロードの要素を特定することから始めます。すべてのコンポーネントを把握したら、AWS X-Ray や OpenTelemetry などのツールを活用してトレースデータを収集し、X-Ray や Amazon CloudWatch ServiceLens Map などのツールを使用して分析を行います。デベロッパーとのレビューを定期的に実施し、Amazon DevOps Guru、X-Ray Analytics、X-Ray Insights などのツールをサポートとして使用した議論により、より詳細な検出を行います。トレースデータからアラートを設定して、ワークロードのモニタリング計画で定義されている結果に対してリスクが検出された場合に通知します。
### 実装手順
分散トレースを効果的に実装する方法:
1. **[AWS X-Ray](https://aws.amazon.com/xray/) の採用:** をアプリケーションに組み込むと、アプリケーションの動作に関するインサイトを取得したり、パフォーマンスを把握して、ボトルネックを特定したりできます。X-Ray Insights を自動トレース分析に活用します。
1. **サービスを計測する:** [AWS Lambda](https://aws.amazon.com/lambda/) 関数から [EC2 インスタンス](https://aws.amazon.com/ec2/)まですべてのサービスがトレースデータを送信していることを確認します。計測するサービスが多いほど、エンドツーエンドのビューが明確になります。
1. **[CloudWatch Real User Monitoring](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) と [Synthetic Monitoring](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) を統合する:** Real User Monitoring (RUM) と Synthetic Monitoring を X-Ray と統合します。これにより、実際のユーザーエクスペリエンスをキャプチャしてユーザーの操作をシミュレートし、潜在的な問題を特定できます。
1. **[CloudWatch エージェント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)を使用する:** エージェントは X-Ray と OpenTelemetry のいずれかを使ってトレースを送信できるため、取得できるインサイトの奥行きがさらに深まります。
1. **[Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) を使用する:** DevOps Guru は X-Ray、CloudWatch、AWS Config、AWS CloudTrail のデータを使用して実行可能なレコメンデーションを提供します。
1. **トレースを分析する:** トレースデータを定期的に確認して、アプリケーションのパフォーマンスに影響を及ぼす可能性のあるパターン、異常、またはボトルネックを特定します。
1. **アラートを設定する:** 異常なパターンや長時間のレイテンシー向けに [CloudWatch](https://aws.amazon.com/cloudwatch/) でアラームを設定し、先を見越して問題に対処することを可能にします。
1. **継続的な改善:** サービスが追加または変更されたら、関連するすべてのデータポイントが取得できるように、トレース戦略を再検討します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS04-BP01 主要業績評価指標を特定する](ops_observability_identify_kpis.md)
+ [OPS04-BP02 アプリケーションテレメトリを実装する](ops_observability_application_telemetry.md)
+ [OPS04-BP03 ユーザーエクスペリエンステレメトリを実装する](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリを実装する](ops_observability_dependency_telemetry.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/Install-CloudWatch-Agent.html)
+ [Amazon DevOps Guru ユーザーガイド](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
**関連動画:**
+ [Use AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS on Air ft. Observability: Amazon CloudWatch and AWS X-Ray](https://www.youtube.com/watch?v=qBDBnPkZ-KI)
**関連する例:**
+ [AWS X-Ray 向けのアプリケーションのインストルメント化](https://aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)