元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2013/04/16

by grover_net

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


以前、「噂の高速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) のインスタンスを利用。
  • 20GBStandard 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 * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read1600019408182072069329066
sequential write542160616083847811380
randam read1369522821244902958231047
randam write6450123451736101935139

f:id:rx7:20130416211202p:image:w480


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


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read94.935138.043144.395146.329145.51
write50.94192.38116.796121.771122.54

f:id:rx7:20130416211203p:image:w480


まず、数値が全体にただのディスクとは思えないレベルですね。FlashCacheのようなSSDを使ったキャッシュ機構の仕組みが介在していそうな感じです。一度に5GBくらいのファイルサイズの書き込みだと、結構キャッシュが効いてくるのでしょうか。

どの程度のパフォーマンスが欲しいのかによりますが、EBSボリューム2本のRAID0でもバランスの良いパフォーマンスが出そうな雰囲気です。


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


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

次にインスタンスタイプを変えて、ベンチマークをとってみました。条件は以下の通りです。

先ほどのc1.mediumでのベンチマークからの変更点は以下の通りです。


先ほど同様のfioコマンドを実行した結果が以下です。

IOPS(4k)から。


ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read1673017854198302831529210
sequential write537259396465791811894
randam read1431124287306133018030213
randam write595611769207132294023253

f:id:rx7:20130416211204p:image:w480


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

ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read104.978142.768144.378143.793144.915
write48.41694.625120.106121.975121.477

f:id:rx7:20130416211205p:image:w480


インスタンスタイプを大きくして、より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 * 1ebs * 2ebs * 4ebs * 8ebs * 16
sequential read2094222552233132636926673
sequential write498066167055898116939
randam read3751644109122664326002
randam write119430143611482034

f:id:rx7:20130416211206p:image:w480


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

ebs * 1ebs * 2ebs * 4ebs * 8ebs * 16
read106.325122.6131.364131.727131.807
write46.16895.129118.033118.611119.533

f:id:rx7:20130416211207p:image:w480


今度は明らかに、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 * 4ebs * 8ebs * 16
randam read162037746443
randam write5137362367

f:id:rx7:20130416211208p:image:w480


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

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


おまけ

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

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

ebs * 16
randam read2439
randam write1056

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


まとめ

  • 一度扱うファイルサイズが小さいときは、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)だと、どのような結果になるか確認する。

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


追記

続編を書きました。


あわせて読みたい



まとめ


htairahtaira 2013/04/20 10:49 ところでインスタンス内のIOスケジューラーには何を使ったのでしょうか?cfq?deadline?

rx7rx7 2013/04/20 13:16 ↑に記載していますが、noopですよー。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。


オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)