[AWS]新しいEBSタイプ:ST1を試してみた

More than 3 years have passed since last update.

AWSのアップデートにより、EBSに新しい2つのタイプが追加されました。

https://aws.amazon.com/jp/blogs/aws/amazon-ebs-update-new-cold-storage-and-throughput-options/

どちらもHDDで、スループットに最適化されたST1と低頻度アクセス向けのSC1です。

上記リンクによると、1TBボリュームで 250 MB/s 、バースト時には最大 500 MB/s まで出るようです。

AWSのページでは、料金の部分のみ更新されていました。(2016/4/20時点)

ebs02.png


評価

早速試してみました。

EC2作成時、ルートボリュームには従来のタイプしかあらわれず、追加ボリュームのみにST1/SC1が選択可能になっていました。

ST1の評価がメインですが、比較用にGP1、Standard(magnetic) も同じ容量 (1TB) アタッチしました。

インスタンスはAmazonLinuxの m4.large で作成しています。

ebs01.png

作成後、EBSのマネジメントコンソールでは以下のように見えています。

ebs05.png

各ボリュームをマウントしました。

ファイルシステムは ext4 にしています。

$ df -h

Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.8G 935M 6.8G 12% /
devtmpfs 3.9G 84K 3.9G 1% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
/dev/mapper/gp2-gp2Lv 985G 72M 935G 1% /data/gp2
/dev/mapper/st1-st1Lv 985G 72M 935G 1% /data/st1
/dev/mapper/std-stdLv 985G 72M 935G 1% /data/std

ランダムアクセスは期待していませんので、dd で 100GB の書き込みをしてシーケンシャルのスループットを測定します。

$ sudo time dd if=/dev/zero of=/data/gp2/write.tmp ibs=1M obs=1M count=102400

102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 2269.99 s, 47.3 MB/s
10.14user 81.46system 37:50.11elapsed 4%CPU (0avgtext+0avgdata 4028maxresident)k
0inputs+209715200outputs (0major+592minor)pagefaults 0swaps

$ sudo time dd if=/dev/zero of=/data/st1/write.tmp ibs=1M obs=1M count=102400

102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 1974.39 s, 54.4 MB/s
11.37user 78.90system 32:54.54elapsed 4%CPU (0avgtext+0avgdata 4088maxresident)k
0inputs+209715200outputs (0major+594minor)pagefaults 0swaps

$ sudo time dd if=/dev/zero of=/data/std/write.tmp ibs=1M obs=1M count=102400

102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 4989.37 s, 21.5 MB/s
10.32user 83.49system 1:23:09elapsed 1%CPU (0avgtext+0avgdata 4260maxresident)k
0inputs+209715200outputs (0major+598minor)pagefaults 0swaps

まとめるとこのようになりました。

EBS タイプ
スループット (MB/s)

GP2
47.3

ST1
54.4

Standard
21.5

Standard以外のGP2、ST1はインスタンスタイプの制限でサチってそうです。

インスタンスタイプを m4.large -> m4.4xlarge に上げて再度測定しました。

$ sudo time dd if=/dev/zero of=/data/gp2/write.tmp ibs=1M obs=1M count=102400

102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 644.162 s, 167 MB/s
9.06user 69.83system 10:44.60elapsed 12%CPU (0avgtext+0avgdata 4016maxresident)k
6488inputs+209715200outputs (0major+593minor)pagefaults 0swaps

$ sudo time dd if=/dev/zero of=/data/st1/write.tmp ibs=1M obs=1M count=102400

102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 432.609 s, 248 MB/s
8.26user 67.76system 7:21.72elapsed 17%CPU (0avgtext+0avgdata 4100maxresident)k
6512inputs+209715200outputs (1major+594minor)pagefaults 0swaps

EBS タイプ
スループット (MB/s)

GP2
167

ST1
248

先程と別物ですね。

ST1はGP2のスループットを大幅に超え、ほぼ公称に近い 248 MB/s のスループットを発揮しています。

ちなみに、上記テストの CloudWatch モニタリング結果はこのようになっています。

ebs04.png

m4.large で実施した際はインスタンスのスループット限界でサチっているのが明らかです。


まとめ

新しく追加された EBS タイプである ST1 ですが、その名の通りシーケンシャルのスループットはかなり高いストレージです。

ただし、今回はひとまずシーケンシャルで試しましたが、HDD は多重度が上がったりランダムアクセスになると極端にスループットが低下する傾向がありますので、これらいろいろなパターンで試し、追記したいと思います。