トップ > IT > 噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた

噂の高速SSDを積んだAmazon EC2インスタンスのI/Oベンチマークをとってみた

IT Linux CloudComputing

High I/O Instance ベンチマーク



先日、Amazon EC2で使える、2TB分のSSDを積んだ新しいインスタンスタイプ(High I/O Instances / High I/O Quadruple Extra Large Instance)が発表されました。
ディスクI/O性能が高速なインスタンスは初登場なので、I/Oがシビアに要求されるデータベース等の利用においては、期待を寄せちゃいますよねー。


というわけで、このSSDのディスクI/Oパフォーマンスがどのくらい速いのかを試してみちゃいました。厳密なベンチマークではないですが、参考になれば幸いです。


・・・ちなみに、過去のベンチマークエントリもあわせてどうぞ。

ベンチマーク対象

ベンチマークをかける対象は、もちろん発表されたばかりの「High I/O Quadruple Extra Large Instance (hi1.4xlarge)」のEC2インスタンスです。

発表されているスペックは以下の通り。

High I/O Quadruple Extra Large Instance

60.5 GB of memory
35 EC2 Compute Units (16 virtual cores*)
2 SSD-based volumes each with 1024 GB of instance storage
64-bit platform
I/O Performance: Very High (10 Gigabit Ethernet)
Storage I/O Performance: Very High**
API name: hi1.4xlarge

*8 cores + 8 hyperthreads for 16 virtual cores


そのインスタンスで起動させるAMIは、「Amazon Linux AMI 2012.03」の64bitにしてみました。


# cat /proc/version
Linux version 3.2.21-1.32.6.amzn1.x86_64 (mockbuild@gobi-build-31004) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Sat Jun 23 02:32:15 UTC 2012


さて、肝心のディスク(ストレージ)ですが、エフェメラルディスクであっても、最近はAWS Management Consoleからアタッチとかできたりします。便利になりましたね。


というわけで、以下のような感じのディスク構成にしてみました。


SSDのデバイス2つに加えて、比較対象として、(小さいですが)10GBのEBSのデバイスも2つほどアタッチして、インスタンスを起動させます。

利用ツール(fio)のインストール/実行


EC2インスタンスが起動したら、次はベンチマークをかける環境を作ります。
と、その前に、起動したインスタンスで、デバイスが↑で設定した通りに認識しているかを確認します。

# ll /dev/sd*
lrwxrwxrwx 1 root root 5 Jul 25 12:44 /dev/sda1 -> xvda1
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdf -> xvdf
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdg -> xvdg
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdh -> xvdh
lrwxrwxrwx 1 root root 4 Jul 25 12:44 /dev/sdi -> xvdi

OK。認識できていますねー。


ちなみにCPUはIntel Xeon E5620が積まれていました。8core x2 (HT)で見えたので、CPU2つ分かな。

# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
stepping        : 2
microcode       : 0x13
cpu MHz         : 2400.084
cache size      : 12288 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 32
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 popcnt aes hypervisor lahf_lm arat dts
bogomips        : 4800.16
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

・・・・・15までズラッと


さて、閑話休題。
今回、ディスクI/Oを計測するツールは「fio」で測ってみることにしたので、そのツールを以下の要領でインストールします。

# wget http://pkgs.repoforge.org/fio/fio-2.0.7-1.rf.src.rpm

src.rpmをダウンロードして、、、

# yum -y install rpm-build libaio-devel gcc make

ビルドに必要になる関連パッケージをyumでインストール。

# rpmbuild --rebuild fio-2.0.7-1.rf.src.rpm

からのrpmbuildでRPMを作りーの、、、

# rpm -Uvh rpmbuild/RPMS/x86_64/fio-2.0.7-1.amzn1.x86_64.rpm

RPMをインストール。

# fio -v
fio 2.0.7

はい、ベンチマークできる環境が整いました。


ちなみに今回ベンチマークを取るのに使ったコマンドは以下の6つです。

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

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


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

# fio -filename=/data/test2g -direct=1 -rw=read -bs=32m -size=2G -numjobs=16 -runtime=10 -group_reporting -name=file1
# fio -filename=/data/test2g -direct=1 -rw=write -bs=32m -size=2G -numjobs=16 -runtime=10 -group_reporting -name=file1

SSDディスク単体のパフォーマンス

High I/O Quadruple Extra Large Instance では、1TBのSSDが2本積まれていますので、まずは1本単体の性能チェックをしてみます。

# fdisk /dev/sdf

まずは、パーティションを切って"/dev/sdf1"を作ります。(fdiskの使い方はググってちょ)
今回は、xfsファイルシステムで統一してベンチマークを取ってみたいので、、、

# yum -y install xfsprogs

安定のyumでxfs関連のパッケージをインスコ。

# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/sdf1

とりあえず、こんな感じで"/dev/sdf1"にxfsファイルシステムを作成すべくmkfsします。

# mkdir /data
# mount -t xfs -o noatime,logbufs=8 /dev/sdf1 /data

で、こんな感じのパラメータでマウントします。


ここで、先ほど書いた6つのfioコマンドを流して計測した結果が以下です。

Benchmark Type Bandwidth IOPS
4k, sequential read 270.1MB/s 67536
4k, sequential write 82.8MB/s 20696
4k, randam read 339.8MB/s 84945
4k, randam write 86.4MB/s 21608
32m, sequential read 623.5MB/s 19
32m, sequential write 564.7MB/s 17


なかなか優秀です。さすがSSD・・・。

SSD2つでRAID0(ストライピング)でのパフォーマンス

このインスタンスは、せっかくSSDデバイスが2つ付いているので、それならRAID0で束ねなきゃね、って発想は誰もが思うはずなので、こちらもベンチマークをとってみます。

というわけで、さっきの↑と同じ感じで準備します。
(当然、さっき使ったデータが残っていたりする場合は、umountして、パーティション情報を削除して、、、みたいなことをしましょう。)

# /sbin/mdadm --create /dev/md0 --chunk=256 --level=0 --raid-devices=2 /dev/sdf /dev/sdg
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md0
# mount -t xfs -o noatime,logbufs=8 /dev/md0 /data

こんな感じで、ソフトウェアRAID0で"/dev/md0"を作成、xfsファイルシステムを作成＆マウントって感じです。

で、、、先ほど同様に6コマンドを実行した結果は以下の通り。

Benchmark Type Bandwidth IOPS
4k, sequential read 442.4MB/s 110611
4k, sequential write 85.4MB/s 21345
4k, randam read 471.4MB/s 117840
4k, randam write 74.9MB/s 18719
32m, sequential read 1268.7MB/s 39
32m, sequential write 1129.5MB/s 35

なぜかライトは伸びていませんが、リードは4kでシーケンシャル/ランダムアクセスともに100,000IOPSを超えています！BSが4kで100,000IOPS超えはなかなか優秀じゃないでしょうか。素晴らしい・・・！

EBSボリューム2つでRAID0(ストライピング)でのパフォーマンス

せっかく比較対象で、EBSボリュームを2つアタッチしているので、こちらでもRAID0(ストライピング)を組んでベンチマークをとってみます。

# /sbin/mdadm --create /dev/md1 --chunk=256 --level=0 --raid-devices=2 /dev/sdh /dev/sdi
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md1
# mount -t xfs -o noatime,logbufs=8 /dev/md1 /data

さっき同様に準備。

からの6コマンドを実行した結果が以下。

Benchmark Type Bandwidth IOPS
4k, sequential read 100.0MB/s 24993
4k, sequential write 12.5MB/s 3113
4k, randam read 83.2MB/s 20803
4k, randam write 14.5MB/s 3614
32m, sequential read 198.9MB/s 6
32m, sequential write 69.1MB/s 2

意外とIOPSが出ております。ランダムリードでも20,000IOPSを超えている。
EBSボリュームって普通のハードディスクとかではなさそうな感じですね。SSDキャッシュとかがついてるのかしら？

通常のエフェメラルディスク2つでRAID0(ストライピング)でのパフォーマンス

せっかくなので、さらに同様な感じで、通常のエフェメラルディスク(これまでAWSで使えたもの)についても、同様にディスク2本でRAID0を組んでベンチマークを取ってみました。

使用したインスタンスタイプは、↑で使ったものに近いスペックであるHigh-Memory Quadruple Extra Large Instance(スペックは以下)を使用し、AMIは↑と同じものを使っています。

High-Memory Quadruple Extra Large Instance

68.4 GB of memory
26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each)
1690 GB of instance storage
64-bit platform
I/O Performance: High
API name: m2.4xlarge


ちなみにストレージ構成はこんな感じで、↑のインスタンスで使えるエフェメラルディスクをフルに使います。

OSが起動したら、早速RAID0なボリュームを作るべく準備します。

# /sbin/mdadm --create /dev/md0 --chunk=256 --level=0 --raid-devices=2 /dev/sdf /dev/sdg
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md0

# mkdir /data
# mount -t xfs -o noatime,logbufs=8 /dev/md0 /data

とはいっても、先ほどと同じ要領・パラメータです。

そして、6コマンドを実行した結果が以下となります。

Benchmark Type Bandwidth IOPS
4k, sequential read 32.8MB/s 8189
4k, sequential write 6.3MB/s 1590
4k, randam read 2.9MB/s 722
4k, randam write 3.2MB/s 796
32m, sequential read 185.1MB/s 5
32m, sequential write 85.1MB/s 2


こちらはシーケンシャルアクセスに関してはそこそこですが、ランダムアクセスとなると700〜800IOPSとなっているので、通常のディスクに近い感覚ですね。

ベンチマークのまとめ

というわけで、ベンチマーク結果をまとめたグラフがこちらになります。

IOPS

※ 単位はIOPS、ブロックサイズ4k

Bandwidth

※ 単位はMB/s

結論

そこそこのI/Oリソースが要求されるケースでも、これだけのシーケンシャル/ランダムアクセス性能があれば、ある程度は、このインスタンスで十分こなせるのではないでしょうか。IOPSで100,000以上、帯域幅は1GB/sを超えていますので。
今までのエフェメラルディスクで使えるディスクのI/Oパフォーマンスを比較しても、特にランダムアクセスに関してはかなり優秀な結果となっています。というわけで当然の結果ではありますが、、、

EC2で使えるSSDは速かった！


それでは！それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

参考



まとめ


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

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

rx7 読者になる

関連記事
コメントを書く