AWS監視の二つの世界: 標準インフラメトリクスとOSレベルの詳細な監視

AWS監視の二つの世界: Standard vs Extended

AWSの監視サービス、Amazon CloudWatchは、監視データを収集するレイヤーの違いから、大きく2つのカテゴリに分けられます。それは 『標準（Standard）』監視 と 『拡張（Extended）』監視 です。この2つは、データを収集する位置、頻度、種類、そしてコストが根本的に異なります。

標準監視 (Standard Monitoring)

標準監視は、AWSリソースが稼働しているハイパーバイザーや、サービスの制御プレーンから直接収集される基本的かつインフラレベルのメトリクスです。RDS、EC2、Elastic Load Balancing、EBSなど、ほとんどのAWSリソースはデフォルトでこの監視を有効にしています。

• 収集位置: ハイパーバイザー、サービス制御プレーン（リソースの「外側」）
• 収集頻度: 通常は5分ごと。一部のリソースでは1分間隔の監視も利用可能。
• 主要なメトリクス:
  • CPUUtilization (CPU使用率)
  • FreeStorageSpace (空きディスク容量)
  • NetworkIn, NetworkOut (ネットワークトラフィック)
  • ReadIOPS, WriteIOPS (EBS・RDSのI/O毎秒)
• コスト: 追加コストなし（既定のCloudWatchメトリクスとして提供）。

このレベルの監視は、リソースの基本的な健全性を確認するのに適しています。例えば、「EC2インスタンスが高CPUで稼働しているかどうか」や「EBSボリュームに空き容量があるか」を確認できます。

拡張監視 (Detailed Monitoring)

拡張監視は、リソースの「内側」にあるオペレーティングシステム（OS）や、アプリケーションのプロセスから直接データを収集する監視手法です。これは標準監視では見えない、より詳細な運用上のKPI（Key Performance Indicator）の監視を可能にします。

• 収集位置: EC2インスタンスのOS、RDSインスタンスのOS（モニタリングエンジンが実行されたリソース内部）
• 収集頻度: 最大1秒間隔で超解像度のデータを取得し、リアルタイムにシステムの状態を把握できます。
• 主要なメトリクス例:
  • MemoryUtilization (EC2のメモリ使用率)
  • DiskUsed, DiskFree (OSレベルのディスク領域使用率)
  • プロセス数、スレッド数（Javaアプリケーションのスレッドリーク検知などに有用）
  • カスタムビジネスKPI: モノリスな決済APIの1秒間あたりの「注文数」、バッチ処理キューの「滞留数」など。
• コスト: カスタムメトリクスとして扱われるため、通常のCloudWatchの課金対象となります。ただし、RDSの「拡張監視」機能は、そのサービスの機能として提供され、追加コストは発生しません。

拡張監視の具体的な手法

AWSの多くのサービスは、独自に「拡張監視」の機能を備えています。RDSの「拡張モニタリング」はその代表例です。これを有効化することで、RDSインスタンス内部で動くオペレーティングシステムの50種類以上のメトリクスを、CloudWatchのカスタムメトリクスとして取得できます。

一方、汎用的な監視手段として、CloudWatchエージェントを利用する手法があります。これはEC2インスタンスにインストールする軽量なエージェントで、OS内部のログやメトリクスを任意のフォルダーやログファイルから/procファイルシステムやpsコマンドの出力を収集して、CloudWatchに送信することで、あらゆるカスタム監視に対応できます。

監視アーキテクチャの設計

このように、AWSの監視には目的に応じて使い分けるべき2つの世界があります。アーキテクチャ設計の際には、何を、どのレイヤーで、どの程度の頻度で監視するかを明確にし、コストとパフォーマンスのバランスを取ることが重要です。