Agile Cat — in the cloud

メジャー・クラウドの比較テスト Part_1 : 性能は Amazon S3 と Azure が圧勝

Posted in Amazon, Google, Microsoft, Research by Agile Cat on May 29, 2010

End-To-End Performance Study of Cloud Services
DateWednesday, May 26, 2010 at 4:49PM



メジャー・クラウドを並べた、初めてのテストだと思います。性能に関しては、Amazon S3 と Azure が圧勝と書きましたが、あくまでも Many-Wtite-Many-Query の形態のようであり、Write-Once-Read-Many ではありません。 そのため、Google App Engine などは散々な結果となっています。 文中にも、イベンチュアル・コンシステンシーを前提としたテスト(Part_2?)を計画中と書いてありますが、そちらでは別の結果がでると予測されます。 クラウドにおけるワークロード・モデルは 1つでは有りませんが、一般的なエンタープライズ・モデルにおいては、このテスト結果 Part_1 が適用できるはずだと思います。ーーー A.C.


Cloud computing promises a number of advantages for the deployment of data-intensive applications. Most prominently, these include reducing cost with a pay-as-you-go pricing model and (virtually) unlimited throughput by adding servers if the workload increases. At the Systems Group, ETH Zurich, we did an extensive end-to-end performance study to compare the major cloud offerings regarding their ability to fulfill these promises and their implied cost.

クラウド・コンピューティングが約束するのは、データ・セントリックなアプリケーションのディプロイメントにおける、数多くのアドバンテージである。 最も顕著なものには、ワークロードの増加に応じたサーバーの追加により、pay-as-you-go の料金モデルと、(事実上)無制限のスループットを実現し、コストを削減することも含まれる。 ETH Zurich の Systems Group では、大規模な End-to-End パフォーマンス実験を行い、それらの約束と暗黙のコストを満たす能力について、メジャー・クラウドを比較した。

The focus of the work is on transaction processing (i.e., read and update work-loads), rather than analytics workloads. We used the TPC-W, a standardized benchmark simulating a Web-shop, as the baseline for our comparison. The TPC-W defines that users are simulated through emulated browsers (EB) and issue page requests, called web-interactions (WI), against the system. As a major modification to the benchmark, we constantly increase the load from 1 to 9000 simultaneous users to measure the scalability and cost variance of the system.  Figure 1 shows an overview of the different combinations of services we tested in the benchmark.

この作業におけるフォーカスは、ワークロード(Read / Update)の分析というよりは、トランザクション処理にあった。比較のためのベースラインとしては、Web-shop をシミュレートするための標準的なベンチマークである、TPC-W を用いている。この TPC-W が定義するのは、EB(Emulated Browser)を介してエミュレートされるユーザーと、ページ・リクエストの発行であり、それれは、システムに対する WIPS(Web Interaction Per Second)と呼ばれるものとなる。 このベンチマークに対する主要な修正としては、対象システムのスケーラビリティとコスト相違を測るために、シュミレートされる同時使用ユーザー数を、1~9000 間でリニアに増やせるようにしたことである。  Figure 1 が示すのは、このベンチマークでテストしてサービスの、それぞれの組み合わせに関する概要である。

ETH Cloud Test _1

Figure 1: Systems Under Test

The main results are shown in Figure 2 and Table 1 – 2 and are surprising in several ways. Most importantly, it seems that all major vendors have adopted a different architecture for their cloud services (e.g., master-slave replication, partitioning, distributed control and various combinations of it). As a result, the cost and performance of the services vary significantly depending on the workload. A detailed description of the architectures is provided in the paper. Furthermore, only two architectures, the one implemented on top of Amazon S3 and MS Azure using SQL Azure as the database, were able to scale and sustain our maximum workload of 9000 EBs, resulting in over 1200 Web-interactions per second (WIPS).  MySQL installed on EC2 and Amazon RDS are able to sustain a maximum load of approximate 3500 EBs. MySQL Replication performed similar to MySQL standalone with EBS, so we left it off the picture. Figure 1 shows that the WIPS of Amazon’s SimpleDB grow up to about 3000 EBs and more than 200 WIPS. In fact, SimpleDB was already overloaded at about 1000 EBs and 128 WIPS in our experiments. At this point, all write requests to hot spots failed. Google AppEngine already dropped out at 500 emulated browsers with 49 WIPS. This is mainly due to Google’s transaction model not being built for such high write workloads. When implementing the benchmark, our policy was to always use the highest offered consistency guarantees, which come closest to the TPC-W requirements. Thus, in the case of AppEngine, we used the offered transaction model inside an entity group. However, it turned out, that this is a big slow-down for the whole performance. We are now in the process of re-running the experiment without transaction guarantees and curios about the new performance results.

Figure 2 と、Table 1 ー2 示される主な結果は、いくつかの面で驚きをもたらす。 最も重要なことは、それぞれのクラウド・サービスにおいて、メジャー・ベンダーが異なるアーキテクチャを採用している点だと思われる(たとえば、マスター・スレーブ・リプリケーション/パーティショニング/分散制御/多様な組み合わせなど)。 その結果として、サービスにおけるコストとパフォーマンスは、ワークロードに応じて大幅に変化する。個々のアーキテクチャに関する詳細は、このペーパーで提供されている。 さらに、だた 2つのアーキテクチャである、Amazon S3 と MS Azure(SQL Azure )に実装されたものだけが、9000 EB という最大のワークロードをスケールし、また、維持することが可能だった。 それは、毎秒 1200 WIPS という値に相当する。 Amazon の EC2 と RDS 上インストールされた MySQL は、3500の EB の最大ワークロードを支えることが可能だった。 MySQL Replication のパフォーマンスは、EBS を用いたスタンドアロン MySQL と同等であるため、Figure 2 から削除している。 また、Amazon SimpleDB の WIPS は、最大で約 3000 の EB と、200 の WIPS まで伸びている。 ただし、 私たちの実験では、SimpleDB は 1000 EB と 128 WIPS の辺りで、すでにオーバーロードをきたしている。 つまり、この時点にいおて、ホットスポットに対する、すべての書込みリクエストが失敗している。 Google AppEngine は、500 EB/49 WIPS 辺りで、すでに脱落している。Google のトランザクション・モデルが、このような高度な書込みワークロードに対応していない点に、その要因がある。 このベンチマークを実装するときのポリシーは、最も強固なコンシステンシーを保証するものであり、それは TPC-W 要件に最も近いものとなる。 したがって、AppEngine のケースでは、エンティティ・グループ内にトランザクション・モデルを提供する手法を用いた。 しかし、結局のところ、その手法がパフォーマンス全体を大きくスローダウンさせることになった。 そのため、現時点において、トランザクション保証と従来からの観点を用いることの無い、新しいパフォーマンス結果をもたらすための、再実験を進めているところだ。

ETH Cloud Test _2

Figure 2: Comparison of Architectures [WIPS]

Table 1 shows the total cost per web-interaction in milli dollar for the alternative approaches and a varying load (EBs). Google AE is cheapest for low workloads (below 100 EBs) whereas Azure is cheapest for medium to large workloads (more than 100 EBs).  The three MySQL variants (MySQL, MySQL/R, and RDS) have (almost) the same cost as Azure for medium workloads (EB=100 and EB=3000), but they are not able to sustain large workloads.

Table 1 が示すのは、WIPS に関する 1/1000 ドル単位でのトータル・コストであり、変動する EB に対応する別の指標となる。 ミドルからラージの負荷(100 EB 以上)では Azure が最も低価格なのに対して、Google AE はスモール(100 EB 以下)で最安値となる。 MySQL の 3つの派生物(MySQL、MySQL/R、RDS)は、ミドルの負荷(100~3000 EB)では Azure に等しいが、ラージの負荷を維持できない。

ETH Cloud Test _3

Table 1: Cost per WI [m$], Vary EB

The success of Google AE for small loads has two reasons.  First, Google AE is the only variant that has no fixed costs. There is only a negligible monthly fee to store the database. Second, at the time these experiments were carried out, Google gave a quota of six CPU hours per day for free.  That is, applications which are below or slightly above this daily quota are particularly cheap.

スモールにおける Google AE の成功は、2つの理由による。  最初に、Google AE は固定費を伴わないという、唯一の例外であることが挙げられる。 ただし、データベースをストアするための、微細な月額料金が必要になる。 次に、この実験が実施されたとき、 Google は 6 CPU 時間/日を無償にするという割引を提供していた。  そのため、上下の Table における適用は、通常より低価格となっている。

Azure and the MySQL variants win for medium and large workloads because all these approaches can amortize their fixed cost for these workloads. Azure SQL server has a fixed cost per month of USD 100 for a database of up to 10 GB, independent of the number of requests that need to be processed by the database.  For MySQL and MySQL/R, EC2 instances must be rented in order to keep the database online.  Likewise, RDS involves an hourly fixed fee so that the cost per WIPS decreases in a load situation.  It should be noted that network traffic is cheaper with Google than with both Amazon and Microsoft.  

Azure および MySQL 派生物が、ミドルからラージの負荷において勝者となる理由は、その全てのアプローチにおいて、固定的なコストを償却できるからだ。 Azure SQL Server は、最大で 10GB のデータベースのための USD 100/月への固定コストを伴なうが、データベースが処理する必要のあるリクエスト数は、そこから独立している。  MySQL と MySQL/R では、データベースをオンライン状態に保つために、EC2 インスタンスをリターンしなくてはならない。  同様に、EDS は 1時間単位の固定コストを伴うため、 WIPS ごとのコストが負荷の状況にいうて減少する。ネットワーク・トラフィックに関しては、Amazon と Microsoft よりも Google の方が安価なことが指摘されるべきだ。

Table 2 shows the total cost per day for the alternative approaches and a varying load (EBs). (A "-" indicates that the variant was not able to sustain the load.)  These results confirm the observations made previously:  Google wins for small workloads;  Azure wins for medium and large workloads.  All the other variants are somewhere in between.  The three MySQL variants come close to Azure in the range of workloads that they sustain. Azure and the three MySQL variants roughly share the same architectural principles (replication with master copy architectures). SimpleDB is an outlier in this experiment. With the current pricing scheme, SimpleDB is an exceptionally expensive service.  For a large number of EBs, the high cost of SimpleDB is particularly annoying because users must pay even though SimpleDB drops many requests and is not able to sustain the workload.

Table 2 が示すのは、1日あたりのトータル・コストであり、変動する EB に対応する別の指標となる。 ("ー" は、それらの形態でサポートできなかったことを示す)  この結果から確認できるのは、1つ前の観察と同じでことある。 つまり、スモール負荷では Google が勝者であり、ミドルとラージでは Azure が勝者である。  その他すべては、この両者の中間にある。  MySQL の 3つの派生物は、それらが維持できるレンジにおいて、Azure に近い結果をもたらす。 それら全ては、アーキテクチャにおいて、同一の原則を共有している(マスター・コピーを用いたリプリケーションのアーキテクチャ)。 この実験において、SimpleDB は異常値を呈している。 現行の価格スキームにおいて、SimpleDB は例外的に高価なサービスとなる。  大量の EB における SimpleDB は、たとえ多数のリクエストをドロップし、また、ワークロードを維持することが不可能であっても、ユーザーからの支払いが低減されないため、敬遠される存在になる。

ETH Cloud Test _4

Table 2: Total Cost per Day [$], Vary EB

Turning to the S3 cost in Table 2, the total cost grows linearly with the workload.  This behavior is exactly what one would expect from a pay-as-you-go model.  For S3, the high cost is matched by high throughputs so that the high cost for S3 at high workloads is tolerable. This observation is in line with a good Cost/WI metric for S3 and high workloads  (Table 1). Nevertheless, S3 is indeed more expensive than all the other approaches (except for SimpleDB) for most workloads.  This phenomenon can be explained by Amazon’s pricing model for EBS and S3. For instance, a write operation to S3 is hundred times more expensive than a write operation to EBS which is used in the MySQL variant.  Amazon can justify this difference because S3 supports concurrent updates with an eventual consistency policy whereas EBS only supports a single writer (and reader) at a time.

Table 2 における S3 に目を向けると、そのトータル・コストがリニアに伸びているのが分かる。  この傾向は、pay-as-you-go モデルに基づく期待値を、正確にトレースするものとなる。  S3 おいては、コストに応じたスループットが提供されるが、それにより、大きな負荷での高いコストにも納得できるようになる。この観察結果は、S3 と高負荷における Cost/WIPS 指標とも、きれいに一致している。 そにもかかわらず、S3 は作業負荷に関する大半のケースにおいて、他のアプローチ(除くSimpleDB)より高価である。  この現象は、EB と S3 に関する Amazon の価格モデルにより説明することが可能だ。 実際に、S3 への書出しオペレーションは、MySQL 系で用いられる EB 書出しオペレーションと比べて、100 倍ほど高価になる  S3 はイベンチュアル・コンシステンシーのポリシーを用いて、複数の同時アップデートをサポートするのに対して、EB では 1回に 1つの書き込みだけがサポートされるため、Amazon は違いを正当化できるだろう。

In addition to the here presented results, the paper also compares the overload behavior and presents the different cost-factors leading to the here presented numbers. If you are interested in these results and additional information about the test-setup, the paper will be presented at this year’s SIGMOD conference and can also be downloaded here.

ここで提供される結果のほかに、オーバーロードにおける振舞いを比較し、また、異なるコスト要因を提供するペーパーもある。 もし、それらの結果とテスト環境に関する詳細情報に興味があるなら、今年の SIGMOD カンファレンスで提供されるペーパーも、ダウンロードできるようになる。


それにしても、素晴らしいテストを行ってくれたものです。 このテストの形態は、性能について、また、価格について、クラウドを測定する際の 1つの指標になるでしょうね。 次に予定されるイベンチュアル・コンシステンシー・テストが楽しみです。 ーーー A.C.


2 Responses

Subscribe to comments with RSS.

  1. […] [今日のTOP]メジャー・クラウドの比較テスト Part_1 : 性能は Amazon S3 と Azure が圧勝 […]

  2. Agile Cat said, on May 31, 2010 at 3:37 am


Comments are closed.

%d bloggers like this: