パブリッククラウドサービス Amazon EC2 の性能検証レポート

パブリッククラウドサービス Amazon EC2 の性能検証レポート
<日付 2011/02/28>
システムディベロップメントグループ
並河 祐貴
はじめに
大手パブリッククラウドサービスの 1 つに Amazon Web Services がある。Amazon Web Services
は、仮想サーバを 1 時間単位課金の従量制で利用できる Amazon EC2 や、高信頼性のオンライン
ス ト レ ー ジ を 1GB 単 位 か ら の 従 量 制 課 金 で 利 用 で き る Amazon S3 な ど を 中 心 と し た 、
IaaS(Infrastructure as a Service)の代表格である。
現在も定期的に続々と新しいサービスや機能を発表し、Amazon Web Services は日本でも益々
注目を集める存在である。本稿では、この Amazon Web Services の中でも、特に仮想サーバ部分
である Amazon EC2 について、主に性能に関する調査結果を記す。通常の物理サーバで確認した
性能と比較することで、Amazon EC2 から既存物理サーバからの移行や、もしくは既存物理サーバ
から Amazon EC2 への移行、Amazon EC2 を利用した新規構築の際のサーバ選定の参考になれば
幸いである。
本研究の目的
パブリッククラウドサービスを使う目的の 1 つは、部分的なコストの削減である。アメーバのような、
既に巨大なメディアサービスを自社インフラで運用する弊社が、パブリッククラウドサービス使う機会
は、現時点でそう多くはないかもしれないが、既存のデータと連携しないような新規サービスをリリ
ースする際は、例えば以下のコスト的な観点により、利用するシーンが存在すると考える。
* サービスインしてみないと必要なサーバ台数がまったく計算できない場合
多くの Web サービスがこの悩みに遭遇していると思われるが、通常、新しい Web サービスはサー
ビスインしてみないと、どのくらいアクセスがある(ユーザにヒットする)かは、なかなか正しく予想し辛
いものである。ヒットするかわからない、新しい Web サービスに多額の初期投資(多くのサーバやネ
ットワークの準備)は賭けに出るようなものだが、全く準備しないというわけにもいかず、サービスを
始める際には、通常何かしらの設備投資が必要となる。
そこで、クラウドを利用すれば、アクセス状況を見ながら、サーバ数を増減させることが容易かつ
低コストで実現出来るため、例えばサービスイン時はクラウドサービスを利用して負荷状況を確認し
つつサーバ台数を調整しながら運用し、運用が落ち着いた頃に自社インフラへ移行することで、正
しいキャパシティプランニングが可能となる。
* 季節モノ(クリスマス・お正月など)やキャンペーン等で一時的にしか多くのサーバを必要としない
場合
例えば、お正月向けのサービスであれば、お正月のみ本稼動させていれば良く、それ以外の時
期はシステムを縮退させておけば良い。12 月および 1 月はサーバ 20 台必要で、それ以外の時期
は 1 台で良い場合、サーバの増減に柔軟に対応できるクラウドサービスの利用は相性が良い。
また、上記以外にも、自社インフラを持たないグループ会社や、その他投資しているスタートアッ
プのベンチャーにおいては、初期費用無しで 1 時間単位($0.02/1hour)からサーバを借りることの
出来る、このパブリッククラウドサービスを検討する価値があると考える。
しかし、Amazon EC2 では、公表している公称スペック(以降、計測・比較対象の項にて紹
介)においては、CPU スペックが ECU といった独自単位であったり、I/O 性能が非定量的
かつ相対的な 4 段階評価である等、初めて利用するユーザにとっては、サーバの選定・サ
イジングがし辛い問題が現状としてあげられる。
そこで本稿では、実際に物理サーバに対して扱うようなベンチマークツールを利用して、
Amazon EC2 の仮想サーバ上で、CPU やディスクに対する性能調査を行った。本稿の調査
結果と、普段利用している物理サーバでのベンチマーク結果と照らし合わせることで、
Amazon EC2 からの移行、もしくは Amazon EC2 への移行時においての、サーバサイジン
グの材料になると考える。
計測・比較対象
今回、計測・比較を行うのは、現時点(2011/02)で利用可能となっている、以下の 4 Region
(サーバの設置ロケーション)、および Amazon EC2 で提供されている 10 Instance type (サ
ーバの種類・スペック)となる。
Region (現在利用可能なリージョン全て)
* us-east (アメリカ東海岸)
* us-west (アメリカ西海岸)
* ap-southeast (アジア・シンガポール)
* eu-west (ヨーロッパ西部)
Instance Type (現在利用可能なインスタンスタイプ全て)
Instance
Price
(per hour)
Memory
CPU
Disk
I/O
performance
Micro Instances
Micro Instance
[t1.micro]
$0.02
Small Instance
[m1.small]
$0.085
Large Instance
[m1.large]
$0.34
Extra Large
Instance
[m1.xlarge]
$0.68
High-CPU
Medium Instance
[c1.medium]
High-CPU
Extra Large
Instance
[c1.xlarge]
$0.17
$0.68
613 MB
Up to 2 ECU
(for short periodic bursts)
Standard Instances
1 ECU
1.7 GB (1 virtual core
with 1 ECU)
4 ECU
7.5 GB (2 virtual cores
with 2 ECU each)
8 ECU
15 GB (4 virtual cores
with 2 ECU each)
High-CPU Instances
5 ECU
1.7 GB (2 virtual cores
with 2.5 ECU each)
7 GB
20 ECU
(8 virtual cores
with 2.5 ECU each)
EBS
storage
only
Low
160 GB
Moderate
850 GB
High
1690 GB
High
350 GB
1690 GB
Moderate
High
High-Memory Instances
High-Memory
Extra Large
Instance
[m2.xlarge]
High-Memory
Double Extra
Large Instance
[m2.2xlarge]
High-Memory
Quadruple Extra
Large Instance
[m2.4xlarge]
Cluster Compute
Quadruple Extra
Large Instance
[cc1.4xlarge]
$0.50
17.1 GB
6.5 ECU
(2 virtual cores
with 3.25 ECU each)
850 GB
Moderate
$1.20
34.2 GB
13 ECU
(4 virtual cores
with 3.25 ECU each)
850 GB
High
$2.40
68.4 GB
26 ECU
(8 virtual cores
with 3.25 ECU each)
1690 GB
High
1690 GB
Very High
(10 Gigabit
Ethernet)
$1.60
Cluster Compute Instances
33.5 ECU
(2 x Intel Xeon X5570,
23 GB
quad-core "Nehalem"
architecture)
※ 1ECU (EC2 Compute Unit)は、Xeon もしくは Opteron の 1.0～1.2GHz 相当。
※ Price(価格)は、us-east で Linux プラットフォームを稼動させた場合の 1 時間あたりの料金。
(2011/02 現在)
各 Region からのネットワークレイテンシ
計測方法
各 Region にて、Amazon EC2 の仮想サーバを起動し、日本で割と普及しているとされる、
OCN 系の ISP 網内および Softbank 系の ISP 網内のクライアントマシンより、ping(ICMP
Echo)を 10 回実行し、RTT(Round Trip Time)の平均値を取った。単位は msec となる。
実行結果
from OCN 系 ISP
from Softbank 系 ISP
us-east
183.920
178.129
us-west
129.306
124.487
eu-west
278.324
262.590
85.716
77.956
ap-southeast
ap-southeast
eu-west
from Softbank系ISP
from OCN系ISP
us-west
us-east
0
50
100
150
200
250
300
上記の結果より、日本国内からのネットワークレイテンシについては、"ap-southeast (ア
ジア・シンガポール)"が最も小さいという結果となった。
日本国内向けの Web サービスを展開する際は、この ap-southeast の Region を利用する
ことが、他 Region と比べて、最もユーザに対して良いレスポンスが返りやすいということ
となる。
各 Instance type での CPU ベンチマーク
計測方法
各 Instance type の仮想マシンを起動し、それぞれのマシン上で、CPU ベンチマークソ
フトである「姫野ベンチマーク」(http://accc.riken.jp/HPC/HimenoBMT.html)を利用して
測定を行った。測定の際に利用したものは、"C, static allocate version"の M サイズのソー
スコードを実機でコンパイルしたものである。
以下ベンチマークの対象は、Amazon EC2 のインスタンス(10 種類)となり、結果値の単
位は"MFLOPS"である。
実際にインスタンスで利用されていた CPU
検証を行う際に、実際に Amazon EC2 の各 Instance type の仮想サーバ上にて、
"/proc/cpuinfo"の情報から確認した CPU モデルは以下の通りであった。
Instance type
CPU Model
t1.micro
Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 1core
m1.small
Dual-Core AMD Opteron(tm) Processor 2218 HE x 1core (us-east
のみ)
Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 1core (上記以外)
m1.large
Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 2cores
m1.xlarge
Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 4cores
c1.medium
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz x 2cores
c1.xlarge
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz x 8cores
m2.xlarge
Intel(R) Xeon(R) CPU X5550 @ 2.67GHz x 2cores
m2.2xlarge
Intel(R) Xeon(R) CPU X5550 @ 2.67GHz x 4cores
m2.4xlarge
Intel(R) Xeon(R) CPU X5550 @ 2.67GHz x 8cores
cc1.4xlarge
Intel(R) Xeon(R) CPU X5570 @ 2.93GHz x 16cores
実行結果
Instance type
MFLOPS measured
(vCore)
t1.micro
271.320092
(x1)
m1.small
324.676111
(x1)
c1.medium
774.602322
(x2)
m1.large
892.176316
(x2)
m1.xlarge
880.100758
(x4)
c1.xlarge
1044.821975
(x8)
m2.xlarge
1544.973882
(x2)
m2.2xlarge
1600.39996
(x4)
m2.4xlarge
1572.732919
(x8)
cc1.4xlarge
1676.395005
(x16)
cc1.4xlarge
m2.4xlarge
m2.2xlarge
m2.xlarge
c1.xlarge
m1.xlarge
m1.large
c1.medium
m1.small
t1.micro
0
200
400
600
800
1000
1200
1400
1600
1800
姫野ベンチマークでは、単純なシングルコアでの性能値が算出されているように見受け
られるため、実際の総合的なベンチマークとしては、上記の実測値と Core 数の積と考えら
れる。
上記の結果は、概ね想定通りの結果ではあるが、公称値 5ECU(2.5ECU x 2)の c1.medium
より、4ECU(2ECU x 2)の m1.large の性能値が良いことが意外であった。尚、CPU の型番
からは、c1.medium は Xeon E5410(2.33GHz)で、m1.large は Xeon E5430(2.66GHz)とな
るため、この結果は納得がいく。
尚、m1.small については、他インスタンスタイプとの比較値、および性能テスト中の
OS 上では、steal 値が 60%前後だったことを考慮すると、1 つの CPU を、2.5～3 つのイ
ンスタンスで共有しているように見受けられる。
参考: 私物のサーバ(CPU)での姫野ベンチマーク結果
上記と同様のテストを、私物の物理サーバ(Linux)で行ったところ以下のような結果とな
った。比較の参考となれば幸いである。
CPU model
MFLOPS measured
Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz x 2cores
1503.59
AMD Phenom(tm) 9950 Quad-Core Processor x 4cores
1192.06
AMD Athlon(tm) 64 Processor 3500+ x 1core
814.56
Dual-Core AMD Opteron(tm) Processor 1210 x 2cores
725.76
Intel(R) Pentium(R) III CPU family 1.13GHz x 2CPUS
121
各 Instance type でのディスク I/O ベンチマーク
計測方法
各 Instance type の仮想マシンを起動し、それぞれのマシン上で、ディスク I/O のベンチ
マ ー ク を 計 測 す る べ く 「 dbench 」 (http://dbench.samba.org/) と 「 hdparm 」
(http://hdparm.sourceforge.net/)を利用して測定を行った。
hdparm は、ディスクの読み込みスループット計測がメインとなり、ルートパーティショ
ンのディスク(/dev/sda1)、エフェメラルディスク(/dev/sdb)、EBS ボリュームとしてアタッ
チしたディスク(/dev/sdf1)の 3 種類に対して計測を実行した。ここでの結果値は、"-t"オプ
ションを利用し、連続で 5 回実行した平均値とする。(以下は、参考までに、hdparm の man
より、"-t"オプションに関する記載を引用した。)
-t
ベンチマーク及び比較目的で、デバイス読み込みを測定する。有意な結果を得るためには、少なくとも数メガバイト
の空きメモリがあり、他にアクティブなプロセスがない状態で、この操作を 2, 3 回繰り返すべきである。これはデ
ータのキャッシュがない状態から、バッファキャッシュを通してディスクを読み出す速度を表示する。これは、ファ
イルシステムのオーバーヘッドなしに、そのドライブが Linux でどれだけ連続データ読み込み速度を維持できるか
を測定するものである。測定の正確さを上げたいのであれば、 -t の実行の間に BLKFLSBUF ioctl を使ってバッ
ファキャッシュをクリアする。
※ hdparm の man より引用
また、dbench のベンチマークについては、ルートパーティションのディスク(/dev/sda1)
および、EBS ブートで稼動させたインスタンスのルートパーティションのディスク(つまり
EBS ボリューム)に対して、計測を実行した。尚、4clients からの書き込みを想定した設定
を行った。
hdparm の実行結果
以下が、instance-root タイプの各インスタンスに対し、上記手順にて hdparm を行った
実行結果となる。結果値の単位は MB/sec である。
/dev/sda1
m1.small
/dev/sdb
/dev/sdf1
252.872
275.708
66.86
271.04
306.462
66.152
m1.large
153.548
166.746
75.746
m1.xlarge
196.758
170.98
67.002
c1.xlarge
196.282
197.344
75.318
m2.xlarge
577.024
375.936
79.056
m2.2xlarge
612.69
432.278
86.486
c1.medium
m2.4xlarge
m2.2xlarge
m2.xlarge
/dev/sdf1
/dev/sdb
/dev/sda1
c1.xlarge
m1.xlarge
m1.large
c1.medium
m1.small
0
100
200
300
400
500
600
700
I/O performance が公称値では Moderate となっている m1.small と c1.medium のイン
スタンスの測定結果が、思いのほか、良い結果となった。また、m2 系の「High-Memory
Instances」のパフォーマンスも値が良い結果となっている。
ルートパーティションのディスク(/dev/sda1)とエフェメラルディスク(/dev/sdb)について
は、それほど大きな差が見られないため、同等の性能を持つディスクと見てよいと考える。
EBS ボリュームについては、公表されている情報では、特に区分けがないため。どのイ
ンスタンスタイプでも同様の結果となる想定であったが、思いのほか結果にややバラつき
が出ている。また、上位のインスタンスで良い結果が出ている傾向となっており、EBS ボ
リュームのスループットは概ね"65～85MB/sec"となる。
次に、以下は EBS タイプのインスタンスに対する hdparm の測定結果となる。
「Cluster Compute Instance」である"cc1.4xlarge"のインスタンス、および「マイクロイ
ンスタンス」の"t1.micro"インスタンスが、EBS AMI ベースのものしか準備されていない
ため、以下にて簡単にベンチマークを行い比較した。結果値の単位は MB/sec である。
尚、比較対象となっている"c1.medium”、"m1.large"、"m2.xlarge"について、エフェメラ
ルディスク(/dev/sdb)や、EBS ボリュームとしてアタッチしたディスク(/dev/sdf1)は、上記
で同様の測定を行っているため、ここでは省略する。また、"t1.micro"についてもエフェメ
ラルディスク(dev/sdb)が存在していないため、計測は行っていない。
/dev/sda1
t1.micro
/dev/sdb
/dev/sdf1
85.12
-
81.798
c1.medium
77.212
-
-
m1.large
74.126
-
-
m2.xlarge
86.244
-
-
cc1.4xlarge
140.594
234.084
84.992
m2.xlarge
m1.large
/dev/sdf1
/dev/sdb
/dev/sda1
c1.medium
t1.micro
cc1.4xlarge
0
50
100
150
200
250
ここでは、"cc1.4xlarge"タイプが非常に良い実行結果が出ている。ただ、エフェメラルデ
ィスク(dev/sdb)については、m2 系(High-Memory Instances)のインスタンスに付いている
エフェメラルディスクの性能より低い結果となっており、最上位のインスタンスではある
が、この点には注意が必要となる。
EBS ボリュームについては、他のインスタンスタイプ同様それほどスループットは大きく
出ていないが、レイテンシも低く、終始安定した書き込みを行っている感覚を受けた。(結
果毎にバラつきが出ない。)
dbench の実行結果
以下が、instance-root タイプの各インスタンスに対して上記手順にて dbench を行った
実行結果である。Throughput の単位は MB/sec、max_latency の単位は ms となる。
Throughput
max_latency
m1.small
83.3971
3152.082
c1.medium
144.739
1847.075
m1.large
172.128
4875.352
m1.xlarge
197.14
2492.915
c1.xlarge
198.618
3100.112
m2.xlarge
276.09
4059.14
m2.2xlarge
293.215
3569.074
m2.4xlarge
313.331
3623.604
350
6000
300
5000
250
4000
200
3000
150
2000
100
1000
50
0
0
m1.small c1.medium m1.large m1.xlarge c1.xlarge m2.xlarge m2.2xlargem2.4xlarge
Throughput
max_latency
公称されているスペックでの I/O パフォーマンスは、"Moderate"、"High"、"Very High"
の 3 種類であるが、
同じ"Moderate"の"m1.small"と"c1.medium"、"m2.xlarge"の 3 つでも、
割と差がある感じとなった、尚、公表スペックの I/O パフォーマンスは、ディスクだけでは
なくネットワークの I/O も含まれていると考えられる。
また、m2 系の「High-Memory Instances」は、レイテンシが少々高めではあるがスルー
プット結果は良く、高パフォーマンスを出しているといえる。
次に、以下は EBS タイプのインスタンスに対する dbench の測定結果となる。
Throughput
max_latency
t1.micro
40.6677
2520.518
c1.medium
45.1286
692.144
m1.large
39.8205
674.802
m2.xlarge
69.861
1167.158
cc1.4xlarge
137.968
382.083
160
3000
140
2500
120
2000
100
80
1500
60
1000
40
500
20
0
0
t1.micro
c1.medium
m1.large
Throughput
m2.xlarge
cc1.4xlarge
max_latency
この結果から、EBS ボリュームを持つディスクタイプについては、"t1.micro”以外は、レ
イテンシが全体的に低く高レスポンスだが、instance-root タイプ(先ほどの結果のもの)ほど
のパフォーマンスは出ていないことがわかった。ただ、この結果においても、他インスタ
ンスと比べて、"cc1.4xlarge"タイプの結果が非常に優れていることがわかる。
おわりに
本稿では、Amazon EC2 の各 Region、および各 Instance type について、ネットワーク
レイテンシ、CPU、ディスクに関する性能調査を行った。調査結果より、それぞれの Instance
type において、CPU およびディスク性能の定量的な数値が計測できたことで、既存物理サ
ーバとの比較材料とすることができると考える。
参考図書にも記しているが、パブリッククラウドサービスはシステム上のメリットとデ
メリットをきちんと把握した上で利用することで、大きなコストメリットが生まれる場合
がある。制約が少なからずあるため、特に大規模な Web サービスにおいては、パブリック
クラウドサービスだけで事業・サービスのインフラが完結することは少ないが、ハイブリ
ッドに利用することで前述のメリットを享受できるケースが少なくないため、今後ウォッ
チを続け、適材適所で有効活用できればと考えている。
補足: 参考図書
* [書籍] 並河祐貴, 安達輝雄: クラウド Amazon EC2/S3 のすべて ～実践者から学ぶ設計/
構築/運用ノウハウ～, 日経 BP 社 (2009)