Agile Cat — in the cloud

Google IO 2011 での、Big Data 関連ビデオをピックアップ!

Posted in Big Data, Google by Agile Cat on June 17, 2011

Stuff to Watch from Google IO 2011
Wednesday, June 8, 2011 at 8:54AM


With the Google IO Developer Conference completed there are dozens and dozens of information packed videos now available. While you won’t get any of the nifty free swag the attendees rake in, it’s great of Google to make these videos available so quickly after the conference.

今年の Google IO Developer Conference が終了し、きわめて大量の情報が、ビデオになって提供されている。参加者たちがかき集めた、気のきいた無料のグッズを差し上げることはできなが、そのカンファレンスが終わって、これほど素早くビデオを提供する Google は素晴らしい。

imageLet’s say you don’t want to watch all the videos on the pretense you have a life, here are just a dozen scalability and architecture related videos you might find interesting:

あなたは、日々の時間を費やしてまで、すべてのビデオを見ないだろうが、ちょうど 12本の、スケーラビリティとアーキテクチャに関連するビデオがある:

  1. App Engine Backends by Justin Haugh, Greg Darke. One of this biggest complaints about GAE are the request deadlines. Those are now gone when you rent a new Backend node.

    App Engine Backends by Justin Haugh, Greg Darke. ーーー GAE における最大の問題の 1つは、そのリクエストに関する Dead Line である。 新しい Backend ノードを借り入れるときには、それらのリクエストが消えてしまっている。

  2. Scaling App Engine Applications by Justin Haugh, Guido van Rossum. Two parts: how App Engine scales internally and how you as a programmer make it scale using the tools. Good discussion of scaling and why it’s hard; 10,000 queries per second is a large app that needs good architecting; a good discussion of GAE’s predictive scaling formula of how it decides when to spawn instances; throughput is determined by CPU usage; understand your apps performance; using load testing; strategies for scaling; common pitfalls. The less you do the faster it will be and the less it wil cost.

    Scaling App Engine Applications by Justin Haugh, Guido van Rossum. ーーー 2つのパート: どのようにして、App Engine は内部でスケールするのか。 そして、どのようにしてプログラマーは、ツールを用いてスケールしていくのか。 スケーリングに関する適切なディスカッションと、それが難しい理由:毎秒 10,000 のクエリーを必要とするのが、適切なアーキテクチャを必要とする大規模アプリケーションである。GAE の予測されたスケーリング基準に関する適切なディスカッションが、インスタンス生成における方式とタイミングを決定する。スループットは、CPU 使用の度合いにより決定される。自身のアプリケーション性能を理解すべきだ。 負荷テストを使用すべきだ。スケーリングに戦略を持て。一般的な落とし穴は? 取り組んだ分だけ、高速化が実現されるが、それが少なければ、コストに跳ね返るだろう。

  3. App Engine MapReduce by Mike Aizatskyi. Previously you could only write Map jobs, now you can run full Map Reduce jobs on App Engine.

    App Engine MapReduce by Mike Aizatskyi. 以前には、Map ジョブの記述までしかできなかったが、App Engine 上でフル Map Reduce ジョブが実行できるようになった。

  4. Coding For The Cloud: How We Write Enterprise Apps for Google on App Engine by Ben Fried, Justin McWilliams, Eric Schoeffler, Justin Fagnani. App Engine is just a backend for Facebook games, Google want to remind you that they do the Enterprise too: performance reviews, help desk, course scheduling, expense reporting, payroll, etc.

    Coding For The Cloud: How We Write Enterprise Apps for Google on App Engine by Ben Fried, ーーー Justin McWilliams, Eric Schoeffler, Justin Fagnani. App Engine は Facebook ゲームのバックエンドとして使われているが、Google としてはエンタープライズでの利用も促進したい: パフォーマンスレビューや、ヘルプデスク、コース・スケジューリング、給与関連など。。。

  5. Fireside Chat with the App Engine Team with Max Ross, Alon Levi, Sean Lynch, Greg Dalesandre, Guido van Rossum, Brett Slatkin, Peter Magnusson, Mickey Kataria, Peter McKenzie. Get the marshmallows, the fire is hot. The team talks about the pricing changes, HR datastore, and lots of great questions that lead to more great things to work on.

    Fireside Chat with the App Engine Team with Max Ross, Alon Levi, Sean Lynch, Greg Dalesandre, Guido van Rossum, Brett Slatkin, Peter Magnusson, Mickey Kataria, Peter McKenzie. ーーー(パス:Get the marshmallows, the fire is hot.) このチームは、価格設定の変更および、HR データストアについて説明し、また、取り組むべき重要な事柄について、数多くの問題を提起した。

  6. Full Text Search by Bo Majewski, Ged Ellis. A quirky fact about a Google App Engine is that it did not support search.  Now it will.

    Full Text Search by Bo Majewski, Ged Ellis. ーーー Google App Engine における奇異な点は、サーチエンジンをサポートしていないことだった。 そのサポートが始まる。

  7. More 9s Please: Under The Covers of the High Replication Datastore by Alfred Fuller, Matt Wilder. GAE is replacing their original Master/Slave Datastore with the  High Replication Datastore. Why such a big step? Higher availability. The cost? Latency and consistency. Excellent discussion of the different tradeoffs and why they were made.

    More 9s Please: Under The Covers of the High Replication Datastore by Alfred Fuller, Matt Wilder.  ーーー GAE は、オリジナルの   Master/Slave Datastore を、自身の High Replication Datastore で置き換える。 なぜ、このように大きなステップを取るのかといえば、 より高い可用性が理由となる。  レイテンシーとコンシステンシーの改善により、コストが低減される。 それぞれのトレードオフと、それを行う理由について、丁寧な説明がある。

  8. Putting Task Queues to Work by Nicholas Verne, Vivek Sahasranaman. Always a great feature, task queues were restricted by being pushed based, now pull based queues make it possible to process tasks in a VM by pulling from queues using a REST API.

    Putting Task Queues to Work by Nicholas Verne, Vivek Sahasranaman. ーーー 常に素晴らしい機能で在り続けてきたタスク・キューは、プッシュ・ベースという制約を持っていたが、REST API を用いたキューからプルすることで、VM 上でのタスクの処理が可能な、プル・ベースのキューになった。

  9. Large-scale Data Analysis Using the App Engine Pipeline API by Brett Slatkin. Think Big Data and you think Google. Here’s how you do Big Data on GAE: build multi-phase Map Reduce workflows; how to merge multiple large data sources with "join" operations; and how to build reusable analysis components.

    Large-scale Data Analysis Using the App Engine Pipeline API by Brett Slatkin. ーーー Big Data を考えると、Google のことを考えるようになる。 GAE 上で、Big Data に取り組む際の、方式について解説する。 具体的には、マルチ・フェーズの Map Rerduce ワークフローの構築と、”join” オペレーションによるマルチ・データ・ソースのマージ、再利用可能な分析コンポーネントの構築賞式となる。

  10. Use Page Speed to Optimize Your Web Site For Mobile by Bryan McQuade, Libo Song, Claudia Dent. Page Speed is a tool that helps reduce the latency for mobile apps. Good discussion of the issues and how to diagnose and fix them: cache, defer JavaScript, cache redirects, use touch events, enable keep-alives.

    Use Page Speed to Optimize Your Web Site For Mobile by Bryan McQuade, Libo Song, Claudia Dent.  ーーー Page Speed は、モバイル・アプリケーションにおけるレイテンシーを緩和するためのツールである。 その問題についてのディスカッションを提供するが、具体的には、キャッシュおよび、defer JavaScript、キャッシュのリダイレクト、タッチ・イベントの使用、そして keep-alives の達成となる。 

  11. Using The Google Docs APIs To Store All Your Information In The Cloud by Vic Fryzel. Not just another file store: Storage is per user; users control storage quota; Data is inherently structured; All entries have the same metadata; Documents currently use zero quota.

    Using The Google Docs APIs To Store All Your Information In The Cloud by Vic Fryzel.  ーーー 単なる別のファイル・ストアというわけではなく、ユーザーごとの Storage、ストレージ・クォータの制御、本質的に構造化された Data、すべてのエンティティが共有するメタ・データ、Decuments によるゼロ・クォータの使用などについて説明する。

  12. Highly Productive GWT: Rapid Development with App Engine, Objectify, RequestFactory, and gwt-platform by David Chandler, Philippe Beaudoin, Jeff Schnitzer. GAE+GWT+objectify+ other tools is an awesomely productive tool chain. Nice examples with code on how to make it work.

    Highly Productive GWT: Rapid Development with App Engine, Objectify, RequestFactory, and gwt-platform by David Chandler, Philippe Beaudoin, Jeff Schnitzer. ーーー GAE+GWT+objectify+ other tools の組み合わせは、生産性のための価値ある連鎖である。 それらを機能させるための、すばらしい事例を紹介する。

These talks are generally of high quality and provide insight you won’t get elsewhere. Highly recommended to take a look around.

これらのビデオは、きわめて品質の高いものであり、他では得られない洞察を提供する。 それらの参照を、お勧めする。


ほんとうに、大量の情報ですね。 この週末、お時間のある方は、チャレンジしてみたら如何でしょうか :) ーーー __AC Stamp 2



Google 的 クラウド連携の ABC ?
Google は 1000万台のサーバーを目指す ?
Google Instant では MapReduce を排除!
Google にテクノロジー・リーダーの称号を与えるプロダクト
Google Wave が、Apache の提案によりカムバックする?

Eric Schmidt が Chrome を語る – 2011 は Web OS の年だ

Posted in Google by Agile Cat on December 19, 2010

Google Predicts Rise of Web OS in 2011
Om Malik
Dec. 17, 2010, 3:00pm PDT

_ Gigaom

With the launch of ChromeOS, Google chief executive Eric Schmidt has realized his long time dream of building a network computer, one that taps into the Internet and offers browser-based-network-hosted applications. My view, when it comes to the ChromeOS? Google should forget chasing the consumers and go hard after the corporate market – especially after verticals that need low-cost, zero-maintenance machines dedicated to a few tasks.

ChromeOS の立ち上げにより、Google の CEO である Eric Schmidt は、自身の長年の夢であるネットワーク・コンピュータを実現する。 それは、Internet にアクセスし、ブラウザ・ベースのネットワーク・ホスティングされたアプリケーションを提供するものとなる。 ChromeOS の到来は、私には、どのように映るのだろうか? まず Google は、コンシューマを追うのではなく、コーポレート・マーケットをハードに追うべきである。つまり、低コストへのニーズと、ゼロ・メンテナンス・マシンによる少量化を、徹底的に掘り下げるべきだ。

It looks like Google is headed in that direction. Yesterday, the Mountain View, Calif.-based company announced that IT administrators can deploy and optimize the Chrome browser to meet their specific corporate needs.

昨日(12/16)のことだが、Mountain View、 Calif ベースの同社は、Chrome ブラウザのディプロイと最適化により、それぞれの IT アドミニストレータは、彼らの企業ニーズを充たすことができると発表した。

Today, we’re announcing that Chrome offers controls that enable IT administrators to easily configure and deploy the browser on Windows, Mac, and Linux according to their business requirements. We’ve created an MSI installer that enables businesses who use standard deployment tools to install Chrome for all their managed users. We’ve also added support for managed group policy with a list of policies and a set of templates that allow administrators to easily customize browser settings to manage security and privacy.

今日、私たちがアナウンスする Chrome は、Windows/Mac/Linux 上で、それぞれの IT アドミニストレータがビジネス要件に応じて、ブラウザのコンフィグレーションとディプロイを容易に行うための制御を提供する。私たちは、MSI インストーラを作成した。それにより、標準的なディプロイメント・ツールを用いる企業は、そこで管理するユーザー用に、Chrome をインストールできる。 さらに、ポリシー・リストテンプレート・セットを用いて、グループ・ポリシーのためのサポートを加えている。 それにより、アドミニストレータは、セキュリティとプライバシーを管理するためのブラウザ設定について、容易なカスタマイズを実現する。

Coincidentally, manageability and security were two questions raised.  Today, Dave Girouard, president of Google Enterprise in a blog post, vividly paints the company’s cloud-future. He writes:

時を同じくして、マネージャビリティとセキュリティが、2つの論点として提起されている。  今日のことだが、Google Enterprise 社長の Dave Girouard が、同社が描くクラウドの未来について、鮮やかなプログ・ポストを提供している。 彼は、以下のように記している:

While many IT vendors have now adopted (or co-opted) the term “cloud computing” to describe a wide variety of technologies, most don’t deliver on the true promise of the cloud. Hosting single-tenant server products in a data center is not cloud computing. Nor is requiring customers to install thick client software. In a 100% web world, business applications are delivered over the Internet and accessed in a web browser.  Devices like notebooks, tablets, and smartphones are portals to the data that help people be productive from anywhere, at any time. 100% web is a dramatic shift from how companies have traditionally purchased, deployed, and managed IT. But the more we talk with customers the more we realize that this is the change they’ve been waiting for. If 2010 was the year of the cloud, 2011 looks to be the year of nothing but the web.

数多くの IT ベンダーが、クラウド・コンピューティングという用語を用いて(あるいは組み入れて)、その多様なテクノロジーを表現しているが、ほんとうの意味において、その大半は約束を果たしていない。 データセンターにおいて、単独のテナントとしてホスティングされるサーバー・プロダクトは、クラウド・コンピューティングではない。 また、顧客に対して、重装備のクライアント・ソフトウェアをインストールするよう、要求するのもおかしい。 Web 100% の世界で、インターネット上でビジネス・アプリケーションが提供され、Web ブラウザでアクセスされる。  ノートブック/タブレット/スマートフォンなのどデバイスは、人々による生産活動を、何時でも何処でも支援するための、データへといたるポータルである。これまでのように、IT を購入/実装/管理してきた企業が、Web 100% の企業へと、ドラマチックに移行する。 そして、顧客たちと語ってきた以上のものを、私たちは実現する。 それこそが、顧客たちが待ち望んでいた変化である。 2010 年がクラウドの年であるとすれば、2011 年は Web の年以外の、何ものでもないだろう。

Google, he points out, is doing so through its various initiatives – Google Apps, App Engine, Chrome OS, Chrome Browser and Android. To most of you, this might seem plain as a day, but it’s refreshing to see Google articulate its big picture vision about the cloud and web-based computing.

Google は、Google Apps/App Engine/Chrome OS/Chrome Browser/Android といった多様な戦略を介して、それを実行しようとしていると、彼は指摘する。 大半のユーザーに取って、そのことは、淡々とした日常に映るかもしれない。 しかし、そのクラウドと Web ベースのコンピューティングに関する大きなビジョンを、Google が明瞭に表現することに新鮮さを感じる。

The graphic on its blog post, which points to the company’s blog, makes it clear it’s in battle with Microsoft in this battle and in the end, it wants to end the PC past.

同社のブログを指し示す、このブログ・ポスト上のグラフィクスは、この戦いが、Microsoft との戦いであることを、明確に示している。 そして、最終的には、PC を過去のものしたいという望みを、を明確に伝えている。

Related content from GigaOM Pro (sub. req.):


まぁ、Agile_Cat 的には、ドキュメントのことしか分からないわけですが、それらの元になる情報の 100% が Web から入ってきて、結果としてのアウトプットも、95% が Web と電子ドキュメントという状況なのは、多く方々と共有できる現実なのかと思います。 そうなると、紙の時代と比べて、アプリケーションに求める機能も変化するわけで、現状のキラーアプリも Brower/Evernote/Onenote/Live Writer という感じに、大きくシフトしています。そして、とても便利な時代になったものだと、感心しているというのが、率直な感想です。 ーーー A.C.


Evernote を Version 4 にアップデートしてみました
クロス・プラットフォームへの賛同票を、500万人から集めた Evernote !
ザッケローニ・ジャパン的な Web ブラウザ 選択術
Evernote は $20 Million を調達して、何を狙うのか?
Evernote が 400 万ユーザーに達した! – その理由は?
Agile_Cat の 9つの TOOL とは?- WordPress と Twitter だけじゃないよ!
OneNote 2010 が Evernote に負けているのは ココだ!

メジャー・クラウドの比較テスト 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.


%d bloggers like this: