# OPS 4 ワークロードの状態を理解するために、ワークロードをどのように設計すればよいですか?
ワークロードを設計する際には、すべてのコンポーネント (メトリクス、ログ、トレースなど) にわたって内部状態を理解するために必要な情報が送出されるようにします。そうすることによって、適時に有用な返答を提供できるようになります。
**Topics**
+ [OPS04-BP01 アプリケーションテレメトリーを実装する](ops_telemetry_application_telemetry.md)
+ [OPS04-BP02 ワークロードテレメトリーを実装して設定する](ops_telemetry_workload_telemetry.md)
+ [OPS04-BP03 ユーザーアクティビティテレメトリーを実装する](ops_telemetry_customer_telemetry.md)
+ [OPS04-BP04 依存関係のテレメトリーを実装する](ops_telemetry_dependency_telemetry.md)
+ [OPS04-BP05 トランザクショントレーサビリティを実装する](ops_telemetry_dist_trace.md)
# OPS04-BP01 アプリケーションテレメトリーを実装する
アプリケーションテレメトリーは、ワークロードの可観測性の基盤です。アプリケーションは、アプリケーションの状態やビジネス成果の達成に関するインサイトを提供するテレメトリーを送信する必要があります。トラブルシューティングから新しい機能の効果測定に至るまで、アプリケーションテレメトリーを使用することで、ワークロードの構築、運用、展開方法に関する情報を得ることができます。
アプリケーションテレメトリーは、メトリクスとログで構成されます。メトリクスは、脈や体温などの診断情報を指します。複数のメトリクスを使用することで、アプリケーションの状態を知ることができます。長期間にわたるメトリクスの収集は、ベースラインの開発や異常の検知に役立ちます。ログは、アプリケーションの内部の状態や発生したイベントに関してアプリケーションが送信するメッセージです。記録されるイベントには、エラーコード、トランザクション識別子、ユーザーアクションなどが含まれます。
**期待される成果:**
+ アプリケーションは、アプリケーションの状態とビジネス成果の達成に関するメトリクスとログを送信します。
+ ワークロードのすべてのアプリケーションのメトリクスとログは、一元的に保存されます。
**一般的なアンチパターン:**
+ アプリケーションはテレメトリーを送出しません。何か問題が生じたときは、顧客から通知してもらう以外に方法はありません。
+ お客様から、アプリケーションが応答しないと報告されました。あなたはテレメトリーを備えておらず、現在のユーザーエクスペリエンスを理解するために自らアプリケーションを使用することなく、問題が存在することを確認したり、問題の特徴を把握したりすることができません。
**このベストプラクティスを活用するメリット:**
+ アプリケーションの状態、ユーザーエクスペリエンス、ビジネス成果の達成を理解できます。
+ アプリケーションの状態の変化にすばやく対応できます。
+ アプリケーションの状態の傾向を知ることができます。
+ アプリケーションの改善に関する情報に基づく意思決定を行えます。
+ アプリケーションの問題をすばやく検知して解決できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
アプリケーションテレメトリーを 3 つ手順で実装する: テレメトリーを保存する場所の特定、アプリケーションの状態を示すテレメトリーの特定、アプリケーションへのテレメトリー送信機能の追加によって、アプリケーションテレメトリーを実装します。
例えば、eコマースの会社はアーキテクチャベースのマイクロサービスを持っています。アーキテクチャ設計プロセスの一環として、この会社は各マイクロサービスの状態を理解するのに役立つアプリケーションテレメトリーを特定しました。例えば、ユーザーのカートサービスは、カートへの追加、カートの削除、アイテムがカートに追加されるまでの時間などのイベントに関するテレメトリーを送信します。すべてのマイクロサービスは、エラー、警告、トランザクション情報を記録します。テレメトリーは Amazon CloudWatch に送信され、保存および分析されます。
**実装手順**
最初の手順は、ワークロード内のアプリケーションテレメトリーを一元保存する場所を特定することです。既存のプラットフォームがない場合、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) はテレメトリー収集、ダッシュボード、分析、およびイベント生成機能を提供します。
必要なテレメトリーを特定するには、まず以下の質問から始めます。
+ アプリケーションの状態は正常か。
+ アプリケーションはビジネス成果を達成しているか。
アプリケーションは、これらの質問に対して回答を提示するログやテレメトリーを送信する必要があります。既存のアプリケーションテレメトリーがこれらの質問に答えられない場合、ビジネスおよびエンジニアリングのステークホルダーと協力して、これらの質問に答えるテレメトリーの一覧を作成します。新しいアプリケーションテレメトリーの特定と開発に関しては、AWS アカウント チームに技術的なアドバイスを求めることができます。
新しいアプリケーションテレメトリーを特定できたら、エンジニアリングのステークホルダーと協力して、アプリケーションにテレメトリーの送信機能を追加します。 [AWS Distro for OpenTelemetryは、](https://aws-otel.github.io/) アプリケーションテレメトリーを収集する API、ライブラリ、エージェントを提供します。 [この例は、カスタムメトリクスを使用して JavaScript アプリケーションの状態を計測する方法を示します](https://aws-otel.github.io/docs/getting-started/js-sdk/metric-manual-instr)。
AWS が提供する可観測性サービスを知りたいお客様は、ご自身で [1 つの可観測性ワークショップ](https://catalog.workshops.aws/observability/en-US) を実施したり、AWS アカウント チームにガイダンスとサポートを依頼したりすることができます。このワークショップでは、AWS の可観測性ソリューションの概要を学び、使用例を実際に体験することができます。
アプリケーションテレメトリーの詳細についは、 [Amazon Builder’s Library の](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 「分散システムを装備して、運用の可視性を高める」の記事をご覧ください。この記事では、Amazon によるアプリケーションの計測方法、およびお客様の計測ガイドラインの開発に Amazon がどのように役立つかを紹介しています。
**計画の実装に必要な工数レベル:** ミディアム
## リソース
**関連するベストプラクティス:**
[OPS04-BP02 ワークロードテレメトリーを実装して設定する](ops_telemetry_workload_telemetry.md) - アプリケーションテレメトリーはワークロードテレメトリーのコンポーネントの 1 つです。ワークロード全体の状態を理解するには、ワークロードを構成する個別のアプリケーションの状態を理解する必要があります。
[OPS04-BP03 ユーザーアクティビティテレメトリーを実装する](ops_telemetry_customer_telemetry.md) - ユーザーアクティビティテレメトリーは、アプリケーションテレメトリーのサブセットになることがあります。カートへの追加イベント、ストリームのクリック、トランザクションの完了などのユーザーアクティビティは、ユーザーエクスペリエンスに関するインサイトを提供します。
[OPS04-BP04 依存関係のテレメトリーを実装する](ops_telemetry_dependency_telemetry.md) - 依存関係チェックはアプリケーションテレメトリーに関連しているため、アプリケーションに追加することができます。アプリケーションが DNS やデータベースなどの外部システムに依存している場合、アプリケーションはアクセス性、タイムアウト、および他のイベントに関するメトリクスとログを送信できます。
[OPS04-BP05 トランザクショントレーサビリティを実装する](ops_telemetry_dist_trace.md) - ワークロード全体のトランザクションを追跡するには、各アプリケーションが共有したイベントをどのように処理したかについての情報を送信する必要があります。各アプリケーションがこれらのイベントを処理した方法は、アプリケーションテレメトリーを介して送信されます。
[OPS08-BP02 ワークロードのメトリクスを定義する](ops_workload_health_design_workload_metrics.md) - ワークロードメトリクスは、ワークロードの状態を示す重要なインジケーターです。主要なアプリケーションメトリクスは、ワークロードメトリクスの一部です。
**関連するドキュメント:**
+ [AWS Builders' Library - 分散システムを装備して、運用の可視性を高める](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)
+ [AWS Distro for OpenTelemetry](https://aws-otel.github.io/)
+ [AWS Well-Architected 運用上の優秀性の柱のホワイトペーパー - テレメトリーの設計](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-telemetry.html)
+ [フィルターを使用したログイベントからのメトリクスの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [Amazon CloudWatch を使用したログ記録とモニタリングの実装](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html)
+ [AWS Distro for OpenTelemetry を使用したアプリケーションの状態とパフォーマンスのモニタリング](https://aws.amazon.com/blogs/opensource/monitoring-application-health-and-performance-with-aws-distro-for-opentelemetry/)
+ [新規 - Amazon CloudWatch エージェントを使用してカスタムアプリケーションメトリクスをより効果的にモニタリングする方法](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/)
+ [AWS における可観測性](https://aws.amazon.com/products/management-and-governance/use-cases/monitoring-and-observability/)
+ [シナリオ - CloudWatch へのメトリクスの公開](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/PublishMetrics.html)
+ [構築の開始 - アプリケーションを効率的にモニタリングする方法](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/)
+ [AWS SDK での CloudWatch の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sdk-general-information-section.html)
**関連動画:**
+ [AWS re:Invent 2021 - オープンソースの可観測性](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [CloudWatch エージェントを使用して Amazon EC2 インスタンスからメトリクスとログを収集する](https://www.youtube.com/watch?v=vAnIhIwE5hY)
+ [AWS ワークロードのアプリケーションモニタリングを簡単に設定する方法 - AWS オンラインテックトーク](https://www.youtube.com/watch?v=LKCth30RqnA)
+ [サーバーレスアプリケーションの可観測性をマスターする - AWS オンラインテックトーク](https://www.youtube.com/watch?v=CtsiXhiAUq8)
+ [AWS におけるオープンソースの可観測性 - AWS 仮想ワークショップ](https://www.youtube.com/watch?v=vAnIhIwE5hY)
**関連する例:**
+ [AWS のログ記録およびモニタリングの例に関するリソース](https://github.com/aws-samples/logging-monitoring-apg-guide-examples)
+ [AWS ソリューション: Amazon CloudWatch モニタリングフレームワーク](https://aws.amazon.com/solutions/implementations/amazon-cloudwatch-monitoring-framework/?did=sl_card&trk=sl_card)
+ [AWS ソリューション: 集中ロギング](https://aws.amazon.com/solutions/implementations/centralized-logging/)
+ [1 つの可観測性ワークショップ](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 ワークロードテレメトリーを実装して設定する
内部状態や現在のステータスに関する情報 (API 呼び出しのボリューム、HTTP ステータスコード、スケーリングイベントなど) が送出されるよう、ワークロードを設計および設定します。この情報を使用して、応答が必要とされるタイミングを特定します。
Amazon CloudWatch などの [サービスを](https://aws.amazon.com/cloudwatch/) を使用して、ワークロードコンポーネントからのログとメトリクスを集計します (例: API ログ、 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)、 [AWS Lambda メトリクス](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)、 [Amazon VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)、および [その他のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/aws-services-sending-logs.html))。
**一般的なアンチパターン:**
+ 顧客が、パフォーマンスが低いことについて苦情を申し立てています。アプリケーションに最近の変更はないため、あなたは、ワークロードコンポーネントに問題があると考えています。あなたは、パフォーマンスの低さに影響しているコンポーネントを特定するために分析を行うテレメトリーを備えていません。
+ あなたは、アプリケーションにアクセスできません。あなたには、ネットワーキングの問題であるかどうかを判断するためのテレメトリーがありません。
**このベストプラクティスを確立するメリット:** ワークロード内で何が起こっているかを理解することで、必要に応じて対応できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ ログとメトリクステレメトリーを実装する: 内部状態、ステータス、およびビジネス成果の達成に関する情報が送出されるよう、ワークロードを計測します。この情報を使用して、応答が必要とされるタイミングを特定します。
+ [Gaining better observability of your VMs with Amazon CloudWatch - AWS Online Tech Talks (Amazon CloudWatch で VM の可観測性を改善する - AWS オンラインテックトーク)](https://youtu.be/1Ck_me4azMw)
+ [Amazon CloudWatch の仕組み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ ワークロードテレメトリーを実装して設定する: 内部状態や現在のステータスに関する情報 (API 呼び出しのボリューム、HTTP ステータスコード、スケーリングイベントなど) が送出されるよう、ワークロードを設計および設定します。
+ [Amazon CloudWatch metrics and dimensions reference (Amazon CloudWatch のメトリクスとディメンションのリファレンス)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [AWS CloudTrail とは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
## リソース
**関連するドキュメント:**
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)
+ [Amazon CloudWatch ドキュメント](https://docs.aws.amazon.com/cloudwatch/index.html)
+ [Amazon CloudWatch metrics and dimensions reference (Amazon CloudWatch のメトリクスとディメンションのリファレンス)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon CloudWatch の仕組み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html)
+ [Amazon CloudWatch メトリクスを使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)
+ [AWS CloudTrail とは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
+ [Amazon CloudWatch Logs とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon CloudWatch とは](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
**関連動画:**
+ [Application Performance Management on AWS (AWS でのアプリケーションのパフォーマンスメトリクス)](https://www.youtube.com/watch?v=5T4stR-HFas)
+ [Gaining Better Observability of Your VMs with Amazon CloudWatch (Amazon CloudWatchで VM の可観測性を改善する)](https://youtu.be/1Ck_me4azMw)
+ [Gaining better observability of your VMs with Amazon CloudWatch - AWS Online Tech Talks (Amazon CloudWatch で VM の可観測性を改善する - AWS オンラインテックトーク)](https://youtu.be/1Ck_me4azMw)
# OPS04-BP03 ユーザーアクティビティテレメトリーを実装する
ユーザーアクティビティに関する情報 (クリックストリームのほか、開始、放棄、完了済みトランザクションなど) が送出されるよう、アプリケーションコードをインストルメント化します。この情報を使用して、アプリケーションの使用方法や使用パターンを理解したり、応答が必要とされるタイミングを特定したりできます。
**一般的なアンチパターン:**
+ 開発者は、ユーザーのテレメトリーなしで新しい機能をデプロイし、使用率が増加しました。あなたは、使用率の増加が新しい機能の使用によるものなのか、あるいは新しいコードで発生した問題なのかを判別できません。
+ 開発者は、ユーザーのテレメトリーなしで新しい機能をデプロイしました。あなたは、顧客に問い合わせて尋ねなければ、顧客が当該機能を使用しているかどうかがわかりません。
**このベストプラクティスを活用するメリット:** 顧客がアプリケーションを使用して使用パターンや予期しない動作を特定し、必要に応じてお客様が対応することを可能にする方法を理解します。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ ユーザーアクティビティテレメトリを実装する: ユーザーアクティビティに関する情報 (クリックストリームのほか、開始、放棄、完了済みトランザクションなど) が送出されるよう、アプリケーションコードを設計します。この情報を使用して、アプリケーションの使用方法や使用パターンを理解したり、応答が必要とされるタイミングを特定したりできます。
# OPS04-BP04 依存関係のテレメトリーを実装する
依存するリソースの状態 (到達可能性や応答時間など) に関する情報を出力するようにワークロードを設計および設定します。外部依存関係の例としては、外部データベース、DNS、ネットワーク接続などがあります。この情報を使用して、応答が必要とされるタイミングを特定します。
**一般的なアンチパターン:**
+ アプリケーションにアクセスできない理由が DNS の問題であるかどうかを判断するには、手動で DNS プロバイダーが動作しているかどうかを確認する必要があります。
+ ショッピングカートアプリケーションはトランザクションを完了できません。クレジットカード処理プロバイダーの問題であるかどうかを確認するには、そのプロバイダーに連絡する必要があります。
**このベストプラクティスを活用するメリット:** 依存関係の状態を理解することで、必要に応じて対応できます。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 依存関係のテレメトリーを実装する: ワークロードが依存するシステムの状態やステータスに関する情報が送出されるよう、ワークロードを設計および設定します。たとえば、外部データベース、DNS、ネットワーク接続、外部クレジットカード処理サービスなどがあります。
+ [AWS Systems Manager 統合での Amazon CloudWatch エージェント - Linux および Windows 向けの統合メトリクスおよびログ収集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [CloudWatch エージェントを使用した Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
## リソース
**関連するドキュメント:**
+ [AWS Systems Manager 統合での Amazon CloudWatch エージェント - Linux および Windows 向けの統合メトリクスおよびログ収集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/)
+ [CloudWatch エージェントを使用した Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
**関連する例:**
+ [Well-Architected ラボ - 依存関係のモニタリング](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/)
# OPS04-BP05 トランザクショントレーサビリティを実装する
ワークロード全体のトランザクションフローに関する情報が送出されるよう、アプリケーションコードを実装し、ワークロードコンポーネントを設定します。この情報を使用して、応答が必要とされるタイミングを特定し、問題につながる要素の特定に役立てます。
AWS では、次のような分散トレーシングサービスを使用できます。 [AWS X-Ray](https://aws.amazon.com/xray/)では、トランザクションがワークロードを通過するときにトレースを収集して記録したり、マップを生成してワークロードやサービス間でトランザクションがどのように流れるかを確認したり、コンポーネント間の関係を把握したり、さらにはリアルタイムで問題を特定して分析したりできます。
**一般的なアンチパターン:**
+ あなたは、複数のアカウントにまたがるサーバーレスマイクロサービスアーキテクチャを実装しました。断続的なパフォーマンスの問題が顧客に発生しています。アプリケーション内でパフォーマンスの問題が存在する場所と問題の原因の特定を可能にするトレースがないため、どの機能またはコンポーネントが問題を引き起こしているのかを特定できません。
+ あなたは、開発を行う際に対処できるように、ワークロードのパフォーマンスのボトルネックがどこにあるかを特定しようとしています。あなたは、アプリケーションコンポーネントと、それらがやり取りするサービスとの関係を確認できず、アプリケーションのパフォーマンスに影響を及ぼす特定のサービスやパスのドリルダウンを可能にするトレースがないため、ボトルネックがどこにあるかを特定できません。
**このベストプラクティスを確立するメリット:** ワークロード全体のトランザクションフローを理解することで、ワークロードトランザクションの予想される動作と、ワークロード全体の予想される動作のバリエーションを理解できるため、必要に応じて対応できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
+ トランザクショントレーサビリティを実装する: トランザクションステージ、アクティブコンポーネント、アクティビティ完了までの時間など、システムコンポーネント全体のトランザクションフローに関する情報を送出するよう、アプリケーションとワークロードを設計します。この情報を使用して、進行中のもの、完了しているもの、および完了したアクティビティの結果を特定できます。これは、応答が必要とされるタイミングを特定するのに役立ちます。例えば、コンポーネント内のトランザクション応答時間が予想より長い場合、そのコンポーネントに問題があることがわかります。
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS X-Ray とは](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
## リソース
**関連するドキュメント:**
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [AWS X-Ray とは](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)