Agile Cat — in the cloud

Microsoft が IaaS に進出 : ライバルは Amazon AWS だ!

Posted in .Selected, Microsoft by Agile Cat on April 17, 2013

Microsoft Takes Aim at Amazon With a New Cloud Service
http://wp.me/pwo1E-5Z3

April 16, 2013 – By
NICK WINGFIELD
http://bits.blogs.nytimes.com/2013/04/16/microsoft-crashing-amazons-cloud-party/

image

As president of Microsoft’s server and tools division, a $19 billion-a-year business devoted to databases, servers and other software products, Satya Nadella has a predictable cast of competitors to worry about. There is Oracle, VMware, SAP and a bunch of other makers of highly technical products that make everyday services like banking and airline reservations work, even if the software running them is invisible to most consumers.

Microsoft の Server and Tools Division は、データベースおよびサーバーなどのソフトウェア・プロダクトを中心に、年間で $19 billion を稼ぎだす部門であるが、その President である Satya Nadella は、今後の競合において 2つの心配ごとを持っている。Oracle や、VMware、SAP といった数多くのメーカーが、大半の顧客には分からないかたちではあっても、その高度なテクノロジー・プロダクトを用いて、銀行業務や航空券予約といった日常的なサービスを提供している。

But one of Mr. Nadella’s competitors – Amazon – is not like the others.

しかし、Mr. Nadella から見たコンペティタは Amazon であり、それらのライバルたちとは異なる。

Satya Nadella

The Internet retailer is beloved by consumers for its seemingly infinite online selection of merchandise available for one-click purchasing, speedy delivery and Kindle e-readers. Out of view of most of the public, though, it has transformed itself into a huge player in the field of cloud computing. By renting capacity on the industrial-strength servers and beefy Internet connections in its data centers to anyone willing to pay for it, Amazon has become the virtual landlord of choice for technology start-ups, including the likes of Instagram and Foursquare.

このインターネットを利用する小売業者は、ワンクリックでの購入や、商品の迅速な配送、そして Kindle eリーダーで構成される、無限とも言えるオンラインの選択肢を提供することで、消費者の支持を受けている。しかし、一般的な視野から遮られたところで、同社はクラウド·コンピューティング分野における、巨大なプレーヤーへと自身を変革してきた。そのデータセンター内に配置された、パワフルなサーバーと潤沢なインターネット接続というキャパシティを借りることに、誰もが喜んで対価を支払うに至っている。それにより Amazon は、InstagramFoursquare をも含む、各種のテクノロジー・スタートアップが選ぶ、仮想の世界の家主となっている。

Microsoft wants a piece of the action. On Tuesday, the company is opening to general availability a new service that competes directly with Amazon’s cloud offering. (Microsoft has been testing the service with customers for the past year.) And to make sure it’s taken seriously, Microsoft is committing to match Amazon’s prices for its cloud service, which is known as the Elastic Compute Cloud.

Microsoft は、そのためのアクションを起こそうとしている。火曜日(4/16)に同社は、Amazon クラウド・サービスとダイレクトに競合する、新しいサービスを一般へ向けてオープンにした(Microsoft は、これまでの数年ににわたり、このサービスを顧客たちとテストしてきた)。その本気度を示すために、Microsoft クラウド·サービスの価格は、Amazon に合わせられる。 つまり、ターゲットは Elastic Compute Cloud として知られるものとなる。

“It’s a two-horse race between us and Amazon,” Mr. Nadella said in a phone interview last week, noting the Seattle location of its cloud rival, a short distance away from Microsoft’s Redmond, Wash., headquarters.

「 それは、私たちと、Amazon との間の、二頭立てのレースだ 」と、 Mr. Nadella は、先週の電話インタビューで語っている。つまり、Microsoft の HQ がある Redmond, Wash から、それほど遠くない Seattle のクラウド・ライバルを意識しているのだ。

Actually, that may be wishful thinking on Mr. Nadella’s part. Google and Rackspace are among the other companies that are fighting with Microsoft for the number-two spot in the cloud market.

しかし、実際のところ、それは希望的観測に過ぎないかもしれない。クラウド市場における No.2 の座を、Microsoft と争う企業として、Google と Rackspace の存在があるのだ。

The cloud represents a profound threat to Microsoft’s traditional business of selling software that people install on their machines. As a result, the company’s executives for some time now have been blaring their own plans to become serious cloud players.

このクラウドは、ユーザーが自分のマシンにインストールするための、ソフトウェアを販売するという、Microsoft における従来からのビジネスに対して、深刻な脅威となってきている。その結果として、これまでの期間において、同社の幹部たちは、自身がクラウド·プレーヤーになるという計画をささやき続けてきた。

For its first foray into the business a few years ago with a service called Windows Azure, Microsoft settled on an approach that played to its strengths, offering customers the ability to rent applications like databases and servers for broadcasting video. Amazon, in contrast, was known for more minimalist, low-level services — storage space on its servers, computing time and a share of its Internet connections.

Microsoft は Windows Azure というサービスで、このフィールドに数年前から進出している。そして、顧客に対して、ビデオ・ブロードキャストのためのデータベースやサーバーといった、応用形態をレンタルするというアプローチで、この世界に定住している。それとは対照的に、Amazon はコストを削減するための低レベル・サービスを目指し、そのサーバー上のストレージ・スペースや、コンピューティング・リソース、そしてインターネット接続などを、共有するビジネスを展開してきた。

If Microsoft’s offering was akin to a garage space outfitted with an arsenal power of tools, Amazon was renting just the garage.

Microsoft がパワフルなツールで充たされたガレージを提供するなら、Amazon はガレージ・スペースだけを提供してきたことになる。

Microsoft’s approach had appeal – the company says it has 200,000 Windows Azure customers – but not as much as what Amazon is offering. While the big companies targeted by Microsoft for its initial Windows Azure services will likely move to aggressively embrace the cloud at some point, the most ardent cloud supporters right now are technically sophisticated start-ups. And what they want is what Amazon – and starting this week, perhaps Microsoft – has to offer.

Microsoft のアプローチは魅力的であり、20万の Windows Azure の顧客を抱えていると言うが、Amazon が提供するものは、その比ではない。 初期の Windows Azure サービスにおいて、Microsoft がターゲットにした大企業たちが、いくつかの点においてクラウドを受け入れるようになってきたが、いまの時代で、最も熱心なクラウド・サポーターはというと、技術的に洗練されたスタートアップたちとなる。そして、彼らは行いたいことは、Amazon が提供する環境で実現されている。 そこへ向けて、おそらく Microsoft は、今週から立ち向かっていくのだ。

“They mistimed the market for sure,” James Staten, an analyst at Forrester Research, said of Microsoft.

「 彼らが、確実にマーケットを手にしたいなら、時宣を失っている」 と、Forrester Research のアナリストである James Staten は、Microsoft について発言している。

In Forrester’s surveys of cloud developers, roughly 70 percent say they are using Amazon’s infrastructure, while about 30 percent say they are using Microsoft. (Many customers spread their business across several cloud vendors.)

Forrester のクラウド・デベロッパー調査によると、彼らの 約70% が Amazon のインフラを使用していると言い、約 30% がマイクロソフトを使用していると言っている(多くの顧客たちが、複数のクラウド·ベンダーをまたぐかたちで、ビジネスを広げている)。

Mr. Nadella, a Microsoft veteran, said the company is well positioned to become a stronger player in cloud computing because it has a more diverse portfolio of offerings than Amazon, including, of course, software that big customers can install in their own data centers if they want to take full control of their online services.

Microsoft のベテランである Mr. Nadella は、クラウド·コンピューティングにおける強者になるための、適切なポジションに同社が居ると発言している。なぜなら、Microsoft には、Amazon よりも多様なポートフォリオがあり、たとえば、オンライン・サービスをフル制御をしたい場合には、大手の顧客は自身のデータセンターに、Microsoft のソフトウェアをインストールできると、付け加えている。

“It’s still the early part of the cloud market,” Mr. Nadella said. “Clearly they have done a good job in one segment of it. But it will play out.”

「 いまのクラウド・マーケットは、依然として黎明期にある。 そして、1つのセグメントにおいて、彼らは良い仕事をしたが、戦いは延々と続く」と Mr. Nadella は発言している。

ーーーーー

TAG index文中に記されているように、Amazon EC2 の前に、Google の Compute Engine および、Rackspace の OpenStack と戦うことになるのでしょう。AWS は eコマースで鍛えられたモデルが特徴であり、また、GCE は Google の身体能力を受け継ぎ、OpenStack はユーザーが作るクラウドという、それぞれの特色があります。そして、プロプライエタリである Windows は、強みであり弱みでもあると思います。 でも、こうして、IaaS での橋頭堡を確保しておけば、それこそ、将来において、たとえば OpenStack もホストするなど、プロプライエタリとオープンの二本立てという、自由自在な展開も可能になります。 面白くなりますね! image

ーーーーー

Information Week : Microsoft Azure Public Cloud Matches Amazon Prices
GigaOM: At long last, Microsoft is ready to compete head on with AWS
Ars Technica : Microsoft aims at Amazon with Azure virtual Windows IaaS
S/N Ratio (by SATO Naoki) : Windows Azure: IaaSの正式リリース (GA)

ーーーーー

<関連>

PDC10 後の Windows Azure は、AWS とガチンコ勝負か?
PDC と Silverlight について – Bob Muglia
Bob Muglia の辞任は、Windows Azure にとって悲運の呪文に?
Microsoft が OpenStack に参加する背景を GIGAOM が解説
Microsoft を去る Ray Ozzie へ、Steveb からのメール

 

Google Compute Engine 対 Amazon EC2 : 性能をチャートで比較する

Posted in .Chronicle, .Selected, Amazon, Google, Research by Agile Cat on March 17, 2013

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/

_ Gigaom

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: 昨年の 6月に 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

ーーーーー

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

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分間で売切れてしまった

 

GW プチ特集 – Amazon の 2011年 1月~4月

Posted in Amazon by Agile Cat on May 7, 2011

なんといっても、話題が満載です ・・・

Amazon AWS は、何の説明も必要がないほど、パブリック・クラウドの代表格として認められているサービスです。 その市場の規模および、最先端を走るテクノロジーなど、どれをとってもナルホドと思わせてくれます。 そんな中、この 4月に起こってしまった、アメリカ東部でのサービス停止が、パブリック・クラウドの適切な使い方について、利用者側に再認識させる結果をもたらすことになりました。 ーーー __AC Stamp 2 

ーーーーー

January 14 Amazon Elastic MapReduce のアップデート – 5TB オブジェクトにも対応

January 19 : AWS 用のモバイル・アプリを作るなら、Amazon Appstore へ登録を!

January 20 : Amazon は Beanstalk で、Microsoft と Salesforce に対抗していく!

January 25 : Elastic Beanstalk とは? – Amazon CTO の Werner Vogels が語る

January 26 : Amazon がバルク・メール・ソリューションを発表

January 31 : Amazon S3 のオブジェクト数が 2620 億個に!

February 17 : Real World NoSQL シリーズ – Netflix における Amazon SimpleDB

March 3 : Amazon AWS Region in Tokyo をオープンしました — Jeff;

March 10 : Amazon CTO – Werner Vogels が、クラウド・エコシステムを語る

March 24 : Angry Birds がタダで欲しければ、Amazon Appstore for Android へ急げ!

March 31 : 早くも登場! Amazon Cloud Player for Web & Android

April 23 : Amazon に起こった大規模ダウンタイムを分析する

April 25 : Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1

April 27 : Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2

April 30 : Amazon の障害に関する オフィシャル・レポートを解説する

ーーーーー

今回の障害は、Amazon だけが考えるべきものではなく、他のクラウド・プロバイダーも考えるべき、とても重要なプラクティスを提供してくれたと捉えるべきなのでしょうね。 ーーー __AC Stamp 2

ーーーーー

<関連>

Amazon 2010 総集編 Agile_Cat 版

 

Amazon の障害に関する オフィシャル・レポートを解説する – Data Center Knowledge

Posted in .Selected, Amazon by Agile Cat on April 30, 2011

Amazon: Networking Error Caused Cloud Outage
April 29th, 2011 : Rich Miller
http://www.datacenterknowledge.com/archives/2011/04/29/amazon-networking-error-caused-cloud-outage/

_ DC Knowledge

Last week’s lengthy outage for the Amazon Web Services cloud computing platform was caused by a network configuration error as Amazon was attempting to upgrade capacity on its network. That error triggered a sequence of events that culminated in a “re-mirroring storm” in which automated replication of storage volumes maxed out the capacity of Amazon’s servers in a portion of their platform.

先週の Amazon Web Services クラウド・コンピューティング・プラットフォームにおける長時間におよぶサービス停止は、Amazon がネットワーク・キャパシティを引き上げた際の、ネットワーク・コンフィグレーション・エラーが原因だった。 そのエラーにより、ストレージ・ボリュームの自動リプリケーションが、Amazon プラットフォームの一部分で1部で、キャパシティを限界まで使い切ってしまった。そして、「再ミラーリングの嵐」の反復となる、イベントのシーケンスを引き起こした。Image(5)

Amazon provided a detailed incident report this morning in which it discussed the outage, apologized to customers and outlined plans to make its platform more resilient in the future. The company also issued a 10-day credit to customers using the US East Region at the time of the outage.

そして、今朝(4/29)になって Amazon は、このサービス停止に関する詳細なインシデント・レポートを提供して、顧客に対して陳謝し、そのプラットフォームの弾力性を将来へ向けて強化する計画を概説した。さらに同社は、この  US East Region におけるサービス停止で被害を受けた顧客に、10日間のクレジットを発行した。

Traffic Shift ‘Executed Incorrectly’

The incident began at 12:47 a.m. Pacific time on April 21, when Amazon began a network upgrade in a single availability zone in the US East region. “During the change, one of the standard steps is to shift traffic off of one of the redundant routers in the primary EBS (Elastic Block Storage) network to allow the upgrade to happen,” Amazon said. “The traffic shift was executed incorrectly and rather than routing the traffic to the other router on the primary network, the traffic was routed onto the lower capacity redundant EBS network.”

『 この変更の際に、主要な EBS(Elastic Block Storage)ネットワークで、余剰のルーターにトラフィックをシフトするという、標準的なステップの 1つが、アップグレードを引き起こした。 そしてトラフィックのシフトが、間違って実施された。 つまり、主要なネットワーク上のルーターへ向けた、トラフィックのルーティングが行われるのではなく、よりキャパシティの低い予備的な EBS ネットワークにルーティングされてしまった 』と、 Amazon は発言している。

AmazonThe traffic routing error overloaded the storage network. When network connectivity was restored, volumes stored on EBS began an automated mirroring process designed to preserve data during system failures. “In this case, because the issue affected such a large number of volumes concurrently, the free capacity of the EBS cluster was quickly exhausted, leaving many of the nodes ‘stuck’ in a loop, continuously searching the cluster for free space,” Amazon reported. “This quickly led to a ‘re-mirroring storm,’ where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica.”

このトラフィックのルーティング・エラーが、ストレージ・ネットワークに負担をかけ過ぎることになった。 そして、ネットワーク接続が復活したとき、 EBS にストアされたボリュームが、システム障害の間にデータを維持するようデザインされている、自動化されたミラーリングプロセスを開始した。 『 こうした状況において、大量のボリュームに対する影響が同時に発生したため、EBS クラスタ内の余剰のキャパシティは短時間で使い尽くされ、多数のノードをループ状態にスタックさせ、空きスペースを探すための、クラスタ・サーチを繰り返すことになった 。そして、たちどころに「再ミラーリング嵐」が導かれ、新しいレプリカのために必要なストレージ・スペースがサーチされる間に、多数のボリュームが急激にスタックしていくという状況に陥った』と、Amazon はレポートしている。

The company said it would take steps to improve its customer communication, which was the focus of sharp criticism during the outage. The incident report was released early Friday, as global media attention focused on the royal wedding in England.

同社は、顧客とのコミュニケーションを改善するためのステップをとり、今回のサービス停止の間に生じた痛烈な批判に取り組んでいく。 このインシデント・レポートは、グローバル・メディアがEngland のロイヤル・ウェディングに釘付けになってる、金曜日の朝にリリースされた。

Amazon: No ‘Significant’ Impact to Other Zones

Amazon’s report sought to deflect criticism that the outage affected multiple availability zones, a key point of contention for some unhappy customers. In theory, using multiple availability zones should allow customers to continue to operate if a single availability zone experiences a failure. There were numerous reports that EBS access was impaired across multiple availability zones, but Amazon challenged the notion that this was widespread.

この Amazon レポートは、今回のサービス停止が多数のアベイラブル・ゾーンに影響を与えたという批判と、いくつかの不幸な顧客における論点を、静めるように努めている。 理論上、マルチ・アベイラブル・ゾーンの利用により、シングル・アベイラブル・ゾーンで障害が発生しても、運用の継続は可能になる。しかし、 多数のアベイラブル・ゾーンを横断するかたちで、EBS へのアクセスが損なわれていたという、多数のレポートがある。そして Amazon は、それが広範囲におよんだという指摘に、異議を唱えている。

“While our monitoring clearly shows the effect of the re-mirroring storm on the EBS control plane and on volumes within the affected Availability Zone, it does not reflect significant impact to existing EBS volumes within other Availability Zones in the Region,” the incident report states. “We do see that there were slightly more ‘stuck’ volumes than we would have expected in the healthy Availability Zones, though still an extremely small number. To put this in perspective, the peak ‘stuck’ volume percentage we saw in the Region outside of the affected Availability Zone was less than 0.07%.”

『 私たちのモニタリングにより、EBS のコントロール・プレーンおよび、影響を受けた Availability Zone 内のボリュームに対して、再ミラーリング嵐が吹き荒れたことが明らかになっている。 しかし、他の Availability Zones 内の既存 EBS ボリュームに対して、重大な影響はおよんでいない。  私たちは、健全だと思っていた Availability Zones に、少量のスタックしたボリュームが存在するのを確認しているが、それれは、きわめて小さなものだ。 その全容を確認するために、影響を受けた Availability Zone 外の Reagion を調べたが、スタックしているボリュームは、最大でも 0.07% 以下であった 』 と、そのインシデント・レポートには述べられている。

Amazon also created the AWS Architecture Center to share information on best practices for deploying cloud assets reliably. The company scheduled a series of webinars to educate customers on their options for designing their AWS deployments to survive outages.

また、Amzon は、クラウド資産を確実にディプロイするための、ベスト・プラクティスに関する情報を共有するために、AWS Architecture Center を開設した。 そして、さらに、耐障害性に富んだ AWS ディプロイメントをデザインするために、カスタマーに提供されているオプションを紹介する Webinar シリースを予定している。

The company also apologized for the outage’s impact on customers, and vowed to take steps to prevent a recurrence. “As with any significant operational issue, we will spend many hours over the coming days and weeks improving our understanding of the details of the various parts of this event and determining how to make changes to improve our services and processes,” the AWS team wrote.

そして同社は、今回のサービス停止について顧客に陳謝し、その再発を防止するための処置をとると約束した。 『 運用における重要な問題と同様に、私たちは今後の数日あるは数週のうちに、この現象における多様なパートを、詳細まで理解・改善する。そして、私たちのサービスとプロセスを改善するために、どのよな変更が必要になるのかを判断・決定するために、充分な時間を費やしていく』と、AWS チームは記述している。

ーーーーー

Amazon だからこそ、こうしたトラブルに多くの顧客が巻き込まれ、また、世界の注目を浴びてしまいます。 そして、今回における Amazon の対処により、今後のクラウド・トラブル処理に関する規範が示されることになるのでしょう。 たいへんでしょうが、頑張ってください! ーーー __AC Stamp 2

ーーーーー

<関連>

Amazon に起こった大規模ダウンタイムを分析する – Data Center Knowledge
Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1
Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2

Posted in .Chronicle, Amazon by Agile Cat on April 27, 2011

The AWS Outage: The Cloud’s Shining Moment
Image(25)[5]By
George Reese
April 23, 2011
http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html

image[3]

ーーーーー

初めてのからは、こちらから ど~ぞ!
<その1>
Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1

ーーーーー

Applied "Design for Failure"

In presentations, I refer to the "design for failure" model as the AWS model. AWS doesn’t have any particular monopoly on this model, but their lack of persistent virtual machines pushes this model to its extreme. Actually, best practices for building greenfield applications in most clouds fit under this model.

これまでの私のプレゼンテーションでは、AWS モデルのような Design for Failure モデルについて述べてきた。 このモデルを、AWS が独占しているわけではないが、仮想マシンの永続性という観点を取り除くことで、このモデルを極限まで高めている。 実際のところ、このモデルにフィットしたクラウドで、将来のアプリケーションを構築する上でベスト・プラクティスだと言えるだろう。

Image(26)[4]

The fundamental principle of "design for failure" is that the application is responsible for its own availability, regardless of the reliability of the underlying cloud infrastructure. In other word, you should be able to deploy a "design for failure" application and achieve 99.9999% uptime (really, 100%) leveraging any cloud infrastructure. It doesn’t matter if the underlying infrastructural components have only a 90% uptime rating. It doesn’t matter if the cloud has a complete data center meltdown that takes it entirely off the Internet.

Design for Failure の基本的な原則は、基礎をなすクラウド・インフラストラクチャの信頼性にかかわらず、対象となるアプリケーション自身が、その可用性について責任を負うというものである。 言い換えると、Design for Failure 型のアプリケーションをディプロイし、クラウド・インフラストラクチャに各種の強化策を適用することで、99.9999% のアップタイム(実際は 100%)が達成できるようになるはずだ。 基礎をなすインフラストラクチャ・コンポーネントが、たった 90% のアップタイムを有している状況であっても、それは重要ではない。 極端な話、1つのデータセンターが完全なメルトダウンを起こし、そのインターネット接続を完全に喪失したとしても、それは重要ではない。

There are several requirements for "design for failure":

  • Each application component must be deployed across redundant cloud components, ideally with minimal or no common points of failure
  • Each application component must make no assumptions about the underlying infrastructure—it must be able to adapt to changes in the infrastructure without downtime
  • Each application component should be partition tolerant—in other words, it should be able to survive network latency (or loss of communication) among the nodes that support that component
  • Automation tools must be in place to orchestrate application responses to failures or other changes in the infrastructure (full disclosure, I am CTO of a company that sells such automation tools, enStratus)

Design for Failure には、いくつかの要件がある:

  • それぞれのアプリケーション・コンポーネントは、冗長性のあるクラウド・コンポーネントのいたるところにディプロイされる必要がある。 そして、理想的には、共通のフェイル・ポイントを、可能なかぎり避けるべきだ。
  • それぞれのアプリケーション・コンポーネントは、基礎をなすインフラストラクチャの可用性を仮定をしてはならない。つまり、ダウンタイムを伴うこと無く、インフラストラクチャの変化に順応しなければならない。
  • それぞれのアプリケーション・コンポーネントは、パーティション・トレラントでなければならない。 言い換えると、対象となるコンポーネント・サポートするノード間での、ネットワーク・レイテンシー(あるいは通信の喪失)においても、生き残らなければならない。
  • オートメーション・ツールは、インフラストラクチャの障害もしくは変更に対する、アプリケーションの反応を調整するために、適切な位置に配置されなければならない。(私が、自動化ツールを提供する enStratus の CTO であることを明らかにしておく)

Applications built with "design for failure" in mind don’t need SLAs. They don’t care about the lack of control associated with deploying in someone else’s infrastructure. By their very nature, they will achieve uptimes you can’t dream of with other architectures and survive extreme failures in the cloud infrastructure.

Design for Failure を前提に構築されたアプリケーションは、SLA を必要としない。 それらのアプリケーションは、他の誰かが提供するインフラストラクチャにディプロイされた、何ものかに関連するコントロールの欠如を気にかけない。 その本質により、他のアーキテクチャでは想像することもできないアップタイムを達成し、クラウド・インフラストラクチャにおける極限の障害からも生き残るだろう。

Let’s look at a design for failure model that would have come through the AWS outage in flying colors:

  • Dynamic DNS pointing to elastic load balancers in Virginia and California
  • Load balancers routing to web applications in at least two zones in each region
  • A NoSQL data store with the ring spread across all web application availability zones in both Virginia and California
  • A cloud management tool (running outside the cloud!) monitoring this infrastructure for failures and handling reconfiguration

AWS での障害を乗り切ったであろう、適切な Design for Failure モデルを確認していく:

  • Dynamic DNS が、Virginia と California のエラスティックなロード・バランサを指し示している。
  • Web アプリケーションをルーティングするロード・バランサーが、最低でも、それぞれのリージョンにおける 2つのゾーンに配置されている。
  • リングを用いる NoSQL データストアが、Virginia と California における全ての Web アプリケーション・アベイラブル・ゾーンに展開されている。
  • クラウド・マネージメント・ツール(対象となるクラウドの外側で動いている!)が、障害を起こしたインフラストラクチャをモニタリングし、再コンフィグレーションを行う。

Upon failure, your California systems and the management tool take over. The management tool reconfigures DNS to remove the Virginia load balancer from the mix. All traffic is now going to California. The web applications in California are stupid and don’t care about Virginia under any circumstance, and your NoSQL system is able to deal with the lost Virginia systems. Your cloud management tool attempts to kill off all Virginia resources and bring up resources in California to replace the load.

障害の発生時には、全体的な制御が、このマネージメント・ツールと California のシステムに切り替わる。 そして、このマネージメント・ツールにより DNS が再コンフィグレーションされ、共存している Virginia のロード・バランサーが切り離される。そして、すべてのトラフィックが California へと向かうことになる。しかし、California の Web アプリケーションはワケが分からないため、いかなる状況下においても、Virginia のことを気にかけることはない。したがって、失われた Virginia システムを取り扱うことになるが、そこでは NoSQL システムの利用が可能となる。そのとき、クラウド・マネージメント・ツールは、すべての Virginia リソースを KILL し、その負荷を切り替えるために、 リソースを California へ送り出そうと試みる。

Voila, no humans, no 2am calls, and no outage! Extra bonus points for "bursting" into Singapore, Japan, Ireland, or another cloud! When Virginia comes back up, the system may or may not attempt to rebalance back into Virginia.

ジャジャーン! 夜中の 2時に人はいないし、電話もない。 システムの停止もなし! 特別なボーナス・ポイントを、Singapore と、Japan と、Ireland、そして、もう 1つのクラウドにくれてやろう! Virginia が戻って来るとき、このシステムは、Virginia の中で再調整を試みるかもしれない。あるいは、試みないかもしれない。

Amazon[3]Relational Databases

OK, so I neatly sidestepped the issue of relational databases. Things are obviously not so clean with relational database systems and the NoSQL system almost certainly would have lost some minimal amounts of data in the cut-over. If that data loss is acceptable, you better not be running a relational database system. If it is not acceptable, then you need to be running a relational database system.

それで OK。 リレーショナル・データベースの問題を、私はキチッと回避した。 しかし、リレーショナル・データベース・システムにおいて、ものごとは、それほど単純ではない。そして、NoSQL システムに関しては、その切替時において、少量のデータを失ったことが確実視される。 そのデータ喪失が受容できる場合には、リレーショナル・データベース・システムは走らせない方が良い。そして、受容できない場合は、リレーショナル・データベース・システムを走らせる必要がある。

A NoSQL database (and I hate the term NoSQL with the passion of a billion white hot suns) trades off data consistency for something called partition tolerance. The layman’s description of partition tolerance is basically the ability to split your data across multiple, geographically distinct partitions. A relational system can’t give you that. A NoSQL system can’t give you data consistency. Pick your poison.

NoSQL データベース(私は、この名前が大嫌いだ)は、パーティション・トレランスと呼ばれる、データ一・コンシステンシーに関するトレードオフを行う。 パーティション・トレランスは素人の言い方であるが、基本的には、地理的に分離されたマルチ・パーティションを俯瞰して、データをスプリットする能力のことである。 リレーショナル・システムは、それを提供できない。 また、NoSQL システムは、データ・コンシステンシーが提供できない。 したがって、いずれかの毒を受け入れることになる。

Sometimes that poison must be a relational database. And that means we can’t easily partition our data across California and Virginia. You now need to look at several different options:

  • Master/slave across regions with automated slave promotion using your cloud management tool
  • Master/slave across regions with manual slave promotion
  • Regional data segmentation with a master/master configuration and automated failover

その毒が、リレーショナル・データベースにならざえるを得ない場合もある。 そして、それは、California と Virginia をまたいだデータの分割が、容易に出来なくなることを示している。したがって、いくつかの選択肢を検証する必要がある:

  • クラウド・マネージメント・ツールを用いた、自動スレーブ・プロモーションによる、リージョンをまたいだマスター/スレーブ。
  • 手動スレーブ・プロモーションによる、リージョンをまたいだマスター/スレーブ。
  • マスター/マスターのコンフィグレーションおよび、自動フェイルオーバーを用いた、リージョナル・データ・セグメンテーション。

There are likely a number of other options depending on your data model and DBA skillset. All of them involve potential data loss when you recover systems to the California region, as well as some basic level of downtime. All, however, protect your data consistency during normal operations—something the NoSQL option doesn’t provide you. The choice of automated vs. manual depends on whether you want a human making data loss acceptance decisions. You may particularly want a human involved in that decision in a scenario like what happened this week because only a human really can judge, "How confident am I that AWS will have the system up in the next (INSERT AN INTERVAL HERE)?"

おそらく、データ・モデルと DBA スキルセットに依存した、数多くの選択肢があるはずだ。 それら全てが、California リージョンでシステムをリカバーするときの、データ喪失の可能性に関連するだけではなく、ダウンタイムの基本的なレベルにも関連する。 しかし、すべての選択肢が、通常のオペレーションにおいては、データ一・コンシステンシーを保持する。(NoSQL オプションでは提供できない) また、自動と主導の選択は、人手によるデータ喪失を受容できるのか否かに応じて、決定されるべきである。 たとえば、今週に起きたシナリオでは、その判断に関与できる人が必要になるだろう。なぜなら、『 どのようにしたら、来週に AWS が復活すると判断できるのか?』という問に、判断を下せる人が限られているからである。

The Traditional Model

As its name implies, the "design for failure" requires you to design for failure. It therefore significantly constrains your application architecture. While most of these constraints are things you should be doing anyways, most legacy applications just aren’t built that way. Of course, "design for failure" is also heavily biased towards NoSQL databases which often are not appropriate in an enterprise application context.

その名前が暗示するように、この Design for Failure は、失敗のためのデザインを要求する。 したがって、アプリケーションのアーキテクチャが、大幅に制約されることになる。 それらの制約が必要になるにしても、大半のレガシー・アプリケーションは、その方式では作られていない。 もちろん、 Design for Failure は、 NoSQL データベースに大きく偏ったものであり、エンタープライズ・アプリケーションのコンテキストでは、多くの場合に不適切なものとなる。

The traditional model will support any kind of application, even a "design for failure" application. The problem is that it’s often harder to build "design for failure" systems on top of the traditional model because most current implementations of the traditional model simply lack the flexibility and tools that make "design for failure" work in other clouds.

しかし、この従来からのモデルは、仮に Design for Failure  であるにしても、あらゆる種類のアプリケーションをサポートするだろう。 ここでの問題は、従来からのモデル上に Design for Failure システムを構築することが、多くのケースで困難を伴うところにある。その理由は、それらの従来からのモデルの、現時点における大半の実装が柔軟性に欠け、また、他のクラウドでも Design for Failure をもたらすために機能する、ツールが存在しない点にある。

Control, SLAs, Cloud Models, and You

When you make the move into the cloud, you are doing so exactly because you want to give up control over the infrastructure level. The knee-jerk reaction is to look for an SLA from your cloud provider to cover this lack of control. The better reaction is to deploy applications in the cloud designed to make your lack of control irrelevant. It’s not simply an availability issue; it also extends to other aspects of cloud computing like security and governance. You don’t need no stinking SLA.

クラウドへの移行において、誰もがきわめて慎重になるのは、インフラストラクチャ・レベルのコントロールを断念したくなるからである。 そこでのパターン化した反応は、コントロールの欠落をカバーするために、対象となるクラウド・プロバイダーからの SLA の受け入れることである。 それよりも好ましい反応は、コントロールの欠落とは無関係なかたちにデザインされたクラウドに、アプリケーションをディプロイすることである。 それは、単なる可用性の問題ではなく、セキュリティやガバナンスといった、クラウド・コンピューティングにおける他の局面におよぶものとなる。そして、あなたは、ひどい SLA を必要としなくなる。

As I stated earlier, this outage highlights the power of cloud computing. What about Netflix, an AWS customer that kept on going because they had proper "design for failure"? Try doing that in your private IT infrastructure with the complete loss of a data center. What about another AWS/enStratus startup customer who did not design for failure, but took advantage of the cloud DR capabilities to rapidly move their systems to California? What startup would ever have been able to relocate their entire application across country within a few hours of the loss of their entire data center without already paying through the nose for it?

この原稿を書き始めたとき、今回のサービス停止により、クラウド・コンピューティングのパワーが際立つと述べた。 AWS の顧客である Netflix は、適切な  Design for Failure を独自に有していたから、サービスを継続できたのだろうか? プライベートな ITインフラストラクチャで、データセンターの完全な喪失に備えて、試してみるのも良いだろう。 別の AWS/enStratus スタートアップは、Design for Failure を採用していなかったが、cloud DR の機能を活用して、そのシステムを California に素早く移行できたのだろうか? そして、どのようなスタートアップが、法外な金額を支払うこともなく、データセンター全体の喪失から数時間のうちに、アプリケーション全体を他国へ移動できるのだろうか?

These kinds of failures don’t expose the weaknesses of the cloud—they expose why the cloud is so important.

この種の障害が、クラウドの脆弱性を露呈するというのは間違いだ。 むしろ、クラウドの重要性を強調すると、理解すべきだ。

<終わり>

Tags:

ーーーーー

訳し終わって、ふぅ~~~ っとため息が出るようなコンテンツでした。 George Reese さんの総括とビジョンは、Amazon だけではなく、Rackspace にも、Microsoft にも、Google にも、とても有難いものになったはずです。 また、今回の障害を取り上げて、『 ほら見たことか 』と叩くのは容易ですが、それは意味のないことのように思えます。ITに に携わる、すべての人々が、真正面からクラウドを捉える、とても良いキッカケになるはずです。 ーーー __AC Stamp 2

ーーーーー

<関連>

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1
Amazon に起こった大規模ダウンタイムを分析する – Data Center Knowledge

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1

Posted in .Chronicle, .Selected, Amazon by Agile Cat on April 25, 2011

The AWS Outage: The Cloud’s Shining Moment
Image(25)By
George Reese
April 23, 2011
http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html

image

So many cloud pundits are piling on to the misfortunes of Amazon Web Services this week as a response to the massive failures in the AWS Virginia region. If you think this week exposed weakness in the cloud, you don’t get it: it was the cloud’s shining moment, exposing the strength of cloud computing.

今週に AWS Virginia リージョンで起こった大規模な障害に対する反応として、かなりの数のクラウド評論家たちが、Amazon Web Servicesの失敗に尾ひれを付けている。 しかし、クラウドが脆弱さを露呈したと考えるなら、あなたはクラウドの輝く瞬間を見逃し、また、クラウド・コンピューティングのパワーを理解していないことになる。

Image(26)

In short, if your systems failed in the Amazon cloud this week, it wasn’t Amazon’s fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon’s cloud computing model. The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider.

要するに、あなたのシステムが、今週に Amazon クラウドで障害を起こしていても、それは Amazon の過失ではない。 あなたは、このサービス停止を、当然の事として受容すべきリスクとみなしたのか、さもなければ、Amazon クラウド・コンピューティング・モデルを設計をし損ねただけだ。 クラウド・コンピューティングの強さとは、アプリケーションの可用性に関するコントロールが、アプリケーション・デベロッパーの手に委ねられることにある。 つまり、あなたの IT スタッフや、データセンターの限界、そして、マネージ・サービス・プロバイダーに委ねられるのではない。

The AWS outage highlighted the fact that, in the cloud, you control your SLA in the cloud—not AWS.

また、今回の AWS におけるサービス停止により、クラウドにおける SLA は、あなたが自身がコントロールすべきことであり、それを AWS に委ねてはならないという事実が浮き彫りにされた。

The Dueling Models of Cloud Computing

Until this past week, there’s been a mostly silent war ranging out there between two dueling architectural models of cloud computing applications: “design for failure” and traditional. This battle is about how we ultimately handle availability in the context of cloud computing.

一週間前まで、クラウド・コンピューティング・アプリケーションにおいては、2つのアーキテクチャ・モデルの間に、つまり、Design for Failure(障害を前提としたデザイン)と、従来からのデザインの間に、出口の見つからない静かな論争があった。その戦いは、クラウド・コンピューティング環境における可用性の、究極的な処理方法に関するものである。

The Amazon model is the “design for failure” model. Under the “design for failure” model, combinations of your software and management tools take responsibility for application availability. The actual infrastructure availability is entirely irrelevant to your application availability. 100% uptime should be achievable even when your cloud provider has a massive, data-center-wide outage.

Amazon モデルは、その Design for Failure モデルである。 この Design for Failure モデルにおいては、あなたのソフトウェアとマネージメント・ツールの組み合わせが、アプリケーションの可用性に対して責任を負う。そして、実際のインフラストラクチャにおける可用性は、あなたのアプリケーションの可用性とはまったく無関係である。 したがって、対象となるクラウド・プロバイダーが、データセンターごと機能を停電するという、大規模なダウンタイムを生じるときでさえ、100% のアップタイムを達成できなければならない。

Most cloud providers follow some variant of the “design for failure” model. A handful of providers, however, follow the traditional model in which the underlying infrastructure takes ultimate responsibility for availability. It doesn’t matter how dumb your application is, the infrastructure will provide the redundancy necessary to keep it running in the face of failure. The clouds that tend to follow this model are vCloud-based clouds that leverage the capabilities of VMware to provide this level of infrastructural support.

大半のクラウド・プロバイダーが、この Design for Failure から派生した、なんらかのモデルにしたがっている。 しかし、その基礎をなすインフラストラクチャにおいて、従来からのモデルに従順なプロバイダは、可用性に対する究極の責任を取らざるを得ない。 そして、どれほど稚拙なアプリケーションであっても、それが重要になることはない。 障害に直面した時であっても、アプリケーションを実行するために必要な冗長性が、対象となるインフラストラクチャから提供されるだろう。 こうしたモデルに追随するクラウドとしては、vCloud ベース・クラウドがある。 そこでは、必要とされるレベルのインフラストラクチャが、VMware の機能を高めることで実現されている。

The advantage of the traditional model is that any application can be deployed into it and assigned the level of redundancy appropriate to its function. The downside is that the traditional model is heavily constrained by geography. It would not have helped you survive this level of cloud provider (public or private) outage.

この、従来からのモデルにおけるアドバンテージは、いかなるアプリケーションであってもディプロイし、その機能に適切とされる冗長性のレベルを割り当てられる点にある。 その反面、この従来型モデルは、地理的な制約を受けるという欠点を持つ。 したがって、今回のような、クラウド・プロバイダ(public or private)がもたらすレベルのサービス停止では、あなたのアプリケーションの可用性を保持する上で、何の役にも立たないだろう。

The advantage of the “design for failure” model is that the application developer has total control of their availability with only their data model and volume imposing geographical limitations. The downside of the “design for failure” model is that you must “design for failure” up front.

Design for Failure モデルのアドバンテージは、この地理的な制約を圧倒するデータのモデルとボリュームだけを用いて、アプリケーション・デベロッパーが全体的な可用性をコントロールできる点にある。 そして、Design for Failure モデルの欠点は、前もって Design for Failure モデルを、自分自身で考える必要性が生じる点にある。

AmazonThe Five Levels of Redundancy

In a cloud computing environment, there are five possible levels of redundancy:

クラウド・コンピューティング環境には、冗長性を実現するための 5つのレベルが存在する:

  • Physical
  • Virtual resource
  • Availability zone
  • Region
  • Cloud

When I talk about redundancy, I’m talking about a level of redundancy that enables you to survive failures with zero downtime. You have the redundancy that simply lets the system keep moving when faced with failures.

冗長性について話すなら、障害を回避してダウンタイムをゼロにする、冗長性のレベルについて説明したい。つまり、障害に直面しているときであっても、そのシステムを簡単に動かし続ける冗長性を手にしているという話だ。

Physical redundancy encompasses all traditional “n+1″ concepts: redundant hardware, data center redundancy, the ability to do vMotion or equivalents, and the ability to replicate an entire network topology in the face of massive infrastructural failure.

物理的な冗長性は、従来からの 『 N+1』 コンセプトの全てをカバーする。 つまり、インフラストラクチャの大規模な障害に直面する際の、ハードウェアの冗長性および、データセンターの冗長性、vMotion レベルの能力、そして、ネットワーク・トポロジ全体のリプリケーションのことである。

Traditional models end at physical redundancy. “Design for failure” doesn’t care about physical redundancy. Instead, it allocates redundant virtual resources like virtual machines so that the failure of the underlying infrastructure supporting one virtual machine doesn’t impact the operations of the other unless they are sharing the failed infrastructural component.

従来からのモデルを突き詰めていくと、この物理的な冗長性にたどりつく。 そして、Design for Failure は、この物理的な冗長性を無視している。 それに換えて、仮想マシンのような、冗長性のための仮想リソースが割り当てられる。それにより、障害を持つインフラストラクチャ・コンポーネントを共有していない場合に限り、仮想マシンをサポートしているインフラストラクチャの障害が、他の運用に影響を与えないようになる。

The fault tolerance of virtual redundancy generally ends at the cluster/cabinet/data center level (depending on your virtualization topology). To achieve better redundancy, you spread your virtualization resources across multiple availability zones. At this time, I believe only Amazon gives you full control over your availability zone deployments. When you have redundant resources across multiple availability zones, you can survive the complete loss of (n-1) availability zones (where n is the number of availability zones in which you are redundant).

一般的に、仮想を用いる冗長性のフォールト・トレランスは、クラスタ/キャビネット/データセンターのレベルに到達する(それぞれの仮想化トポロジーに応じて)。さらに優れた冗長性を達成するためには、多数のアベイラビリティ・ゾーンをまたいで、仮想化されたリソースを展開すべきだ。 現時点において、Amazon だけが、アベイラビリティ・ゾーンに関するフル・コントロールを提供しているはずだ。 多数のアベイラビリティ・ゾーンを横断する形で、冗長化されたリソースを有しているなら、アベイラビリティ・ゾーンの完全な喪失(n-1)からも、アプリケーションを守ることができる(冗長性は、n 個のアベイラビリティ・ゾーンにより担保される)。

Until this week, no one has needed anything more than availability zone redundancy. If you had redundancy across availability zones, you would have survived every outage suffered to date in the Amazon cloud. As we noted this week, however, an outage can take out an entire cloud region.

今週の出来事を経験するまで、アベイラビリティ・ゾーンの冗長性のことや、それ以上のことを、誰も必要としていなかった。 アベイラビリティ・ゾーンをまたがる冗長性を有していたなら、Amazon クラウドがサービスを停止しても、アプリケーションは生き残っていたはずだ。しかし、私たちが指摘したように、1回のサービス停止が、クラウド・リージョン全体を壊してしまうこともある。

Regional redundancy enables you to survive the loss of an entire cloud region. If you had regional redundancy in place, you would have come through the recent outage without any problems except maybe an increased workload for your surviving virtual resources. Of course, regional redundancy won’t let you survive business failures of your cloud provider.

リージョンについても、そこに冗長性を持たせることで、1つのクラウド・リージョン全体の喪失からも、生き残ることが可能となる。 リージョンに関する冗長性を、適切に配置していたなら、今回のサービス停止を、何の問題もなく乗り切ることができたはずだ。そこで必要となったのは、あなたの仮想リソースを保持するための、ワークロードが増加くらいだろう。そして、もちろん、リージョンに関する冗長性は、クラウド・プロバイダにおけるビジネス上の失敗を、保護するものにはならない。

Cloud redundancy enables you to survive the complete loss of a cloud provider.

つまり、クラウドの冗長性は、クラウド・プロバイダの完全な喪失からも、あなたのアプリケーションを守るものになるのだ。

<続く> ⇒ Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2

 

 

 

 

 

Tags:

ーーーーー

この春に、私たちは、原子力発電所の喪失と、最強クラウドの喪失を経験しましたが、いかなる技術や情熱が注がれるにしても、シングル・フェイル・ポイントは重要な視点を欠いていると、証明されたのだと思います。

先週末から、いろいろな文献を読みあさってみましたが、今の時点で総括まで踏み込んでいるのは、George Reese さんの、この一本だけだったと記憶しています。 とても素晴らしい見識であり、訳していて、感銘してしまいました。 ーーー  __AC Stamp 2

ーーーーー

<関連>

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_2
Amazon に起こった大規模ダウンタイムを分析する – Data Center Knowledge

Amazon に起こった大規模ダウンタイムを分析する – Data Center Knowledge

Posted in Amazon, Data Center Trends by Agile Cat on April 23, 2011

Major Amazon Outage Ripples Across Web
April 21st, 2011 : Rich Miller
http://www.datacenterknowledge.com/archives/2011/04/21/major-amazon-outage-ripples-across-web/

_ DC Knowledge

ーーーーー

<関連>

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1

ーーーーー

When a busy cloud computing platform crashes, the impact is felt widely. That’s the case with today’s extended outage for Amazon Web Services, which is battling latency issues at one of its northern Virginia data centers. The problems are rippling through to customers, causing downtime for many services that use Amazon’s cloud to run their web services.

人気の高いクラウド・コンピューティング・プラットフォームがクラッシュすると、その影響が広範囲におよぶ。 Amazon Web Services に広がった、今回の機能停止のケースでは、Virginia 北部のデータセンターにおけるレイテンシーへの取り組みが続いている。 この問題が、 Amazon クラウド上で稼動している数多くのWeb サービスにダウンタイムをもたらしたことで、その顧客の間に波紋が広がっている。

Image(5)

The sites knocked offline by Amazon’s problems include social media hub Reddit, the HootSuite link-sharing tool, the popular question-and-answer service Quora, and even a Facebook app for Microsoft (see a full list of affected sites).

この Amazon の問題によりオンライン機能を失ったサイトには、ソーシャル・メディア・ハブの Reddit や、HootSuite リンク共有ツール、人気の Q&A サービスである Quora に加えて、Microsoft 用の Facebook アプリケーションまで含まれる。(影響を受けたサイトの全リスト

AmazonThe issues began at about 1 a.m. Pacific time and are continuing as of 2:30 p.m. Pacific, with Amazon saying it still cannot predict when services will be fully recovered. By mid-afternoon, Amazon said it had limited the problems to a single availability zone in the Eastern U.S., and was attempting to route around the affected infrastructure. The AWS status dashboard shows that the services experiencing problems include Elastic Compute Cloud (EC2), Amazon Relational Database Service and Amazon Elastic MapReduce and are focused in the US-East-1 region.

この問題は Pacific タイムの 1 AM に始まり、2:30 PM の時点でも収束していない。 そして Amazon によると、いつになったらサービスが完全に回復されるのか、予測できない状況にあるという。 午後にいたるまでの Amazon の発言は、Eastern U.S の Availability Zone に限った問題であり、その影響を受けたインフラストラクチャに対するルーティングを試みるというものだった。AWS のステータス・ダッシュボードは、Elastic Compute Cloud(EC2)および、Amazon Relational Database Service、Amazon Elastic MapReduce も問題が生じていること、また、その問題が US  East-1 リージョンに集中していることを示している。

Networking Event Triggers Problems

The problems are focused on Elastic Block Storage (EBS), which provides block level storage volumes for use with Amazon EC2 instances. Latency problems at EBS were cited by Reddit when the site experienced major downtime in March.

今回の問題は、Amazon EC2 インスタンスで用いられ、ブロックレベルのストレージ・ボリュームを提供する、Elastic Block Storage(EBS)に集中している。 このサイトが、3月に大規模なダウンタイムに見舞われたとき、Reddit は EBS におけるレイテンシー問題に言及していた。

“A networking event early this morning triggered a large amount of re-mirroring of EBS volumes in US-EAST-1,” Amazon said in a status update just before 9 am Pacific time. “This re-mirroring created a shortage of capacity in one of the US-EAST-1 Availability Zones, which impacted new EBS volume creation as well as the pace with which we could re-mirror and recover affected EBS volumes. Additionally, one of our internal control planes for EBS has become inundated such that it’s difficult to create new EBS volumes and EBS backed instances.

『 今朝早くのことだが、US-EAST-1 で大量の EBS ボリュームが再ミラーリングされるという、ネットワークのイベントが発見された。この再ミラーリングにより、US  EAST-1 Availability Zones の 1つに、キャパシティの欠乏が生じた。それにより、新しい EBS のボリュームの生成に影響が生じただけではなく、影響を受けた EBS のボリュームを再ミラーリングとリカバーにも影響が生じた。 それに加えて、EBS のための内部コントロール・プレーンの 1つが逼迫し、新しい EBS ボリュームの作成や、EBS のインスタンス確保が困難になった 』 と、Pacific タイム 9時前のステータス・アップデートでAmazon は発言している。

“We are working as quickly as possible to add capacity to that one Availability Zone to speed up the re-mirroring, and working to restore the control plane issue,” Amazon continued. “We’re starting to see progress on these efforts, but are not there yet. We will continue to provide updates when we have them.”

『 私たちは、その Availability Zone にキャパシティを加え、再ミラーリングを早期に実現するために、最大限に努力している。そして、問題のコントロール・プレーンも復活させようとしている。それらの作業における進歩を注視しているが、まだ結果が現れていない。 それらの問題が収束するまで、私たちはアップデートを提供し続けるだろう 』と、Amazon は続けて言及している。

UPDATE: At 10:30 Pacific, Amazon said it was making “significant progress in stabilizing the affected EBS control plane service,” which was now seeing lower failure rates. “We have also brought additional capacity online in the affected Availability Zone and stuck EBS volumes (those that were being remirrored) are beginning to recover. We cannot yet estimate when these volumes will be completely recovered, but we will provide an estimate as soon as we have sufficient data to estimate the recovery.”

UPDATE: Pasific タイムの 10:30 に Amazon は 『 影響を受けた EBS コントロール・プレーン・サービスを安定させる作業において、の著しい進展が見られる 』と発言し、障害レートの低減も確認されている。 『 さらに、影響を受けた Availability Zone にオンライン・キャパシティを追加し、スタックしていた(再ミラーリングされていた)EBS ボリュームが回復し始めている。それらのボリュームが完全に回復されまでの時間は、まだ見積もることができないが、リカバリ時間を見積もるための充分なデータが得られれば、それを直ちに公表する 』

UPDATE 2: At 1:48 p.m. Amazon said a single Availability Zone in the US-EAST-1 region continues to experience problems launching EBS backed instances or creating volumes. “All other Availability Zones are operating normally,” Amazon said. “Customers with snapshots of their affected volumes can re-launch their volumes and instances in another zone. We recommend customers do not target a specific Availability Zone when launching instances. We have updated our service to avoid placing any instances in the impaired zone for untargeted requests.”

UPDATE 2: 1:48 PM に Amazon は、US EASTー1 シージョンの Single Availability Zone において、インスタンスを報奨された EBS の立ち上げおよびボリュームの作成に、まだ問題が残っていると発言した。 『 その他の、すべての Availability Zones は、通常どおりに運用されている 』と、Amazon は発言している。 『 影響を受けたボリュームのスナップショットを用いる顧客は、別のゾーンでボリュームとインスタンスの再立ち上げが可能となっている。なお、それらのインスタンスを立ち上げる時には、特定の Availability Zone をターゲットにしない方式を推奨する。 目標を定めないリクエストを、機能が損なわれたゾーンに配置しないように、サービスをアップデートしている 』

The outage even has affected a Microsoft initiative, according to a Facebook post by the company. “For those of you trying to enter our ‘Big Box of Awesome’ sweepstakes…the entry site is currently down, related to a broader problem impacting a number of sites across the internet today,” Microsoft told its Facebook followers. “We’ll let you know when it’s back up.” Microsoft has its own data center infrastructure, but some business units use third-party services. The Big Box of Awesome Facebook app is hosted on EC2.

Microsoft の Facebook ポストによると、今回のサービス停止により、同社のイニシアティブにも影響が生じている。 そして、『 私たちの  ‘Big Box of Awesome’ 懸賞に参加しようとする人々にとって、そのためのエントリー・サイトがダウンしている。 インターネット全体におよび、数多くのサイトに影響を与えた、今日の問題と関係がある。その復旧のタイミングは、後に知らせる 』と、同社の Facebook フォロワーへ向けて発言している。 Microsoft は、自身のデータセンター・インフラストラクチャを有しているが、いくつかのビジネス・ユニットでは、サードパーティーのサービスが利用されている。 つまり、Big Box of Awesome Facebook アプリケーションは、EC2 上にホストされていることになる。

Multi-Region Failover Option

The outage appears to affect many, but not all, customers using the US-East-1 region. Amazon operates multiple regions, allowing users to add redundancy to their applications by hosting them in several regions. In a multi-region setup, when one region experiences performance problems, customers can shift workloads to an unaffected region.

今回のサービス停止は、広範囲に影響をおよぼしているが、それは US-East-1 を用いる顧客に対するものであり、すべてに対するものでは無い。 Amazon はマルチ・リージョンを運営しており、それらをまたいで顧客をホストすることで、アプリケーションに冗長性を加えるている。 マルチ・リージョンの設定においては、1つのリージョンに問題が生じたとき、その影響を受けていないリージョンに、そのワークロードを移すことができる。

Whenever Amazon Web Services experiences outages and performance problems, it typically highlights the multi-region option, which allows customers to avoid having its cloud assets constitute a “single point of failure.” Today’s outage is likely to prompt some customers that rely on Amazon to examine adding additional regions to their deployment and other strategies to work around EC2 outages.

Amazon Web Services に、サービスの停止やパーフォーマンスの問題が生じるときには必ず、このマルチ・リージョンの選択が注目を集める。それにより、クラウド資産の構成が “single point of failure” を回避できるようになる。 今日のサービス停止により、Amazon に依存する何社かの顧客は、そのディプロイメント・リージョンの追加を促され、また、EC2 サービス停止への取り組みを促されるだろう。

The outage is also likely to prompt discussion of the reliability of cloud computing. Is it a fair question to raise? Today’s outage has affected many customers, highlighting the vulnerability of a single service hosting many popular sites.

さらに、今回のサービス停止は、クラウド・コンピューティングの信頼性についても、議論を促すことになるだろう。 それは、提起されるべき、公正な問題になるのだろうか? 今回の問題は、数多くの顧客に影響を与え、数多くの人気サイトを、単一のサービス上にホスティングうことの脆弱性を浮き彫りにした。

This has also been true of earlier outages at dedicated hosting providers like The Planet or data center hubs like Fisher Plaza. Companies relying upon those facilities could avoid outages by adding backup installations at other data centers – which is essentially the same principle as adding additional zones at Amazon.

それは、The Planet のような専用のホスティング・プロバイダーや、Fisher Plaza のようなデータ・センター・ハブに起きた、以前の障害においても真実である。 それらの企業は、他のデータセンターにバックアップ・インストールを加えることで、同社のファシリティに依存する顧客を、サービス停止から回避させることができた。そして、それは、Amazon に追加ゾーンを加えることと、本質的に同じことである。

Stuff happens. We write about outages all the time. But real-world downtime is particularly problematic in the context of claims that the cloud “never goes down.” Cloud infrastructure can also fail. The difference is that cloud deployments offer new options for managing redundancy and routing around failures when they happen.

必ず、何かが起こる。 したがって、私たちは常に、サービス停止について論じてきた。 しかし、現実世界のダウンタイムは、クラウドは「決してダウンしない」という主張という状況において、特に重視すべき問題である。 やはり、クラウド・インフラストラクチャにも、障害が発生することがあるのだ。 従来タイプに対するクラウドの相違点は、そのディプロイメントが冗長性を管理し、また、発生した障害を回避するルーティングを提供するところにある。

ーーーーー

昨日に起こった、Amazon AWS のサービス停止については、数多くのメディアが取り扱っていますが、こういうときは、やはり Rich Miller さんの出番ですね。 すべての情報が収集できている状況ではないと思いますが、それを Amazon に促し、AWS の問題というより、クラウド業界の問題として、前向きに対処していこうとする姿勢に拍手です。 また、Amazon としても、AWS の規模があるからこそ、起こり得た問題として捉え、情報の開示によるクラウド業界への貢献を考えて欲しいですね。 リーダーなんですから、きっと Werner Vogels さんが、やってくれるでしょう! ーーー __AC Stamp 2

ーーーーー

<関連>

Amazon AWS の障害を総括すると、クラウドの勝利が見えてくる_1
Amazon CTO – Werner Vogels が、クラウド・エコシステムを語る
Elastic Beanstalk とは? – Amazon CTO の Werner Vogels が語る
Amazon S3 のオブジェクト数が 2620 億個に!
もう SLA なんて不要だ – Google が自慢する究極のインフラ

Amazon AWS Region in Tokyo をオープンしました — Jeff;

Posted in Amazon by Agile Cat on March 3, 2011

Now Open: AWS Region in Tokyo
March 02, 2011
http://aws.typepad.com/aws/2011/03/now-open-aws-region-in-tokyo.html

image

JP_region_menu_1

I have made many visits to Japan over the last several years to speak at conferences and to meet with developers. I really enjoy the people, the strong sense of community, and the cuisine.

この何年かの間に、私は何度も日本を訪問して、カンファレンスで喋ったり、デベロッパーと会ったりしてきた。 そして、人々との時間を楽しみ、コミュニティに力強さを感じ、そしてモチロン、日本食も楽しんだ。

Over the years I have learned that there’s really no substitute for sitting down, face to face, with customers and potential customers. You can learn things in a single meeting that might not be obvious after a dozen emails. You can also get a sense for the environment in which they (and their users or customers) have to operate. For example, developers in Japan have told me that latency and in-country data storage are of great importance to them.

その歳月において、顧客と向き合って座り、フェイス -to- フェイスで話す以外に方法がないことを、私は学んだ。 それらは、会って話せば分かることだが、何本も電子メールを交わしたからといって、明らかになるものではないだろう。 そして、さらに、日本の顧客やユーザーが運用しなければならない環境についても、感覚を得ることができた。 日本のデベロッパーが話してくれたのは、レイテンシーへの対応と、国内に配置されるデータ・ストレージが、きわめて重要だという点である。

Long story short, we’ve just opened up an AWS Region in Japan, Tokyo to be precise. The new region supportsAmazon EC2 (including Elastic IP Addresses, Amazon CloudWatch, Elastic Block Storage, Elastic Load Balancing, VM Import, and Auto Scaling), Amazon S3,Amazon SimpleDB, the Amazon Relational Database Service, the Amazon Simple Queue Service, the Amazon Simple Notification Service, Amazon Route 53, and Amazon CloudFront. All of the usual EC2 instance types are available with the exception of the Cluster Compute and Cluster GPU. The page for each service includes full pricing information for the Region.

手短に話すと、私たちは、いま まさに Tokyo Japan で AWS Region をオープンしたというのが、正確なところだ。この新しい Region は、Amazon EC2 (including Elastic IP AddressesAmazon CloudWatchElastic Block StorageElastic Load BalancingVM ImportAuto Scaling) および、Amazon S3Amazon SimpleDBRelational Database ServiceSimple Queue ServiceSimple Notification ServiceRoute 53Amazon CloudFront をサポートする。Cluster Compute と Cluster GPU を除いて、おなじみの EC2 インスタンスの、すべてのタイプが利用できる。それらのサービスを説明するページには、この Region におおける料金体系も掲載されている。

Although I can’t share the exact location of the Region with you, I can tell you that private beta testers have been putting it to the test and have reported single digit latency (e.g. 1-10 ms) from locations in and around Tokyo. They were very pleased with the observed latency and performance.

この Region の正確な位置を共有することができないが、プライベート・ベータ・テスターたちによると、Tokyo 周辺では 1桁のレイテンシー(例 1-10 ms)を記録したとレポートされている。 そこで観察されたレイテンシーとパフォーマンスに、彼らはとても満足していた。

host_your_website_jeff_barr_japan_2

Existing toolkit and tools can make use of the new Tokyo Region with a simple change of endpoints. The documentation for each service lists all of the endpoints for each service.

既存のツールキットとツールにより、この新しい Tokyo Region を利用し、また、エンドポイントを簡単に変更できる。 それぞれのサービスのためのドキュメントが、個々のサービスのためのエンドポイントをリストアップしている。

This offering goes beyond the services themselves. We also have the following resources available:

これらを提供することで、サービスをカバーしていく。 さらに、以下のリソースを利用できるようにした:

Put it all together and developers in Japan can now build applications that respond very quickly and that store data within the country.

それら全ての組み合わせれば、日本のデベロッパーによるアプリケーション構築は既に可能であり、また、素早いレスポンスと国内でのデータ・ストアも約束されている。

jaws_logo_1 The JAWS-UG (Japan AWS User Group) is another important resource. The group is headquartered in Tokyo, with regional branches in Osaka and other cities. I have spoken at JAWS meetings in Tokyo and Osaka and they are always a lot of fun. I start the meeting with an AWS update. The rest of the meeting is devoted to short "lightning" talks related to AWS or to a product built with AWS. For example, the developer of the Cacoo drawing application spoke at the initial JAWS event in Osaka in late February. Cacoo runs on AWS and features real-time collaborative drawing.

もう1つの重要なリソースが、JAWS-UG (Japan AWS User Group) である。 このグループの本拠は Tokyo にあり、Osaka などの都市にもの支所がある。 Tokyo と Osaka での  JAWS ミーティングで話したことがあるが、それは、とても楽しい経験であった。 そのミーティングは、私からの AWS アップデートにより始まった。 そして、AWS あるいは、AWS で構築したプロダクトなどを紹介する、"lightning" トークがあった。 たとえば、Cacoo ドローの開発者は、2月下旬に Osaka で開催された最初の JAWS イベントで、そのアプリケーションを説明してくれた。 Cacoo は AWS 上で動作し、コラボレーティブ・ドローをリアルタイムで実現する。

ーーーーー とりあえず、抄訳は ココまで ーーーーー

We’ve been working with some of our customers to bring their apps to the new Region ahead of the official launch. Here is a sampling:

Zynga is now running a number of their applications here. In fact (I promise I am not making this up) I saw a middle-aged man playing Farmville on his Android phone on the subway when I was in Japan last month. He was moving sheep and fences around with rapid-fire precision!

enstratus_cluster_1The enStratus cloud management and governance tools support the new region. enStratus supports role-based access, management of encryption keys, intrusion detection and alerting, authentication, audit logging, and reporting. All of the enStratus AMIs are available. The tools feature a fully localized user interface (Cloud Manager, Cluster Manager, User Manager, and Report) that can display text in English, Japanese, Korean, Traditional Chinese, and French. enStratus also provides local currency support and can display estimated operational costs in JPY (Japan / Yen) and a number of other currencies.

sekai_camera_flow_1Sekai Camera is a very cool augmented reality application for iPhones and Android devices. It uses the built-in camera on each device to display a tagged, augmented version of what the camera is looking at. Users can leave "air tags" at any geographical location. The application is built on AWS and makes use of a number of services including EC2, S3, SimpleDB, SQS, and Elastic Load Balancing. Moving the application to the Tokyo Region will make it even more responsive and interactive.

g_mode_tetris_capture_1

G-Mode Games is running a multi-user version of Tetris®© in the new Region. The game is available for the iPhone and the iPod and allows you to play against another person.

cloudworks_jp_console_4

Cloudworks is a management tool for AWS built in Japan, and with a Japanese language user interface. It includes a daily usage report, scheduled jobs, and a history of all user actions. It also supports AWS Identity and Access Management (IAM) and copying of AMIs from region to region.

browser_3gokushi_1Browser 3Gokushi is a well-established RPG (Role-Playing Game) that is now running in the new region.

Here are some of the jobs that we have open in Japan:

– Jeff;

ーーーーー

今日(米時間で 3/2)は iPad 2 の発表とかで、早起きしてみたら、このニュースが飛び込んできました。 ついに キタッ !!! ・・・ という感じですね。 ーーー __AC Stamp 2

ーーーーー

<関連>
Amazon DC が やって来た – アイルランドでのシェアを調査
Android と iOS のデベロッパーへ、Amazon AWS からのラブコール
Elastic Beanstalk とは? – Amazon CTO の Werner Vogels が語る
Amazon は Beanstalk で、Microsoft と Salesforce に対抗していく!
AWS 用のモバイル・アプリを作るなら、Amazon Appstore へ登録を!
Amazon S3 のオブジェクト数が 2620 億個に!
Amazon Elastic MapReduce のアップデート – 5TB オブジェクトにも対応
Amazon がバルク・メール・ソリューションを発表
GPGPU を用いたソートについて考える – James Hamilton

%d bloggers like this: