Agile Cat — in the cloud

Amazon AWS には、リージョン間で 200倍もの速度差があるって?

Posted in .Selected, Amazon, Network by Agile Cat on June 12, 2013

Amazon Web Services speeds can vary by up to 200X depending on region
http://wp.me/pwo1E-6ex

June 3, 2013 –
John Koetsier
http://venturebeat.com/2013/06/03/amazon-web-services-speeds-can-vary-by-up-to-200x-depending-on-region/

_ VB Cloud

Australia is slow, Singapore is fast, and Europe to Oregon is twice as fast as Europe to California.

Australia は遅くて、Singapore が速い、そして、Europe から Oregon は、Europe から California に対して、2倍の速度を持つ。

Increasingly, we rely on “the cloud” to deliver web services. But the cloud is not one amorphous thing, and the cloud is not all equal. As every developer knows, what we generically call the cloud reduces down, ultimately, to physical servers and wires. And even within one company’s cloud — such as Amazon — there are vast differences in speed and optimization from region to region.

私たちは、Web でのサービスを提供するために、クラウド への依存度を高めている。しかし、クラウドは不定形のものではなく、また、すべてに対して等しいものでもない。そして、すべての開発者が認識しているように、一般に提唱されているものは、何かクラウドにおいて低減されるのかという視点であり、最終的には物理的なサーバーとワイヤーにまで落としこまれるものとなる。 しかし、たとえば Amazon などの、1つの企業が提供するクラウドの内側であっても、そのスピードと最適化において、リージョンごとに大きな格差が生じている。

What that ultimately means is that developers who don’t pay attention to cloud regions, as server debugging company Takipi discovered, can actually cause their apps to run 10 or even 200 times slower than necessary.

サーバーをデバッグする Takipi が発見したところによると、クラウドのリージョンに注意を払わなくてもよいはずの開発者たちが、そうではない状況に置かれているという現実がある。つまり、前述の最終的という言い回しが示すように、自分たちのアプリが、想定の 10 倍速で実行されたり、反対に 200倍も遅くなってしまう状況にあるのだ。

And Amazon doesn’t disclose any of that data. “We noticed that in many cases there’s 10X (or even more) difference in the performance of services due to AWS/S3 regions and external APIs,” Takipi co-founder Iris Shoor told me via email.

そして Amazon は、この種のデータについて、なにも開示していない。Takipi の Co-Founder である Iris Shoor は、「 私たちが気づいたのは、多くの場合(または殆どの場合)において、AWS/S3 のリージョンごとに、また、外部接続 API ごとに、サービスにおける性能差が 10倍もあることだ」 と、電子メールを介して伝えてきた。

In fact, Amazon’s cloud performance could vary in speed from region to region by as much as 200 times.

実際に、Amazon クラウドの性能は、リージョンごとの速度差が 200倍 にも達する場合もある。

For example, upload times vary significantly within each region. Uploading a file in Virginia to Amazon’s U.S. East cloud region, also in Virginia, takes three time longer than uploading a file in Singapore to AWS in Singapore. But it’s moving files between regions to serve differing international clients that will cause the greatest slowdowns: Shifting a file from Amazon’s São Paulo Region in Brazil to its Sydney, Australia region takes 200 times longer than shifting files between geographically close regions like Amazon’s U.S .West (Oregon) and U.S. West (California).

アップロード時間を例にして、その顕著なケースをリージョンごとに比較してみよう。Amazon の U.S. East クラウド・リージョンにある Virginia に、(Virginia から)ファイルをアップロードすると、AWS の Singapore リージョンに、(Singapore から)ファイルをアップロードする場合よりも、3倍もの時間がかかってしまう。そして、インターナショナル・クライアントたちは、リージョン間でのファイルの移動において、大幅なスローダウンという問題に直面していく。つまり、Brazil にある  Amazon の São Paulo リージョンから、Australia の Sydney リージョンへとファイルを移動すると、たとえば Amazon U.S.West (Oregon) から、U.S.West (California) へと移行する時と比べて、なんと 200倍もの時間がかかってしまうのだ。

“It seems that the new region — Australia — is by far the slowest,” Shoor says. “Uploading files to Australia can cause 10X latency versus other regions.”

そして Shoor は、「 新しいリージョンだと思われる Australia が、きわめて遅い。 Australia へ向けたファイルのアップロードは、他のリージョンと比較して、10倍ものレイテンシーを引き起こすことがある」と述べている。

And that makes sense — Australia is an island continent served by a limited number of international connections, and the file has a lot longer to go. But it is something to keep in mind when building global services.

そして、Australia はインターナショナル接続数が限られた島国であり、それらのファイルは長距離を旅することになる。しかし、それが理に適っているとしても、グローバル・サービスを構築する際には、心に留めておくべき点となる。

And some of the latency issues aren’t easily explainable due to geographical isolation — they’re more likely side effects of Amazon Web services system design. For example, there’s a big difference between uploading a file from Amazon’s S3 servers in Ireland to the U.S. East Coast and transferring the same file from the same location to the U.S. West Coast. The West Coast, Takipi says, will take twice the time, despite the fact that it’s only 25 percent further.

ただし、いくつかのレイテンシに関する問題は、地理的な距離だけ、簡単に説明できるではない。そこには、Amazon Web Services における、システム・デザインの副作用もあるだろう。たとえば、Ireland にある Amazon S3 Server から、U.S. East Coast と U.S. West Coast へ向けて、ファイルをアップロードする際にも大きな違いが生じる。その距離が 25% だけ遠くなるという事実にもかかわらず、時間的には 2倍もかかると、Takipi は述べている。

Even worse, Europe to California takes twice the time of Europe to Oregon: “It’s possible to make amazing optimizations just by changing the region,” says Shoor. “For example, choosing Oregon over CA for a company that serves the European market will cut the upload time by half.”

さらに悪いことに、Europe から California へ向けた場合は、Europe から Oregon へ向けた場合の、2倍もの時間を必要とする。それに対して Shoor は、「 リージョンを変更することで、驚くほどの最適化を達成できるはずだ。たとえば、European 市場をターゲットとする企業の場合は、California に替えて Oregon 選択するだけで、アップロード時間を半分に短縮できる」と述べている。

One of the main problems when hunting down the cause of slow services, Takipi says, is API latency. And regionality has a huge impact there, even if you’re as geographically optimized as you can possibly be.

サービスのスローダウンにおいて、その原因を追求するための重要は視点は、API のレイテンシにあると、Takipi は述べている。そして、リージョンの選択において、それが地理的に最適化されている場合であっても、大きな劣化が生じる可能性がある。

For example, Shoor says, even if your app is optimized for Australia and you’re using Amazon cloud services in Australia, Facebook’s API is 11 times slower down under, on average, than it is elsewhere.

あなたのアプリが Australia に最適化されていて、Australia の Amazon クラウド・サービスを使っている場合であっても、Australia  から Facebook の API を使うと、他のリージョンと比較して、平均で 11倍以上も遅くなると、Shoor は言う。

To monitor those slowdowns, Takipi is currently building “Project Barkdog,” a service to inform developers of slow APIs globally. Barkdog will likely launch in a couple of weeks, and will inform developers via email or Twitter when APIs that they’re using are slowing down.

こうした速度の低下を監視するために、グローバルにおける API の状況を開発者に通知する Project Barkdog を、Takipi はサービスとして構築している。 おそらく、Barkdog は数週間後には立ち上がり、それぞれの開発者たちが使用している API の速度が低下したときに、Mail や Twitter を介して通知することになる。

“It’s possible to speed up performance significantly,” Shoor says. “Amazon doesn’t share any of this data.”

「 パフォーマンスが、大幅に改善される可能性はある。 しかし、Amazon は何もデータを共有しないだろう」と、Shoor は発言している。

Image credits: Takipi, Amazon iCloud by John Koetsier, Globe by WoodleyWonderWorks/Flickr

ーーーーー

TAG index昨年の 2月に、『Amazon が安いのか? Hosting が安いのか? コスト分析モデルで比較する!』という抄訳をポストしましたが、そこではデータセンターからインターネットへのアウト・バウンド ・トラフィック量が、AWS を選択するかしないかの分岐点あると述べられていました。つまり、ネットワークをキャリアに依存する AWS の強みと弱みが、そこに集約されているのでしょう。 このポストも同様に、それを論点にしているように思えます。また、IDC によると、すべての IT ワークロードの、わずか 5% がクラウドに移行したに過ぎないようです。 それぞれのユーザーに最適化されたクラウド選びが、これからも、延々と繰り返されていくのでしょうね。__AC Stamp 2

ーーーーー

<関連>

Amazon AWS の年商は、どう見ても $ 1 billion を超えている
Microsoft が IaaS に進出 : ライバルは Amazon AWS だ!
マルチ・クラウドを活用する組織が、大勢を占めるようになってきた
なんと! 2013 Q1 のクラウド売上は $2B : 順位は AM>SF>MS>IBM>GO
空芯型ファイバーにより、光速の 99、7% に到達するテクノロジーとは?

 

Comments Off on Amazon AWS には、リージョン間で 200倍もの速度差があるって?

%d bloggers like this: