Agile Cat — in the cloud

これまでの Little Data のように、Big Data も価値を作り出すのか?

Posted in .Selected, Big Data by Agile Cat on October 20, 2011

Will Big Data Create As Much Prosperity As Little Data?
by Jon Bruner :9/26/2011
http://www.forbes.com/sites/jonbruner/2011/09/26/will-big-data-create-as-much-prosperity-as-little-data/

image

 

I spent three days at the O’Reilly Strata conference on big data last week, and came away impressed by what I saw: visualizations, new ways of understanding human patterns, new kinds of business intelligence. It was the most optimistic gathering that I’ve visited in a long time: while the country as a whole confronts a dim economic outlook, the mood within this industry is strikingly positive: it’s one of the very hottest parts of the tech sector right now, and lots of presentations ended with “we’re hiring” slides.

先週のことだが、Big Data を対象とする O’Reilly の Strata カンファレンスで、3日ほど過ごしてきた。そこで聞いた、視覚化/人間のパターンを理解する新しい方式/新類のビジネス・インテリジェンスに関する話から、私は大いに感銘を受けた。 私が長い時間を費やしたのは、最も楽天的な集会であった。アメリカ全体が、暗い景気の見通しに直面する一方で、この業界におけるムードは、ものすごくポジティブである。それは、ハイテク領域の今における、最もホットなパートの 1つであり、大半のプレゼンテーションのスライドが、「人材を求む」という言葉で終わっていたほどである。

The big data revolution, which allows anyone to capture and analyze quantities of data that were too large to handle just a few years ago, stands to have a big impact on the business world, where the emphasis seems to be on big data’s role in guiding operations from an executive level. Decisions will be made with better foresight, trends will be better predicted and day-to-day operations will be better understood. I’m certain that all of this will result in better-run companies and greater profit at the institutional level.

Big Data 革命 とは、ほんの数年前まで、処理するには余りにも大きすぎたデータを、誰もがキャプチャ/分析できるようにするものだ。そして、経営者レベルでの運用を方向付け、また、Big Data の役割を強調することで、ビジネスの世界に大きな影響を与える立場にあるように思える。 つまり、さらに洞察力に富んだ判断がもたらされ、また、傾向が正確に予測され、日常業務の理解が促進されるであろう。それら全てが、組織的なレベルで適切に運営される企業に、さらに大きい利益をもたらすと、私は確信する。

clip_image001The previous data revolution–the 1990s adoption of the personal computer that we might in retrospect call “little data”–dramatically improved both worker productivity and corporate profitability by acting on every level of business from executives down to individual workers. Put a PC on your billing clerk’s desk, and he can suddenly handle twice the work he had done before. That combination of productivity and profitability led to an unprecedented improvement in household wealth across most strata of the American workforce.

前回のデータ革命は、1990年代にパーソナル・コンピュータに適用されたものであり、Little Data という名で振り返るべきものなのかもしれないそれは、経営者のレベルから、個々の労働者に働きかけることで、労働者の生産性と企業の収益性を、劇的に改善するものとなった。 あなたの伝票処理デスクに PC を置きなさい。 そうすれば、彼らは突然に、以前の 2倍の効率で働き出すかもしれない、というふうに。生産性と収益性のその組み合わせは、アメリカの労働者が構成する階層を貫いて、あらゆる家庭の富を、前例がないほど改善した。

But if big data happens at the executive and managerial levels, can it have the same positive impact on American prosperity? Sure, profits will grow as management improves. And better-managed workers, whose attention is directed to the right initiatives by cutting-edge analytics and decision-making software, will undoubtedly be more productive.

しかし、Big Data が、経営者や管理者のレベルで発生する場合に、前回のように、アメリカ経済の繁栄に対して、好影響をもたらすことが可能なのか? その答えは、『もちろん』となる。 なぜなら、マネージメントが改善されるにつれて、利益が増大するからだ。 そして、最先端の分析/意志決定ソフトウェアにより、正しい方向性へと組織をを導く、良く管理されたナレッジ・ワーカーたちが、さらなる生産性を確実にもたらすだろう。

We already see big data in plenty of consumer products–Google, as Tim O’Reilly pointed out at the conference, is a big data product, as are other new services from Foursquare’s recommendation engine to LinkedIn’s “people you may know.” But what will the impact of big data be on individual workers? Will it complement labor at every level of the business world like PCs did in the 1990s? The American economy could use a stimulative shot from the tech industry in the form of new technology that helps businesses provide value to their customers–and helps workers provide value to their employers. I imagine that big data could play a role in that sort of reform–but what will that role look like?

このカンファレンスで、Tim O’Reilly が指摘したように、Google に代表されるコンシューマ・プロダクトにおいて、私たちは多様な Big Data を、すでに目にしている。それは、Foursquare の推薦エンジンから、LinkedIn の「“people you may know」へと至る、各種の新サービスにおいても、同じことである。しかし、この Big Data は、個々の労働者たちに、何をもたらすのだろうか? 1990年代に PC が実現したように、ビッグジネスの世界の全レベルにおいて、労働を補完することになるのだろうか? アメリカ経済は、新技術という形態において、ハイテク産業からの刺激的な一撃を活用できるだろう。それにより、企業がから顧客に提供される価値を高め、また、ナレッジ・ワーカーから労働者に提供される、情報の価値が高められていく。 私が想像するには、Big Data は改革者の役割を果たすことになると思うが、その役割自体は、どのように見えるものになるのだろう?

Jon Bruner’s Popular Posts

I’m deputy editor for new products at Forbes, where I develop new editorial concepts for the Web and magazine and explore questions that interest me by writing and programming. I graduated from the University of Chicago in 2006 with degrees in mathematics and economics.  Follow me on Twitter: @JonBruner

ーーーーー

TAG indexなるほど、これまでは Little Data ですか :) とても分かりやすく、また、過激な分類ですが、Forbes という一般誌の見出しであることに、少々 驚いてしまいます。そして、Big Data に対する理解が徐々に広まり、すでに経営者層にも届き始めているのだと、この記事を読んでいて感じました。 ーーー __AC Stamp 2

ーーーーー

<関連>

クラウドで Big Data をハンドリングする 6 社の事例
Big Data を探せ! アメリカの 5つの具体的な事例とは?
Google の 3つの世代を振り返る – Batch, Warehouse, Instant
OpenFlow と Big Data の 深い関係について
Microsoft が発表した、OSS ベースのクラウド・サービスとは?

 

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

Apple は Web-based サービスの重要性を理解していない、、、と Web 2.0 Expo で Tim O’Reilly

Posted in Apple, Events by Agile Cat on May 7, 2010

Web 2.0 Expo SF 2010 のビデオが Youtube で続々と公開!
http://www.web2expo.com/webexsf2010

image

行きたかったなぁ~~~ という人も多いのではないかと思いますが、Web 2.0 Expo SF 2010 のビデオが公開され始めました。 何かキーワードかというと、Internet Operating System らしいです。 また、TechCrunch も ” Tim O’Reilly: Steve Jobs Is Trying To Build A Fundamental Challenge To The Web – by Jason Kincaid on May 6, 2010 ” という速報を掲載しています。 そこからの抜粋ですが、O’Reilly は Apple に対して、「Web の根本に対抗して世界征服を狙っているようだが失敗する」 と言っているようです。 ただ、ビデオを見る限り、そんな過激な発言は聞き取れませんでした。 ーーー A.C.

TechCrunch から ・・・

Apple, he says, “has a vision of world domination”, and that with the App Store platform Steve Jobs is trying to build a fundamental challenge to the web. But it falls short in one key area: O’Reilly believes that Apple doesn’t understand the importance of web-based services, as evidenced by its decision to make its (somewhat lackluster) MobileMe service premium, with little in the way of a social graph.

OreillyMedia — 2010年05月05日 —
At Web 2.0 Expo, Tim O’Reilly discusses the major players,
platforms and key subsystems in the Internet Operating System.

OreillyMedia — 2010年05月05日 —
Danny Sullivan (Search Engine Land), "The Search Platform: Friend Or Vampire?"

OreillyMedia — 2010年05月05日 —
Rashmi Sinha (SlideShare, Inc.), "Slideshare"

OreillyMedia — 2010年05月05日 —
Kevin Lynch (Adobe Systems Incorporated), "A Conversation with Kevin Lynch"

そして、Adobe の Kevin Lynch の対談も面白いです。 もう一方の渦中の人という感じですが、拍手を浴びていた点が印象に残ります。 話の中で触れている Open Screen Project とは、以下の ORG です。調べたところ、Adobe が提唱者で、Apple と Microsoft 以外のキープレイヤーは参加しているように見えます。

The Open Screen Project is an industry-wide initiative, led by Adobe and backed by other industry leaders who all share one clear vision: Enable consumers to engage with rich Internet experiences seamlessly across any device, anywhere.

http://www.openscreenproject.org/
http://www.openscreenproject.org/partners/current_partners.html

この 4本のビデオを見た限りでは(あくまでも雰囲気ですが)、Web ベースのサービスをモバイル・デバイスで共有し、ユーザーにとってメリットのある形にするには、どうしたら良いのだろう? ・・・ という Web 2.0 Expo SF 2010 だったように思えます。 ーーー A.C.

ーーーーー

<関連>
米当局が Apple を反トラスト法で調査? May 3, 2010
歓迎すべきことに、Apple は制空権を失いつつある
Jobs の Adobe 批判って、自爆してません?
Microsoft は オープンソースへ走ると、O’Reilly が予言!
O’Reilly の忠告に、知らねぇよと Google 言い、Buzz 大炎上!

Tagged with: , , , , , , , , ,

Observer と ZooKeeper:玉川竜司バージョン!

Posted in .Chronicle by Agile Cat on February 8, 2010

オープン・トランスレーションがあっても良いのでは?

AC

みなさんも良くご存知の、O’reilly の Hadoop 本の訳者である玉川竜司さんが、Agile_Cat の迷訳を名訳に変えてくださいました。とても嬉しいことです。 テキトーに訳すつもりはありませんが、それは、それで、時間をやりくりしながらの作業となり、粗いところも多々あると思います。今回は、それを見かねて玉川さんが、いくらなんでもという部分を直してくださり、先ほどですが修正版の Observer と ZooKeeper をアップしたところです。 すでに読まれた方も、また、ご覧ください。

オープ・ソースがあるのに、なぜオープン・トランスレーションが無いのかと、つね日頃より疑問に思っていた Agile_Cat にとっては、ひとつのポストの質が上がったことの喜びもありますが、こうしたブログなどを介して、複数の人がコミュニケーションしながら情報の制度を高め、みなさんとの知識の共有を深めることに、さらなる喜びを感じています。

その意味で、より多くの方々にも、いろいろなご意見や指摘を頂ければと考えています。 とにかく、今回のことは、 Agile_Cat 史上初の快挙であり、とても素晴らしいことだと感激しています。

玉川さん、ありがとう!  みなさんも、よろしく お願いしま~~~す! ーーー A.C.

O’Reilly の Hadoop 本が、1月23日に日本で発売!

Posted in Books, Hadoop by Agile Cat on January 13, 2010

待ちに待った Hadoop: The Definitive Guide, First Edition の訳本です!

昨年の 11月の、Hadoop Conference の会場で、校正の段階に入りましたと玉川さんから聞いて以来、まだか、まだかと、待ちわびていたのですが、ついに 1月 23日の発売が決まったとのご連絡をいただきました。 よくよく考えてみると、この訳本なしに、日本の Hadooper は長いこと頑張ってきたわけですが、、、それも あと少しの辛抱で、23日以降は日本語で Hadoop の勉強ができるようになるんです。 スバラシイ!

O’Reilly Japan の URL は、ここ ↓ で~す!
http://www.oreilly.co.jp/books/9784873114392/

oreilly_header2

Hadoop Book J

● Tom White 著 、玉川 竜司、兼田 聖士 訳
● 2010年01月23日 発売予定
● 568ページ
● 定価4,830円
● ISBN978-4-87311-439-2
● 原書:
Hadoop: The Definitive Guide, First Edition

本書は、Hadoopの基礎から応用までを包括的に解説する書籍です。はじめに、Hadoopの分散ファイルシステムHDFSやI/Oの効率化の仕組みなど、Hadoopの基礎を説明し、なかでもMapReduceについて詳しく解説します。MapReduceのアプリケーションを開発するために必要なステップを一通り紹介し、さらにユーザの目から見てMapReduceがどう実装されるのかを詳述します。後半ではHadoop管理者のために、HDFSと MapReduceを実行するためのHadoopクラスタの立ち上げと管理の方法を紹介。さらにPig、HBase、ZooKeeperについて述べ、 Apache Hadoopコミュニティメンバーから寄せられた、FacebookやLast.fmなどの大規模なケーススタディ集を収録しています。信頼ある Hadoopコミッターが執筆した本書は、Hadoopに関心あるすべての人に必携の一冊です。

序文
訳者まえがき
はじめに
1章 Hadoop事始め
    1.1 データ!
    1.2 データの保管と分析
    1.3 他のシステムとの比較
    1.4 Hadoopの歴史
    1.5 Apache Hadoopプロジェクト
2章 MapReduce
    2.1 気象情報データセット
    2.2 Unixのツールによるデータ分析
    2.3 Hadoopによるデータの分析
    2.4 スケールアウト
    2.5 Hadoopストリーミング
    2.6 Hadoop Pipes
3章 Hadoop分散ファイルシステム
    3.1 HDFSの設計
    3.2 HDFSに関する概念
    3.3 コマンドラインインターフェース
    3.4 Hadoopのファイルシステム群
    3.5 Javaインターフェース
    3.6 データフロー
    3.7 distcpによる並列コピー
    3.8 Hadoopアーカイブ
4章 HadoopのI/O
    4.1 データの整合性
    4.2 圧縮
    4.3 シリアライゼーション
    4.4 ファイルベースのデータ構造
5章 MapReduceアプリケーションの開発
    5.1 設定API
    5.2 開発環境の設定
    5.3 ユニットテストの作成
    5.4 テストデータを使ったローカルでの実行
    5.5 クラスタでの実行
    5.6 ジョブのチューニング
    5.7 MapReduceのワークフロー
6章 MapReduceの動作
    6.1 MapReduceジョブの実行の内幕
    6.2 障害
    6.3 ジョブのスケジューリング
    6.4 シャッフルとソート
    6.5 タスクの実行
7章 MapReduceの型とフォーマット
    7.1 MapReduceの型
    7.2 入力フォーマット
    7.3 出力フォーマット
8章 MapReduceの機能
    8.1 カウンター
    8.2 ソート
    8.3 結合
    8.4 サイドデータの配布
    8.5 MapReduceライブラリクラス
9章 Hadoopクラスタの構築
    9.1 クラスタの仕様
    9.2 クラスタのセットアップとインストール
    9.3 SSHの設定
    9.4 Hadoopの設定
    9.5 インストールの後処理
    9.6 Hadoopクラスタのベンチマーク
    9.7 クラウドにおけるHadoop
10章 Hadoopの管理
    10.1 HDFS
    10.2 モニタリング
    10.3 メンテナンス
11章 Pig
    11.1 Pigのインストールと実行
    11.2 例
    11.3 データベースとの比較
    11.4 Pig Latin
    11.5 ユーザー定義関数
    11.6 データ処理オペレータ
    11.7 実践Pig
12章 HBase
    12.1 Hbaseの基礎
    12.2 概念
    12.3 インストール
    12.4 クライアント
    12.5 例
    12.6 HBase対RDBMS
    12.7 実践
13章 ZooKeeper
    13.1 ZooKeeperのインストールと実行
    13.2 例
    13.3 ZooKeeperサービス
    13.4 ZooKeeperによるアプリケーションの構築
    13.5 ZooKeeperの実用化
14章 ケーススタディ
    14.1 Last.fmにおけるHadoopの利用
    14.2 FacebookにおけるHadoopとHive
    14.3 Nutch検索エンジン
    14.4 Rackspaceにおけるログの処理
    14.5 Cascading
    14.6 Apache Hadoopでのテラバイトソート
付録A Apache Hadoopのインストール
    A.1 必要事項
    A.2 インストール
    A.3 設定
    A.3.1 スタンドアロンモード
    A.3.2 擬似分散モード
    A.3.3 完全分散モード
付録B ClouderaのDistribution for Hadoopについて
    B.1 必要事項
    B.2 スタンドアロンモード
    B.3 擬似分散モード
    B.4 完全分散モード
    B.5 Hadoopの関連パッケージ
付録C NCDC気象情報データの準備

ーーー

O’Reilly Japan サイトには、もっと詳細な目次が掲載されていますよ。 最後になってしまいましたが、玉川さん、兼田さん、おめでとうございます。 そして、お疲れ様でした。 ーーー A.C. 

<関連>
楽天の河村さん:Hadoop Conference Japan 2009に参加しました
This is ARAKI’s daily notes 前半 後半
Hadoop World 2009 レポート
Hadoop Conference Japan 2009 が、もう満員だって!
北京でも Hadoop World を開催
台湾でも Hadoop World を開催
Hadoop World Report:優良企業はなぜ Hadoop に走るのか
Hadoopが秘める可能性:オンプレミスでもクラウドでも使えるプラットフォームの魅力
Hadoopの最新動向を「Hadoop World:NY 2009」の資料から

Hadoop_J、PDC、Web 2.0 Expo、QCon、Chrome の Video など

Posted in .Chronicle by Agile Cat on November 23, 2009

怒涛の 1週間でしたね。。。

11月13日の、東京での Hadoop Conference に始まり、翌週の PDC 2009(LA)、Web 2.0 Expo(NY)、QCon(SF)とイベントが続き、そこに Google Chrome OS の発表までが重なるという、とても過密な、まるで惑星大直列みないな 1週間となりました。これらのイベントに関しては、ほかにも膨大なリソースがありますが、とりあえず、Agile Cat が見ていたもの、書いたものを掲載しておきます。

Hadoop

Cloudera の Christophe  Bisciglia さんが来日して、楽天などが発表するという、日本で初の Hadoop Conference です。予想以上の盛り上がりに、皆さんも驚いたのではないでしょうか。

分散処理ソフト「Hadoop」のユーザー会が日本で発足、企業の導入が広がる 
速報 : Hadoop Conference 2009 Tokyo レポート
Overview of Hadoop Conference 2009 in Japan – English Edition

二年連続の PDC でしたね。 2 番目の Wrapping Up というのは、Mary-Jo Foley さんたちの強烈なライブ・ブログを要約したものです。 英語になってしまいますが、まず他には無いリソースだと思います。
 
PDC 2009 の Video と PPT
Microsoft PDC09 Keynote 1 – Wrapping Up
MapReduce in DryadLINQ

Open Web 2 expo

この 1週間で、もっとも輝いていたのは Tim O’Reilly さんではなかったでしょうか。 競合から協調へと唱えているわけですが、その意味では、一番最後の SF(4月)のビデオの方が解りやすいと思います。
 
Web 2.0 Expo Archive
Microsoft は オープンソースへ走ると、O’Reilly が予言!
Web 2.0 Expo NY 09: Tim O’Reilly, "The O’Reilly Radar"
Web 2.0 Expo SF 09: Tim O’Reilly, "O’Reilly Radar"

QCon

DSL のトラックもあり、Don Box さんの M に関するセッションが、Twitter では好評でした。 ほかにも、Philip Zeyliger さんや、Simon Guest さんなどの興味深いセッションがありました。

QCon のスライド
 

clip_image001

ウワサ にはなっていましたが、このタイミングに Google もぶつけてきましたね。2番目と 3番目は、これもライブ・ブログからのものであり、英語となってしまいますが、とても詳しい情報が得られます。
 
Chrome OS on Youtube
Google Chrome OS press conference : Part_1
Google Chrome OS press conference : Part_2

ーーーーー

Web を追いかけるだけで、クタクタになってしまう 1週間でしたね :) --- A.C.

%d bloggers like this: