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」の詳細については下記リンク先をご覧ください。

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) のインスタンスを利用。
  • 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


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

ランダムアクセスに関しては読み込み/書き込みともに、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

次回予告

  • Provisioned IOPSボリューム16本でのベンチマーク。
  • ランダムアクセスで性能が落ち込むケースにおいての詳細調査。


それでは次回もお楽しみに! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́