« 2010年08月 | メイン | 2010年10月 »

2010年09月09日

Amazon EC2のEBSディスクは遅い?

アンタスでは、アプリケーションの動作・性能検証や、技術調査などで、8GBや16GB、32GBなどの大きめのメモリや大きめのディスク容量を必要とする環境が急ぎで必要な場合、Amazon EC2(Amazon Web Service, AWS)を使用することがあります。
必要なリソース分のサーバが簡単に起動できるのはとても便利です。
また、用件を終えたらそのOSはもう使用しないので、時間課金であるのも助かりますね。
最小限の設定はAMIに保存できますし。

先日、MySQL InnoDB Pluginの性能を評価しようと、tpcc-mysqlによるベンチマークテストを実施してみて気づいたことがありました。
それは「EBSディスクは遅い」ということです。

試した環境は以下。

Region: US East
AMI: カスタマイズしたCentOS 5.4のEBSブートOS
Instance: Extra Large (CPU 4Core, Memory 15GB)
OS: CentOS 5.4 (x86_64)

tpcc-mysqlで、warehouseを100(DBデータサイズは計9GBぐらい)としてベンチマークを実施したところ、例えば下記のようにNew-Orderなどの項目でNGとなり、有効な結果が得られません。

(all must be [OK])
[transaction percentage]
Payment: 45.00% (>=43.0%) [OK]
Order-Status: 3.33% (>= 4.0%) [NG] *
Delivery: 3.33% (>= 4.0%) [NG] *
Stock-Level: 4.17% (>= 4.0%) [OK]
[response time (at least 90% passed)]
New-Order: 30.19% [NG] *
Payment: 90.74% [OK]
Order-Status: 100.00% [OK]
Delivery: 100.00% [OK]
Stock-Level: 80.00% [NG] *

初期データのロード方法やEBSの作り方をいろいろ変えても状況は変わりません。
ひょっとしてディスクが遅いのかも、と思ってdbenchでディスクのベンチマークを実施してみたところ、、、

・1-a. Extra LargeでEBSブートインスタンスの場合

Throughput 40.7681 MB/sec 1 clients 1 procs max_latency=1279.961 ms

・1-b. Extra Largeで通常の(EBSブートではない)インスタンスの場合

Throughput 210.732 MB/sec 1 clients 1 procs max_latency=745.396 ms

ということで、なんと、EBSブートのほうは通常インスタンスの20%ほどの性能しかありません。

ちなみに、通常の(EBSブートではない)インスタンスでマウントしたEBSディスクの速度はというと、、、
以下はSmallインスタンスでdbenchした結果です。

・2-a. Smallインスタンスのローカルディスク


Throughput 97.4738 MB/sec 1 clients 1 procs max_latency=448.029 ms

・2-b. SmallインスタンスのEBSディスク


Throughput 27.9529 MB/sec 1 clients 1 procs max_latency=1352.467 ms

と、EBSディスクのほうは、ローカルディスクの30%ほどの性能しかありません。
(インスタンスタイプが違うものですみません。)

EBS、残念!
読み書きの激しいDBなどを使う方は要注意ですね。
EBSのストレージ装置についてはAmazonは非公開のようですが、どこかボトルネックになるような箇所があるのでしょう。
EC2については、「日本からだとネットワークが遅い」という話はよく聞いていましたが、「ディスクが遅い」という話は聞いたことがなかったので驚きでした。
と思ったら、同じようにベンチマークを実施された方がいらっしゃっいました。
ずばり、EBSは遅い、と書かれていますね。

RX-7乗りの適当な日々 - Amazon EC2性能検証!気になるパフォーマンスをインスタンスタイプやリージョン毎に計測・比較してみた:
http://d.hatena.ne.jp/rx7/20100722/p1

海老澤澄夫の個人ブログ - EC2のEBSは期待外れ:
http://sebisawa-private.blogspot.com/2010/09/ec2ebs.html

(参考)IT Pro - ITベンダー、アマゾン(2) 〜低料金と使い勝手の良さを両立
http://itpro.nikkeibp.co.jp/article/COLUMN/20081202/320506/?ST=cloud&P=2

--
ついでに、通常のインスタンスで、EBSではなく外付けっぽい追加デバイスの速度はどうかというと、、、
以下はExtra Largeインスタンスでdbenchした結果です。

・3-a. Extra Largeインスタンスのローカルディスク


Throughput 247.074 MB/sec 1 clients 1 procs max_latency=1392.021 ms

・3-b. Extra Largeインスタンスの外付けディスク(/dev/sdb)


Throughput 101.833 MB/sec 1 clients 1 procs max_latency=365.433 ms

EBSよりはマシでそこそこの速度が出ていますが、ローカルディスクに比べると、外付け(っぽい)ディスクのほうは40%ほどの性能しかありません。

--
ディスクベンチマークツールdbenchについては、以前、「ベンチマークツールdbenchを使用したディスク性能の評価」という記事を書きました。
http://antas.jp/blog/ina/archives/2008/05/disk_benchmark_dbench.html

ここで、「物理的に異なるディスクのベンチマークをとるときは、-cオプションをつける」と書いのですが、、、
今回の調査の過程で-cオプションではダメで、-Dオプションが必要なことがわかったので記述を修正しました。
すみません。

--
ちなみに、今回はなぜEBSを使おうとしたかというと、、、

まず、tpcc-mysqlの初期データのロードはwarehouse 100で2時間弱、warehouse 50で40分程度、とすごく時間がかかります。
また、tpcc-mysqlのベンチマークを実施すると、DBデータに不可逆の変更が加わるため、同時接続やパラメータなど条件をいろいろ変えてテストするときは、毎回初期データの状態に戻す必要があります。
それで、初期データをAMIかEBSに入れておいて、ひとつのテストを終えるごとにそのインスタンスをTerminateして、新しいインスタンスをCreateすれば、条件の違うテストを効率よく実施できると考えました。
それで、AMIのローカルディスクは10GBしかないので、warehouse 100のデータを投入するには少しディスクが足りなので、だったら任意のディスク容量を指定できるEBSを使うといいじゃないか、ということで、EBSにしました。
EBSブートOSは通常のAMIよりも起動が速いのがうれしいですね。

結局、今回のtpcc-mysqlによるMySQL InnoDB Pluginのベンチマークテストは、warehouseを当初の半分の50(DBデータサイズは計4.7GB)とし、AMI内に初期データを押しこめ、AMIのローカルディスクのみを使用して実施することになりました。

MySQL InnoDB Pluginのベンチマークテストについては、SH2さんが詳しく書かれていますが、僕も何か新しい情報が得られればここに書きます。

SH2の日記 - tpcc-mysqlによるMySQLのベンチマーク:
http://d.hatena.ne.jp/sh2/20090212