EBS のパフォーマンス不足時の検知に役立つメトリクスが CloudWatch に 2 つ追加されました
2024.11.01はじめに
Amazon CloudWatch に、EBS ボリュームのパフォーマンスに関する 2 つの新しいメトリクスが追加されました。EBS ボリュームに設定した IOPS やスループットの値を超過するアクセスがあったことを検知できるようになりました。
なにが嬉しいのか
新しいメトリクスによって EBS ボリュームのパフォーマンスの問題を早期発見ができるようになりました。
- EBS の IOPS とスループット性能不足の検知が可能
- CloudWatch アラームを設定してパフォーマンス不足時に通知可能
新メトリクスの概要
Amazon CloudWatch に、VolumeIOPSExceededCheckとVolumeThroughputExceededCheckの 2 つの新しいメトリクスが追加されました。EBS ボリュームの設定された IOPS またはスループットのパフォーマンスを超えるアクセスがあった場合に検知します。
対応ボリュームと制限事項
- 対応：Nitro 世代のインスタンスにアタッチされたマグネティック（標準）以外のすべてのボリュームタイプ
- 非対応：
- マルチアタッチが有効なボリューム
- Amazon ECS および AWS Fargate タスクにアタッチされたボリューム
メトリクスの共通点
1 分間隔で自動的に収集され、追加料金なしで利用できます。
- 値の範囲：0（超過なし）または 1（超過あり）
- 測定期間：直近 1 分間
- 更新頻度：1 分ごと
VolumeIOPSExceededCheck メトリクス
アプリケーションがボリュームのプロビジョニングされた IOPS パフォーマンスを超える IOPS が記録されるとメトリクスの値が変化します。
- 0：プロビジョニングされた IOPS を超えていない
- 1：プロビジョニングされた IOPS を超えている
VolumeThroughputExceededCheck メトリクス
アプリケーションがボリュームのプロビジョニングされたスループットパフォーマンスを超えるスループットが記録されるとメトリクスの値が変化します。
- 0：プロビジョニングされたスループットを超えていない
- 1：プロビジョニングされたスループットを超えている
EBS ボリュームのパフォーマンスの問題を早期に検出可能となり、パフォーマンス状況を把握しやすくなりました。
EBS に負荷をかけてみた
fio を使用して EBS（gp3）へ負荷をかけて検知するか試してみます。
検証環境
EC2インスタンス仕様
| 項目 | 仕様 |
|---|---|
| Instance Type | c7i.2xlarge |
| vCPU | 8 |
| Memory | 16GB |
| OS | Amazon Linux 2023 |
EBS（gp3）は標準の性能と、IOPS と、スループット値を 2 倍に設定したボリュームの 2 つをアタッチします。
EBSボリューム仕様
| 項目 | gp3-1 (標準) | gp3-2 (若干高性能) |
|---|---|---|
| サイズ | 50GB | 50GB |
| IOPS | 3,000 | 6,000 |
| スループット | 125 MB/s | 250 MB/s |
EBS のマウントと、fio インストール
lsblk
sudo mkfs -t xfs /dev/nvme1n1
sudo mkfs -t xfs /dev/nvme2n1
sudo mkdir -p /data/gp3-1
sudo mkdir -p /data/gp3-2
sudo chown ec2-user: /data/gp3-1
sudo chown ec2-user: /data/gp3-2
sudo mount /dev/nvme1n1 /data/gp3-1
sudo mount /dev/nvme2n1 /data/gp3-2
sudo yum install fio -y
50GB の EBS が 2 つマウントされました。
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 3.1G 648K 3.1G 1% /run
/dev/nvme0n1p1 8.0G 1.7G 6.4G 21% /
tmpfs 7.7G 0 7.7G 0% /tmp
/dev/nvme0n1p128 10M 1.3M 8.7M 13% /boot/efi
tmpfs 1.6G 0 1.6G 0% /run/user/0
/dev/nvme1n1 50G 389M 50G 1% /data/gp3-1
/dev/nvme2n1 50G 389M 50G 1% /data/gp3-2
EBS に負荷をかける
fio を使用して各 EBS に対して小さいファイルの読み書きと、大きなファイルの読み込みで IOPS とスループットに負荷をかけるテストを実施しました。
[global]
ioengine=libaio
direct=1
kb_base=1024
directory=/data/gp3-1
stonewall
group_reporting
time_based=1
runtime=180 # 3分に変更
norandommap=1
# IO負荷テスト（ランダムリード/ライト）
[random-mixed-iops]
description=Random mixed read/write test for IOPS
bs=4k
iodepth=32
numjobs=8
size=2G
rw=randrw
rwmixread=70
# スループット負荷テスト（シーケンシャルリードのみ）
[sequential-read-throughput]
description=Sequential read throughput test
bs=1m
iodepth=8
numjobs=8
size=2G
rw=read
実行結果は JSON 形式で保存します。
fio config --output=results-gp3-1.json --output-format=json
実行結果
VolumeIOPSExceededCheck メトリクスが 1 を示し、IOPS が設定したパフォーマンスでは足りていないことが確認できました。
VolumeThroughputExceededCheck メトリクスが 1 を示し、スループットが設定したパフォーマンスでは足りていないことが確認できました。
gp3 の性能を 2 倍に設定した結果も同じでした。程よく負荷のかけかたを調整しないとダメですね。ベンチマークの結果はきれいに 2 倍の差になっています。
Random Mixed Read/Write Test (4KB)
| 指標 | gp3-1 | gp3-2 | 比較 |
|---|---|---|---|
| Read IOPS | 2,110 | 4,222 | +100.1% |
| Write IOPS | 906 | 1,811 | +99.9% |
| Read Bandwidth | 8.4 MB/s | 16.9 MB/s | +101.2% |
| Write Bandwidth | 3.6 MB/s | 7.2 MB/s | +100.0% |
| Read Avg Latency | 84.64 ms | 42.04 ms | -50.3% |
| Write Avg Latency | 85.37 ms | 43.34 ms | -49.2% |
| Read P99 Latency | 177.21 ms | 90.70 ms | -48.8% |
| Write P99 Latency | 177.21 ms | 91.75 ms | -48.2% |
Sequential Read Test (1MB)
| 指標 | gp3-1 | gp3-2 | 比較 |
|---|---|---|---|
| Bandwidth | 128.8 MB/s | 257.6 MB/s | +100.0% |
| IOPS | 125.8 | 251.5 | +100.0% |
| Avg Latency | 508.73 ms | 254.41 ms | -50.0% |
| P99 Latency | 541.07 ms | 270.53 ms | -50.0% |
まとめ
EBS ボリュームのパフォーマンスの問題をより早く特定可能となるメトリクスが追加されました。
おわりに
ちなみに io2 をマウントして試したところ、今回の負荷程度では 1 を示しませんでした。さすが高性能なボリュータイプです。
