EBS 新メトリクス VolumeStalledIOCheck とは？【2023年11月】

TOC

はじめに
1. 新しい EBS Stalled I/O Check メトリクスの公式発表 (英語)
EBS Stalled I/O Check とは
StatusCheckFailed_AttachedEBS と似ている？
1. StatusCheckFailed_AttachedEBS とは
2. StatusCheckFailed_AttachedEBS 失敗の原因
実際にメトリクスを確認してみよう
1. Nitro インスタンスでメトリクスを確認
  1. VolumeStalledIOCheck 確認
  2. StatusCheckFailed_AttachedEBS 確認
2. Xen インスタンスでメトリクスを確認
  1. VolumeStalledIOCheck 確認
  2. StatusCheckFailed_AttachedEBS 確認
実際にメトリクスを失敗させてみよう
VolumeStalledIOCheck と StatusCheckFailed_AttachedEBS の違いまとめ
さいごに

はじめに

2023年11月16日、AWS の EBS に新たなメトリクス、VolumeStalledIOCheck が追加されたと発表がありました。

新しい EBS Stalled I/O Check メトリクスの公式発表 (英語)

AWS 公式から以下のように発表がありました。

New Amazon CloudWatch metric monitors EBS volume I/O health
Posted On: Nov 16, 2023
Today, Amazon announced the availability of a new CloudWatch metric called EBS Stalled I/O Check to monitor the health of your AWS EBS volumes. You can use this CloudWatch metric to monitor the status of the I/O being driven on your EBS volume to determine when your volumes are impaired. With this new volume level metric, you can now quickly detect and respond to EBS impairments that may potentially be impacting the performance of your applications. The metric will return a 0 (pass) or a 1 (fail) status based on if the EBS volume is processing requested I/O operations. With Amazon CloudWatch, you can use the new metric to create customized dashboards and set alarms that notify you or automatically perform actions based on the metric.
The EBS Stalled IO Check metric is available by default at a 1-minute frequency at no additional charges, and is supported for all EBS volumes attached to an EC2 instance in all commercial AWS regions, including the AWS GovCloud (US) Regions. To learn more about the EBS Stalled I/O Check CloudWatch metric, please visit the EBS CloudWatch Metrics documentation.
https://aws.amazon.com/jp/about-aws/whats-new/2023/11/new-amazon-cloudwatch-metric-monitors-ebs-volume-i-o-health/

新しい Amazon CloudWatch メトリクスで EBS ボリューム I/O の正常性を監視する

今回は、この新しいメトリクスについて詳細を確認していきます。

「どういうときにどんな値を取るのか」「どういう対応が必要なのか」をクリアにしていきたいです。

最近発表されたもう一つのメトリクス、StatusCheckFailed_AttachedEBS との違いについても、実際にメトリクスを確認しつつ進めます。

EBS Stalled I/O Check とは

新しい EBS Stalled I/O Check メトリクスの公式発表 (翻訳)

先ほどの公式発表は現時点まだ日本語ページが存在しません。
そこで、翻訳してみました。

新しい Amazon CloudWatch メトリクスがEBSボリュームのI/O健康状態を監視
投稿日：2023年11月16日
本日、Amazon は AWS EBS ボリュームの健康状態を監視するための新しい CloudWatch メトリクス「EBS Stalled I/O Check」の利用可能性を発表しました。この CloudWatch メトリクスを使用して、EBS ボリュームで実行されている I/O の状態を監視し、ボリュームが障害を受けているかどうかを判断することができます。この新しいボリュームレベルのメトリクスにより、アプリケーションのパフォーマンスに影響を与える可能性のある EBS の障害を迅速に検出し、対応することができます。メトリクスは、EBS ボリュームが要求された I/O 操作を処理しているかどうかに基づいて0（合格）または1（失敗）の状態を返します。Amazon CloudWatch を使用すると、新しいメトリクスを使用してカスタマイズされたダッシュボードを作成し、メトリクスに基づいて通知を送信したり自動的にアクションを実行するアラームを設定することができます。
EBS Stalled IO Check メトリクスは、追加料金なしで1分間隔でデフォルトで利用可能であり、すべての商業 AWS リージョン、および AWS GovCloud（US）リージョンの EC2 インスタンスに接続されたすべての EBS ボリュームでサポートされています。EBS Stalled I/O Check CloudWatch メトリクスについての詳細は、EBS CloudWatch メトリクスのドキュメントをご覧ください。EBS Stalled IO Check メトリクスは、追加料金なしで 1 分間隔でデフォルトで利用可能であり、すべての商業AWSリージョン、および AWS GovCloud（US）リージョンのEC2インスタンスに接続されたすべての EBS ボリュームでサポートされています。EBS Stalled I/O Check CloudWatch メトリクスについての詳細は、EBS CloudWatch メトリクスのドキュメントをご覧ください。

要約すると、以下のような感じかと思います。

新しいメトリクス「EBS Stalled I/O Check」は、EBS ボリュームの障害を検知
- ボリュームが要求された I/O 操作を処理しているかで判断
- 0（合格）または1（失敗）
追加料金なし
1分間隔
デフォルトで利用可能
全商用リージョン、AWS GovCloud (米国) リージョンで利用可能

メトリクス名は VolumeStalledIOCheck

先ほどの発表に以下の案内がありました。

To learn more about the EBS Stalled I/O Check CloudWatch metric, please visit the EBS CloudWatch Metrics documentation.

もっと学びたいので、ドキュメントを追いかけましょう。

Metric Description
VolumeStalledIOCheck Reports whether a volume has passed or failed a stalled IO check in the last minute. For more information, see Monitor I/O characteristics using CloudWatch. This metric can be either 0 (passed) or 1 (failed). Units: Count
Volume metrics for volumes attached to all instance types
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html#ebs-volume-metrics

こちらも日本語ドキュメントにはまだなさそうでした。

メトリクス名は VolumeStalledIOCheck であるようです。
説明自体は先ほどの要約内容と同じですね。

VolumeStalledIOCheck 失敗時の原因・対策・検証方法

以下の案内に従い、更に見てみましょう。

For more information, see Monitor I/O characteristics using CloudWatch.

こちらも日本語ドキュメントはまだなさそうでした。

VolumeStalledIOCheck monitors the status of your EBS volumes to determine when your volumes are impaired. 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.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html#ebs-io-metrics

VolumeStalledIOCheck 失敗の原因

This check detects underlying issues with the Amazon EBS infrastructure, such as the following:
Hardware or software issues on the storage subsystems underlying the EBS volumes
Hardware issues on the physical host that impact reachability of the EBS volumes from your EC2 instance
Connectivity issues between the instance and EBS volumes
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html#ebs-io-metrics

メトリクス VolumeStalledIOCheck が 1 (失敗) を記録した際は、以下のような問題が発生しているようです。

EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題
EC2 インスタンスから EBS ボリュームへの到達性に影響を与える物理ホスト上のハードウェアの問題
インスタンスと EBS ボリューム間の接続性の問題

主に基盤側の障害っぽいですね。
「それはそうと、StatusCheckFailed_AttachedEBS と似ている？」と思った方は後述の章をご覧ください。

VolumeStalledIOCheck 失敗時の対策

If the VolumeStalledIOCheck metric fails, you can either wait for AWS to resolve the issue, or you can take actions, such as replacing the affected volume or stopping and restarting the instance to which the volume is attached. In most cases, when this metric fails, EBS will automatically diagnose and recover your volume within a few minutes.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html#ebs-io-metrics

VolumeStalledIOCheck 失敗時の対策としては以下のアクションが取れるようです。

AWS が問題を解決するのを待つ
影響を受けるボリュームを交換する
ボリュームがアタッチされているインスタンスを停止して再起動する

とはいえ、公式ドキュメント的に、基本的には EBS が自動的にボリュームを診断して、数分以内に回復するみたいですね。

VolumeStalledIOCheck 検証方法

You can use the Pause I/O action in AWS Fault Injection Simulator to run controlled experiments to test your architecture and monitoring based on this metric to improve your resiliency to storage faults.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-io-characteristics.html#ebs-io-metrics

VolumeStalledIOCheck 失敗の再現方法としては、 AWS Fault Injection Simulator の Pause I/O アクションを使用することが可能なようです。

感想

我々利用者側からこのメトリクスを再現させる方法はないのかは気になりますね。
(fio で負荷かけても、EC2 – EBS 間の I/O 操作整合性に影響は与えれるわけでもないし、nvme ドライバをブラックリスト化するとかはそもそも起動できなくなるから事象として違うだろうし、体感的には無理そう。色々試してみたいところですが、何か良い案ないかなぁ)

StatusCheckFailed_AttachedEBS と似ている？

先ほどの VolumeStalledIOCheck の説明を読んで、「 StatusCheckFailed_AttachedEBS との違いって何？」ってなった方もいるのではないでしょうか。
私はなりました。

StatusCheckFailed_AttachedEBS とは

先月 (2023年10月11日) にも新しいメトリクス、StatusCheckFailed_AttachedEBS が発表されました。
こちらのメトリクスは現時点で日本語での発表ページがありました。

Amazon CloudWatch の新しいメトリクスが EBS ボリュームへの EC2 インスタンスの到達可能性をモニタリング可能に
投稿日: Oct 11, 2023
本日、「アタッチされた EBS のステータスチェック」という新しい Amazon CloudWatch メトリクスをリリースしました。このメトリクスは、EC2 インスタンスにアタッチされた 1 つ以上の Amazon EBS ボリュームがアクセス可能で I/O オペレーションを実行可能かどうかをモニタリングできます。この新しいメトリクスにより、Amazon EC2 インスタンスで実行されているアプリケーションのパフォーマンスに影響を与える可能性のある EBS での障害を迅速に検出して対応できるようになりました。
「アタッチされた EBS のステータスチェック」メトリクスは、CloudWatch アラームを使用してモニタリングできます。このメトリクスは、デフォルトでは 1 分間隔で追加料金なしで利用できます。また、AWS GovCloud (米国) リージョンを含むすべての商用 AWS リージョンにおいてすべての EC2 Nitro インスタンスでサポートされています。「アタッチされた EBS のステータスチェック」CloudWatch メトリクスの詳細については、Status checks for your instances をご覧ください。
https://aws.amazon.com/jp/about-aws/whats-new/2023/10/amazon-cloudwatch-metric-monitors-reachability-ebs-volumes/#aws-page-content

StatusCheckFailed_AttachedEBS は、Nitro インスタンスでのみサポートされているようです。

StatusCheckFailed_AttachedEBS 失敗の原因

このメトリクスの詳細については公式ドキュメントに説明があります。
メトリクスの失敗原因としては以下が考えられます。

アタッチ済みの EBS ステータスチェックが失敗する原因となる問題の例を次に示します。
EBS ボリュームの基盤となるストレージサブシステムのハードウェアまたはソフトウェアの問題
EBS ボリュームの到達可能性に影響する、物理ホスト上のハードウェアの問題
インスタンスと EBS ボリューム間の接続に関する問題
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html

先ほどの「 VolumeStalledIOCheck 失敗の原因」で記載したものと同じです。
いずれのメトリクスも、同じ問題が発生したときに、同じ値を示すメトリクスという事みたいです。
じゃあ、なぜ別々のメトリクスが存在しているんだろうか。
ということで、実際にメトリクスを見てみました。

実際にメトリクスを確認してみよう

ここでは、実際に VolumeStalledIOCheck と StatusCheckFailed_AttachedEBS がどのように記録されているのか確認してみます。
StatusCheckFailed_AttachedEBS は Nitro でのみサポートされているため、インスタンスは Nitro / Xen でそれぞれ確認したいと思います。
今回は t3.micro, t2.micro で確認してみます。

$ aws ec2 describe-instance-types --instance-types t3.micro t2.micro --query 'InstanceTypes[].{Hypervisor: Hypervisor,InstanceType: InstanceType}' --output table
--------------------------------
|     DescribeInstanceTypes    |
+-------------+----------------+
| Hypervisor  | InstanceType   |
+-------------+----------------+
|  xen        |  t2.micro      |
|  nitro      |  t3.micro      |
+-------------+----------------+

Nitro インスタンスでメトリクスを確認

以下のような構成を準備しました。

インスタンス名: test-instance
インスタンス ID: i-xxxxxxxxxxxx
ルートボリューム ID: vol-yyyyyyyyyyyy
追加のボリューム ID: vol-zzzzzzzzzzzz
インスタンスタイプ: t3.micro
OS: Amazon Linux 2023

なお、マスキングのために ID は以下のようにブラウザ上のみ書き換えておきます。
この状態でメトリクスを見てみましょう。

VolumeStalledIOCheck 確認

CloudWatch メトリクスから確認してみます。

CloudWatch Metrics VolumeStalledIOCheck on Nitro

メトリクスの検索では、インスタンス ID とメトリクス名を指定しています。
結果、ルートボリュームと追加のボリュームのメトリクスがそれぞれ表示されました。

また、上記メトリクスは [すべて] → [EBS] → [InstanceId,VolumeId] に存在しています。
つまり EBS のメトリクスであり、名前空間が AWS/EBS であることがわかります。

なお、線が被っちゃってますが、オレンジの線もきちんと記録されています。

StatusCheckFailed_AttachedEBS 確認

CloudWatch Metrics StatusCheckFailed_AttachedEBS on Nitro

こちらもメトリクスの検索では、インスタンス ID とメトリクス名を指定しています。
しかし、結果は先ほどと異なり、表示されたメトリクスは一つのみでした。

また、上記メトリクスは [すべて] → [EC2] → [インスタンス別メトリクス] に存在しています。
つまり EC2 のメトリクスであり、名前空間が AWS/EC2 であることがわかります。

Xen インスタンスでメトリクスを確認

以下のような構成を準備しました。

インスタンス名: test-instance
インスタンス ID: i-111111111111
ルートボリューム ID: vol-222222222222
インスタンスタイプ: t2.micro
OS: Amazon Linux 2023

今回は追加のボリュームはアタッチしていません。
この状態でメトリクスを見てみましょう。

VolumeStalledIOCheck 確認

CloudWatch Metrics VolumeStalledIOCheck on Xen

VolumeStalledIOCheck は問題なく表示されています。
インスタンスが Nitro か Xen かによって表示 / 非表示は変わらないようですね。

StatusCheckFailed_AttachedEBS 確認

CloudWatch Metrics StatusCheckFailed_AttachedEBS on Xen

StatusCheckFailed_AttachedEBS はメトリクスが生成されませんでした。
ドキュメント通りではありますが、Xen インスタンスではサポートがありません。

実際にメトリクスを失敗させてみよう

この章では、実際に I/O を停止させ、メトリクスを失敗させてみようと思います。
「I/O 停止時に VolumeStalledIOCheck は失敗となるのか」「StatusCheckFailed_AttachedEBS と失敗条件は全く同じなのか」をクリアにしたいです。

先ほど作成した Nitro インスタンスの構成でテストを行います。

AWS Fault Injection Simulator とは

事象再現には AWS Fault Injection Simulator※ を利用します。
※ AWS FIS

AWS FIS はその名の通り異常を注入するシミュレータです。
わざと異常な状態を作り出し、システムが正常性を保てるかをテストできます。

割愛しますが、詳しくは公式ドキュメントを読んでみてください。

耐障害性テストツール – AWS Fault Injection Service – AWS

AWS Resilience Hub の一部である AWS Fault Injection Simulator Service (FIS) は、アプリケーションのパフォーマンス、オブザーバビリティ、回復性を向上させるために、フォールトインジ...

具体的な再現手順

この章では、AWS FIS を用いた障害発生の手順を確認します。

AWS FIS サービスを選択

サービス検索で FIS を入力すると出てきます。

実験テンプレートを作成

まず、左ペインで「実験テンプレート」を選択
次に、「実験テンプレートを作成」をクリックします。

説明と名前を記入

アクションを定義

ここでは、アクションタイプで EBS を選択します。
次に、aws:ebs:pause-volume-io を選択します。

ターゲットを定義

ここでは、先ほど Nitro インスタンスに追加でアタッチしたボリュームをターゲットに指定します。

その他

以降の部分では、サービスアクセスや停止条件、ログの設定を適宜変更してください。
「サービスアクセス」では、「実験テンプレート用の新しいロールを作成する」を選択すれば問題ないです。
自動的に適切なポリシーが付与された IAM ロールが生成されます。

新規にロールを作成したくない方は、既存のロールに以下のアクションを許可してきましょう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeVolumes"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:PauseVolumeIO"
            ],
            "Resource": "arn:aws:ec2:ap-northeast-1:<your-account-id>:volume/*"
        }
    ]
}

<your-account-id> にはご自身の AWS アカウント ID を入力

完了したら最下部に移動し、実験テンプレートを作成します。

実験を開始

「実験を開始」をクリックします。

必要に応じて「開始」を入力しましょう。

IO 操作を実行

実験を開始すると、I/O が一時的に停止します。
この状態で、一度だけ I/O 操作を実行してみました。

# sudo mkfs.ext4 /dev/nvme1n1

/dev/nvme1n1 は、追加ボリュームです。
コマンド自体は I/O 停止しているのでフリーズします。

実験の終了を確認

IO 操作の終了を確認

実験終了後、先ほどのコマンドが終了していることを確認しましょう。
今回の手順では、mkfs.ext4 を実行したため、 journal ログとファイルシステムメタデータから完了時間を確認しておきます。

# journalctl _PID=6118 | cat
Nov 18 07:48:08 audit[6118]: USER_ACCT pid=6118 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Nov 18 07:48:08 audit[6118]: USER_CMD pid=6118 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='cwd="/root" cmd=6D6B66732E65787434202F6465762F6E766D65316E31 exe="/usr/bin/sudo" terminal=pts/0 res=success'
Nov 18 07:48:08 sudo[6118]:     root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/sbin/mkfs.ext4 /dev/nvme1n1
Nov 18 07:48:08 audit[6118]: CRED_REFR pid=6118 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Nov 18 07:48:08 sudo[6118]: pam_unix(sudo:session): session opened for user root(uid=0) by ec2-user(uid=0)
Nov 18 07:48:08 audit[6118]: USER_START pid=6118 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Nov 18 07:49:45 sudo[6118]: pam_unix(sudo:session): session closed for user root
Nov 18 07:49:45 audit[6118]: USER_END pid=6118 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
Nov 18 07:49:45 audit[6118]: CRED_DISP pid=6118 uid=0 auid=1000 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success'
# dumpe2fs /dev/nvme1n1 | grep 'Filesystem created:'
dumpe2fs 1.46.5 (30-Dec-2021)
Filesystem created:       Sat Nov 18 07:49:45 2023

以上で、再現手順は完了です。
時系列を UTC で以下に整理しておきましょう。

タイムスタンプ	作業内容
Nov 18 07:39:34	FIS 実験 (I/O Pause) 開始
Nov 18 07:48:08	I/O 操作 (mkfs.ext4) 実行
Nov 18 07:49:45	I/O 操作 (mkfs.ext4) 完了
Nov 18 07:49:46	FIS 実験 (I/O Pause) 終了

再現時の時系列

I/O 操作の完了と FIS 実験の終了のタイムスタンプが時系列的に微妙ですが、誤差の範囲でしょう。
では、この時にどんなふうにメトリクスが記録されているのか確認しましょう。

CloudWatch で VolumeStalledIOCheck と StatusCheckFailed_AttachedEBS の失敗を確認

CloudWatch Metrics VolumeStalledIOCheck and StatusCheckFailed_AttachedEBS

結果としては、以下の通り。

VolumeStalledIOCheck:
- I/O 操作を実際に行った際に失敗
- 操作されたボリュームのみで失敗 (ルートボリュームは成功)
StatusCheckFailed_AttachedEBS:
- FIS 実験の間ずっと失敗
いずれも若干のラグはあるが、誤差の範囲

感想としては、ちょっと意外でした。
追加ボリュームの VolumeStalledIOCheck (オレンジ線) とインスタンスの StatusCheckFailed_AttachedEBS (緑線) は一致するのかと思っていました。

この結果から、VolumeStalledIOCheck は実際に I/O 操作がボリュームに対して行われている場合に失敗し、StatusCheckFailed_AttachedEBS は I/O 操作がボリュームに対して行われていない場合においても失敗することがわかりました。
（I/O Stalled Check は EC2 は能動的に、EBS は受動的に行っている？等と邪推してます）

VolumeStalledIOCheck と StatusCheckFailed_AttachedEBS の違いまとめ

VolumeStalledIOCheck と StatusCheckFailed_AttachedEBS の違いをまとめると以下のような感じになるかと思います。

VolumeStalledIOCheck:
- EBS ボリューム毎に観測される (名前空間が AWS/EBS)
- インスタンスが Nitro / Xen タイプに関わらずメトリクスが取得できる
- 実際にボリュームに対する I/O Stalled が発生すれば失敗する

StatusCheckFailed_AttachedEBS:
- EC2 インスタンス毎に観測される (名前空間が AWS/EC2)
- インスタンスが Nitro タイプの場合のみメトリクスが取得できる
- 実際にボリュームに対する I/O Stalled が発生していない場合も失敗する

ユースケースとしては、以下が適してそうだなと感じました。
StatusCheckFailed_AttachedEBS → 通常運用時の監視目的として
VolumeStalledIOCheck → 障害発生時の調査の足掛かりとして

さいごに

本記事では新メトリクス VolumeStalledIOCheck を確認しました。
また、StatusCheckFailed_AttachedEBS との違いも整理しました。
まだ2023年11月16日に発表されたばかりで情報が少ないですが、監視対象として組み込むことで、より安全なシステム運用が期待ができそうです。

なお、この記事は推測を含んでいます。
そのため、正しい情報は AWS 公式ドキュメントを確認してください。
また、サポートに問い合わせるのも良いかと思います。

記事の途中で記載した、「OS 上でこのメトリクスを失敗させられないか」について
もしも、何らかの方法で実現できた方いればコメントいただけると嬉しいです。

以上です。