概要

AWS EC2インスタンスのディスクパフォーマンスを監視する際、似たような名前の2種類のメトリクスがあります:

EC2

インスタンスレベルのメトリクス

DiskReadBytes DiskWriteBytes

EC2インスタンスのOSが認識するディスク操作を測定します。

EBS

ボリュームレベルのメトリクス

VolumeReadBytes VolumeWriteBytes

EBSボリュームの実際の物理的なI/O操作を測定します。

メトリクスの詳細

EC2

DiskReadBytes / DiskWriteBytes

これらはEC2インスタンスの 論理的なI/O操作 を測定するメトリクスです。

  • 測定場所: インスタンスのOSレベル(ハイパーバイザーから見たI/O)
  • キャッシュの影響: OSのキャッシュやバッファリングの影響を受けます
  • 計測単位: バイト数
  • 取得方法: CloudWatchメトリクスの「EC2」名前空間から
EBS

VolumeReadBytes / VolumeWriteBytes

これらはEBSボリュームの 物理的なI/O操作 を測定するメトリクスです。

  • 測定場所: EBSボリュームレベル(実際のストレージデバイス)
  • キャッシュの影響: OSのキャッシュやバッファリングの影響を受けません
  • 計測単位: バイト数
  • 取得方法: CloudWatchメトリクスの「EBS」名前空間から

主な違い

比較項目 DiskReadBytes / DiskWriteBytes VolumeReadBytes / VolumeWriteBytes
測定レベル インスタンス(OS)レベル ボリューム(物理ストレージ)レベル
データの正確性 OSのキャッシュにより値が少なく見える場合がある 実際にディスクに書き込まれた正確なバイト数
ユースケース アプリケーションの論理的I/O性能の把握 実際のEBSボリュームのパフォーマンス把握
複数ボリューム インスタンスにアタッチされた全ボリュームの合計 個別のボリュームごとに測定可能
監視の目的 アプリケーションがどれだけのI/Oを要求しているか 物理的なディスクの使用状況と性能

値の差が生じる理由

同じインスタンスで測定した場合でも、これらのメトリクスの値が異なることがあります。主な理由は:

  • OSのキャッシュ: OSはディスク操作を最適化するためにメモリ上にキャッシュを持ちます。読み取りがキャッシュから行われた場合、DiskReadBytesには含まれませんが、最初にデータを読み取る際にはVolumeReadBytesに記録されます。
  • バッファリング: 書き込みはOSによってバッファリングされ、一定のタイミングでまとめて物理ディスクに書き込まれます。そのため、DiskWriteBytesとVolumeWriteBytesの間で時間差が生じることがあります。
  • ファイルシステムのオーバーヘッド: ファイルシステムが内部で行う操作(メタデータの更新など)により、アプリケーションが要求した以上のディスクI/Oが発生することがあります。

データの流れ

アプリケーション
データの読み書きを要求
OSのキャッシュ・バッファ
DiskReadBytes / DiskWriteBytes はここで測定
EBSボリューム(物理ストレージ)
VolumeReadBytes / VolumeWriteBytes はここで測定
例:ファイル読み取りの場合

1. アプリケーションが10MBのファイルを読み取り要求

2. 初回アクセス時:OSはEBSから10MB読み取り → VolumeReadBytes = 10MB , DiskReadBytes = 10MB

3. 2回目のアクセス時:OSがキャッシュから読み取り → VolumeReadBytes = 0MB (追加読み取りなし), DiskReadBytes = 10MB

使い分け方

EC2

DiskReadBytes / DiskWriteBytes を使う場合

  • アプリケーションの要求するI/O量 を把握したい場合
  • アプリケーションレベルの パフォーマンスチューニング をする場合
  • 複数のEBSボリュームを使用しており、 インスタンス全体の論理的なI/O を監視したい場合
EBS

VolumeReadBytes / VolumeWriteBytes を使う場合

  • 実際のディスク使用量 を正確に把握したい場合
  • EBSボリュームの パフォーマンス制限 に近づいているかを確認したい場合
  • 複数のEBSボリュームがある場合に 個別のボリュームパフォーマンス を監視したい場合
  • ストレージコストの 最適化 を行いたい場合

監視のベストプラクティス

効果的な監視のためのヒント

  • 両方のメトリクスを監視する: 完全な状況を把握するためには、両方のメトリクスを監視することをお勧めします。
  • 差異に注目する: 二つのメトリクス間に大きな差がある場合、それはOSのキャッシュが効いている、またはI/Oの問題がある可能性があります。
  • アラートの設定: VolumeReadBytes/VolumeWriteBytesがボリュームの制限に近づいた場合にアラートを設定すると、パフォーマンスの問題を事前に検知できます。
  • トレンドの分析: 単発の値よりも時間経過による傾向を分析することで、システムの健全性をより良く理解できます。

Created by SSuzuki1063

AWS SAP Learning Resources