Agile Cat — in the cloud

By the numbers: How Google Compute Engine stacks up to Amazon EC2
http://wp.me/pwo1E-5Md
By Sebastian Stadil, Scalr – March 15, 2013
http://gigaom.com/2013/03/15/by-the-numbers-how-google-compute-engine-stacks-up-to-amazon-ec2/

Summary: When Google launched its EC2 rival, Google Compute Engine, last June, it set some high expectations. Sebastian Standil’s team at Scalr put the cloud infrastructure service through its paces — and were pleasantly surprised at what they found.

Summary: 昨年の ６月に Google Compute Engine が、EC2 のライバルとしてローンチしたとき、いくつかの高い期待値が設定された。 Scalr の Sebastian Standil チームは、このクラウド･インフラ･サービスに対する厳しいテストを、自分自身のペースで行なっているが、その結果として見出したものは、嬉しい驚きである。

ーーーーー

At Scalr, we’ve been happy customers of Amazon’s infrastructure service, EC2, since 2007. In fact, we’ve built our tools for EC2 because we saw an opportunity to leverage its flexibility to help AWS customers easily design and manage resilient services. But as competitors spring up, we always test them to see how they compare, especially in regards to io performance.

Scalr における私たちのチームは、2007年から現在にいたるまで、Amazon のインフラ･サービスである EC2 の顧客として満足してきた。 実際のところ、私たちが EC2 用のツールを構築したのは、サービスを設計／管理する AWS の顧客を、さらに柔軟な世界へ容易に取り込んでいくチャンスを見出したからだ。しかし、コンペティタが登場するたびに、その性能をテストし（とりわけ I/O の性能）、AWS と比較してきた。

On a warm June day in San Francisco, the Scalr team attended Google I/O 2012. Google was rumored to be launching a EC2 competitor, which we were interested in for our multi-cloud management software. It launched. And boy did it sound good. You see, EC2 and GCE offer pretty much the same core service, but Amazon has been plagued by poor network and disk performance, so Google’s promise to offer both higher and more consistent performance struck a real chord.

6月の San Francisco にしては、温かいと感じる日に、私たち Scalr チームは、Google I/O 2012 に参加した。 Google には、 EC2 のコンペティタをローンチするというウワサがあり、また、私たちのマルチ･クラウド･マネージメント･ソフトウェアにとって、興味深い対象でもあった。 そして、それはローンチされた。 さらに言えば、きわめて響きの良いものであった。 よく聴いて欲しいのだが、「 大まかなところで EC2 と GCE は、同じコア･サービスを提供する。 しかし、プアなネットワークとディスク･パフォーマンスという、Amazon が引きずっている悩みに対して、一貫性のあるパフォーマンス･スタックを、質と量の両面で高め、それらを調和させていくことを、Google は約束する 」と言っているのだ。

Not ones to be fooled by marketing-driven, hyped-up software, we applied for early access and were let in so we could start testing it ourselves. Once we got in, we felt like kids in a candy store. Google Compute Engine is not just fast. It’s Google fast. In fact, it’s a class of fast that enables new service architectures entirely. Here are the results from our tests, along with explanations of how GCE and EC2 differ, as well as comments and use cases.

マーケティングに騙されるわけでもなく、ソフトウェア･ハイプに乗せられるわけでもなく、私たちはアーリー･アクセスにエントリーし、そこに参加し、私たち自身のテストを開始できた。 そして、そこに入った途端に、自分たちが、まるでキャンディ･ストア内の子供たちになったように思えてきた。 Google Compute  Engine は、単に速いだけではない。 それ、Google の速さなのである。 実際のところ、まったく新しいサービスの、アーキテクチャを可能にするほどのファースト･クラスなのである。 以下に示すのは、私たちのテストの結果であり、それは GCE と EC2 の差異を説明し、ユースケースを伴うものでもある。

A note about our data: The benchmarks run to collect the data presented here were taken twice a day, over four days, then averaged. When a high variance was observed, we took note of it and present it here as intervals for which 80 percent of observed data points fall into.

一連のデータに関しては、1日に 2度のサンプリングを、4日以上にわたり継続し、その平均値を求めた結果であることを、指摘しておく。大きな変動が観察されたときには、それを記録し、観察されたデータ･ポイントの 80% が、安定した値を示している期間のデータを、以下に示すようにしている。

API

First off, GCE’s API is beautifully simple, explicit and easy to work with. Just take a look at it. Their firewalls are called “firewalls,” vlans are “networks,” and kernels are “kernels” (AKIs, anyone?). Anyone familiar with Unix will feel right at home.

まず、第一に、 GCE の API は美しいほどにシンプルであり、明快であり、また、容易に動かせる。 以下を、見てもらえれば、すぐに意味がわかる。 そのファイアウォールは “firewalls” と呼ばれ、VLAN は “networks” であり、そして、カーネルは “kernels”である (AKIs, anyone?)。 Unix を使い慣れた人であれば、まさに、自宅へ戻ってきた気分だろう。

Fast boot

Second, VMs are deployed and started with impressive speed (and we’ve extensively used 10 clouds). It routinely takes less than 30 seconds to login as root after making the insert call to launch a VM. As a reference point, this is the amount of time it takes AWS to get to the running state, after which you still need to wait for the OS to boot, for a total of 120 seconds on a good day, and 300 on a bad one (data points taken from us-east-1).

第二に、VM のディプロイとスタートであるが、素晴らしいスピードで処理される（そして、10個のクラウドでの利用まで、その範囲を広げている）。通常であれば、VM の始動を要求にしてから 30秒以内で、root としてログインするところまでたどり着く。 リファレンス･ポイントとして、その状態になるまでに、AWS がが必要とする時間を確認すると、 調子の良い日で 120秒、悪い日で 300秒という時間が、OS をブートするまでの待ち時間となる（このデータは us-east-1 のものである）。

Boot times are measured in seconds.
ブート･タイムを秒で表示

We don’t know what sort of sorcery Google does here, but they clearly demonstrate engineering prowess. That’s 4-10x faster.

どのような種類の魔術を、Google が駆使しているのかは分からないが、明らかに優れたエンジニアリング能力を実証している。 その速度差は、4x ～ 10x に相当する。

Volumes

Those of you familiar with Amazon’s EBS volumes know that you can attach and detach volumes to any instance, anytime. On GCE, you can’t (at least not yet). This precludes you from switching drives to minimize downtime: attaching a volume on a running server allows you to skip the boot and configure stages of bringing a new node up, which is useful when promoting an existing mysql slave to master and you just need to swap out storage devices.

Amazon の EBS ボリュームに精通した人たちであれば、あらゆるインスタンスに対して、いつでもボリュームを attach/detach できることを知っている。 しかし GCE においては、それが出来ない（少なくと現時点では）。 それにより、デバイスの切り替えにおいて、ダウンタイムを最小限にすることが不可能になる。 つまり、実行中のサーバーにボリュームを付加することで、新しいノードを立ち上げるための、ブートとコンフィグレーションのステージを、スキップすることが不可能なのだ。それは、既存の MySQL Slave を Master に昇格させるときや、ストレージ･デバイスを入れ替えるときに、きわめて有用なものなのだ。

While GCE’s “disks” (as they call them) have that one disadvantage, they offer some unique advantages over Amazon volumes.

このように、GCE の "disks"（と呼ばれている） にはディスアドバンテージがあるが、Amazon ボリュームに対して、いくつかのユニークなアドバンテージも提供している。

Read/write speeds are measured in MB/s. Higher numbers mean faster throughput.

Read/Write のスピードは、MB/秒 で測定されている。 したがって、大きな値のほうが、高いスループットを示す。

For example, disks can be mounted read-only on multiple instances, which makes for more convenient fileserving than object stores, especially for software such as WordPress (see disclosure) or Drupal that expect a local filesystem. Disks are really fast too, and don’t seem to have the variable performance that plagued EBS before the introduction of Provisioned IOPS. See for yourself in the following benchmarks.

たとえば、この disks は、マルチ･インスタンス上に read-only でマウントできる。そして、それは、オブジェクト･ストアよりも、利便性の高いファイル･サービスを実現する場合がある。 とりわけ、ローカルなファイル･システムを要求する、WordPress （see disclosure）やDrupal のようなソフトウェアのケースが、それに該当する。 さらに言えば、この disks は、きわめて高速であり、また、Provisioned IOPS を導入する前に EBS を悩ませる、変化しやすいパフォーマンスという特性を持っていないと思われる。 以下のベンチマークを、確認して欲しい。

As you can see, GCE and EC2 are equivalent on reads, but GCE is 2-4x faster on writes.

ここで確認できるように、GCE と EC2 は Read において互角であり、Write では GCE が 2x～4x ほど優る。

Network

A short note about multi-cloud. I’m talking here about services that span multiple clouds, such as replicating a database from us-east-1 to us-west-1, for disaster recovery or latency-lowering purposes, not the multi-cloud management capabilities widely used in the enterprise. I believe that first kind of multi-cloud is a myth driven by the industry’s less tech-savvy folks. I’ve seen too many people attempt it unsuccessfully to recommend it: what usually happens is the slave database falls behind on the master, with an ever-increasing inconsistency window, because the load on the master exceeds the meager bandwidth available between master and slave. Our friends at Continuent are doing great work with Tungsten to accelerate that, but still.

マルチ・クラウド全体について、述べているのではないことを指摘しておく。 ここで取り上げるのは、たとえば us-east-1 から us-west-1 へ向けた、データベースの複写という範囲での、マルチ･クラウド･サービスである。それは 、DR（Disaster Recovery）や低レイテンシを実現するためのものであり、エンタープライズで広く使われる、マルチ･クラウドの管理能力のことではない。 私は、広範囲におよぶマルチ･クラウドというものは、この業界における、それほど技術に精通していない人々により、広められた神話だと確信している。まぜなら、その促進において、余りにも多くの人々が、失敗するのを見てきたからだ。 一般的に見て、常に増加していく矛盾という視点において、Master データベースの背後に置かれた、Slave データベースが崩壊していくのである。なぜなら、Master における負荷が、Master と Slave の間で利用可能な、不十分なバンドワイズの範囲を超えていくからである。 Continuent における友人たちが、それを加速するために、Tungsten と素晴らしい仕事をしているのだが。。。

Higher bandwidth is better and
means faster up and downlinks.

このバンドワイズに関するデータは、
大きな値の方が Up/Down において高速となる。

Google’s network is so fast, however, that this kind of multi-cloud might just be possible. To illustrate the difference in speeds, we ran a bandwidth benchmark in which we copied a single, 500 Mb file between two regions. It took 242 seconds on AWS at an average speed of 15 Mbit/s, and 15 seconds on GCE with an average speed of 300Mbit/s. GCE came out 20x faster.

しかし、Google のネットワークは、きわめて高速である。 したがって、その種のマルチ･クラウドも可能になるかもしれない。そのスピードにおける差異を例証するために、500 MB のファイルを、2つのリージョン間でコピーするという、ベンチマークを実施してみた。 その結果は、AWS の平均が 242秒（15 Mbit / s）であり、また、GCE の平均が 15秒（300 Mbit / s）というものだった。 GCE の方が、20× も高速という結果になった。

After being so very much impressed, we made a latency benchmark between the same regions. We got an average of 20ms for GCE and 86ms for AWS. GCE came out 4x faster.

この、GCE の、素晴らしいデータが得られた後で、リージョン間でのレイテンシについて、同条件でのベンチマークを実施してみた。 そして、GCE では平均で 20ms という値が得られ、AWS では平均で 86ms という値が得られた。 つまり、GCE の方が、4x も高速であるという結果になった。

Lower latency is better and means
shorter wait times.

低レイテンシの方が優れた結果であり、
待ち時間が短くなる。

This might allow new architectures, and high-load replicated databases might just become possible. Put a slave in different regions of the US (and if/when GCE goes international, why not different regions of the world?) to dramatically speed up SaaS applications for read performance.

それにより、新しいアーキテクチャが実現するかもしれない。 つまり、高負荷におけるデータベース複写が、可能になるという話である。たとえば、アメリカ国内における個々のリージョンに（ GCE のインターナショナライズが実現すれば、世界中のリージョンが対象）、SaaS アプリケーションの Slave を配置すれば、Read に関するパフォーマンスが劇的に向上するだろう。

Of course, unless Amazon and Google work together to enable Direct Connect, bandwidth from GCE to EC2 will still be slow. I also hear that Amazon is working on creating a private backbone between regions to enable the same use cases, which would be an expected smart move from them.

もちろん、 Amazon と Google が、Direct Connect を実現するために協調しなければ、GCE から EC2 へ（その逆も）向けたバンドワイズは低いままとなるだろう。 そして、同じユース･ケースを実現するリージョン間プライベート･バックボーンを、Amazon も構築しているという話を耳にしている。Amazon による、スマートな対応になると期待される。

Multi-region images

We’re not quite sure why AWS doesn’t support this, but images on GCE are multi-region (“multi-zone” in their terms), that is to say when you snapshot an instance into an image, you can immediately launch new instances from that image in any region. This makes disaster recovery that much easier and makes their scheduled region maintenance (which occurs a couple of times a year) less of a problem. On that note, I’d also like to add that it forces people to plan their infrastructure to be multi-region, similar to what AWS did for instance failure by making local disk storage ephemeral.

この件に関して、AWS がサポートしない理由が分からないが、GCE 上のイメージは、マルチ･リージョン（GCE では Multi-Zone と呼ばれている）に対応している。それは、インスタンスのスナップショットを、イメージとして取り込んだときに、そのイメージから得られる新しいインスタンスを、あらゆるリージョンで即座に展開できるというものだ。 つまり、DR（Disaster Recovery ）が容易になり、定期的なリージョン･メンテナンス（通常では年に2回程度）における問題が低減される。 ここで指摘しておきたいのは、それぞれのインフラに関する、マルチ･リージョン化を計画すべきという点である。 それは、AWS が、ローカル･ディスク･ストレージを ephemeral（短期）に留めることで、インスタンスの劣化に対処するのと、同じような意味合いを持つ。

So should you switch?

AWS offers an extremely comprehensive cloud service, with everything from DNS to database. Google does not. This makes building applications on AWS easier, since you have bigger building blocks. So if you don’t mind locking yourself into a vendor, you’ll be more productive on AWS.

AWS においては、DNS からデータベースにまで至る、きわめて包括的なクラウド･サービスが提供されている。 だが、Google は、そうではない。 あなたの開発するビルディング･ブロックが大規模なら、AWS におけるアプリケーション構築の方が容易になる。 つまり、ベンダー･ロックを厭わないなら、AWS 上で生産性を高めていけるだろう。

But that said, with Google Compute Engine, AWS has a formidable new competitor in the public cloud space, and we’ll likely be moving some of Scalr’s production workloads from our hybrid aws-rackspace-softlayer setup to it when it leaves beta. There’s a strong technical case for migrating heavy workloads to GCE, and I’ll be grabbing popcorn to eagerly watch as the battle unfolds between the giants.

しかし、それはそうとして、Google Compute Engine の登場により、AWS はパブリック･クラウド･スペースにおいて、手強いコンペティタを持つことになる。そして、GCE がベータから脱するとき、Scalr のプロダクト･ラインにおいても、Aws-Rackspace-Softlayer というハイブリッド設定に対して、手を加えることになるだろう。ヘビーなワークロードを、GCE に移行させるという、テクニカルなケースがあるはずだ。そして、巨人同士のバトルが展開される様子を、私はポップコーンを片手に、観客席から熱心に見守ることになるだろう。

Sebastian Stadil is the founder of Scalr, a simple, powerful cloud management suite, and SVCCG, the world’s largest cloud computing user group. When not working on cloud, Sebastian enjoys making sushi and playing rugby.

Note: Data scientists from LinkedIn, Continuuity, Quantcast and NASA will talk about their hardware and software stacks at our “guru panel” at Structure:Data next week, March 20-21, in New York City.

Disclosure: Automattic, maker of WordPress.com, is backed by True Ventures, a venture capital firm that is an investor in the parent company of this blog, GigaOM. Om Malik, founder of GigaOM, is also a venture partner at True.

Related research

• Metered IT: the path to utility computing October 2012
• Takeaways from the second quarter in cloud and data July 2012
• Migrating media applications to the private cloud: best practices for businesses December 2011

ーーーーー

かなりシリアスな内容のポストであり、GigaOm のサイトにも、数多くのコメントが寄せられています。 また、AWS の Jeff Barr さんも、『 The AWS Report – Sebastian Stadil of Scalr 』というタイトルで、Scalr の Sebastian Stadil さんへのインタビューを紹介しています。 そのタイミングが、この GigaOM へのポストの前日というのも、ちょっと気になるところです。 内容は、以下のコメントと Youtube 動画です。

In the latest episode of The AWS Report, I spoke with Sebastian Stadil of Scalr to learn more about their cloud management software:

ーーーーー

＜関連＞

Google Compute Engine は、どこで Amazon AWS を上回るのか？
Google Compute Engine の登場で、どのような影響が IssS 業界に？
Google Compute Engine の立ち位置を、RightScale が分析する _1
Google Compute Engine の立ち位置を、RightScale が分析する _2
Google の Knowledge Graph は、スタートレックを目指す！
Google I/O – 2013 の登録開始：しかし 48分間で売切れてしまった