Amazon CloudWatch Metricsの超詳細解説

# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。

この記事ではAmazon CloudWatch Metricsに関連する内容を超詳細にまとめています。

具体的には以下流れで説明します。

- Amazon CloudWatch Metricsとは
- Amazon CloudWatch Metricsの活用
- Amazon CloudWatch Metrics for Advance
- Amazon CloudWatch Metricsのベストプラクティス

AWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。

# この記事を読んでほしい人
- Amazon CloudWatch Metricsがどういうサービスか説明できるようになりたい人
- Amazon CloudWatch Metricsを採用するときのベストプラクティスを説明できるようになりたい人
- AWS Certified DevOps Engineer Professionalを目指している人

# Amazon CloudWatch Metricsとは
Amazon CloudWatch Metricsは、AWSクラウド上で発生するリソースやアプリケーションのパフォーマンスデータを収集し、可視化するためのサービスです。
これにより、リアルタイムでシステムの状態をモニタリングし、トラブルシューティングや効果的なリソースの管理が可能となります。

Amazon CloudWatch Metricsを利用する際にはNamespaceとDimensionという2つを理解することが必要です。

まずNamespaceです。
CloudWatch MetricsはNamespaceと呼ばれる論理的なグループにメトリクスを分類します。
NamespaceはAWSサービスやカスタムアプリケーションごとに異なり、メトリクスの一元管理を可能にします。
AWSサービスのメトリクスは通常、そのサービス名がNamespaceとして使用されます。
たとえば、Amazon EC2のメトリクスはAWS/EC2というNamespaceに属します。

次にDimensionです。
ディメンションは、メトリクスを更に特定化するためのキー/バリューペアであり、メトリクスデータをより細かく分類します。
例えば、EC2インスタンスのCPU使用率をモニタリングする場合、インスタンスIDがディメンションとなります。
ディメンションを指定することで、同じメトリクスでも異なるコンテキストでのデータを取得できます。

NamespaceとDimensionを組み合わせることで、例えばAWS/EC2 Namespace内で、インスタンスIDごとのCPU使用率やネットワークトラフィックを別々にモニタリングすることが可能です。
これにより、異なるリソースやサービスに関するメトリクスを個別に管理・分析できます。

# Amazon CloudWatch Metricsの活用
Amazon CloudWatch MetricsはAWSクラウド上のリソースのパフォーマンスデータを収集し、モニタリングする優れたツールです。以下に、その活用方法について詳しく解説します。

## CloudWatch Custom Metrics
CloudWatch Metricsを活用する際、AWSが提供するメトリクスだけでなく、ユーザーが独自にカスタムメトリクスを作成できます。
これにより、特定のアプリケーションやサービスに特有の指標をモニタリングすることが可能です。

例えば、特定のアプリケーションの処理時間やカスタムログのエラーカウントなどをカスタムメトリクスとして定義し、可視化することができます。

また、カスタムメトリクスは、特定のビジネスケースに合わせて利用できます。
例えば、EC2インスタンスのカスタムメトリクスを作成して、特定のアプリケーションのパフォーマンスやユーザーエクスペリエンスに関するデータを収集し、ダッシュボード上で視覚的に表示することができます。

## CloudWatch Metric Streams
CloudWatch Metric Streamsは、メトリクスデータを準リアルタイムでストリームできる機能です。
![](https://storage.googleapis.com/zenn-user-upload/116b7048b184-20231204.png)

実態としてはKinesis Data Firehoseを利用したストリームで、S3やRedshift、OpenSearchに流し込むことができるのでメトリクス分析がしやすくなります。

また、3rdパーティの監視製品、例えばDatadogやNew Relicに流し込むことも可能です。
CloudWatch Metric Streamsを使うことで容易にメトリクス連携ができるようになり、より高度な監視を行うことができます。

なお、連携するメトリクスはフィルターをかけることができます。
そのため、不要なコストを防止するためにも連携するメトリクスは精査することがベストプラクティスです。

# Amazon CloudWatch Metrics for Advance
## CloudWatch Anomaly Detection
CloudWatch Anomaly Detectionは、機械学習アルゴリズムを使用して異常なパターンや動向を自動的に検出します。

![](https://storage.googleapis.com/zenn-user-upload/15beb4f15b27-20231204.png)
上記は[AWS公式](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)の図ですが赤線部分がトレンドから外れた異常値として検知されているのがわかると思います。

これにより、通常の挙動から外れるイベントや異常なトレンドを検知し、アラームをトリガーすることができます。
異常検知による自動アラーミングは、問題の早期発見や迅速な対応を可能にし、サービスの可用性や安定性を向上させます。

## Amazon Lookout for Metrics
Amazon Lookout for Metricsは、CloudWatch Metricsデータを活用してビジネスインサイトを獲得するためのサービスです。

![](https://storage.googleapis.com/zenn-user-upload/269c31aa239f-20231204.png)

機械学習によって異常を抽出し、異常の原因や傾向を理解することで、ビジネスの成果向上や問題の予防に寄与します。
AppFlowを通じで3rdパーティの製品、例えばSalesforceやMarketo、Zendeskに連携できるため、より高度なビジネス活用が可能になります。

# Amazon CloudWatch Metricsのベストプラクティス
Amazon CloudWatch Metricsをより効果的に活用するためのベストプラクティスを以下にまとめました。

|ベストプラクティス | 説明|
|--- | ---|
|メトリクスの正確な設定 | カスタムメトリクスを正確かつ意味のあるものに設定し、冗長なメトリクスを避けます。|
|リソースのタグ付け | リソースにタグを付け、メトリクスの整理や検索を容易にします。大規模な環境で特に効果的です。|
|アラームの設定と通知 | 閾値を超えた場合にアラームを設定し、通知を受けてリアクティブな対応が可能となります。|
|データの保持期間の設定 | デフォルトの保持期間以外のデータを保存することで、長期的なトレンドの分析が可能になります。|
|異常検知の適切な設定 | CloudWatch Anomaly DetectionやAmazon Lookout for Metricsを使用する際には、適切なトレーニングと設定が必要です。ノイズの影響を受けないように慎重に調整します。|

実プロジェクトではメトリクスを何となく眺めることが少なくないですが、何をしたいのかという目的から逆算してメトリクス設計をすることで、運用負荷の軽減やビジネスへの活用が実現できます。

# まとめ
この記事ではAmazon CloudWatch Metricsに関連する内容を超詳細にまとめました。

- Amazon CloudWatch Metricsとは
- Amazon CloudWatch Metricsの活用
- Amazon CloudWatch Metrics for Advance
- Amazon CloudWatch Metricsのベストプラクティス

次回はAmazon CloudWatch Logsについて超詳細解説します。