tech・3分で読める

EC2 メトリクス監視：推奨メトリクスとアラーム設定ガイド

EC2インスタンスの運用において監視すべき推奨メトリクスと、その選定理由、アラーム設定のベストプラクティスをまとめました。

#AWS#EC2#監視#CloudWatch#DevOps

EC2 メトリクス監視

本ドキュメントでは、EC2インスタンスの運用において監視すべき推奨メトリクスと、その選定理由についてまとめます。

監視の目的

  • 可用性の維持: ハードウェア障害やOSレベルの障害を即座に検知し、サービスダウン時間を最小限に抑える。
  • リソース枯渇の未然防止: CPU、メモリ、ディスク等のリソース不足によるパフォーマンス劣化やプロセス停止を防ぐ。
  • パフォーマンス維持: アプリケーションの健全な動作に必要なリソースが確保されているかを監視する。

監視すべきメトリクス

AWS CloudWatchで取得可能なメトリクスは「標準メトリクス」と、 CloudWatch Agentの導入が必要な「カスタムメトリクス」に分類されます。

標準メトリクス

AWSにより自動的に提供されるメトリクスです。追加費用なし(標準モニタリング)で利用可能です。

メトリクス名推奨統計推奨閾値 (例)
StatusCheckFailed_SystemMaximum>= 1
StatusCheckFailed_InstanceMaximum>= 1
StatusCheckFailed_AttachedEBSMaximum>= 1
CPUUtilizationAverage> 80% (5分間平均)

カスタムメトリクス

EC2のハイパーバイザーからは見えないOS内部の情報です。CloudWatch Agentのインストールと設定が必要です。 特にWebサーバーやDBサーバーとして運用する場合、これらはCPU監視と同等以上に重要です。

メトリクス名推奨統計推奨閾値 (例)
mem_available_percentAverage< 20%
disk_used_percentMaximum> 85%
swap_used_percentAverage> 50%

状況に応じて検討する標準メトリクス (追加検討項目)

全てのインスタンスで一律に監視するのではなく、サーバーの役割（ロール）やインスタンスタイプに応じて追加を検討すべき項目です。

メトリクス名推奨統計推奨閾値 (例)導入を検討すべき状況
NetworkIn / NetworkOutSumベースライン帯域の80%動画配信、ファイルサーバー、大量API処理サーバーなど
NetworkPacketsIn / NetworkPacketsOutSumインスタンスタイプ固有のPPS上限の80%高トラフィックなWebサーバー、DNSサーバー、プロキシなど
EBSReadOps / EBSWriteOpsSumプロビジョニングIOPSの80-90%データベースサーバー、ログ集約サーバーなど
DiskReadBytes / DiskWriteBytesSumインスタンスタイプ固有の帯域上限を参照データ分析、ストリーミング配信など（インスタンスストア使用時）
InstanceEBSIOPSExceededCheck /
InstanceEBSThroughputExceededCheck		Maximum>= 1インスタンス全般
EBSIOBalance% / EBSByteBalance%Average< 25%バースト可能インスタンス(一部の *.4xlarge 以下)
CPUCreditBalanceAverage最大クレジットの30%以下T系インスタンス

メトリクス詳細説明

StatusCheckFailed_System

監視の意図・根拠: 電源障害やネットワーク機器の故障など、利用者側では対処不可能なAWS基盤側の障害を検知します。復旧にはAWS側の対応を待つか、停止/開始による別ホストへの移動が必要となるため、即時検知が必須です。

推奨される対応: 推奨はCloudWatchアクションによる「EC2インスタンスの自動復旧」です。自動復旧が利用できない場合、10-15分続くようなら手動で停止(Stop)→開始(Start)を実施します。※再起動(Reboot)ではホスト移動しないため効果が薄いです。

StatusCheckFailed_Instance

監視の意図・根拠: メモリ枯渇によるカーネルパニック、ファイルシステム破損、誤ったネットワーク設定など、OS内部の問題を検知します。Systemチェックが正常でも、OSがハングアップしていればサービスは停止しています。

推奨される対応: インスタンスの再起動を試行してください。復旧しない場合、「システムログの取得」を行い、カーネルパニックやブートエラーの原因を特定します。

StatusCheckFailed_AttachedEBS

監視の意図・根拠: アタッチされたEBSボリュームへのI/Oパスに障害があることを検知します。EBS自体の障害やアタッチメントの問題により、ディスクI/Oが失敗している状態です。

推奨される対応: System障害と同様、インスタンスの停止(Stop)→開始(Start)でホスト移動することで復旧する可能性があります。 復旧しない場合、ボリューム自体の障害の可能性があるため、サポートへの問い合わせやスナップショットからの復元・交換を検討します。

CPUUtilization

監視の意図・根拠: CPUリソースの飽和を検知します。100%に達するとSSH接続すら応答しなくなり、調査が困難になります。80%を閾値とすることで、完全に飽和する前に調査・対応する余地（ヘッドルーム）を残します。

推奨される対応: SSH接続し top コマンド等で高負荷プロセスを特定します。定常的に高い場合はインスタンスタイプ変更（スケールアップ）や台数増加（スケールアウト）を検討します。

mem_available_percent

監視の意図・根拠: CloudWatch Agent の mem_available_percent は「プロセスへ即時に割り当て可能なメモリ割合」を示します。 これが枯渇すると OOM Killer が発動しプロセスが強制終了されるため、枯渇リスクの一次アラートとして推奨します。

推奨される対応: free -m や top でメモリ使用状況を確認。 アプリケーションのメモリリークの可能性を疑うか、メモリ容量の大きいインスタンスタイプへ変更します。

disk_used_percent

監視の意図・根拠: ディスク容量が100%になると、ログ出力やコマンド実行が失敗します。 ※あわせて disk_inodes_used (inode使用率) も監視することを推奨します（大量の小ファイル生成による枯渇を防ぐため）。

推奨される対応: du -sh * 等で大容量ファイルを特定し、古いログやバックアップを削除またはS3へ退避します。 恒久的にはEBSボリュームのサイズ拡張を行います。

swap_used_percent

監視の意図・根拠: スワップ領域へのアクセスは物理メモリに比べて著しく低速です。 頻繁なスワップ発生（スラッシング）はシステム全体の劇的なパフォーマンス低下を招くため、物理メモリの増強を検討する指標とします。

推奨される対応: 頻繁にSwapが発生している場合、物理メモリが不足しています。 インスタンスタイプの変更（メモリ増強）を強く推奨します。

NetworkIn / NetworkOut

監視の意図・根拠: インスタンスタイプごとに「ベースライン帯域幅」が決まっています。 定常的に帯域上限に張り付くとパケットドロップが発生し、通信遅延の原因となります。

推奨される対応: 継続高止まりなら、ドロップ/制限を確認 → スケールアップ/アウト または転送量削減。

NetworkPacketsIn / NetworkPacketsOut

監視の意図・根拠: 帯域幅(Bytes)に余裕があっても、パケット数(PPS)の上限に達するとパケットドロップが発生します。 インスタンスサイズごとにPPS上限があり、これを超過すると通信遅延や接続断が発生するため。

推奨される対応: PPS高止まり＋影響ありなら、ドロップ/制限を確認 → スケールアップ/アウト またはパケット削減（Keep-Alive/HTTP2等）。

EBSReadOps / EBSWriteOps

監視の意図・根拠: EBSボリュームタイプ（gp2, gp3など）ごとにIOPSの上限があります。 上限に達するとディスクアクセス待ちが発生し、CPUもメモリも余裕があるのにシステムが遅いという状況に陥ります。

推奨される対応: ボリューム側 vs インスタンス側を確認 → ボリューム増強/変更 or インスタンスタイプ変更。

DiskReadBytes / DiskWriteBytes

監視の意図・根拠: インスタンスストアはホスト物理ディスクを使用するため、高速ですが帯域上限は存在します。 インスタンスストアが無い場合は 0 または未報告になり得ます。

推奨される対応: インスタンスストア利用を確認 → 改善不可なら ストレージ性能の高いタイプへ変更（または設計見直し）。

InstanceEBSIOPSExceededCheck / InstanceEBSThroughputExceededCheck

監視の意図・根拠: インスタンス自体のEBS IOPS/スループット上限に達したことを検知します (0=正常, 1=超過)。 ボリューム性能が十分でもインスタンス側がボトルネックになるのを防ぎます。

推奨される対応: 継続して1なら インスタンスタイプ変更（EBS性能が高いもの）＋I/O削減。

EBSIOBalance% / EBSByteBalance%

監視の意図・根拠: 一部インスタンスで提供される「インスタンス側のEBSバースト残量」です。 ※gp2ボリューム自体のバースト残量は BurstBalance (AWS/EBS) を参照してください。

推奨される対応: 低下が継続なら サイズ/タイプ見直し（ベースライン改善）＋I/O平準化。

CPUCreditBalance

監視の意図・根拠: T系インスタンスはCPUバーストクレジットを消費して性能を出します。 クレジットが枯渇するとベースライン性能（例: 5%〜20%程度）に制限され、実用的な速度が出なくなります。

推奨される対応: 枯渇傾向なら より大きいT or 非バースト(M/C等)へ移行（unlimitedはサープラス課金も確認）。

アラーム設定のベストプラクティス

  • 期間 (Period) の設定:
    • 通常は 5分 (300秒) が標準的です。
    • より即時性が求められる本番環境の死活監視では 1分 (60秒) を検討してください（詳細モニタリングの有効化が必要な場合があります）。
  • 評価期間 (Evaluation Periods) の設定:
    • 一瞬のスパイクでアラームを鳴らさないために、N回連続して閾値を超えたら という設定にします。
    • 例: 閾値80%超過が 3回 (15分間) 続いたら発報。
  • 欠損データ (Missing Data) の扱い:
    • StatusCheck: breaching (不正) として扱うのが安全です（データが来ない＝インスタンスが落ちている可能性が高いため）。
    • CPU/Memory: missing または ignore。インスタンス停止中(夜間停止など)にアラームが鳴るのを防ぐため。

チューニングの進め方

  1. 初期構築時は上記「推奨閾値」で設定を開始する。
  2. 運用開始後1ヶ月程度で「誤検知」が多いアラームを洗い出す。
  3. 実際にサービス影響がなかったスパイクについては、閾値を緩和するか、評価期間(連続回数)を長めに調整する。

RK

1997年生まれ

ITエンジニア

インフラ・SRE