【研究課題レポート抜粋】パブリッククラウドサービスAmazon EC2の性能検証レポート | サイバーエージェント 公式エンジニアブログ
※これはをシステムエンジニアのNamikawaさんが優秀賞を受賞した第6回研究課題レポート(2011年3月提出)からの抜粋です。

 はじめに

大手パブリッククラウドサービスの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 (現在利用可能なインスタンスタイプ全て)


InstancePrice (per hour)MemoryCPUDiskI/O performance
Micro Instances
Micro Instance [t1.micro]$0.02613 MBUp to 2 ECU (for short periodic bursts)EBS storage onlyLow
Standard Instances
Small Instance [m1.small]$0.0851.7 GB1 ECU (1 virtual core with 1 ECU)160 GBModerate
Large Instance [m1.large]$0.347.5 GB4 ECU (2 virtual cores with 2 ECU each)850 GBHigh
Extra Large Instance [m1.xlarge]$0.6815 GB8 ECU (4 virtual cores with 2 ECU each)1690GBHigh
High-CPU Instances
High-CPU Medium Instance [c1.medium]$0.171.7 GB5 ECU (2 virtual cores with 2.5 ECU each)350 GBModerate
High-CPU Extra Large Instance [c1.xlarge]$0.687 GB20 ECU (8 virtual cores with 2.5 ECU each)1690GBHigh
High-Memory Instances
High-Memory Extra Large Instance [m2.xlarge]$0.5017.1 GB6.5 ECU (2 virtual cores with 3.25 ECU each)850 GBModerate
High-Memory Double Extra Large Instance [m2.2xlarge]$1.2034.2 GB13 ECU (4 virtual cores with 3.25 ECU each)850 GBHigh
High-Memory Quadruple Extra Large Instance [m2.4xlarge]$2.4068.4 GB26 ECU (8 virtual cores with 3.25 ECU each)1690GBHigh
Cluster Compute Instances
Cluster Compute Quadruple Extra Large Instance [cc1.4xlarge]$1.6023 GB33.5 ECU (2 x Intel Xeon X5570, quad-core "Nehalem"
architecture)
1690GBVery High (10 Gigabit Ethernet)


※ 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系ISPfrom Softbank系ISP
us-east183.920178.129
us-west129.306124.487
eu-west278.324262.590
ap-southeast85.71677.956


$サイバーエージェント 公式エンジニアブログ

上記の結果より、日本国内からのネットワークレイテンシについては、"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 typeCPU Model
t1.microIntel(R) Xeon(R) CPU E5430 @ 2.66GHz x 1core
m1.smallDual-Core AMD Opteron(tm) Processor 2218 HE x 1core (us-eastのみ)
Intel(R) Xeon(R) CPU E5430 @ 2.66GHz x 1core (上記以外)
m1.largeIntel(R) Xeon(R) CPU E5430 @ 2.66GHz x 2cores
m1.xlargeIntel(R) Xeon(R) CPU E5430 @ 2.66GHz x 4cores
c1.mediumIntel(R) Xeon(R) CPU E5410 @ 2.33GHz x 2cores
c1.xlargeIntel(R) Xeon(R) CPU E5410 @ 2.33GHz x 8cores
m2.xlargeIntel(R) Xeon(R) CPU X5550 @ 2.67GHz x 2cores
m2.2xlargeIntel(R) Xeon(R) CPU X5550 @ 2.67GHz x 4cores
m2.4xlargeIntel(R) Xeon(R) CPU X5550 @ 2.67GHz x 8cores
cc1.4xlargeIntel(R) Xeon(R) CPU X5570 @ 2.93GHz x 16cores


 実行結果

Instance typeMFLOPS measured(vCore)
t1.micro271.320092(x1)
m1.small324.676111(x1)
c1.medium774.602322(x2)
m1.large892.176316(x2)
m1.xlarge880.100758(x4)
c1.xlarge1044.821975(x8)
m2.xlarge1544.973882(x2)
m2.2xlarge1600.39996(x4)
m2.4xlarge1572.732919(x8)
cc1.4xlarge1676.395005(x16)


$サイバーエージェント 公式エンジニアブログ

姫野ベンチマークでは、単純なシングルコアでの性能値が算出されているように見受けられるため、実際の総合的なベンチマークとしては、上記の実測値と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 modelMFLOPS measured
Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz x 2cores1503.59
AMD Phenom(tm) 9950 Quad-Core Processor x 4cores1192.06
AMD Athlon(tm) 64 Processor 3500+ x 1core814.56
Dual-Core AMD Opteron(tm) Processor 1210 x 2cores725.76
Intel(R) Pentium(R) III CPU family 1.13GHz x 2CPUS121



 各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/dev/sdb/dev/sdf1
    m1.small252.872275.70866.86
    c1.medium271.04306.46266.152
    m1.large153.548166.74675.746
    m1.xlarge196.758170.9867.002
    c1.xlarge196.282197.34475.318
    m2.xlarge577.024375.93679.056
    m2.2xlarge612.69432.27886.486


    $サイバーエージェント 公式エンジニアブログ

    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/dev/sdb/dev/sdf1
    t1.micro85.1281.798
    c1.medium77.212
    m1.large74.126
    m2.xlarge86.244
    cc1.4xlarge140.594234.08484.992


    $サイバーエージェント 公式エンジニアブログ

    ここでは、"cc1.4xlarge"タイプが非常に良い実行結果が出ている。ただ、エフェメラルディスク(dev/sdb)については、m2系(High-Memory Instances)のインスタンスに付いているエフェメラルディスクの性能より低い結果となっており、最上位のインスタンスではあるが、この点には注意が必要となる。
    EBSボリュームについては、他のインスタンスタイプ同様それほどスループットは大きく出ていないが、レイテンシも低く、終始安定した書き込みを行っている感覚を受けた。(結果毎にバラつきが出ない。)

     dbenchの実行結果

    以下が、instance-rootタイプの各インスタンスに対して上記手順にてdbenchを行った実行結果である。Throughputの単位はMB/sec、max_latency の単位はmsとなる。

    Throughputmax_latency
    m1.small83.39713152.082
    c1.medium144.7391847.075
    m1.large172.1284875.352
    m1.xlarge197.142492.915
    c1.xlarge198.6183100.112
    m2.xlarge276.094059.14
    m2.2xlarge293.2153569.074
    m2.4xlarge313.3313623.604


    $サイバーエージェント 公式エンジニアブログ

    公称されているスペックでの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の測定結果となる。

    Throughputmax_latency
    t1.micro40.66772520.518
    c1.medium45.1286692.144
    m1.large39.8205674.802
    m2.xlarge69.8611167.158
    cc1.4xlarge137.968382.083


    $サイバーエージェント 公式エンジニアブログ


    この結果から、EBSボリュームを持つディスクタイプについては、"t1.micro”以外は、レイテンシが全体的に低く高レスポンスだが、instance-rootタイプ(先ほどの結果のもの)ほどのパフォーマンスは出ていないことがわかった。ただ、この結果においても、他インスタンスと比べて、"cc1.4xlarge"タイプの結果が非常に優れていることがわかる。

     おわりに

    本稿では、Amazon EC2の各Region、および各Instance typeについて、ネットワークレイテンシ、CPU、ディスクに関する性能調査を行った。調査結果より、それぞれのInstance typeにおいて、CPUおよびディスク性能の定量的な数値が計測できたことで、既存物理サーバとの比較材料とすることができると考える。
    参考図書にも記しているが、パブリッククラウドサービスはシステム上のメリットとデメリットをきちんと把握した上で利用することで、大きなコストメリットが生まれる場合がある。制約が少なからずあるため、特に大規模なWebサービスにおいては、パブリッククラウドサービスだけで事業・サービスのインフラが完結することは少ないが、ハイブリッドに利用することで前述のメリットを享受できるケースが少なくないため、今後ウォッチを続け、適材適所で有効活用できればと考えている。

     補足: 参考図書
    * [書籍] 並河祐貴, 安達輝雄: クラウド Amazon EC2/S3のすべて ~実践者から学ぶ設計/構築/運用ノウハウ~, 日経BP社 (2009)