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

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](https://qiita-image-store.s3.amazonaws.com/0/111300/02f1d7bc-8747-2c5e-fb7f-1dffb2226f02.png)

評価
-----

早速試してみました。
EC2作成時、ルートボリュームには従来のタイプしかあらわれず、追加ボリュームのみにST1/SC1が選択可能になっていました。
ST1の評価がメインですが、比較用にGP1、Standard(magnetic) も同じ容量 (1TB) アタッチしました。
インスタンスはAmazonLinuxの **m4.large** で作成しています。

![ebs01.png](https://qiita-image-store.s3.amazonaws.com/0/111300/697bf089-dcc5-1417-66b5-f38bbac0441d.png)

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

![ebs05.png](https://qiita-image-store.s3.amazonaws.com/0/111300/51b48676-9f42-0292-eb6e-3d2a3360cecf.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](https://qiita-image-store.s3.amazonaws.com/0/111300/dfbe47fe-a83e-b459-e269-d28ab1ba74b3.png)

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

まとめ
----

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