[アップデート] AWS Fault Injection Service (FIS) で EBS の I/O レイテンシー注入アクションが利用出来るようになりました

いわさです。

AWS Fault Injection Service (FIS) を使うと、サポートされている様々なサービスで障害をシミュレーションすることが出来ます。
EBS に対して、これまでは次の I/O 停止アクションがサポートされていました。

https://dev.classmethod.jp/articles/aws-fis-pause-io-action-ebs/

先日のアップデートで、さらに I/O レイテンシー注入アクションが追加されました。
これによって完全な I/O 停止だけでなく、割合ベースでレイテンシーが増加した場合のアプリケーション挙動を確認することが出来るようになります。

https://aws.amazon.com/about-aws/whats-new/2025/09/aws-fis-action-inject-io-latency-on-ebs/

また、このアクションは読み込み・書き込みそれぞれでの障害注入も可能で、書き込みレイテンシーのみが急増した場合などケース別の評価を行うことも可能です。
I/O 停止アクションの時と同じで、一部のインスタンスタイプを除く Nitro ベースの EC2 インスタンスにアタッチされた EBS ボリュームタイプで利用が可能です。

事前準備

I/O 上昇なので、事前に EC2 上で読み込みと書き込みを繰り返すスクリプトを用意しておきました。(Amazon Q Developer 作)
今回は t3.micro な Amazon Linux 2023 上を新規作成し、このスクリプトを実行させておきます。

			
			#!/bin/bash

# EBS レイテンシ評価スクリプト
# 使用方法: ./ebs_latency_test.sh [テストディレクトリ] [実行時間(分)]

TEST_DIR=${1:-"/tmp/ebs_test"}
DURATION_MINUTES=${2:-10}
FILE_SIZE="100M"
BLOCK_SIZE="4k"

echo "EBS レイテンシテスト開始"
echo "テストディレクトリ: $TEST_DIR"
echo "実行時間: ${DURATION_MINUTES}分"
echo "ファイルサイズ: $FILE_SIZE"
echo "ブロックサイズ: $BLOCK_SIZE"

# テストディレクトリ作成
mkdir -p "$TEST_DIR"
cd "$TEST_DIR"

# 終了時間計算
END_TIME=$(($(date +%s) + $DURATION_MINUTES * 60))

# テストファイル作成
echo "テストファイル作成中..."
dd if=/dev/zero of=testfile bs=1M count=100 2>/dev/null

echo "継続的I/Oテスト開始 (Ctrl+Cで停止)"

while [ $(date +%s) -lt $END_TIME ]; do
    # ランダム書き込み
    dd if=/dev/urandom of=testfile bs=$BLOCK_SIZE count=1000 conv=notrunc 2>/dev/null
    
    # ランダム読み込み
    dd if=testfile of=/dev/null bs=$BLOCK_SIZE count=1000 2>/dev/null
    
    # sync でディスクに強制書き込み
    sync
    
    # 短い間隔
    sleep 0.1
done

echo "テスト完了"
rm -f testfile

		

実験テンプレートの作成

ではまずは実験テンプレートを作成しましょう。
今回追加されたアクションは以下のaws:ebs:volume-io-latencyです。

アクションパラメータとして特徴的なのが「I/O latency mode」で、読み込みと書き込みの両方、読み込みのみ、書き込みのみ、とレイテンシーを発生させる対象を指定することが出来ます。
あとは読み込み・書き込みそれぞれに対してレイテンシーを発生させる割合と時間を指定します。

ターゲットに指定できるのは I/O 停止アクションと同様に EBS ボリューム自体が対象です。EC2 インスタンスではありません。

実験開始

では冒頭のスクリプトを実行し、上記実験テンプレートから実験を開始してみましょう。
少し待つと EC2 インスタンスにアタッチされた実験対象ストレージのメトリクスで平均読み込みレイテンシーと書き込みレイテンシーが増加していることが確認できますね。

CloudWatch メトリクスでも見てみましょう。
上記メトリクスはVolumeTotalReadTimeとVolumeReadOpsなどから計算されたものです。
何度か実験してみましたが、次のように実験期間中に平均レイテンシーが指定した時間（100ミリほど）まで増加していることが確認できました。

また、実験後に SSM ドキュメントなどを確認してみたのですが、今回のアクションと関連したドキュメントは存在しないようでした。
CPU やネットワーク障害系は SSM ドキュメントを使った OS レイヤーでの実行なのですが、EBS アクションについては完全に Nitro 基盤の裏側で実行されているようです。

さいごに

本日は AWS Fault Injection Service (FIS) で EBS の I/O レイテンシー注入アクションが利用出来るようになったので使ってみました。

断続的に障害が発生するとか、突然のスパイクからの回復とか、I/O 完全停止よりもより柔軟な障害シナリオに対応出来そうですね。
ぜひ使ってみてください。