Amazon EBS の性能ベンチマークその2 (Standard-Vol増量編)

by Jemimus

昨日エントリ「Amazon EBS の性能ベンチマークその1 (Standard編)」の続きです。

昨日のエントリで、次はEBSボリュームのサイズを20GBではなく、もっと大きなものにしてみたら、どうなるのだろう？と疑問となった部分があるので、そこのベンチマーク結果となります。

ベンチマークの条件の詳細等は、以下の昨日のエントリからご確認くださいませ。

Amazon EBS の性能ベンチマークその1 (Standard編)

5. 200GBのEBSボリュームを使ったベンチマーク

おさらい的にベンチマークを取得した環境は以下です。

東京リージョン(ap-northeast)で実施。
c1.xlarge (High-CPU Extra Large Instance) のインスタンスを利用。
- http://aws.amazon.com/jp/ec2/instance-types/ によると「EBS 最適化利用: 1000 Mbps」となっています。
200GBのStandard EBSボリュームを1〜16個利用。
Amazon Linux AMI (2013.3)
ファイルシステムは"xfs"
ベンチマークプログラムは"fio"
- 扱うファイルサイズは5GBです。(パラメータ詳細は昨日のエントリをご参照ください。)

さて、それでは、昨日のエントリと同じような感じでベンチマークを行った結果が以下です。まずはIOPS(4k)から。

	ebs * 1	ebs * 2	ebs * 4	ebs * 8	ebs * 16
sequential read	14774	19310	21092	25094	26320
sequential write	4926	5813	6887	9039	13796
randam read	16074	22964	30321	30371	30276
randam write	933	1106	23215	23431	23582

続いて、Bandwidth。単位はMB/sec。

	ebs * 1	ebs * 2	ebs * 4	ebs * 8	ebs * 16
read	113.737	145.059	144.386	146.711	145.317
write	32.527	95.964	120.228	122.126	122.262

計測したタイミングでは、EBSボリュームが1本のときと2本のときのランダムライトの落ち込みが大きかったです。昨日のエントリでも、ランダムアクセスが落ちていたケースがあったので、もうちょっと踏み込んで後日追試予定です。
その他については、EBSボリュームが20GBのケースとそれほど差の無い結果となりました(下部にEBSボリューム20GBでの測定結果を掲載)。EBSボリュームの大小に関しては、性能に影響を及ぼさないようです。

参考: EBSボリューム(20GB)の同一ベンチマーク結果(IOPS)

[:480]

6. EBSボリューム200GBで、fioで扱うサイズを50GBに変更

それでは、ベンチマークで扱うファイルサイズを10倍の50GBまで増やしてみます。
EBSボリュームの容量を増やすことで、利用できるキャッシュ(？)の容量との相関を調べてみます。
昨日同様、fioのruntimeオプションを"64"(sec)に変更して実行し、対象となるEBSボリュームの本数は、4, 8, 16本(いずれもRAID0)としました。

その結果が以下です。IOPS(4k)。

	ebs * 4	ebs * 8	ebs * 16
randam read	1344	3322	10493
randam write	577	1829	4357

これだけでは、比較結果わかりづらいと思いますので、昨日のエントリの4.のベンチマーク結果(同一条件でEBSボリューム20GBのもの)とあわせて表とグラフにしてみます。

	ebs * 4	ebs * 8	ebs * 16
ebs-20GB, randam read	1620	3774	6443
ebs-20GB, randam write	513	736	2367
ebs-200GB, randam read	1344	3322	10493
ebs-200GB, randam write	577	1829	4357

ここからは、EBSボリュームの容量が大きい方(特に16本でRAID0を組んだケース)が優れた性能が出ているため、やはり扱うファイルサイズが大きい場合は、EBSボリュームの容量および束ねる本数を多くするほうが、より高いランダムアクセス性能を引き出せそうです。

まとめ

スタンダードタイプのEBSボリュームは、ランダムアクセス(特に書き込み)については、たまに(相性なのかタイミングなのかは不明。後日追試予定。)性能が落ちて不安定なケースがある。
EBSボリュームは、キャッシュ機構っぽい仕組みがあり、ランダムアクセスについては、そのキャッシュをできるだけ利用したほうが高性能となるっぽい。
キャッシュっぽいところに乗ってしまうと、ランダムアクセス(4k)は、「Read: 約30000, Write: 約23000」あたりまで性能が出る。
スループットのMAX値は、「Read: 145MB/sec, Write: 120MB/sec」。
利用できるキャッシュの容量は限られていて、一度に扱うファイルサイズに影響している。
EBSボリューム自体の容量と、束ねる本数を増やしていくことで、ある程度までのランダムアクセス性能の低下を防ぐことができそう。