Amazon EBS の性能ベンチマークその3 (Provisioned IOPS編)

by AndiH

さて、またまた昨日のエントリ「Amazon EBS の性能ベンチマークその2 (Standard-Vol増量編)」の続きです。

ここまでの経緯は以下。

ここまでのベンチマークでは、StandardタイプのEBSボリュームを使っていたのですが、ここからは、必要とするIOPSを設定することが可能な"Provisioned IOPS"なEBSボリューム(プロビジョンドIOPSボリューム)を使って性能を計測してみたいと思います。
~~# 個人で Provisioned IOPS ボリュームを使って高負荷テストとかクラウド破産まっしぐら。~~

ベンチマークの条件の詳細等は、上記のこれまでのエントリからご確認くださいませ。

今回ベンチマークの対象とする「Provisioned IOPS for EBS」の詳細については下記リンク先をご覧ください。

Amazon Web Services ブログ: 【AWS発表】Provisioned IOPS for EBS - I/O性能を設定できるEBSボリュームが登場!

7. 200GBの Provisioned IOPS ボリュームを使ったベンチマーク

ところで、Provisioned IOPSボリュームは、何も制限解除していないと(通常利用)、1アカウントあたり10000IOPSまでしか使えないんですね。現在(2013/4)、1EBSボリュームあたり2000IOPSが上限になっているので、2000IOPSに設定したボリュームだと5つまでしか作れない。
本当はこれまでのエントリ同様、ボリュームを16本作りたかったんですが、解除申請も面倒くさかったので、一旦4本まででやってみることにしました。(これは後日追試かな。)

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

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

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

	ebs * 1	ebs * 2	ebs * 4
sequential read	3545	3771	4347
sequential write	3461	3696	4203
randam read	2064	4114	8150
randam write	2056	4112	8157

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

	ebs * 1	ebs * 2	ebs * 4
read	41.86	83.72	113.238
write	41.729	83.508	114.232

これは特に考察する必要が無いくらい美しいグラフを描いていますｗ

ランダムアクセスに関しては読み込み/書き込みともに、1本あたり約2000IOPSな結果ですね。公称値通りです。2本束ねたらIOPSが2倍。4本束ねたらIOPSは4倍となっています。シーケンシャルアクセスについては、1〜4本でそれほど大きな変化はないですね。(3500〜4300IOPS)
しかし、StandardなEBSボリュームと比較すると、ピークのパフォーマンスの数字そのものは落ちていて、全体的に綺麗にキャップされてるなぁ、という印象です。

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

では、これまでのパターン通り、fioで扱うファイルサイズを50GBまで上げてみます。
これまで同様、fioのruntimeオプションを"64"(sec)に変更して実行し、対象となるEBSボリュームの本数は4本(いずれもRAID0)のみとしました。

前回のエントリの6.の結果と並列に結果を書いてみます。その結果が以下です。IOPS(4k)。
今回のProvisioned IOPS ボリュームのベンチマーク結果は、一番右端の"ebs 200GB (provisioned)"列となります。

	ebs 20GB	ebs 200GB	ebs 200GB (provisioned)
randam read	1620	1344	8191
randam write	513	577	8094

Standardボリュームでは、一度に扱うファイルサイズが大きくなるにつれて、ランダムアクセスのIOPSが落ち込んでいっていましたが、Provisioned IOPSボリュームでは、見事に公称値(2000IOPS * 4ボリュームでRAID0)のパフォーマンスを保ったままでした。違いは、そういうことなんですね。

まとめ

一度に扱うファイルサイズが大きくなった場合においても、Provisioned IOPSボリュームは設定したIOPS通りのパフォーマンスを出してくれる。
一度に扱うファイルサイズが小さい場合は、Standardボリュームの方がパフォーマンスは良い。
Standardボリュームは、ベンチマークパターンの相性なのかタイミングなのかはわからないが、ランダムアクセス時にパフォーマンスが落ち込んでしまうことが、所々で見受けられた。それに比べ、Provisioned IOPSボリュームは終始一貫したパフォーマンスだった。
- 簡単に言うと、「普段は速いけど、たまに遅くなるボリューム」 VS 「安定してそこそこ速いボリューム」的な？
Provisioned IOPSボリュームの方がお高くつくので、負荷試験利用でのクラウド破産までの道のりが(ry