Amazon EC2は立ち上げるインスタンスによって微妙なパフォーマンス差が出ると言われていて、複数回、インスタンスを立ち上げたり、捨てたりして、良いインスタンスを得ることを”Amazon EC2インスタンスガチャと”呼ばれています。
そのパフォーマンス差は、どれくらいなのか？気になったので測ってみました。
検証環境はこんな感じです。
AMI ID: CentOS 7 x86_64 (2014_09_29) EBS HVM-b7ee8a69-ee97-4a49-9e68-afaee216db2e-ami-d2a117ba.2 (ami-89634988)
Instance Type: c3.xlarge
１）Magnetic(standard)
２）Magnetic(standard) + EBS-Optimized
３）General Purpose (SSD) + EBS-Optimized
４）Provisioned IOPS (IOPS 1000) + EBS-Optimized
fioでベンチマーク
まず。fioでIOPSを調べます。
fioをインストール。
# yum -y install epel-release.noarch
# yum -y install fio
fioをランダムリード・モードで実行。
# fio -rw=randread -bs=4k -size=1G -numjobs=32 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -iodepth=32 -iodepth_batch=32 -group_reporting -name=randread
インスタンスによって差異が出てきました。
dbenchでベンチマーク
違うベンチマークツールでスループットを調べてみます。ベンチマークには、dbench（https://dbench.samba.org/）を使います。
dbenchをインストール。
# yum -y install dbench
dbenchを実行。
# dbench 5 -D . > dbench.log
まとめ
インスタンスによっては、ディスク性能でけっこうな差がでてしまいました。Magnetic(standard)はAWSガチャによってかなりの性能差が出ます。EBS-Optimizedをつけても変わりません。
一見、General Purpose (SSD)が良い結果を出しているように見えますが、バーストしている状態だと思われます。数十回ベンチマークをかけたら仕様どおりガクンと性能が落ちました。
(最も低い結果で iops=305, Throughput 75.5844 MB/sec, max_latency=7719.676 ms ほど)
長時間連続して負荷がかかる環境には使わないほうがよいでしょう。
逆に、バッチ処理などの用途では威力を発揮しそうです。
General Purpose (SSD)のバーストについては、こちらの記事が参考になります。
『Amazon EBSのGeneral Purpose(SSD)のバーストルールを理解する ｜ Developers.IO』
http://dev.classmethod.jp/cloud/study-ebs-ssd-burst-rule/
Provisioned IOPSはまあまあ安定しています。
ちなみにUnixBenchも試してみましたが、これは主にCPUへのベンチマークツールなので、差は殆どありませんでした。
MySQLのマスターサーバなどでディスク性能が要求される用途では、Provisioned IOPSを選ぶと安心できるでしょう。
※ 2014/10/24 General Purpose (SSD) + EBS-Optimized と Provisioned IOPS (IOPS 1000) + EBS-Optimized のベンチマークを追記。
