トップ > IT > Amazon EBS の性能ベンチマーク その1 (Standard編)

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

IT Linux CloudComputing

by grover_net



以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですｗ)

実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった＆今はまた結果が違うかもなので、やってみた。


ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。
というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた - 元RX-7乗りの適当な日々」の時と同様にfioです。
(シリーズもののエントリとして、しばらく続きますｗ)

1. c1.mediumでベンチマーク

以下がベンチマークを取得した際の環境です。

  • 東京リージョン(ap-northeast)で実施。
  • c1.medium (High-CPU Medium Instance) のインスタンスを利用。
  • 20GBのStandard EBSボリュームを1〜16個利用。
  • Amazon Linux AMI (2013.3)


fioは以下のような感じでインストールしておきます。

# wget http://pkgs.repoforge.org/fio/fio-2.0.9-1.rf.src.rpm
# yum -y install rpm-build libaio-devel gcc make
# rpmbuild --rebuild fio-2.0.9-1.rf.src.rpm
# rpm -Uvh rpmbuild/RPMS/x86_64/fio-2.0.9-1.amzn1.x86_64.rpm


使ったファイルシステムは"xfs"で、以下のようなパラメータで作成/マウントしています。

# mkfs.xfs -f -b size=4096 -i size=512 [デバイス]
# mount -t xfs -o noatime,logbufs=8 [デバイス] /data


ちなみにI/Oスケジューラは、EBSボリュームはデフォルトで"noop"でした。


さて、実際にベンチマークを取ったのは、EBSボリューム単体のケース、2台をRAID0で組んだケース、同じく4台(RAID0)、8台(RAID0)、16台(RAID0)の5パターンです。
それぞれのボリュームに関して、以下のパラメータでfioを走らせました。

# fio -filename=/data/testfio -direct=1 -rw=read -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=write -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=randread -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=randwrite -bs=4k -size=5G -numjobs=64 -runtime=16 -group_reporting -name=file1

上から4つは、それぞれシーケンシャルリード/ライトとランダムリード/ライト、ブロックサイズは4kで設定しています。IOPSのチェックが主目的です。扱うファイルサイズは5GBです。

# fio -filename=/data/testfio -direct=1 -rw=read -bs=32m -size=5G -numjobs=8 -runtime=16 -group_reporting -name=file1
# fio -filename=/data/testfio -direct=1 -rw=write -bs=32m -size=5G -numjobs=8 -runtime=16 -group_reporting -name=file1

あとの2つは、ブロックサイズを大きくして、主にBandwidth(転送レート)をチェックしています。


では、ベンチマーク結果です。まずはIOPS(4k)から。

ebs * 1 ebs * 2 ebs * 4 ebs * 8 ebs * 16
sequential read 16000 19408 18207 20693 29066
sequential write 5421 6061 6083 8478 11380
randam read 13695 22821 24490 29582 31047
randam write 6450 12345 1736 10193 5139


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

ebs * 1 ebs * 2 ebs * 4 ebs * 8 ebs * 16
read 94.935 138.043 144.395 146.329 145.51
write 50.941 92.38 116.796 121.771 122.54


まず、数値が全体にただのディスクとは思えないレベルですね。FlashCacheのようなSSDを使ったキャッシュ機構の仕組みが介在していそうな感じです。一度に5GBくらいのファイルサイズの書き込みだと、結構キャッシュが効いてくるのでしょうか。
どの程度のパフォーマンスが欲しいのかによりますが、EBSボリューム2本のRAID0でもバランスの良いパフォーマンスが出そうな雰囲気です。


ただし、ランダムライトに関しては、グラフの通り、あまり安定したパフォーマンスは出ていないです。たまたまなのか、時間帯が関連しているのか、ベンチマークプログラムとの相性なのかは不明ですが、突拍子に良い結果になることもあれば、思うようにパフォーマンスが出ていない時もありましたが、ベースがハードディスクだとすると、こんなもんでしょうと思えるレベルはいずれも上回っていました。

2. c1.xlargeでベンチマーク

次にインスタンスタイプを変えて、ベンチマークをとってみました。条件は以下の通りです。
先ほどのc1.mediumでのベンチマークからの変更点は以下の通りです。

  • c1.xlarge (High-CPU Extra Large Instance) のインスタンスを利用。


先ほど同様のfioコマンドを実行した結果が以下です。
IOPS(4k)から。

ebs * 1 ebs * 2 ebs * 4 ebs * 8 ebs * 16
sequential read 16730 17854 19830 28315 29210
sequential write 5372 5939 6465 7918 11894
randam read 14311 24287 30613 30180 30213
randam write 5956 11769 20713 22940 23253


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

ebs * 1 ebs * 2 ebs * 4 ebs * 8 ebs * 16
read 104.978 142.768 144.378 143.793 144.915
write 48.416 94.625 120.106 121.975 121.477


インスタンスタイプを大きくして、よりCPU core数の大きいもので、EBSの最適化利用で1000Mbpsのスループットが要求できるものにしてみましたが、結果は上記の通り、c1.mediumと大きな差はついていません。Bandwidthの部分についてもあまり結果が変わらなかったのは、"最適化利用:不可"のc1.mediumでもMbpsのスループットに換算すると、1000Mbps以上出ているため、この結果から「Read: 145MB/sec, Write: 120MB/sec」が通常のEBSボリュームのスループットの上限なのでしょう。

ランダムライトのパフォーマンスのバラつきはなく、安定したパフォーマンスを発揮している印象です。
上記の結果から、今回のベンチマークの条件だと、よほどのことがない限り、EBSボリュームを4本より大きい数で束ねることによるメリットはそんなになさそうです。

3. c1.xlargeでfioで扱うサイズを15GBに変更

ここまでのベンチマークで何か前段にキャッシュがいそうな雰囲気を出しているEBSボリュームですが、それならばと、fioで扱うファイルサイズを5GBから15GBで増やしてみました。
また、扱うファイルサイズを大きくしたので、fioのruntimeオプションを"32"(sec)に変更しました。
それ以外の条件は、先ほどの2.のベンチマークと同じです。


結果が以下です。IOPS(4k)から。

ebs * 1 ebs * 2 ebs * 4 ebs * 8 ebs * 16
sequential read 20942 22552 23313 26369 26673
sequential write 4980 6616 7055 8981 16939
randam read 375 1644 10912 26643 26002
randam write 119 430 1436 1148 2034


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

ebs * 1 ebs * 2 ebs * 4 ebs * 8 ebs * 16
read 106.325 122.6 131.364 131.727 131.807
write 46.168 95.129 118.033 118.611 119.533


今度は明らかに、EBSボリュームのデバイス本数が少ない場合において、ランダムアクセスの性能が落ちました。また、ランダムライトについては本数を増やしても大きく改善はしておらず、キャッシュから溢れる量が大きくなったのでしょうか。
EBSボリュームの本数を増やすことで、5GBのファイル対象のケースと同じような性能値に近づいていくのは、EBSボリュームの利用本数に比例する形で、使えるキャッシュの容量が増えるのかもしれません。
また、Bandwidthについては、Readで多少値は落ちていますが、大きく変化は見られないですね。(バックエンドとの1000Mbpsのスループットの制限でキャップされているみたいですね。)


では、EBSボリュームのサイズを増やせばどうなるのでしょうか？
というケースは、また次回のエントリとして、次はfioで扱うファイルサイズをさらに増やして確認してみます。

4. c1.xlargeでfioで扱うサイズを50GB, 100GBに変更

fioコマンドで扱うファイルサイズをさらに大きく(50GBに変更)して先ほどと同じベンチマークを行います。
(fioのruntimeオプションを"64"(sec)に変更して、実行しています。)


尚、さっきの15GB対象のベンチマークで、EBSボリューム2本のRAID0までは、ランダムアクセスで影響が出てIOPS値が落ちていたため、今回はEBSボリューム{4, 8, 16}本(RAID0)のランダムアクセス(IOPS)を対象としてみます。(あと、EBSボリュームを1本あたり20GBで作ったので、3本以上まとめないと50GBも書き込めない...ｗ)


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

ebs * 4 ebs * 8 ebs * 16
randam read 1620 3774 6443
randam write 513 736 2367


やはり、扱うファイルサイズが5GBや15GBのケースと比べて、IOPS値が落ちてきました。やはりキャッシュから溢れる量が多くなると、ハードディスクっぽいパフォーマンスに近づいていきますね。

ただ、やはり扱うファイルサイズが大きくなれば大きくなるほど、EBSボリュームをRAIDで束ねる数は多ければ多いほど、良いパフォーマンスが出る結果となっています。

おまけ

最後に、fioで扱うファイルサイズを100GBまで増やしてみて、EBSボリューム16本のRAID0で実行してみました。fioコマンドのruntimeオプションを"128"(sec)に変更して実行してみます。

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

ebs * 16
randam read 2439
randam write 1056


想定通りですが、扱うサイズが少量のものと比べて、パフォーマンスがどんどんハードディスクに近い値に近づいていきます。

まとめ

  • 一度扱うファイルサイズが小さいときは、SSDっぽいキャッシュ(？)のおかげで、ただのディスクとは思えないようなパフォーマンスを出してくれる。(IOPS)
    • EBSボリューム単体での利用が最もコストパフォーマンスに優れている。
    • RAID0で2本束ねるとランダムアクセスのパフォーマンスは良い。束ねてもコスパ的にも4本までかな。
    • たまたまかもしれないが、c1.mediumのインスタンスではランダムライトが安定しなかった。(IOPS)
  • 一度に扱うファイルサイズが増えてくると、ハードディスクっぽいパフォーマンスまで落ちてくる。
    • 扱うファイルサイズの増加に対しては、EBSボリュームを束ねる本数を増やすことが効果的。
  • Bandwidthについては、インスタンスタイプを変えても、影響はそれほどなさそう。
    • 束ねる数(RAID0)についても、Readなら2本、Writeでも4本で、ほぼMax値に到達する。
  • EBSボリュームは、I/Oリクエスト数でも課金されるので、ベンチマークで負荷かけまくると、"クラウド破産"に一直線なので、ベンチマークでのご利用は計画的に...

次回予告

続いて、以下についての結果をエントリにまとめます。

  • EBSボリュームのサイズを増やして、ベンチマークにどのくらい影響するか調べる。(キャッシュ的なヤツの使える範囲の増分があるかどうか。)
  • EBSのProvisioned IOPS(プロビジョンドIOPS)だと、どのような結果になるか確認する。


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

追記

続編を書きました。

あわせて読みたい



まとめ


クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

rx7 読者になる

関連記事
コメントを書く