Agile Cat — in the cloud

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

3 Responses

Subscribe to comments with RSS.

  1. masayh said, on April 30, 2011 at 10:09 pm

    内容的には確かにすばらしいのです。しかし、アプリケーションやサービスが自律的に動作する場合はこれで十分なのですが、今やサービスはサプライチェインや各種のサービス部品で構成されているので、サプライチェインのパートナーやサービス構成のプロバイダーシステムの脆弱性まで議論しないと十分とは言えません。
    現実、東日本大震災ではサプライチェインの停滞がビジネスの停滞になった問題が非常に大きいです。こうしたシステム連携に対する信頼性も考えないといけない点がアプリケーションアーキテクチャの難しさです。その他セキュリティ上の権限の委譲の問題などもあり、プラットフォームやデータの可用性に関する問題だけではありません。我々日本のアーキテクトはその点を考慮して参照アーキテクチャを作る予定です。

    • Agile Cat said, on April 30, 2011 at 10:25 pm

      たしかに、アメリカのシンプルなサプライチェーンが前提になっている感じがします。 難しい問題ですね。 IT が 社会と産業に寄り添っていくのか、その逆がよいのか。。。 おそらく、両方が必要なのでしょうね。 ある意味、Amazon は穏健ですが、Google や Facebook などは、社会の形を力技で変えようとしているようにも思えます。 IT と社会って、協調しながら、せめぎ合う関係なのでしょうかね。 最近は、そんなことを考えてしまいます。

    • Agile Cat said, on April 30, 2011 at 10:28 pm

      すみません、途中でサブミットしてしまいました。
      ご計画中の参照アーキテクチャですが、素晴らしい試みだと思います。
      楽しみにしていますので、出来上がったら、ぜひ、お知らせください。


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: