Architecture | Agile Cat --- in the cloud

Pinterest ：自動シャットダウン･システムで、AWS の時間単価を $54 から $20 へ

Posted in .Selected, Amazon, Cloud Businesses, Social by Agile Cat on December 26, 2012

Pinterest Cut Costs from $54 to $20 Per Hour by Automatically Shutting Down Systems
http://wp.me/pwo1E-5rv
Wednesday, December 12, 2012
http://highscalability.com/blog/2012/12/12/pinterest-cut-costs-from-54-to-20-per-hour-by-automatically.html

We’ve long known one of the virtues of the cloud is, through the magic of services and automation, that systems can be shut or tuned down when not in use. What may be surprising is how much money can be saved.

私たちは、クラウドの長所に関して、それが使用されていないときに、システムの全体的／部分的なシャットダウンを実現する、サービスとオートメーションのマジックによるメリットがあると、長い期間にわたって認識してきた。そこでの驚きが何かというと、どれだけのコストが削減されるのかという点に集約される。

This aspect of cloudiness got a lot of pub at AWS re:Invent and is being rebranded under the term Cost-Aware Architecture. An interesting example was given by Ryan Park, Pinterest’s technical operations lead:

この、クラウド全体にまたがる視点は、AWS re:Invent での数多くの発表をもたらし、また、Cost-Aware Architecture の基礎を再構築している。そして、興味深い事例が、Pinterest の技術リーダーである、Ryan Park から提供された：

20% of their systems are shutdown after hours in response to traffic loads
Reserved instances are used for standard traffic
On-demand and spot instances are used to handle the elastic load throughout the day
Using this approach costs have gone from $54 per hour to $20 per hour

トラフィックの負荷に対応した数時間後に、システムの 20% はシャットダウンされる
リザーブド･インスタンスは、スタンダードのトラフィックに対して使用される
オンデマンド／スポット･インスタンスは、日々における収縮性の負荷に対して使用される
このコストに対応するアプローチにより、時間なたりの単価が $54 から $20 へと低減した

We are in very early days of Adaptive Architectures. What is being managed are relatively large resource abstractions running on relatively large scale computer abstractions. Yet it’s a start. More at Cloud Programming Directly Feeds Cost Allocation Back Into Software Design.

私たちは、Adaptive Architectures における、きわめて初期的な段階にある。そこで管理されるものは、相対的にスケールが大規模化していくコンピュータの抽象概念を走らせる、相対的に大規模化していくリソースの抽象概念である。しかし、それは始まったばかりのものである。詳細については、『 Cloud Programming Directly Feeds Cost Allocation Back Into Software Design 』を参照してほしい。

ーーーーー

このところ、Pinterest による AWS 使い倒し術を追いかけている、High Scalability さんです。こういうポストは、分かりやすい事実関係から、さまざまな発想をインスパイヤーするので、読んでいて、とても楽しいです。他を圧倒する実績で、クラウド界のプライス･リーダーとして君臨する AWS ですが、そのコストを、さまざまなユーザーが分析し始めたというのが、今年のトピックなのかもしれません。来年のクラウド経済は、どちらの方向へ進んでいくのでしょうか？とても、楽しみですね。

ーーーーー

Tagged with: Amazon, Amazon AWS, Architecture, Automatically Shutting Down, AWS, AWS re:Invent, Cost-Aware Architecture, IaaS, Pinterest

leave a comment

Pinterest のアーキテクチャと経済： AWS を使い倒せ！

Posted in .Selected, Amazon, Big Data, Social by Agile Cat on November 13, 2012

Pinterest Architecture Update – 18 Million Visitors, 10x Growth,12 Employees, 410 TB of Data
http://wp.me/pwo1E-5aD
Monday, May 21, 2012
http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html

ちょっと古いポストですが、調べ物の最中に見つけたので・・・

ーーーーー

There has been an update on Pinterest: Pinterest growth driven by Amazon cloud scalability since our last post: A Short on the Pinterest Stack for Handling 3+ Million Users.

Pinterest がアップデートされた。前回のポストである『 A Short on the Pinterest Stack for Handling 3+ Million Users』以降、Amazon クラウドのスケーラビリティに支えられ、Pinterest の成長が促進されている。

With Pinterest we see a story very similar to that of Instagram. Huge growth, lots of users, lots of data, with remarkably few employees, all on the cloud.

Pinterest と Instagram に、きわめて類似するストーリーを見出す。つまり、急激な成長と、膨大なユーザー数、大量のデータ、驚くほど少ない従業員、そして、すべてをクラウドに展開、、、という点である。

While it’s true that both Pinterest and Instagram are not making great advances in science and technology, that is more indicator of the easy power of today’s commodity environments rather than a sign of Silicon Valley’s lack of innovation. The numbers are so huge and the valuations are so high we naturally want some sort of fundamental technological revolution to underlie their growth. The revolution is more subtle. It really is just that easy to attain such growth these days, if you can execute on the right idea. Get used to it. This is the new normal. Here’s what Pinterest looks like today:

Pinterest と Instagram には、サイエンス･テクノロジーという観点において、素晴らしい進歩をしていないという事実がある。しかし、いまのコモディティ環境が実現する容易なパワーは、Silicon Valley におけるイノベーションの欠如と比較して、素晴らしい兆しを示している。そのスケールは膨大であり、評価額もきわめて高い。したがって、私たちは、ある種の基本的なテクノロジー革命が、その成長の基礎にあることを望んでいる。その革命は、とても見つけにくい。もし、正しいアイデアを正確に実施できるなら、このような、最近に見られる著しい成長を、容易に達成できるだろう。したがって、それを活用する必要がある。つまり、新しいノーマルである。以下は、いまの Pinterest に見出されるものである：

80 million objects stored in S3 with 410 terabytes of user data, 10x what they had in August. EC2 instances have grown by 3x. Around $39K fo S3 and $30K for EC2.
12 employees as of last December. Using the cloud a site can grow dramatically while maintaining a very small team. Looks like 31 employees as of now.
Pay for what you use saves money. Most traffic happens in the afternoons and evenings, so they reduce the number of instances at night by 40%. At peak traffic $52 an hour is spent on EC2 and at night, during off peak, the spend is as little as $15 an hour.
150 EC2 instances in the web tier
90 instances for in-memory caching, which removes database load
35 instances used for internal purposes
70 master databases with a parallel set of backup databases in different regions around the world for redundancy
Written in Python and Django
Sharding is used, a database is split when it reaches 50% of capacity, allows easy growth and gives sufficient IO capacity
ELB is used to load balance across instances. The ELB API makes it easy to move instances in and out of production.
One of the fastest growing sites in history. Cites AWS for making it possible to handle 18 million visitors in March, a 50% increase from the previous month, with very little IT infrastructure.
The cloud supports easy and low cost experimenation. New services can be tested without buying new servers, no big up front costs.
Hadoop-based Elastic Map Reduce is used for data analysis and costs only a few hundred dollars a month.

S3 にストアされた 80 million のオブジェクトと、410 T Bytes のユーザー･データ。それらは、昨年の８月からみて、10倍に増大している。EC2 インスタンスは 3倍に増大し、S3 に対して $39K と、EC2 に対して $30K の対価が生じる。
昨年12月時点で、従業員数は 12名である。クラウドを使うことで、サイトはダイナミックに成長するが、きわめて小規模なチームを維持している。現状では、31人の従業員がいるようだ。
支出を抑えるために、行なっていること。大半のトラフィックは、午後から夕刻に集中する。したがって、夜間におけるインスタンス数は、ピーク時の 40% にまで低減させる。ピーク時のトラフィックでは、EC2 に対して $52／時間が生じるが、夜間においては $15／時間程度まで低減されている。
Web ティアには、150 の EC2 インスタンスが割り振られている。
In-Memory のキャッシングに対して、90 インスタンスが割り当てられ、データベースの負荷を低減している。
内部利用のために、35 インスタンスが割り当てられている。
70 のマスター･データベースと、パラレルにセットされたバックアップ･データベースが、冗長性を確保するために、別のリージョンに配置されている。
Python と Django により、コードを記述している。
Sharding を用いて、データベースの容量が 50% に達したときに分割している。それにより、拡張が容易になり、また、十分な I/O キャパシティが実現される。
インスタンスをまたいだロード･バランシングのために、ELB を使用している。この ELB API により、プロダクション環境とのインスタンスの出し入れが容易になる。
これまでの歴史において、最速の成長を遂げているサイトの 1つである。この 3月における 18 million というビジターを、AWS を利用してハンドリングしている。その数字は、前月と比較して 50% も伸びているが、きわめて小規模な IT インフラにより実現されている。
このクラウドは、より容易で低コストな実験をサポートする。そこでは、新たなサーバーを購入することも、前払いの対価を準備することも不要である。
Hadoop-based の Elastic Map Reduce が、データ分析のために用いられているが、そのコストは a few hundred dollars／月である。

ーーーーー

EC2 の時間単価について、ピークとオフ･ピークの平均を $30／h だとすると、$720／日、$21.6K／月という対価になります。したがって、「EC2 に対して $30K の対価が生じる」という説明は、月額の費用ということで間違いないでしょう。つまり、S3 と EC2 を合わせて、$69k／月であり、$828k／年となります。 Instagram も同程度の規模と考えると、それが $1B で売買される現実というのも・・・ Smile

ーーーーー

Tagged with: Amazon, Amazon AWS, Architecture, AWS, EC2, Elastic MapReduce, Hadoop, Pinterest, S3, Scalability, Scale

leave a comment

NIST のクラウド定義はスクラップになるべきだ – その理由を説明しよう

Posted in .Chronicle, .Selected, NIST by Agile Cat on December 12, 2011

Why NIST Should Scrap “the Cloud” Entirely
Jon Stokes – 2011,11,12
http://www.wired.com/cloudline/2011/11/why-nist-should-scrap-the-cloud-entirely/

The National Institute of Standards and Technology (NIST) has published a new volume of its roadmap aimed at accelerating the adoption of its previously released Federal Cloud Computing Strategy. The report lays out a set of 10 requirements for further federal cloud adoption, most of which will be familiar to any CIO who has the standard slate of worries about cloud’s interoperability, security, data portability, standards compliance, and privacy. Or, as NIST puts it:

National Institute of Standards and Technology（NIST）は、以前にリリースされた Federal Cloud Computing Strategy の適用を促進するために、新しい分冊としてロードマップを発行した。このレポートは、連邦政府のクラウド適用に関して、10 個の要件セットを展開している。しかし、その大半は、クラウドのインターオペラビリティ／セキュリティ／データ･ポータビリティ／スタンダード･コンプライアンス／プライバシーに対して、不適切なスタンダードを信じることに慣れてしまった、CIO のためのものになるだろう。すなわち、以下のように、NIST は言っている：

In the technology vision of Federal Cloud Computing Strategy success, [U.S. government] agencies will be able to easily locate desired IT services in a mature and competitive marketplace, rapidly procure access to these services, and use them to deliver innovative mission solutions. Cloud services will be secure, interoperable, and reliable. Agencies will be able to switch between providers easily and with minimal cost, and receive equal or superior services.

Federal Cloud Computing Strategy が成功するためのテクノロジーのビジョンにおいて、［ U.S. government ］の行政機関は、競争力を持つ成熟したしたマーケットで、必要とされる IT サービスを容易に見つけ出し、そこにへのアクセス権を迅速に調達する。続いて、革新的でミッション･クリティカルなソリューションを、それらの IT サービスを用いて展開していくだろう。クラウド･サービスは、セキュアであり、インターオペラビリティの達成し、高い信頼性をもたらすものになるだろう。したがって、政府機関は、容易にプロバイダを切り替えられるようになるが、そのコストは最小であり、また、それまでと同等あるいは高品質なサービスを得られるようになる。

The only thing I’d add to this list is, “And every child should have a pony.”

私が、それに何かを付け加えることができるなら、“And every child should have a pony” 程度のものとなる。

Illustration: Richard Perez ⇒

Of course, it’s easy to poke fun at NIST’s pie-in-the-sky wishlist for cloud computing, but the authors themselves know that the document is more aspirational than operational. The plan is to identify priorities, to define goals (however lofty), and to foster discussion that will hopefully nudge to this whole cloud thing forward to the point where the government can start saving money with it. Nonetheless, the challenges that the authors face in trying to help “the cloud” are fundamental, and they’re rooted in the fact that it’s not really clear what, if anything, “the cloud” is.

もちろん、NIST が絵に描くモチである、クラウド･コンピューティングの欲しい物リストを、からかうことは容易であるる。しかし、そのドキュメントの著者たち自身が、運用のために必要なことより、熱望することを書いていることを、よく自覚していることに注目すべきだと思う。この NIST のプランは、プライオリティを識別し、ゴールを定義し（どんなに高くても構わない）、論議を促進することを目的としている。したがって、この NIST のクラウド･ロードマップを用いることで、政府は初期費用を節約し、さらにはクラウド全体を促進させると、説得するつもりなのだろう。それにもかかわらず、「彼らのクラウド」が基本であるという発想を、事実に根ざして促進していく試みにおいて、その著者たちが直面する、クラウドとは何かという課題は、どちらかというと明確にされていない。

I’ve talked before about the confusion around definitions of cloud, and I generally think that people should just stop trying to define the term. The NIST publishes its own definition of “cloud computing,” which features in most definitional discussions of the topic. Few people adopt the NIST definition without alteration, and indeed few adopt almost any definition unaltered.

以前のことだが、クラウド定義の周辺に存在する混乱について話したことがあり、また、その用語の定義を止めるべきだという、私の考えを述べたことがある。 NIST が発行した「クラウド･コンピューティング」における自身の定義は、トピックに関する定義のための論議を促進しようとする。しかし、NIST 定義を変更せずに適用する人々は稀であり、また、あらゆる定義を変更せずに適用しようとするケースは、現実的に有り得ないと思われる。

But as much as it would make me happy to never spend another five minutes of my life listening to or reading someone’s attempt to survey the various definitions of “cloud” before offering their own, it’s clear that confusion reigns even among insiders. So the only point at which this definitional is going to stop is when everyone gets tired of it and moves on — there will be no final definition that ends the debate, and the discussion won’t die as a result of technological shifts because the such shifts are what sustain it in the first place.

自身のクラウドを提示してもいない誰かの、用語の関する定義について、聞かされたり読まされたりするのに、私の人生における 5分間を消費しないで済むなら嬉しいと思うだろう。そして、それと同じような混乱が、NIST の内部を支配しているのも明確である。したがって、この定義が収束させることが可能な唯一の時点は、誰もが退屈し、また、前へ進もうと思い直すタイミングとなる。つまり、定義の完了が、その議論を終わらせるようにはならないだろう。そして、テクノロジー･シフトの結果として、この種の議論が終息しないのは、最初からシフトが約束されているからである。

So “the cloud” is a moving target, and nobody can agree on what it means, which is why the NIST’s attempt to first define “cloud computing” and then build a detailed roadmap around that definition will ultimately prove futile. If the people who are building this ever-changing collection of technologies and services called “the cloud” can’t agree on what it is, then how can one agency define that nebulous abstraction and then give an implementation roadmap? It’s not possible.

したがって、「ここで言うクラウド」は移動し続ける目標となる。そして、最初に「クラウド･コンピューティング」を定義した後に、その定義に基づく詳細なロードマップを構築しようとする NIST の試みが、最終的に徒労に終わると分かっているのに、いったい誰が同意するというのだろうか。この、絶え間なく変化し続ける、「クラウド」というテクノロジとサービスのコレクションを構築しようとする人々は、それが何であるかという点に対して合意に達することができない。そうだとしたら、政府機関の 1つが、この不明瞭な抽象概念を定義した後に、実装のためのロードマップを提供することは、現実的な話といえるのだろうか？それは、有り得ないだろう。

An alternative approach: scrap “the cloud”

I’d like to humbly suggest that if NIST really wants to help government agencies save money, it should get out ahead of the private sector and do what all of us will eventually do one day, which is completely scrap “the cloud” as an useful abstraction.

私が謙虚に提案したいことは、行政機関における IT 支出を、NIST が本当に削減したいと考えるなら、民間部門に先行して前進すべきである。そして、誰もが実施することになる事柄を、極論するなら 1日で完了して欲しい。つまり、有用な抽象概念としての「ここで言うクラウド」を、完全にスクラップにして欲しいのだ。

Instead of framing a discussion of the proper allocation of scarce government IT resources around some notion of “cloud,” NIST should focus first on the kinds of things that users want to do with computers i.e., e-mail, telephony, archival storage, data distribution, publication, content creation, content management, etc. Then, for each application type, the agency should use an agreed-upon set of metrics to evaluate the full range of options that modern computing supplies, from old-fashioned shrink-wrapped software to apps to client-server to SaaS to roll-your-own using PaaS or IaaS.

NIST は、いくつかの「クラウド」概念の周辺で不足している、政府の IT リソースを適切に割り振るために、そのディスカッションに枠にはめるのではなく、ユーザーがコンピュータを用いて処理したい事柄から、最初はフォーカスしていくべきだ。具体的には、電子メール／テレフォニー／アーカイブ･ストレージ／分散データ／パブリッシング／コンテント作成／コンテント管理などである。続いて NIST は、最新のコンピューティングが供給する、フル･レンジの選択肢を評価するために、すでに合意されている基準のセットを、それぞれのアプリケーション･タイプに適用すべきだ。それらの選択肢には、クライアント･サーバーのための、シュリンクラップされた従来型のアプリケーション･ソフトウェアから、 PaaS や IaaS 上に構築される、SaaS を用いたユーザー･ロールまでが含まれる。

So instead of asking, “what’s this cloud thing and how are we supposed to think about it and take advantage of it?” CIOs would ask, “how are we doing e-mail this year? Are we still storing it locally for compliance reasons, or is Google Apps now approved for agency use? And what’s currently my cheapest option for publishing new regulations internally and taking feedback? Are we putting stuff up on Slideshare.net and embedding it in a blog with comments enabled, or has some other agency rolled their wiki-based own solution that I can then re-purpose?”

そして更に、CIO たちは「クラウドとは何であり、また、そのアドバンテージについて、どのように活用すべきか？」と尋ねるのではなく、「電子メールについて、今年はどうすべきか？コンプライアンスのために、ローカルにストアすべきか？ Google Apps は政府機関で使用できるものとして承認されているのか? そして、組織内に新しい規則を通達して、そのフィードバックをえるための、最も安価な選択枝は？資料を Slideshare.net に置き、それをブログにエンベッドして、コメントを加えるようにすべきなのか？あるいは、別の政府機関が実現している、wiki ベースのソリューションを再利用すべきなのか？」と尋ねるべきである。

The great thing about this approach is that NIST could reuse much of its existing cloud work to get started. Most, if not all, of the agency’s 10 “cloud” requirements could be re-framed as general software requirements and used to evaluate the best way to deliver a domain-specific compute experience for government end users. So a future NIST report might identify, say, 20 things that people want to do with their computers and mobile devices, so that a subsequent set of 20 reports (putting these in a wiki would be great) could deal with each thing as its own entity.

上記のアプローチの良さは、これまで NIST が作業してきた、クラウドに関する作業の結果を再利用することで、スタートを切れる点にある。この政府機関における 10個の「クラウド」要件の、すべてとは言えなくても、その大半を、汎用的なソフトウェア要件として再構成できる。そして、政府機関とエンドユーザーのドメインに特化された、コンピューティング･エクスペリエンスの供給における、最も適切な方式を評価するために活用できる。したがって、たとえば NIST からの将来のレポートは、コンピュータとモバイル･デバイスを用いる人々が望む、20 の事柄を識別するようになるかもしれない。それにより、次に提供される 20本のレポート･セットは（wiki に入れば更に素晴らしい）、自身のエンティティとして、個々の事象を掘り下げるものになるかもしれない。

I for one would actually love to read the definitive NIST wiki on government e-mail, or content management, or text-based chat, or off-site backup, or publishing, and so on. Such a living repository of up-to-date evaluations of actual, real-world solutions would be a great resource for the private sector, as well.

私個人としては、政府の電子メール／コンテント･マネージメント／テキスト･ベース･チャット／オフサイト･バックアップ／パブリッシングなどに関する、最終的な NIST wiki を喜んで読むようになるだろう。このような、現実と実世界を見据えたソリューションを、up-to-date に評価するライブ･リポジトリは、民間部門のための重要なリソースにもなるだろう。

ーーーーー

今年は、NIST のドキュメントを訳しながら勉強するという時間を、けっこう取っていまして、以下の Security and Privacy と Architecture の訳が終わり、また、いまは、この記事でも取り上げられている Roadmap に取り組んでいるところです。

DRAFT Guidelines on Security and Privacy Issues in Public Cloud Computing
NIST Cloud Computing Reference Architecture (NIST SP 500-292)
NIST Cloud Computing Standards Roadmap (NIST SP 500-291)

訳す身として考えてみると、やはり、何が何でも定義していこうとするスタンスに見え、また、この３つのドキュメントだけでも定義が重複するところがあり、ちょっと面倒くさいという思いは隠せません。ただ、訳してみなければ、何を言っているのかも分かりませんので、頑張っているところです。その甲斐があってか、この記事で Jon Stokes さんが伝えたいことも良く理解できます。そして、この定義が完了することが無いというのも、本当だと思います。ーーー

ーーーーー

Tagged with: Architecture, Definition, Definitive Guide, Federal Cloud, National Institute of Standards and Technology, NIST, Privacy, Roadmap, Security

2 comments

Google の 3つの世代を振り返る – Batch, Warehouse, Instant

Posted in .Selected, Big Data, Google by Agile Cat on September 27, 2011

The Three Ages of Google – Batch, Warehouse, Instant
Monday, August 29, 2011
http://highscalability.com/blog/2011/8/29/the-three-ages-of-google-batch-warehouse-instant.html

The world has changed. And some things that should not have been forgotten, were lost. I found these words from the Lord of the Rings echoing in my head as I listened to a fascinating presentation by Luiz André Barroso, Distinguished Engineer at Google, concerning Google’s legendary past, golden present, and apocryphal future. His talk, Warehouse-Scale Computing: Entering the Teenage Decade, was given at the Federated Computing Research Conference. Luiz clearly knows his stuff and was early at Google, so he has a deep and penetrating perspective on the technology. There’s much to learn from, think about, and build.

世界は変化した。そして、忘れ去られるべきではない、いくつかのものが失われた。 Google の Distinguished Engineer である、Luiz Andre Barroso による魅力的なプレゼンテーションを聴いたとき、この Lord of the Rings の言葉が、私の頭の中で響いていることに気づいた。それは、Google における伝説的な過去と、現在の輝き、そして疑わしき未来のことである。彼の話である、Warehouse-Scale Computing: Entering the Teenage Decade は、Federated Computing Research Conference で提供されている。明らかに、Luiz は自身の専門分野に明るく、また、早期の Google に在籍していた。したがって、このテクノロジーに対して、深く鋭い見識を持っている。そこには、学習し、思考し、構築すべき、数多くの事柄がある。

Lord of the Rings applies at two levels. At the change level, Middle Earth went through three ages. While listening to Luiz talk, it seems so has Google: Batch (indexes calculated every month), Warehouse (the datacenter is the computer), and Instant (make it all real-time). At the “what was forgot” level, in the Instant Age section of the talk, a common theme was the challenge of making low latency systems on top of commodity systems. These are issues very common in the real-time area and it struck me that these were the things that should not have been forgotten.

Lord of the Rings を、2つのレベルに対して適用する。このレベルの変節において、Middle Earth は 3つの世代を経過してきた。Luiz の話に耳を傾けると、Google には Batch（毎月計算されるインデックス）、Warehouse（データセンターこそコンピューティング）、そしてInstant（すべてをリアル･タイムに）があるように思われる。この話において、Instant Age セクションの「忘れ去られたもの」レベルに在る普遍的なテーマは、普及品システムの上に低レイテンシー･システムを構築するというチャレンジであった。それは、リアルタイム･エリアにおける極めて普遍的な問題であり、また、忘れ去られるべきものではないと、私の頭の中に響いた。

What is completely new, however, is the combining of Warehouse + Instant, and that’s where the opportunities and the future is to be found- the Fourth Age.

しかし、完全に新しいものというと、それは Warehouse + Instant という結合であり、また、機会と未来が見いだされる、Fourth Age のあるべき場所となる。

The First Age – The Age of Batch

The time is 2003. The web is still young and HTML is still page oriented. Ajax has been invented, but is still awaiting early killer apps like Google Maps and a killer marketing strategy, a catchy brand name like Ajax.

話は 2003年にさかのぼる。 Web は、まだ若く、HTML はページ指向であった。そして、Ajax が考案されたが、Google Maps のようなキラー･アプリ待っている状況であり、Ajax のような魅力的なブランドネームを持つ、キラー･マーケティング戦略が待ち望まれていた。

Google is batch oriented. They crawled the web every month (every month!), built a search index, and answered queries. Google was largely read-only, which is pretty easy to scale. This is still probably the model most people have in their minds eye about how Google works.

Google は、バッチ志向である。毎月の Web クローリングを行い（毎月だったのだ！）、検索インデックスを構成し、クエリーに対して答えていた。 Google の大部分はリードオンリーであり、また、そのスケールも、きわめて容易であった。おそらく、この段階の Google は、それが機能すろ様子に、人々が関心をもつという、モデルであったに過ぎない。

Google was still unsophisticated in their hardware. They built racks in colo spaces, bought fans from Walmart and cable trays from Home Depot.

Google は、ハードウェアという視点においても洗練されていなかった。彼らは、コロケーション･スペースにラックを構築し、Walmart からファンを買い、Home Depot からケーブル･トレイを仕入れていた。

It’s quaint to think that all of Google’s hardware and software architecture could be described in seven pages: Web Search for a Planet: The Google Cluster Architecture by Luiz Barroso, Jeffrey Dean, and Urs Hoelzle. That would quickly change.

Google のハードウェアとソフトウェアにおける、すべてのアーキテクチャが、Luiz Barroso／Jeffrey Dean／Urs Hoelzle による 7ページのドキュメン『 Web Search for a Planet: The Google Cluster Architecture 』に記述できていた、と思うこと自体が興味深い。そして、それらは急速に変化していった。

The Second Age – The Age of the Warehouse

The time is 2005. Things move fast on the Internet. The Internet has happened, it has become pervasive, higher speed, and interactive. Google is building their own datacenters and becoming more sophisticated at every level. Iconic systems like BigTable are in production.

時は 2005年である。インターネット上の動向が加速してきた。そして、普及と、高速化と、対話型の実現が、インターネット上で実現されていった。 Google は自身のデータセンターを構築し、すべてのレベルにおいて更に洗練されていった。 BigTable のような象徴的なシステムが、プロダクションのレベルにあった。

About this time Google realized they were building something qualitatively different than had come before, something we now think of, more or less, as cloud computing. Amazon’s EC2 launched in 2006. Another paper, this one is really a book, summarizes what they were trying to do: The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines by Luiz André Barroso and Urs Hölzle. Note the jump from 7 pages to book size and note that it was published in 2009, 4 years after they were implementing the vision. To learn what Google is really up to now will probably take an encyclopedia and come out in a few years, after they are on to the next thing.

この時点において、従来からのものとは質的に異なる何かを、Google は構築していると悟った。それは、多かれ少なかれ、クラウド･コンピューティングとして、現在の我々が考えている何かである。そして Amazon の EC2 が、2006年に立ち上がった。もう 1つのペーパーが、今度は本物の本である、The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines が Luiz Andre Barroso と Urs Holzle により書き下ろされ、彼らが行おうとしていることを要約した。そのノートは、当初の 7ページからブックサイズにまで拡大され、彼らがビジョンを実装した 4年後の、2009年に出版された。これまでに Google が行ってきた、本当のことを学習しようとするなら、彼らが次のステージへ移った後に、おそらく百科事典を手に取り、数年を費やす必要があるだろう。

The fundamental insight in this age is that the datacenter is the computer. You may recall that in the late 1980s Sun’s John Gage hailed “the network is the computer.” The differences are interesting to ponder. When the network was the computer we created client-server architectures that appeared to the outside world as a single application, but in reality they were made of individual nodes connected by a network. Wharehouse-scale Computing (WSC) moves up stack, it considers computer resources, to be as much as possible, fungible, that is they are interchangeable and location independent. Individual computers lose identity and become just a part of a service. Sun later had their own grid network, but I don’t think they ever had this full on WSC vision.

この年代における基本的な洞察は、［the datacenter is the computer］という点に集約される。1980年代の後期に、Sun の John Gage が［the network is the computer］という概念を支持したことを思い出すかもしれない。この相違点について、思い巡らすのも面白い。そして、［ the network is the computer］が登場したとき、外側の世界と結ぶクライアント･サーバ･アーキテクチャを、私たちはシングル･アプリケーションとして構成した。しかし、その実体は、ネットワークにより接続される、個別のノードから構成されるものであった。 Wharehouse-scale Computing（WSC）は、考え得る限りのコンピュータ･リソースを、上位のスタックへと押し上げる。そして、その代償として、ロケーションに依存しない、置き換えが可能なものへとなっていく。それぞれのコンピュータがアイデンティティを失い、サービスにおける単なる一部へと変化していく。 Sun の後期には、自身のグリッド･ネットワークを存在していたが、この WSC のフル･ビジョンを、彼らが持っていたとは思えない。

Warehouse scale machines are different . They are not made up of separate computers. Applications are not designed to run single machines, but to run Internet services on a datacenter full of machines. What matters is the aggregate performance of the entire system.

Warehouse スケールのマシンは、別の考え方による。それらは、別個のコンピュータで構成されるものではない。アプリケーションをシングル･マシンで実行するのではなく、データセンターを埋め尽くす全てのマシンで、インターネット･サービスを実行するようにデザインされている。重要なことは、全体的なステムのパフォーマンス･アグリゲーションである。

The WSC club is not a big one. Luiz says you might have warehouse scale computer if you get paged in the middle of the night because you only have petabytes of data of storage left. With cloud computing

この WSC の世界は、決して広ものではない。 Luiz が言うには、ストレージにペタバイトのデータ残っているから、真夜中に呼び出される場合もあるという、Warehouse スケール･コンピュータの世界になるらしい。

The Third Age – The Age of Instant

The time is now. There’s no encyclopedia yet on how the Age of Instant works because it is still being developed. But because Google is quite open, we do get clues: Google’s Colossus Makes Search Real-Time By Dumping MapReduce; Large-Scale Incremental Processing Using Distributed Transactions And Notifications; Tree Distribution Of Requests And Responses; Google Megastore – 3 Billion Writes and 20 Billion Read Transactions Daily; and so much more I didn’t cover or only referenced.

ようやく、現在にまで戻ってきた。それは、まだ開発の途上であるため、Age of Instant の機能や振る舞いに関する百科事典も無い。ただし、Google はきわめてオープンであるため、私たちは手がかりを得られる： Google’s Colossus Makes Search Real-Time By Dumping MapReduce; Large-Scale Incremental Processing Using Distributed Transactions And Notifications; Tree Distribution Of Requests And Responses; Google Megastore – 3 Billion Writes and 20 Billion Read Transactions Daily ；などの、カバーできていない、リファレンスだけのものがある。

Google’s Instant Search Results is a crude example Luiz says of what the future will hold. This is the feature that when you type in a letter in the search box you instantly get back query results. This means for every query 5 or 6 queries are executed. You can imagine the infrastructure this must take.

Google の Instant Search Results は、 Luiz の言う未来へ向けた、まだ荒削りな事例である。この機能は、検索ボックスで文字入力した直後に、クエリーにより結果を受け取るというものである。つまり、すべての検索において、5～6 回のクエリーが実行されることになる。そのために必要なインフラストラクチャについて、あなたはイメージできるだろうか。

The flip side of search is content indexing. The month long indexing runs are long gone. The Internet is now a giant event monster feeding Google with new content to index continuously and immediately. It is astonishing how quickly content is indexed now. That’s a revolution in architecture.

検索の裏側にあるのは、コンテントのインデックス化である。 1ヶ月も前のインデキシングを実行しなくなってから、ずいぶんと歳月が経っている。そしてインターネットは、新しいコンテントのインデックスを、連続的かつ即時的も Google に供給する、巨大なイベント･モンスターであり続ける。現在における、コンテントのインデックス化を評価するなら、そのスピードに驚くばかりとなる。それは、アーキテクチャにおける革命である。

Luiz thinks in the next few years the level of interactivity, insight and background information the system will have to help you, will dwarf what there is in Instant Search. If you want to know why Google is so insistent on using Real Names in Google+, this is why. Luiz explains this change having 4 drivers:

Luiz の考えでは、この先の数年において、対話性と、洞察力、バックグラウンド情報のシステムにより、ユーザーは支援される必要があるようだ。それにより、Instant Search は突出した存在ではなくなる。なに故に、Google＋における Real Names 使用を、Google が強く主張しているのかと考えるなら、それが答えなのかもしれない。 Luiz の説明によると、この変更は、以下の 4項目を含んでいる：

Applications – instantaneous , personalized, contextual
Scale – increased attention to latency tail
Efficiency – driving utilization up, and energy/water usage down
Hardware Trends – non-volatile storage, multi-cores, fast networks

Instant in the context of Warehouse computing is a massive engineering challenge. It’s a hard thing to treat a datacenter as a computer and it’s a hard thing to provide instant indexing and instant results, to provide instant in a warehouse scale computer is an entirely new level of challenge. This challenge is what the second half of his talk covers.

Warehouse コンピューティングという環境での Instant は、大規模エンジニアリングにおける課題である。 Ddatacenter as a Computer の取り扱いは難しく、また、Instant インデキシングと Instant リザルトの提供も難しいことである。Warehouse スケールのコンピューティングにおいて Instant を提供することは、完全に新しいレベルのチャレンジなのである。このチャレンジについては、彼の話の後半でカバーされている。

The problem is we aren’t meeting this challenge. Our infrastructure is broken. Datacenters have the diameter of a microsecond, yet we are still using entire stacks designed for WANs. Real-time requires low and bounded latencies and our stacks can’t provide low latency at scale. We need to fix this problem and towards this end Luiz sets out a research agenda, targeting problems that need to be solved:

何か問題かといえば、この課題に対して、私たちが立ち向かっていないことである。私たちのインフラストラクチャは、壊れている。データセンターは、マイクロ･セカンド･レベルの容量を有しているが、私たちは依然として、WAN のためにデザインされた全体的なスタックを使っている。 Real-time は、低レイテンシと結合レイテンシを要求し、また、私たちのスタックは、必要とされるスケールでの低レイテンシを提供できない。この問題をフィックスする必要があり、また、Luiz が設定した研究アジェンダに立ち向かっていく必要性がある。そして、解決されるべき問題点は、以下のとおりである：

Rethink IO software stack. An OS that makes scheduling decisions 10s of msecs is incompatible with IO devices that response in microseconds.
Revisit operating systems scheduling.
Rethink threading models.
Re-read 1990′s fast messaging papers.
Make IO design a higher priority. Not just NICs and RDMA, consider CPU design and memory systems.

“The fun starts now” Luiz says, these are still very early days, predicting this will be the:

『興味深いことが始まった』と Luiz は言う。そして、以下の項目を予測するには、まだ、日が浅すぎる：

Decade of resource efficiency
Decade of IO
Decade of low latency (and low tail latency)
Decade of Warehouse-scale disaggregation, making resources available outside of just one machine, not just a single rack, but all machines.

This is a great talk, very informative, and very inspiring. Well worth watching. We’ll talk more about specific technical points in later articles, but his sets the stage not just for Google, but for the rest of the industry as well.

このトークは、とても素晴らしく、また有益であり、大いに触発される。考えるべき、充分な重みを持つ事柄である。私たちは、この後の記事においても、特定のテクニカル･ポイントについて説明していくだろう。ただし、彼のセットするステージは Google のためだけに有るのではなく、この業界全体のための有るのだ。

Related Articles

Web Search for a Planet: The Google Cluster Architecture by Luiz Barroso, Jeffrey Dean, and Urs Hoelzle
The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines by Luiz André Barroso, Urs Hölzle
It’s time for low latency by Stephen M. Rumble, Diego Ongaro, Ryan Stutsman, Mendel Rosenblum, and John K. Ousterhout

ーーーーー

ひさびさの、Todd Hoff さんの記事です（Big Data カンファレンスのリストはありましたが）。この記事は、たしか 8月の終わりにポストされていたのですが、f8 が気になって手を付けられずにいました。でも、Facebook が新機軸を発表した後に、こうして両社を見比べてみると、やはり Google はインフラストラクチャの会社なのだと感じさせてくれますね。とてもカッコ良いですこのドキュメントの先にあるリファレンスは、まだ、まったく見ていませんが、きっと深遠な世界が広がっているのでしょうね。ーーー

ーーーーー

Tagged with: Architecture, Batch, Big Data, Big Table, Google, Instant, Luiz Andre Barroso, MapReduce, Todd Hoff, Warehouse

leave a comment

NIST がクラウドのための Roadmap と Architecture を発表

Posted in .Selected, NIST by Agile Cat on September 21, 2011

NIST Releases Federal Cloud Roadmap, Architecture
By Elizabeth Montalbano September 14, 2011
http://www.informationweek.com/news/government/cloud-saas/231601427

ーーーーー

＜関連＞ NIST の Cloud Architecture 序文

ーーーーー

The organization that creates technology standards for the federal government has released a new cloud computing roadmap and reference architecture as part of its continued efforts to help federal agencies adopt this technology model.

連邦政府のテクノロジー･スタンダードを策定する NIST は、クラウド･テクノロジー･モデルを採択する、各種の連邦機関を支援する継続的な政策の一部として、クラウド･コンピューティングに関する、新しいロードマップとリファレンス･アーキテクチャをリリースした。

The documents provide guidance for agencies to help understand the standards they should use when deploying clouds, as well as the categories of cloud services that can be used across the government, according to the National Institute for Standards and Technology (NIST).

このドキュメントは政府機関に提供するものとしては、クラウドをディプロイするとき使用すべきスタンダードの理解に関するガイダンスだけではなく、National Institute for Standards and Technology (NIST) に準拠する、全体的な政府機関で利用されるクラウド･サービスのカテゴリーも含まれる。

Top 20 Government Cloud Service Providers
Slideshow ⇒

The NIST Cloud Computing Standards Roadmap includes a standards inventory the organization will continue to update as more are created. The inventory covers standards for key features of deploying a cloud computing architecture, such as security, portability, and interoperability. It also identifies models and use cases that are relevant to cloud computing and identifies standardization priorities for the feds in the areas of security auditing and compliance, and identity and access management, according to NIST.

その、NIST Cloud Computing Standards Roadmap は、当組織が更新･策定し続ける、スタンダードの項目を取り込んでいくものとなる。その項目は、セキュリティ／ポータビリティ／インターオペラビリティといった、クラウド･コンピューティング･アーキテクチャの、ディプロイメントに関する重要なスタンダードをカバーする。 NIST によると、それらの項目は、クラウド･コンピューティングに関する適切なモデルとユースケースを識別し、また、セキュリティの監査と遵守および、ID とアクセスの管理領域において、連邦政府職員のために正規化プライオリティを識別するものにもなる。

As the standards were developed, NIST also found gaps that still need to be covered in the areas of security and privacy protection, user interfaces, and business-oriented features, it said. The guiding principles were used to create the NIST Cloud Computing Reference Architecture, a vendor-neutral design meant to serve as a guideline for agencies, not to be followed specifically, according to NIST.

それらのスタンダードが作成されるにつれて、さらに NIST は、セキュリティとプライバシーの保護および、ユーザー･インターフェイス、ビジネス機能などの領域で、カバーされるべきギャップを探し続けていく。NIST Cloud Computing Reference Architecture を作成するために用いられた指針は、ベンダー･ニュートラルなデザインが、政府機関のためのガイドラインを担うが、明確な制約をもたらさないものと、NIST はしている。

The architecture is based on a system of the so-called “actors” in a cloud architecture–consumer, provider, broker, auditor, and carrier–and defines the roles each play. NIST hopes the industry will weigh in on the architecture and compare their cloud offerings with the one presented by the government, NIST Reference Architecture working group co-convener Robert Bohn said in a statement. “The publication is also an opportunity for industry to map their reference architecture to the one NIST developed with input from all sectors,” he said.

このアーキテクチャは、クラウ･ドアーキテクチャで「actor」と呼ばれるシステム（消費／供給／取次／監査／通信）に基づき、また、それぞれの役割を明確に実施していく。この業界が、NIST のアーキテクチャを評価し、彼らが提供するものと、政府が提供するものを、比較することが望まれると、NIST Reference Architecture ワーキング･グループ議長である Robert Bohn はステートメントで語っている。「今回の発行は、すべての行政部門からインプットを用いて、NIST が策定したアーキテクチャに対して、産業界のリファレンス･アーキテクチャをマップする機会である」とも、彼は発言している。

Federal agencies look to NIST to guide them on implementing technology and the standards to support it, and cloud computing is no exception. As the federal government increasingly adopts the cloud to cut costs and create new efficiencies, NIST has slowly been publishing documents to cover the various facets of cloud computing. It will incorporate these and the new documents in its comprehensive NIST U.S. Government Cloud Computing Technology Roadmap, which it expects to release in November.

連邦政府の各機関は、自身をサポートするテクノロジーとスタンダードの実装において、NIST がガイドしてくれることに注目しているが、クラウド･コンピューティングも例外ではない。そして、コストの削減と新たな効果をもたらすために、連邦政府がクラウドを適用を進めるにつれて、クラウド･コンピューティングの多様な局面をカバーする、各種のドキュメントを、NIST はゆっくりとしたペースで発行してきた。それらのドキュメントと、新しいドキュメントが、包括的な NIST U.S. Government Cloud Computing Technology Roadmap に取り入れられ、11月にリリースされる予定である。

NIST previously has released documents with security information for the cloud as well as a more complete set of overall guidelines.

In the new, all-digital issue of InformationWeek Government: As federal agencies close data centers, they must drive up utilization of their remaining systems. That requires a well-conceived virtualization strategy. Download the issue now

More Government Insights
Motivations for software security
Can You Use Cloud to Meet Customer Demand and Succeed?
Research: Federal Government Cloud Computing Survey
SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger

ーーーーー

文中にもあるように、ゆっくりとしたペースで、NIST はスタンダードを発表してきますが、それはノンビリしてというものではなく、デファクトの確立を邪魔しないようにという、配慮なのだと思います。目立たず、目立とうともせず、着々と仕事をこなしている NIST を見ると、アメリカ IT 業界の強さが、この辺りに根ざしていると感じられてきます。今回の Architecture 編は、Appendix を除くと 20ページにも満たない短編なので、ぼちぼち勉強していこうと思っています。でも、Roadmap 編は、76ページもあるので (なが～い)、年末を目標に読破したいですーーー

ーーーーー

Tagged with: Architecture, Cloud, Cloud Computing, NIST, Roadmap

leave a comment

Evernote アーキテクチャ – 900万人のユーザーと、1億 5000万のリクエストに日々対応

Posted in Freemium, Miscs, SOHO with Cloud by Agile Cat on May 31, 2011

Evernote Architecture – 9 Million Users and 150 Million Requests a Day
Monday, May 23, 2011 at 8:33AM
http://highscalability.com/blog/2011/5/23/evernote-architecture-9-million-users-and-150-million-reques.html

The folks at Evernote were kind enough to write up an overview of their architecture in a post titled Architectural Digest. Dave Engberg describes their approach to networking, sharding, user storage, search, and some other custom services.

親切なことに、Evernote の人々は Architectural Digest というタイトルのポストにおいて、そのアーキテクチャの概要を説明してくれた。具体的にいうと、Networking および、Sharding、User Storage、Search や、その他の Custom Service について、Dave Engberg が記述している。

Evernote is a cool application, partially realizing Vannevar Bush‘s amazing vision of a memex. Wikipedia describes Evernote’s features succinctly:

Evernote はイカしたアプリケーションであり、Vannevar Bush のステキなビジョンである memex（"memory" and "index"）を、部分的に具体化したものでもある。 Wikipedia は Evernote の特徴について、以下のように簡潔に紹介している：

Evernote is a suite of software and services designed for notetaking and archiving. A "note" can be a piece of formattable text, a full webpage or webpage excerpt, a photograph, a voice memo, or a handwritten "ink" note. Notes can also have file attachments. Notes can then be sorted into folders, tagged, annotated, edited, given comments, and searched. Evernote supports a number of operating system platforms (including Android, Mac OS X, iOS, Microsoft Windows and WebOS), and also offers online synchronization and backup services.

Evernote とは、ノート作成とアーカイブを目的にデザインされた、ソフトウェアとサービスの組み合わせのことである。その「ノート」は、フォーマットが可能なテキストの断片や、Web ページの全体／一部に対応するだけではなく、写真や、音声メモ、手書きの「インク」にも対応する。さらに「ノート」は、ファイル添付も実現している。また、「ノート」を編集するだけではなく、管理のための機能として、フォルダー内でのソートや、タグ付け、注釈とコメントの追加、検索にも対応している。 Evernote は、数多くのオペレーティング･システムとプラットフォームをサポートし（Android、Mac OS X、iOS、Microsoft Windows、WebOS など）、オンライン同期とバックアップのサービスも提供する。

Key here is that Evernote stores a lot of data, that must be searched, and synced through their cloud to any device you use.

ここでの主題は、Evernote にストアされる大量のデータに関するものである。それらのデータは検索に対応し、また、各種のユーザー･デバイスとクラウドを介して同期しなければならない。

Another key is the effect of Evernote’s business model and cost structure. Evernote is notable for their pioneering of the freemium model, based on the idea from their CEO: The easiest way to get 1 million people paying is to get 1 billion people using. Evernote is designed to become profitable at a 1% conversion rate. The free online service limits users to a hefty 60 MB/month while premium users pay $45 per year for 1,000 MB/month. To be profitable they most store a lot of data without spending a lot of money. There’s not a lot of room for extras, which accounts for the simple practicality of their architecture.

もう 1つの視点は、ビジネス･モデルとコスト構造に関する Evernote の取り組みである。 Evernote は無料ネット･モデルの草分けであり、それが、同社の CEO のアイデアに基づいていることを指摘しておく。つまり、100万人の人々から対価を得るための、最も簡単な方法は、10億人の人々に使ってもらうという発想である。つまり、Evernote は、この 1％の変換レートで、利益が生じるようにデザインされている。無料のオンライン･サービスでは、ユーザーからのアップロードが 60MB（月）に制限されるが、1年間に $45 支払うプレミアム･ユーザーは、その枠が 1,000MB（月）まで広がる。したがって、利益を確保するためには、多額のコストを生じることなく、大量のデータをストアしなければならない。そのアーキテクチャにおけるシンプルな実用性を説明すると、過大な利益が生じない構造が見えてくる。

The article is short and succinct, so definitely read it for details. Some takeaways:

Controlling costs. Evernote runs out of a pair of dedicated cages in a data center in Santa Clara, California. Using a cloud wouldn’t provide enough processing power and storage at a cheap enough cost to make Evernote’s business model work. As their load doesn’t appear to be spiky, using their own colo site makes a lot of sense, especially given how they make use of VMs for reliability.

Controlling costs. Evernote は、California, Santa Clara のデータセンターで、2つの専用フロアを埋め尽くしている。 Evernote のビジネス･モデルをクラウド上で推進しても、大幅に低減されるコストで、充分な処理能力とストレージを実現することは無いだろう。このサービスにおいては、極端なピークが生じないため、自身のコロケーション･サイトでの運用、とりわけ信頼性のための VM 使用において、大きな意味を持つだろう。

Architecture based on the nature of the data. User notes are independent of each other, which makes it very practical for Evernote to shard their 9.5 million total users across 90 shards. Each shard is a pair of two quad-core Intel SuperMicro boxes with lots RAM and a full chassis of Seagate enterprise drives in mirrored RAID configurations. All storage and API processing is handled by a shard. They’ve found using directly attached storage to have the best price/performance ratio. Using a remote storage tier, with the same level of redundancy, would cost substantially more. Adding drives to a server and replicating with DRDB is low both in overhead and costs.

Architecture based on the nature of the data. ユーザー･メモは、全体で 950万人のユーザーを90の区分に Sharing するという、きわめて現実的な Evernote 方式により、どの独立性を守られている。それぞれの区分は、2つの Intel Quad Core と大量のメモリを搭載した SuperMicro ボックスと、 RAID コンフィグレーションされた Seagate のエンタープライズ･ドライブの組み合わせを、ペアで有している。すべてのストレージと API の処理は、この区分ごとに実行される。彼らは、最高の価格／性能比を得るために、ダイレクトにアタッチされるストレージを選択した。リモート･ストレージ･ティアを用いて、同等の冗長性を得るには、さらに多くの費用がかかるだろう。サーバーにドライブを加え、DRDB をリプリケーションする方式は、オーバーヘッドとコストを引き下げる。

Application redundancy. Each box runs two VMs. A primary VM runs the core stack: Debian + Java 6 + Tomcat + Hibernate + Ehcache + Stripes + GWT + MySQL (for metadata) + hierarchical local file systems (for file data). DRDB is used to replication a primary VM to a secondary VM on another box. Heartbeat is used to fail over to a secondary VM is the primary VM dies. A smart way to use those powerful machines and make a reliable system with fewer resources.

Application redundancy. それぞれのボックス内で、2つの VM が稼動している。第1の VM はコア･スタックを実行する。具体的に言うと、 Debian + Java 6 + Tomcat + Hibernate + Ehcache + Stripes + GWT + MySQL (for metadata) + 階層的なローカル･ファイル･システム (for file data) である。 DRDB はリプリケーションのために用いられ、別のボックス内にある第2の VM への模写を行う。ハートビートを用いて、第 1 VM のダウンが検出されると、第 2 VM へのフェイル･オーバーが行われる。こうしたパワフルなマシンを用いて、少量のリソースで信頼性の高いシステムを構築するのは、スマートな手法である。

Data reliability. User data is stored on four different enterprise drives across two different physical servers. Nightly backups copies data over a dedicated 1Gbps link to a secondary data center.

Data reliability. ユーザー･データは、2つの物理的なサーバーまたいだ、4つのエンタープライズ･ドライブにストアされる。バックアップ･コピーは、専用の 1Gbps リンクを用いて、第 2データセンターへ向けて毎晩行われる。

Fast request routing. User account information–username, MD5 password, and user shard ID–is stored in an in-memory MySQL database. Reliability comes from RAID mirroring, DRBD replication to a secondary, and nightly backups. This approach makes the routing of users to their data a simple and fast in-memory lookup, while still being highly available.

Fast request routing. ユーザー･アカウント情報（ユーザ名、MD5 パスワード、ユーザー Sharing ID）は、in-memory MySQL データベースにストアされる。つまり、信頼性は、RAID ミラーリングおよび、第2 DRBD へのリプリケーション、そして、毎晩のバックアップによりもたらされる。このアプローチは、きわめて可用性が高く、また、ユーザー･データへのルーティングを、シンプルで高速のイン･メモリー検索で実現する。

A separate pool of 28 8-core servers process images for search, handwriting recognition, and other services. This is custom software and is a powerful value-add that is not easily replicated by anyone else.

28 セットの 8 Core コア･サーバーにより、検索のためのイメージ生成や、ハンド･ライティング認識などのサービスに対応する。そこで用いられるカスタム･ソフトウェアでは、容易に模倣できるものではない。

Puppet is used for configuration management.

コンフィグレーション･マネージメントのために、Puppet が用いられる。

Monitoring is done with Zabbix, Opsview, and AlertSite.

モニタリングに関しては、Zabbix および、Opsview、AlertSite が用いられる。

There’s a promise of future articles focusing more on individual subsystems. I look forward to these as you have to appreciate the elegance of the system they’ve created for their business model. A good example to learn from.

そこにあるのは、個々のサブシステムに注目することで達成していく、将来へ向けた展望である。彼らのビジネス･モデルに合わせて作られた、そのシステムのそのエレガンスさが、正当に評価されるときを、私は楽しみにしている。そこには、学ぶべき例がある。

A conversation with Phil Libin about EverNote’s new memex by Jon Udell
Comparison of notetaking software
Evernote Announces “Shiny New Evernote Web” by Dan Cohen

ーーーーー

大の Evernote ファンである Agile_Cat としては、このような記事を読めるだけで嬉しいですし、ガンバレという思いをさらに強くしてしまうわけです。この記事で明らかにされたアーキテクチャにより、これまで以上の安心感が得られて、ほんとうに良かったと思っています。＄45／年の使用料というかドネーションも、すでに 2年目の支払いが終わりましたが、とても気分良く払えるところが、Evenote のステキなところです今後とも、よろしくお願いしま～～～す！ーーー

ーーーーー