以前、「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた」でAmazon EC2で利用できるSSDボリュームのベンチマークを取った際に、EBSボリュームに関しても簡単に計測しているのですが、もう少し詳細に見てみようと思い、もうちょっと詳しく性能を計測してみました。(急いでいる方は最後のまとめを読むだけでOKですw)
実は、大昔(3〜4年くらい前)にも同じようなことを軽くやったのですが、結果がどこかにいってしまった&今はまた結果が違うかもなので、やってみた。
ベンチマークの目的は、EBSボリュームをソフトウェアRAIDで束ねた(ストライピング)場合に、どのくらいパフォーマンスが出せるのかという観点。
というわけで、色々な観点から性能を測ってみました。使ったツールは「噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた - 元RX-7乗りの適当な日々」の時と同様にfioです。
(シリーズもののエントリとして、しばらく続きますw)
1. c1.mediumでベンチマーク
以下がベンチマークを取得した際の環境です。
- 東京リージョン(ap-northeast)で実施。
- c1.medium (High-CPU Medium Instance) のインスタンスを利用。
- http://aws.amazon.com/jp/ec2/instance-types/ によると「EBS 最適化利用: 不可」となっています。
- 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) のインスタンスを利用。
- http://aws.amazon.com/jp/ec2/instance-types/ によると「EBS 最適化利用: 1000 Mbps」となっています。
先ほど同様の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も書き込めない...w)
結果が以下です。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)
- 作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2009/11/05
- メディア: 単行本
- 購入: 4人 クリック: 372回
- この商品を含むブログ (18件) を見る