[アップデート] EBSボリュームのI/O健全性を監視するCloudWatchメトリクスが追加されました

しばたです。

本日よりAmazon EBSのI/O健全性をチェックする新しいCloudWatch Metricsが利用可能になりました。

AWSからのアナウンスは以下となります。

VolumeStalledIOCheck メトリクス

新しく追加されたメトリクスはVolumeStalledIOCheckとなります。
デフォルトで1分に一度の間隔で対象EBSボリュームのI/O状態をチェックし、正常なら0、異常があれば1を返します。

具体的にどの様な行為によってI/Oチェックをしているかは明記されていないのですが、ドキュメントによると

The metric is a binary value that will return a 0 (pass) or a 1 (fail) status based on whether or not the EBS volume can complete I/O operations.

とのことで、何らかのI/Oオペレーションが完了するか否かでチェックしている模様です。

このチェックが異常を返す例として

• EBSボリューム基盤のハードウェア異常やストレージサブシステムのソフトウェア異常
• EC2インスタンスからEBSボリュームまでにある物理ハードウェアの異常
• EC2インスタンスからEBSボリュームへの接続に問題がある場合

といったケースが挙げられています。

• 参考 : Monitor I/O characteristics using CloudWatch

StatusCheckFailed_AttachedEBS メトリクスとの違い

先月EC2インスタンスからEBSボリュームへの到達性を監視するStatusCheckFailed_AttachedEBSメトリクスが増えましたが、AWSのドキュメントを見る限りVolumeStalledIOCheckとほとんど同一に見えます。

StatusCheckFailed_AttachedEBSもそのチェックに「I/Oオペレーションの完了」を採用しており異常を返す要因も同一の記述がされています。
ただ、StatusCheckFailed_AttachedEBSはAWS/EC2名前空間のEC2側のメトリクスでNitro Systemのインスタンスファミリーでのみ取得可能です。
そしてディメンションがインスタンスIDとなり、対象インスタンスに紐づく全EBSをまとめて監視します。

対してVolumeStalledIOCheckはAWS/EBS名前空間のEBSボリューム側のメトリクスでありインスタンスファミリーの制限もありません。 ^*1
ディメンションはボリュームID+アタッチ先インスタンスIDであり、あくまでも単一ボリュームに対する監視となります。

EC2インスタンス全体を見るか単一EBSボリュームを見るかの差で両者を使い分けると良いでしょう。

確認してみた

今回は動作確認用にAmazon Linux 2023のインスタンスを新規作成してみました。

インスタンスタイプはt4g.microでインスタンスIDはi-0529bc698f9aa5150、ルートボリュームIDはvol-05c68f0a2b2e12a1cとなります。

動作確認するまで完全に失念していたのですが、EBSボリュームには元々「I/O ステータス」のチェックがありましたね。

• 詳細 : EBS volume status checks

この「I/O ステータス」と今回のメトリクスが同一のものかは明言されていません。
(個人的な考えとしては、マネジメントコンソールの方はI/O enabled statusの呼称でEnable/Disableが主体となっており、VolumeStalledIOCheckという名前が指すものとは別種のように思えます。)

CloudWatch MetricsではAWS/EBSの名前空間から当該メトリクスを参照可能です。

グラフにするとこんな感じで、インスタンスが起動しているときだけ取得可能です。

あとはCloudWatch Alarmで監視するなどよしなに取り扱ってください。

AWS Fault Injection SimulatorでI/Oを止めてみる

AWS Fault Injection Simulator(FIS)でEBSボリュームのI/O停止をシミュレーションできるのでVolumeStalledIOCheckメトリクスが変化するか確認してみました。

(FIS実験までの手順は割愛)

実験を開始すると割とすぐにVolumeStalledIOCheckメトリクスの値が1になりました。

いい感じです。

ちなみにEBSボリューム側のステータスチェックはボリュームのステータスだけ障害となり、「I/Oステータス」の方は変化なし(更新されず)でした。

(これはどうもFISでシミュレートできない問題っぽい...が、断定できず)

ちなみにStatusCheckFailed_AttachedEBSと並べてみるとこんな感じなので概ね同じタイミングでチェックできると考えて良いでしょう。

最後に

簡単ですが以上となります。

EBSボリュームのI/O健全性を監視をする2つのメトリクスを要件に応じて使い分け監視を強化してください。

脚注