Agile Cat — in the cloud

2012年 Agile_Cat 総まとめ ページです

Posted in .Chronicle, .Selected by Agile Cat on December 31, 2012

Cloud と Post-PC と BYOD と・・・
http://wp.me/pwo1E-5sv

image

2012年は、IT にとって、どのような年だったのでしょうか?  それぞれの見方があり、一言でマトメられるものではありませんが、すべてに共有されるべき、数字による事実というものもあります。 その意味で、2012年に入って直ぐに発表された、2011年 Q4 の、iPhone 4S による破壊的な利益は、それまでの Wintel 時代を通じて積み上げられてきた、ありとあらゆる概念や常識を、文字どおり破壊的に吹き飛ばしてしまうものでした。 そして、iPad が登場してからの様々な変化を、チャートを用いて追いかけていく『 みんなで 仰天 Post-PC 特集 』は、この時代の節目を一覧する上で、とても分かりやすいマトメを提供しているはずです。

imageその一方で、Agile_Cat における人気投票ともいえる、『 2012年 Top-10 : カルチャーの再定義が重要という傾向か?』も、やはり、同じような傾向を示しています。このサイトから情報を得ていく皆さんは、ベンダー/プロバイダー/ユーザーといった立場で、IT に携わっているはずです。 そして、みなさんが関心を示したポストを並べてみると、ここで言う時代の変化に、積極的に取り組んでいこうとする意識が感じられてくるのです。

もちろん、Agile_Cat も その一人であり、このブログを構成していく方針として、プロダクト/ビジネス・モデル/カルチャーの再定義が必要という、意識を持っているはずです。 それは、単に、デバイスの話に留まるものではなく、Post-PC と Cloud を両輪として進んでいく、これからの道筋を示すものでもあります。 それを、Agile_Cat なんぞに語らせるのではなく、この世界で活躍する超一流の書き手たちに説明してもらおうと、素晴らしい記事を集めてみたのが、以下の四部作マトメです。

CIO のための 百選 : 2012-Q1
CIO のための 百選 : 2012-Q2
CIO のための 百選 : 2012-Q3
CIO のための 百選 : 2012-Q4

冒頭で、Apple の破壊的、、、という表現を用いましたが、この世界には、同列に並べるべき破壊王が、あと三人いるようです。 IaaS の盟主として君臨する Amazon、そして、常に未来の IT を見せ続ける Google、さらには、10億人のユーザーを使って壮大な実験を繰り広げる Facebook が、そのクラブのメンバーです。奇しくも、The Economist が Battle of the internet giants:Survival of the biggest というタイトルの記事を出しましたが、その号の表紙を飾るのが、この四強による深海での暗闘です。 ちょっとだけ、その書き出し部分を、以下に引用してみます。

インターネット時代における Big-4 である、Google と、Apple と、Facebook と、Amazon は、通常のレベルを超えた生命体である。 この世界いおいて、これほどまでに急速に成長し、また、これ程までの範囲に触手を広げる企業は、他に例を見ない。 Apple は、資本主義の巨像になってしまった。S&P 500 における 4.3% を占め、また、グローバル証券市場の 1.1 % を占めているのだ。 約 4億 2500万人の人々が、オンライン・ストアである iTunes を使い、その仮想化されたコンテンツの棚には、ミュージックなどのデジタル・コンテンツが詰め込まれているのだ。 その一方で Google は、サーチとオンライン・アドの世界で、他者を寄せ付けないグローバル・リーダーとなっている。 その Android ソフトウェアは、世界へ出荷されるスマートフォンの、3/4 に対してパワーを供給している。 Amazon は、数多くの国々において、オンライン小売りと電子ブックの市場を独占しているが、クラウド・コンピューティングの舞台裏における実力については、それほど良くは知られていない。 そして Facebook は、周知のとおり、10億人のユーザーを抱えるソーシャル・ネットワークであり、その人口は世界で 3番目の大国に相当する。

年間を通じて、さまざまな写真やイラストがネット上に溢れ出るわけですが、Agile_Cat としては、2012年を描き出す一枚として、The Economist の表紙を推したいです。この記事は、お正月休み明けにポストするつもりですが、「インターネット時代の独禁法の在り方」を示唆する内容となっています。チョット話が逸れてしまいましたが、Agile_Cat の四強マトメは以下のとおりです。

それ以外にも、今年に目立った動きをしている、以下のカテゴリについてもマトメを作ってみました。James Hamilton さんに関しては、1年でマトメを作るほどの量がないので、これまでの2~3年分をカバーするかたちにしました。そして、一番最後は、これがなければ年が明けないという、Agile_Cat 恒例の Week End 特集です。

・・・というわけで、今年の最後のポストが完成しました。 右ペインにも、このページヘの入口となる、分かりやすいバナーを貼っておきますので、2012年を振り返るときに、ぜひ、ご利用ください。

一年間、有難うございました。 そして、来年も、よろしくお願いします。 良いお年をお迎えくださ~い  Smile

2012年 大晦日 image

みんなが 納得の Amazon 特集

Posted in .Selected, Amazon, Post-PC by Agile Cat on December 11, 2012

脅威の AWS から、Kindle 原価宣言まで・・・
http://wp.me/pwo1E-5ls

Agile_Cat_2012

image[ だいすき] な Apple と、[気になる] Google に続いて、いよいよ Amazon です。やはり、表題の [納得] とか [うなずく] とか、そんな形容詞が似合いますよね。小売業としてのフロントエンドから、利益を求めない Kindle、そして、バックエンドの巨大データセンターまで、一直線のポリシーを貫いている点が、Amazon の Amazon たる所以なのだと思います。

この一年、AWS の成功の理由を考え続けてきましたが、Agile_Cat なりの結論は、ベンダーというより e-Commerce ユーザーとしてのノウハウの蓄積が、そのポジションを築き上げたというものです。 現実に動かしていくべきサービス・モデルが明確であるから、そのインフラである AWS の、つまりクラウドの要件が見えるのだと思うのです。 それと同じことが、Google にも、Facebook にも言えるわけで、その延長線上に Apple は 『 Twitter を買収すべき 』という説まで有るのだと思えるのです。

ーーーーー

Jan 12: Kindle Fire のシェアが、クリスマスを挟んで 3倍以上に伸びたらしい!
Jan 18:
Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚 by James Hamilton
Feb   3:
Kindle Fire ユーザーの半数が、この製品に満足している
Feb 11:
Amazon が安いのか? Hosting が安いのか? コスト分析モデルで比較!
Feb 22:
Amazon の ワークフロー・サービス とは?
Mar   9:
Amazon の新たな悩みは、Sony と OpenStack の蜜月にあるのか
Mar 13:
身勝手 Zynga の、AWS 使い倒し術とは?
Mar 19:
結局のところ、いま ストレージに、何が起こっているのか?
Mar 20:
トップを快走する AWS と、それを追いかける 7人の チャレンジャー
Mar 22:
Amazon と Eucalyptus が提携 – Hybrid を超える Hybrid を!

Apr 12: Amazon は新しい Search Service で、Google や HP を出し抜くのか ?
Apr 19:
Amazon S3 にストアされる Object が [1兆 ] に近づいている
Apr 27:
Android タブレット市場の 52% を、あっという間に Kindle  が占有した!
Jun 12:
NASA は OpenStack を捨て、Amazon に乗り換えたのか?
Jun 14:
Amazon の Virginia DC がダウン: Quora や Heroku に影響が!
Jun 15:
AWS と Rackspace の間で、クラウド・バーストを実験する!

Jul   5: Amazon による UpNext の買収は、スマホ参戦の狼煙か?
Jul 10:
Amazon が通り過ぎた後に、どれだけのクラウドが生き残れるのか?
Jul 12:
AWS S3 にストアされる Object が [ 1兆 ] を超えた
Aug 21:
Google の敵は、Apple でも Facebook でもない:シアトルの あの会社だ
Aug 22:
DynamoDB および、ホット SSD + コールド S3 というパターン
Aug 22:
Amazon がモバイルで狙っている、その広大なマーケットを探る
Sep   1:
Kindle Fire 2 は、広告なしの $200 と、広告つきの $100 になる?
Sep   7:
Amazon が 新 Kindle Fire を発表: 価格は $159 で 9月14日 に出荷
Sep   7:
Kindle Fire の 7 inch HD 版 : 価格は $199 で Nexus 7 とガチンコだ
Sep 10:
Android Tablet の出荷数が、iPad の 40% に迫っている?
Sep 14:
Amazon AWS の年商は、どう見ても $ 1 billion を超えている
Sep 27:
Amazon Glacier は、DEEP & FREEZE なコールド・データを取り扱う

Oct   9: NASDAQ の FinQloud は、AWS ベースの金融サービス・プラットフォームだ
Oct 15:
Amazon 宣言 : すべてのデバイスを原価で提供する – Jeff Bezos
Oct 17:
Amazon が CPU ビジネスに参入 : あの TI を買収する?
Oct 27:
Apple vs. Amazon : リテールの双璧をチャートで比較する
Oct 29:
Amazon は久々の 四半期 赤字 : その内容は?
Nov 13:
Pinterest のアーキテクチャと経済: AWS を使い倒せ!
Nov 17:
学校教育の場で iPad に挑む Kindle と Whispercast
Nov 22:
AWS のコストを分析する:TripAdvisor と Pinterest
Dec   2:
James Hamilton 特集
Dec   4:
Redshift により データ・ウェアハウスの魔法を解く:James Hamilton
Dec   9:
AWS イベントでの Parse が スゴそう – BaaS の勢いが加速する?

ーーーーー

Agile_Cat_2012それにしても、Kindle Fire の原価販売宣言は強烈でしたね。 それは、タブレットに関する方針ですが、徹底してコストを削減したデバイスという、これからの時代に必須のノウハウが詰め込まれているはずです。 もし、Amazon がスマホに参入するなら、開発途上国のマーケットでも通用する、価格戦略を展開できると思います。 ただし、今の時点では、本業である e-Commerce へつながらないという、Amazon ならではの判断があるのでしょうかね? image

ーーーーー

<関連>

みんなの 好きな Apple 特集
みんなの 気になる Google 特集
みんなが 納得の Amazon 特集
みんなが ワクワク Facebook 特集

(=^・^=) 2012 年 8月の Top-30

Posted in Research by Agile Cat on September 1, 2012

インフラに関するポストの多かった月です・・・
http://wp.me/pwo1E-4FZ

image

先月に引き続き、この1ヶ月間(8月)の Top Post – 30 をリストアップしてみました。 さらに、今月からは、Agile_Cat おススメ肉球スタンプも付きました :) 前述のとおり、8月は、とくに Facebook 関連のインフラ話が、つまり OpenCopute 関連のトピックが充実していたように思えます。OpenCompute ってなに? ・・・という方は、まずは「10: Facebook 革命は、なにをハードウェア産業に強いるのか」をご覧ください。とても内容のあるインタビュー記事となっています。

それと、伝説の Google 100万台サーバー説を、我らが James Hamilton 先生が解明してくださいました。Google のデータセンター消費電力から PUE 分を差し引き、それを平均的なサーバー消費電力で割り算するという、きわめてシンプルでありながら、誰も思い描かなかった方式で、ビシッと推測しています! また、Facebook インフラの急成長ぶりに関しても、同様に解説しています。「8: Facebook と Google の サーバー保有台数を推測する」を ご覧くださ~い!

ーーーーー

  1: Google の敵は、Apple でも Facebook でもない:シアトルの あの会社だ

image

  2: Netbook が iPad に踏み潰された状況を、チャートで再現してみる

  3: Google Now が iOS に侵攻 : Siri なんて単なるジョークだ

  4: iMac 2012 と、13″ Retina MacBook Pro と、OS X 10.8.1 のウワサ話

  5: Office 2010 で、メール添付ファイルが開けないという問題を解消するには

  6: Windows 8 RTM の無償トライアルが始まったが、普通の人にはお勧めできない

  7: Gartner の Cloud Hype Cycle 2012 で、これからの市場を占う

image

  8: Facebook と Google の サーバー保有台数を推測する – James Hamilton

image

  9: Google データセンターを埋め尽くす、独自サーバーのコンセプトとは?

image

10: Facebook 革命は、なにをハードウェア産業に強いるのか

image

11: VMware が OpenStack に参加って マヂ ですか?

12: iPhone 5 の写真と仕様がリーク : 厚さは 7.6mm らしい

13: 日本と世界のインターネット・トラフィック – 2012年/7月

14: Windows 8 の UI は、Metro あらため Modern になるらしい

15: Steve Jobs は iPad Mini に同意していたらしい

16: Intel が思い描く、コモディティ SDN の構想 _1

image

17: 主要ソーシャル・メディアについて、年齢と性別の分布を調べてみた

18: 無限のストレージを、$4/月で提供する Backblaze の秘密とは?

19: iPhone の Facebook アプリが、Objective-C で 2倍速になった

20: Facebook の 巨大 DC を気化熱で冷やす、ミストの秘密について説明しよう

image

21: PC と Tablet で構成される市場 : その背景と展望を調査する

22: CloudOn 2.0 は、iPad に Microsoft Office を取り込んでしまうのだ!

23: Apple や Facebook などの、インフラ投資比率をチャートで見比べる

image

24: OneNote 2010 が Evernote に負けているのは ココだ!

25: Google がフィンランドに作った海水冷 DC とは?

image

26: Gartner が指摘する要点 Top-10 : データセンターと IT インフラストラクチャ

27: DynamoDB および、ホット SSD + コールド S3 というパターン

image

28: Intel が思い描く、コモディティ SDN の構想 _2

image

29: なぜ アプリの開発は、最初が iPhone で、次に Android なのか?

30: Amazon がモバイルで狙っている、その広大なマーケットを探る

   

ーーーーー

imageそして、リサーチものというと、「7: Gartner の Cloud Hype Cycle 2012 で、これからの市場を占う」と「23: Apple や Facebook などの、インフラ投資比率をチャートで見比べる」が面白いです。そして、ストレージに関しては、「18: 無限のストレージを、$4/月で提供する Backblaze の秘密とは?」と「27: DynamoDB および、ホット SSD + コールド S3 というパターン」があります。 もちろん、データセンター・フリークのための「20: Facebook の 巨大 DC を気化熱で冷やす、ミストの秘密について説明しよう」と「25: Google がフィンランドに作った海水冷 DC とは?」も、大 お勧めです! それと、番外の「赤いオペラと 緑のエバノ」も、お時間がありましたら、ぜひ、ど~ぞ! ーーー image

ーーーーー

<関連>

(=^・^=) 2012 年 7月の Top-30
(=^・^=) 2012 年 6月の Top-30

Facebook と Google の サーバー保有台数を推測する – James Hamilton

Posted in .Selected, Data Center Trends, Facebook, Google, James Hamilton by Agile Cat on August 17, 2012

Fun with Energy Consumption Data
http://wp.me/pwo1E-4As

Sunday, August 12, 2012
http://perspectives.mvdirona.com/2012/08/13/FunWithEnergyConsumptionData.aspx

Agile_Cat_Loupe

Facebook recently released a detailed report on their energy consumption and carbon footprint: Facebook’s Carbon and Energy Impact. Facebook has always been super open with the details behind there infrastructure. For example, they invited me to tour the Prineville datacenter just prior to its opening:

最近のことだが、Facebook のエネルギー消費とカーボン・フットプリントに関する詳細なレポートが発表された: Facebook’s Carbon and Energy Impact。 Facebook は、そのインフラストラクチャの背景となる詳細な情報を、きわめてオープンなかたちで提供してきた。 たとえば、Prineville データセンターがオープンする前に、彼らは私を招待してくれたほどだ:

Reading through the Facebook Carbon and Energy Impact page, we see they consumed 532 million kWh of energy in 2011 of which 509m kWh went to their datacenters. High scale data centers have fairly small daily variation in power consumption as server load goes up and down and there are some variations in power consumption due to external temperature conditions since hot days require more cooling than chilly days. But, highly efficient datacenters tend to be effected less by weather spending only a tiny fraction of their total power on cooling. Assuming a flat consumption model, Facebook is averaging, over the course of the year, 58.07MW of total power delivered to its data centers.

Facebook の ”Carbon and Energy Impact” ページを読み通してみると、2011年における 532 million kWh という電力消費量に気づく。 つまり、そのデータセンターでは、509m kWh が消費されたことを示している。そのサーバー負荷が上下するにしても、大規模データセンターにおける電力消費量の変動は、きわめて小さなものとなる。もちろん、夏季と冬季を比較すれば、そこでの冷却の必然性が異なるため、こうした外気条件が要因となる、電力消費量の若干の相違が生じる。 しかし、きわめて効率のよいデータセンターにおいては、全体的な消費電力に対する気候変動からの影響が、ごく小さい範囲に収まる傾向にある。 そして、このフラットな消費モデルを前提にすると、Facebook は年間を通じて、そのデータセンターに、58.07MW のトータル電力を供給したことになる。

Facebook reports an unbelievably good 1.07 Power Usage Effectiveness (PUE) which means that for every 1 Watt delivered to their servers they lose only 0.07W in power distribution and mechanical systems. I always take publicly released PUE numbers with a grain of salt in that there has been a bit of a PUE race going on between some of the large operators. It’s just about assured that there are different interpretations and different measurement techniques being employed in computing these numbers so comparing them probably doesn’t tell us much. See PUE is Still Broken but I Still use it and PUE and Total Power Usage Efficiency for more on PUE and some of the issues in using it comparatively.

Facebook のレポートによると、その Power Usage Effectiveness(PUE)は、1.07 という信じられないほどの値を叩き出している。つまり、サーバーに供給される 1 Watt に対して、その配電とメカニカルなシステムにおいて、わずか 0.07W だけが失われていることを意味する。 大手オペレーター間では、ちょっとした PUE レースが行われている感があるので、パブリックに発表された PUE 値を、常に私は割り引いて捉える。 大まかなところで確信できるのは、こうしたコンピューティングに関する値に関しては、それぞれの解釈と、それぞれの測定法が採用されていることだ。 したがって、それは、私にとって、大きな意味をもたらさない。 PUE に関しては、PUE is Still Broken but I Still use itPUE and Total Power Usage Efficiency を参照して欲しい。それを、比較で用いることで生じる、いくつかの問題が浮かび上がるだろう。

Using the Facebook PUE number of 1.07, we know they are delivering 54.27MW to the IT load (servers and storage). We don’t know the average server draw at Facebook but they have excellent server designs (see Open Compute Server Design) so they likely average at or below as 300W per server. Since 300W is an estimate, let’s also look at 250W and 400W per server:

Facebook の PUE である 1.07 を用いることで、IT(サーバーとストレージ)に、54.27 MW が供給されていることが分かる。 私たちは、Facebook における平均的なサーバー負荷を知らないが、彼らは素晴らしいサーバー・デザイン(Open Compute Server Design を参照)を有しているため、サーバーごとの消費電力は、おそらく 300W を下回るだろう。 300W を推定値とする一方で、サーバーごとの消費電力を、250W と 350W に当てはめて見てみよう。

  • 250W/server: 217,080 servers
  • 300W/server: 180,900 servers
  • 350W/server: 155,057 servers

As a comparative data point, Google’s data centers consume 260MW in aggregate (Google Details, and Defends, It’s use of Electricity). Google reports their PUE is 1.14 so we know they are delivering 228MW to their IT infrastructure (servers and storage). Google is perhaps the most focused in the industry on low power consuming servers. They invest deeply in custom designs and are willing to spend considerably more to reduce energy consumption. Estimating their average server power draw at 250W and looking at the +/-25W about that average consumption rate:

それとの比較データとして、 Google のデータセンターの例を挙げたい。 そこでは、全体として 260MW が消費されている(Google Details, and Defends, It’s use of Electricity)。 そして、Google の PUE は 1.14 だとレポートされているため、その IT インフラストラクチャ(サーバーとストレージ)に 、228MW が供給されていると分かる。 おそらく Google は、この業界で、低電力サーバーに最も注力している企業である。 彼ら、カスタムなデザインに対して大きな投資を行い、また、エネルギー消費の削減に注力することを厭わない。 そのサーバーにおける、平均的な消費電力を 250W と見積もり、また、その範囲を +/- 25W まで広げてみると、以下のようになる。

  • 225W/server: 1,155,555 servers
  • 250W/server: 1,040,000 servers
  • 275W/server: 945,454 servers

I find the Google and Facebook server counts interesting for two reasons. First, Google was estimated to have 1 million servers more than 5 years ago. The number may have been high at the time but it’s very clear that they have been super focused on work load efficiency and infrastructure utilization. To grow the search and advertising as much as they have without growing the server count at anywhere close to the same rate (if at all) is impressive. Continuing to add computationally expensive search features and new products and yet still being able to hold the server count near flat is even more impressive.

Google と Facebook におけるサーバーの台数を数えることで、2つの興味深い論点を見つけた。 最初のものは、5年以上も前から、Google は 100万台のサーバーを持つと、推測されていたことだ。 その時点において、100万台という数字は大きかったかもしれないが、ワークロードの効率化と、インフラストラクチャの有効利用について、彼らが熱心に取り組んできたことは明らかだ。 増大するサーチとアドバタイジングに対応するために、サーバーの総数を増やすこともなく、インフラストラクチャを一定のレベルに押さえていることは素晴らしい。さらに言えば、計算上は高価なものとなるサーチ機能を拡張し、また、新しいプロダクトを追加し続けながら、ほとんど変わらぬサーバー総数を維持していることが、とても印象的である。

The second notable observation from this data is that the Facebook server count is growing fast. Back in October of 2009, they had 30,000 servers. In June of 2010 the count climbed to 60,000 servers. Today they are over 150k.

そして、一連のデータから見つけ出された 2つ目のポイントは、Facebook におけるサーバーの台数が、急速に増大している点である。 2009年 10月の時点において、彼らは 30,000台のサーバーを持っていた。2010年6月には、60,000台に上昇している。そして、いま、彼らは 150,000台以上を保有している。

–jrh

James Hamilton
e: jrh@mvdirona.com
w:
http://www.mvdirona.com
b: http://blog.mvdirona.com / http://perspectives.mvdirona.com

ーーーーー

image久々の、James Hamilton 先生です。こういうデータから、こんなふうに推論し、こんな結論を導き出すとは流石です。その途中で、PUE 信仰に対して一石を投じ、Google と Facebook の傾向についてまで、適切な論評を加えてくれるとは、まさに、至れり尽くせりです。 訳していて、とても楽しかったです :) ーーー image

ーーーーー

<関連>

Amazon の James Hamilton が語る、効率の良いデータセンター運用のコツとは?
Facebook メッセージを支えるストレージ・インフラを解説 – James Hamilton
Amazon データセンターについて、James Hamilton が語る
46MW を湖水で冷却し PUE 1.1 を実現する、アルプスの巨大データセンター
Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚 by James Hamilton
Microsoft が発表した、OSS ベースのクラウド・サービスとは?

 

 

Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚 by James Hamilton

Posted in .Selected, Amazon, James Hamilton, NoSQL by Agile Cat on January 27, 2012

Amazon DynamoDB: NoSQL in the Cloud
http://wp.me/pwo1E-3R0
Wednesday, January 18, 2012
http://perspectives.mvdirona.com/2012/01/18/AmazonDynamoDBNoSQLInTheCloud.aspx

_ perspectives

Finally! I’ve been dying to talk about DynamoDB since work began on this scalable, low-latency, high-performance NoSQL service at AWS. This morning, AWS announced availability of DynamoDB: Amazon Web Services Launches Amazon DynamoDB – A New NoSQL Database Service Designed for the Scale of the Internet.

ついに、この日がやってきた!AWS における、スケーラブル/ロー・レイテンシ/ハイ・パフォーマンスな NoSQL サービスに着手したときから、この DynamoDBについて話したいとを強く望んでいた。 今朝のことだが、DynamoDB の提供が開始されたと AWS が発表した: Amazon Web Services Launches Amazon DynamoDB – A New NoSQL Database Service Designed for the Scale of the Internet.

In a past blog entry, One Size Does Not Fit All, I offered a taxonomy of 4 different types of structured storage system, argued that Relational Database Management Systems are not sufficient, and walked through some of the reasons why NoSQL databases have emerged and continue to grow market share quickly. The four database categories I introduced were: 1) features-first, 2) scale-first, 3) simple structure storage, and 4) purpose-optimized stores. RDBMS own the first category.

私は以前のブログ・エントリーである One Size Does Not Fit All で、構造化されたストレージ・システムに関する、4種類のタクソノミーを提供している。そこでは、Relational Database Management Systems が十分ではないことを論じ、また、NoSQL データベースが出現した理由と、素早くマーケット・シェアを拡大し続ける理由について、簡単に説明している。 私が紹介した 4つのデータベース・カテゴリーは: 1) features-first 機能優先、2) scale-first スケール優先、3) simple structure storage シンプルなストレージ構成、4) purpose-optimized stores 目的に最適化されたストア、であった。そして、RDBMS が持つのは、最初のカテゴリのみである。

DynamoDB targets workloads fitting into the Scale-First and Simple Structured storage categories where NoSQL database systems have been so popular over the last few years. Looking at these two categories in more detail.

DynamoDB は、Scale-First と Simple Structured Storage のカテゴリにフィットした、ワークロードをターゲットにするものであるが、これらの領域は、これまでの数年にわたって、NoSQL データベース・システムで人気を集めているところである。これら 2つのカテゴリについて、さらに詳細を追いかけよう。

Scale-First is: Scale-first applications are those that absolutely must scale without bound and being able to do this without restriction is much more important than more features. These applications are exemplified by very high scale web sites such as Facebook, MySpace, Gmail, Yahoo, and Amazon.com. Some of these sites actually do make use of relational databases but many do not. The common theme across all of these services is that scale is more important than features and none of them could possibly run on a single RDBMS. As soon as a single RDBMS instance won’t handle the workload, there are two broad possibilities: 1) shard the application data over a large number of RDBMS systems, or 2) use a highly scalable key-value store.

Scale-First:Scale-first アプリケーションは、境界に影響されることなく、また、あらゆる制約から開放された方式で、絶対的にスケーラブルであることが、その他の機能よりも優先する。 これらのアプリケーションは、Facebook/MySpace/Gmail/Yahoo/Amazon.com といった、きわめてハイ・スケールな Web サイトにより実証される。 これらのサイトにおいて、いくつかのリレーショナル・データベース利用例があるが、大半は別の方式を採用するという現実がある。それら全てのサービスを横断する普遍的なテーマは、スケーラブルであることが機能よりも重要であり、また、それらをシングル RDBMS 上で実現することは、不可能だろうという点に集約される。 シングル RDBMS インスタンスが、対象となるワークロードを処理しきれない場合に、すぐに適応できる 2つの対応策がある: 1) 大量の RDBMS システム上に、アプリケーション・データを Sharding する。あるいは、2) きわめてスケーラブルな Key-Value ストアを使用する。

And, Simple Structured Storage: There are many applications that have a structured storage requirement but they really don’t need the features, cost, or complexity of an RDBMS. Nor are they focused on the scale required by the scale-first structured storage segment. They just need a simple key value store. A file system or BLOB-store is not sufficiently rich in that simple query and index access is needed but nothing even close to the full set of RDBMS features is needed. Simple, cheap, fast, and low operational burden are the most important requirements of this segment of the market.

Simple Structured Storage: 構造化されたストレージ要件を持つ、数多くのアプリケーションが存在するが、そこでは、RDBMS の機能と、コスト、複雑さが必要とされないのも現実である。 また、それらのアプリケーションは、Scale-first の構造化されたストレージ・セグメントが要求する、スケールに対してフォーカスすることもない。 つまり、そこでは、シンプルな Key-Value ストアだけが必要とされる。 必要とされるシンプル・クエリーとインデックス・アクセスにおいて、何らかのファイル・システムや BLOB ストアが、その要件を十分に充たすことはないが、RDBMS のフル機能に似たようなものは、何も必要とされない。 シンプル/安価/高速で、運用上の負担を低減するソリューションが、このマーケット・セグメントにおいて、最も重要な要件である。

_ AmazonMore detail at: One Size Does Not Fit All.

The DynamoDB service is a unified purpose-built hardware platform and software offering. The hardware is based upon a custom server design using Flash Storage spread over a scalable high speed network joining multiple data centers.

DynamoDB は、目的に合せて構築されたハードウェア・プラットフォームと、ソフトウェアが提供するサービスである。 そのハードウェアは、接続されるマルチ・データセンターに対して、高速でスケーラブルなネットワークを供給するために、Flash  Storage 用いたカスタム・サーバー・デザインをベースにしている。

DynamoDB supports a provisioned throughput model. A DynamoDB application programmer decides the number of database requests per second their application should be capable of supporting and DynamoDB automatically spreads the table over an appropriate number of servers. At the same time, it also reserves the required network, server, and flash memory capacity to ensure that request rate can be reliably delivered day and night, week after week, and year after year. There is no need to worry about a neighboring application getting busy or running wild and taking all the needed resources. They are reserved and there whenever needed.

DynamoDB がサポートするのは、プロビジョニングされたスループット・モデルである。 DynamoDB アプリケーションのプログラマーは、自身のアプリケーションがサポートすべき、毎秒ごとのデータベース・リクエスト数を決定する。 そして DynamoDB は、適切な数のサーバー上に、テーブルを自動的に供給していく。 それと同時に、たとえば日/週/年の単位で、リクエスト・レートが確実に供給されることを保証するために、要求されるネットワーク/サーバー/フラッシュ・メモリの容量を確保する。そして、隣接するアプリケーションがビジーになることや、制御不能な状況に陥ること、そして、必要とするリソースを奪っていってしまうようなことを、心配する必要は無い。それらの確保されたリソースは、必要とされるときに、必ず供給される。

The sharding techniques needed to achieve high requests rates are well understood industry-wide but implementing them does take some work. Reliably reserving capacity so it is always there when you need it, takes yet more work. Supporting the ability to allocate more resources, or even less, while online and without disturbing the current request rate takes still more work. DynamoDB makes all this easy. It supports online scaling between very low transaction rates to applications requiring millions of requests per second. No downtime and no disturbance to the currently configured application request rate while resharding. These changes are done online only by changing the DynamoDB provisioned request rate up and down through an API call.

高度なリクエスト・レートを達成する、Sharding のテクニックが必要とされていることは、この業界において広く認識されている。 しかし、それを実装するには、いくつかの作業が欠かせない。 つまり、キャパシティの確保が、必要とされるときに、常に約束されるようにするには、多くの作業が要求される。オンライン時にリクエスト・レートに影響をあたえることなく、 割り当てられているリソースの増減を達成するには、さらに多くの作業が要求される。 DynamoDB は、それら全ての容易に実現する。 具体的には、きわめて低いトランザクション・レートから、何百万回(秒)のレートを必要とするアプリケーションを、停止すること無くスケーリングしていく。 また、Re-Sharding を行う間も、そこ時点でコンフィグレーションされている、アプリケーション・リクエスト・レートを妨害することはなく、もちろん、ダウンタイムを要求することもない。 これらの変更は、プロビジョニングされている DynamoDB のリクエスト・レートを、API コールを介して変更するだけで、オンラインを維持しながら達成される。

In addition to supporting transparent, on-line scaling of provisioned request rates up and down over 6+ orders of magnitude with resource reservation, DynamoDB is also both consistent and multi-datacenter redundant. Eventual consistency is a fine programming model for some applications but it can yield confusing results under some circumstances. For example, if you set a value to 3 and then later set it to 4, then read it back, 3 can be returned. Worse, the value could be set to 4, verified to be 4 by reading it, and yet 3 could be returned later. It’s a tough programming model for some applications and it tends to be overused in an effort to achieve low-latency and high throughput. DynamoDB avoids forcing this by supporting low-latency and high throughout while offering full consistency. It also offers eventual consistency at lower request cost for those applications that run well with that model. Both consistency models are supported.

API による透過的のサポートに加えて、リソースの確保については、プロビジョニングされるリクエスト・レートの、オンラインにおけるスケールを 6段階で増減できる。 つまり DynamoDB は、コンシステンシーとマルチ・データセンターにおける、2つの冗長性に対応する。 インベンチュアル・コンシステンシーは、いくつかのアプリケーションにとっては素晴らしいプログラミング・モデルであるが、別の状況においては、紛らわしい結果をもたらす場合もある。 たとえば、何らかの値を 3に設定し、続いて 4に変更しても、それを読み返すときに 3が返される可能性があるのだ。 さらに悪いことに、4 に設定された値が、4であると確かめられた後に、依然として 3が返される場合もある。 それは、いくつかのアプリケーションにとっては、利用が困難なプログラミング・モデルであり、また、ロー・レイテンシとハイ・スループットを達成するために、過度に使用されるという傾向を持つ。  DynamoDB は、ロー・レイテンシとハイ・スループットをサポートしながら、フル・コンシステンシーを提供することで、こうした問題の発生を回避している。 さらに、このモデルを適切に実行するアプリケーションの、リクエスト・コストを抑制する場合には、インベンチュアル・コンシステンシーも提供される。つまり、2つのコンシステンシー・モデルがサポートされる。

Amazon-DynamoDBIt is not unusual for a NoSQL store to be able to support high transaction rates. What is somewhat unusual is to be able to scale the provisioned rate up and down while on-line. Achieving that while, at the same time, maintaining synchronous, multi-datacenter redundancy is where I start to get excited.

NoSQL が、高度なトランザクション・レートをサポートできたとしても、べつに異常なことではない。 通常と異なる点があるとすれば、オンラインを維持しながら、プロビジョニングされたレートを、上下にスケールできることである。それを達成すると同時に、マルチ・データセンターの同期をとることで、その冗長性を維持できるところが、私がエキサイトするところである。

Clearly nobody wants to run the risk of losing data but NoSQL systems are scale-first by definition. If the only way to high throughput and scale, is to run risk and not commit the data to persistent storage at commit time, that is exactly what is often done. This is where DynamoDB really shines. When data is sent to DynamoDB, it is committed to persistent and reliable storage before the request is acknowledged. Again this is easy to do but doing it with average low single digit millisecond latencies is both harder and requires better hardware. Hard disk drives can’t do it and in-memory systems are not persistent so flash memory is the most cost effective solution.

データを失うというリスクを、望む人がいないのは明らかであるが、NoSQL システムの定義は Scale-First である。 高度なスループットとスケールを達成するための、唯一の方式がリスクを冒すことであり、また、コミット時にデータをパーシスタント・ストレージに入れると約束できないなら、そのような事態が頻繁に生じるということである。 そして、この点が、DynamoDB が本当に輝くところである。 データが DynamoDB に送られるとき、そのリクエストが承認される前に、信頼できるパーシスタント・ストレージに対してコミットが行われる。 繰り返すが、それを実現することは容易である。 ただし、平均で一桁台のミリセカンド・レイテンシを達成することは困難であり、また、より良いハードウェアを必要とする。 ハードディスク・デバイスを用いて、それを達成することは不可能だ。 そして、イン・メモリのシステムはパーシスタントでないため、フラッシュ・メモリが最も費用効果の高いソリューションとなる。

But what if the server to which the data was committed fails, or the storage fails, or the datacenter is destroyed? On most NoSQL systems you would lose your most recent changes. On the better implementations, the data might be saved but could be offline and unavailable. With dynamoDB, if data is committed just as the entire datacenter burns to the ground, the data is safe, and the application can continue to run without negative impact at exactly the same provisioned throughput rate. The loss of an entire datacenter isn’t even inconvenient (unless you work at Amazon :-)) and has no impact on your running application performance.

しかし、そのデータをコミットするサーバーが失敗したら、あるいは、ストレージが失敗したら、データセンターに障害が発生したら、いったい、どうなるのだろう? 大半の NoSQL システムでは、直近の更新が失われてしまうだろう。  それよりも優れた実装が行われていれば、データは保存されるかもしれないが、オフラインとなり、利用できなくなるケースも生じるだろう。 dynamoDB を用いるなら、データをコミットしたときにデータセンターが火災にあっても、そのデータは安全である。 そして、あなたのアプリケーションは、プロビジョニングされたときと、まったく同じスループットレートで、悪影響を受けることなく走り続けるだろう。1つのデータセンターが、まるごと吹っ飛んでも、たいした問題ではない(あなたが Amazon の従業員でない限り :) )。 そして、実行中のアプリケーションに、パフォーマンスの問題が生じることもない。

Combining rock solid synchronous, multi-datacenter redundancy with average latency in the single digits, and throughput scaling to the millions of requests per second is both an excellent engineering challenge and one often not achieved.

強固で堅実な同期と、平均で一桁台のレイテンシを持つマルチ・データセンターの冗長性、そして、何百万回/秒というリクエストをスケーリングするスループットの組み合わせは、エンジニアリングにおける素晴らしいチャレンジであり、また、達成できるのも稀なものである。

More information on DynamoDB:

· Press Release: http://phx.corporate-ir.net/phoenix.zhtml?c=176060&p=irol-newsArticle&ID=1649209&highlight=
· DynamoDB detail Page:
http://aws.amazon.com/dynamodb/
· DynamoDB Developer Guide: http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/
· Blog entries:
· Werner:
http://www.allthingsdistributed.com/2012/01/amazon-dynamodb.html
· Jeff Barr: http://aws.typepad.com/aws/2012/01/amazon-dynamodb-internet-scale-data-storage-the-nosql-way.html
· DynamoDB Frequently Asked Questions:http://aws.amazon.com/dynamodb/faqs/
· DynamoDB Pricing: http://aws.amazon.com/dynamodb/pricing/
· GigaOM: http://gigaom.com/cloud/amazons-dynamodb-shows-hardware-as-mean-to-an-end/
· eWeek: http://www.eweek.com/c/a/Database/Amazon-Web-Services-Launches-DynamoDB-
a-New-NoSQL-Database-Service-874019/

· Seattle Times: http://seattletimes.nwsource.com/html/technologybrierdudleysblog/
2017268136_amazon_unveils_dynamodb_databa.html

Relational systems remain an excellent solution for applications requiring Feature-First structured storage. AWS Relational Database Service supports both the MySQL and Oracle and relational database management systems: http://aws.amazon.com/rds/.

Feature-First の構造化されたストレージを必要とするアプリケーションにとって、リレーショナル・システムは優れたソリューションであり続ける。 そして、AWS Relational Database Service は、MySQL と Oracle 、そして、リレーショナル・データベース・マネージメント・システムをサポートする:http://aws.amazon.com/rds/.

Just as I was blown away when I saw it possible to create the world’s 42nd most powerful super computer with a few API calls to AWS (42: the Answer to the Ultimate Question of Life, the Universe and Everything), it is truly cool to see a couple of API calls to DynamoDB be all that it takes to get a scalable, consistent, low-latency, multi-datacenter redundant, NoSQL service configured, operational and online.

いくつかの API コールを AWS へ送るだけで、世界で 42位のスーパー・コンピュータが構成できるという事実は、私を仰天させた(42: the Answer to the Ultimate Question of Life, the Universe and Everything)。それと同要に、いくつかの DynamoDB API をコールすることで、スケーラブル/コンシステンシー/ロー・レイテンシなマルチ・データセンターにおける冗長性と、コンフィグレーションされた NoSQL サービス、そして、オンラインによるオペレーションの全てが得られるとは、まさに COOL なことである。

–jrh

ーーーーー

_ perspectivesなんというか、息をのむ迫力です。 優れたテクノロジーと AWS のスケールが組み合わされると、このようなものが出来てしまうのですね。 最後の締め括りで、James Hamilton さんが言っているように、DynamoDB であるうがスパコンであろうが、API を叩けば誰でも使えるという、コモディティ感覚が素晴らしいです。 ある意味、「京」などは、その足元にも及びません。 文句なしに スゴイ! 以下の<関連>も、ぜひ ご覧ください。 ーーー __AC Stamp 2

ーーーーー

<関連>

イベンチュアル・コンシステンシーはお好き? — by James Hamilton
Stonebraker と CAP Theorem と Databases – by James Hamilton
Database System エラーと Eventual Consistency と CAP Theorem _1
Database System エラーと Eventual Consistency と CAP Theorem _2
Amazon の James Hamilton が語る、効率の良いデータセンター運用のコツとは?
Facebook メッセージを支えるストレージ・インフラを解説 – James Hamilton

Amazon の James Hamilton が語る、効率の良いデータセンター運用のコツとは?

Posted in .Selected, Data Center Trends, James Hamilton, Open Compute by Agile Cat on November 12, 2011

Amazon’s James Hamilton on how to build a better data center
By
Barb Darrow Nov. 2, 2011
http://gigaom.com/cloud/amazons-james-hamilton-on-how-to-build-a-better-data-center/

_ Gigaom

imageJames Hamilton ⇒ 

You want to build a leaner, greener data center? James Hamilton, VP and distinguished engineer for Amazon Web Services, has some suggestions for you.

もっと効率が良く環境に優しい、データセンターを構築したくないだろうか? Amazon Web Services の VP であり、Distinguished Engineerでもある James Hamilton が、いくつかの案を提供している。

Speaking at a recent Open Compute Project event, Hamilton, who’s something of a rock star among the web infrastructure crowd, provided some food for thought. Here are some of his tips.

先日に開催された Open Compute Project のイベントにおいて、ちょっとしたロックスターである Hamilton は、Web インフラストラクチャ似従事する人々に対して、いくつかの考える材料を提供した。 以下は、そこからの要点の抽出である。

1. Know what you’re spending and for what.

It’s always wise to measure how much you’re spending and what you get for that money. In data centers, nearly a third of overall costs are energy-related in some way.

どれだけの費用の支出があり、その対価により得ているもの考慮することは、いつでも賢明な行為である。 データセンターのコストにおける、約 1/3 は、何らかの方式により、電力に関連するものとなる。

2. Minimize A/C.

Most computer components can run at temperatures that are much higher than even the hottest places on earth. So let them. If you can use outside air as opposed to power-hungry air conditioning, do so.

大半のコンピュータ・コンポーネントは、熱帯地域よりも高い気温の中で、問題なく動作するようになっている。 したがって、そのような環境で動作させるべきだ。 もし、大量の電力を消費する空調に頼らず、戸外の冷気を使用できるなら、そうすべきだ。

3. Cut extra power conversions.

In data centers, power conversion is a repetitive, costly and inefficient process. Rule of thumb: The fewer the conversions, the better.  It’s also helpful to bring high voltage as close as possible to servers.

データセンターにおける反復的な AC/DC 変換は、高価で非効率なプロセスとなる。 経験に基づいた原則として、その変換の回数を低減できると、そのぶんだけ効率が良くなる。高電圧の電力を、可能な限りサーバーの近くまで引きこむことも、ここで言う効率の改善につながる。

Hamilton’s entire presentation is posted to his Perspectives blog.

Hamilton のプレゼンテーションで用いられた資料は、 Perspectives blog からダウンロードできる。

Related research and analysis from GigaOM Pro:

ーーーーー

とても簡潔に、James Hamilton さんのセッション内容をまとめていますね。なお、[2. Minimize A/C.]では、ASHRAE Recommendation 2008 についてチラッと言及されていたと思いますが、守っていたら出来ないよ、、、という主旨だったと記憶しています :)  ーーー __AC Stamp 2

ーーーーー

<関連>

Facebook が推進する Open Compute Project は、離陸できるのだろうか?
オープンなハードウェアは、データセンターに地殻変動を起こせるのか?
Facebook の OPC と Open Data Center Alliance がコラボ?
VMware の Paul Maritz が、Facebook の特許問題を語る
Facebook の Open Compute Summit が開催される

 

Facebook が推進する Open Compute Project は、離陸できるのだろうか?

Posted in .Selected, Data Center Trends, Facebook, Open Compute by Agile Cat on November 3, 2011

Facebook letting Open Compute Project go. Will it fly?
By
Barb Darrow Oct. 27, 2011
http://gigaom.com/2011/10/27/open-compute-project-gets-a-foundation-of-its-own/

_ Gigaom

The Facebook-led Open Compute Project launched a foundation Thursday to help it push the standardization of data center server hardware for webscale deployments. But as the project evolves it’s still hard to see where Facebook ends and Open Compute begins.

Web スケールのディプロイメントに対応する、データセンターのサーバー・ハードウェアを標準化していくファウンデーションが、Facebook がリードしてきた Open Compute Project により、この木曜日(10/27)に立ち上げられた。 しかし、このプロジェクトは進展してはいるが、どこまでがFacebook であり、どこからが Open Compute なのか、その線を見極めることは、依然として難しいようだ。

Leave the chassis to Open Compute and build something new.

image

The goal of the new Open Compute Foundation is to bring more vendors and voices into the mix, make sure their contributed intellectual property is well cared for, and to foster the idea that open-source development — so important in software — can benefit the stodgy world of data center servers. At the Open Compute Project (OCP) launch in April, Facebook laid out building blocks for standard server designs. The idea is that other companies could build and innovate atop those designs and not waste time sweating the nuts and bolts.

この、新設された Open Compute Foundation のゴールは、より多くの参加を促し、そのは発言力を最大限に高めることである。  それにより、コントリビュートされる知的財産が確実に利用できるようになり、また、データセンター・サーバーという古風な世界にメリットをもたらす、オープンソース開発(すでにソフトウェアでは重要)が促進されていく。 Open Compute Project(OCP)が 4月に立ち上がったとき、Facebook はスタンダード・サーバー・デザインのビルディング・ブロックを明確にしている。 この発想により、その他の企業は、提供されたデザインを構築/発展させることが可能であり、基本的な事柄について、時間を浪費しないようになっていく。

The Open Compute battery cabinet.

“The main thing we want to achieve is accelerating the pace of innovation for scale computing environments and by open sourcing some of the base elements we will enable the industry in general to stop spending redundant brain cycles on things like re-inventing the chassis over and over and over and focus more on innovation,” Frankovsky said in an interview in advance of the foundation announcement. The effort will turn the data center, systems level and server hardware into commodity components designed for scaled out architectures.

「私たちが達成を望む大切な事柄は、スケールしていくコンピューティング環境を革新していくペースを速めることである。そして、何らかの基本的な要素をオープン化することで、何度も何度も繰り返してシャシーを再開発するような、不必要な発想のサイクルを脱して、より革新的な部分に、この産業がフォーカスしていくようにできる」と、Frankovsky はファウンデーションの発表に先立ってのインタビューで発言している。 こうした試みにより、データセンターおよび、システムのレベル、そしてサーバー・ハードウェアは、スケール・アウト・アーキテクチャに対応するようデザインされた、普及品コンポーネントに置き換えられていくだろう。

The group has big backers with foundation directors including Silicon Valley superstar Andy Bechtolsheim who co-founded  Sun Microsystems and is now chief development officer of Arista Networks. Also on the board are Don Duet, head of global technology infrastructure for  Goldman Sachs;  Mark Roienigk, the COO of Rackspace; and Jason Waxman, general manager of Intel’s data center group. Frank Frankovsky, Facebook’s director of hardware and supply chain, is executive director.

このグループは、Sun Microsystems の Co-Founder であり、いまは Arista Networks の Chief Development Officer である、Andy Bechtolsheim という強力な Silicon Valley Superstar を後援者として有している。 同じく、Goldman Sachs の Head of Global Technology Infrastructure である Don Duet および、Rackspace の COO である Mark Roienigk 、Intel の Data Center Group – General Manager である Jason Waxman らが、ボードに名を連ねている。 そして Frank Frankovsky は、 Facebook の Hardware and Supply Chain の Director であり、また、Executive Director でもある。

What’s inside Open Compute today and planned for tomorrow.

Along with the creation of the foundation, Facebook announced the Open Rack 1.0 specification, which lays out the basic design for power distribution and cooling for the server rack. That spec will evolve over time, integrating such perks as rack-level power capping, and I/O on the backplane at some point, Frankovsky said.

このファウンデーションの設立と平行して、Facebook は Open Rack 1.0 仕様をアナウンスした。 それは、サーバー・ラックのための配電と冷却に関する、基本的なデザインをレイアウトするものである。 この仕様は、ラック・レベルの電力キャッピングや、背面に設置される I/O といった、いくつかの装置を統合することで、時間をかけて発展していくと、Frankovsky が発言している。  

Also on Thursday ASUS said it will open-source its motherboard designs and Mellanox plans to release specifications for 10 Gigabit Ethernet cards. So far the OCP effort has received intellectual property contributions from Red Hat– which will certify OCP servers. Other contributions came from AMD, Dell, and Cloudera. Arista Networks is also now an official member of OCP, although has no specific contributions to announce at this time.

これまでのところ、OCP の試みにより、Red Hat(OCP サーバーを証明していく)からの知的財産のコントリビューションが実現している。 また、AMD と、Dell、Cloudera からもコントリビューションが行われる。 ただし、OCP のオフィシャル・メンバーである Arista Network からは、いまのところ、具体的なコントリビューションは無い。

The OCP  has also moved to make OCP hardware more broadly available, working with Synnex, a computer distributor and its manufacturing arm, Hyve, which will act as a hardware OEM. Silicon Mechanics, a maker of rack-mount servers, is also aboard. When the effort launched in April Dell and Hewlett-Packard  both showed off servers that incorporated some of the elements of Open Compute.

また、OCP は Synnex との協業により、その ハードウェアを広範囲に提供しようとする。 Synnex は、ハードウェア OEM の役割を担う、コンピュータの製造と供給を行う Hyve の部門である。 ラックマウント・サーバーのメーカーである、Silicon Mechanics も賛同している。この活動が立ち上がった 4月には、Dell と Hewlett-Packard が、Open Compute の要素を取り込むサーバーを誇示していた。

Open Compute Foundation, born of Facebook, still pretty close

The Open Compute chassis.

The fact that a Facebook executive doubles as the foundation’s executive director is bound to raise some eyebrows if OCP wants to shake the perception that it is an effort directed by the social networking giant.  Other open-source projects, notably the Eclipse effort around Java development environments, really hit their stride only after the lead vendor relinquished control. (In Eclipse’s case, that was IBM.) More recently, Rackspace eased some concerns among the OpenStack software crowd by forming an OpenStack Foundation, and vowing to step back.

この、ソーシャル・ネットワークの巨人が指揮する活動という認識を、OCP が振り払いたいと望む場合には、Facebook 経営陣がファウンデーションの幹部を兼任するという事実が、いくつかの疑念を呼び起こすことに疑いの余地はない。 他のオープンソース・プロジェクトにおいては、その主要ベンダーがコントロールを放棄した後にだけ、ほんとうの意味での動きが見られる。(たとえば、Java 開発環境における Eclipse が挙げられるが、そのケースでは IBM が主要ベンダーであった)  もっとも最近では、OpenStack Foundation が組織されているが、Rackspace が一歩引き下がると約束したことで、そのメンバーたちの心配事を緩和されている。

“We modeled this as closely as possible on the Apache Foundation. Each project starts at an incubation committee which names a lead and [is eventually] voted in or out as a project,” Frankovsky said. “I have one-fifth vote. If the others don’t think it’s cool, it’s not in.”

「私たちは、可能な限り、Apache Foundation をモデルとしている。 それぞれのプロジェクトは、リードを指名するインキュベーション委員会で立ち上げられるが、最終的には、それらのプロジェクトにおいて投票が行われるようになる。 つまり、私の権限は 1/5である。 また、他の人々が、それをクールと思わないときには、そこには入らない」と、Frankovsky は発言している。

Frankovsky said the effort is well-funded for now through voluntary seed contributions but the funding model remains a work in process.

Frankovsky は、この活動について、コントリビューションから始まるボランタリーを介して、上手く構成されているが、今後のプロセスにおいて、その財源のモデル化が残されていると発言している。

What’s next for OCP?

As for what’s next? Frankovsky said the first round of motherboards were based on Intel’s Westmere chip technology while version two will be based on Intel’s Sandy Bridge technology. “Intel and Hyve will do a fast-ramp program,” he said.  OCP has worked to get early access to Sandy Bridge technologies that would otherwise not be available until the second quarter.

次に来るものは、何なのだろうか? Frankovsky は、最初のラウンドが、Intel の Westmere テクノロジーをベースにしたのに対して、Version 2 は、Intel の Sandy Bridge テクノロジーに基づくものになると言う。 「Intel と Hyve は、素早く成長していくプログラムを実現するだろう」と、彼は付け加えている。  OCP は、Sandy Bridge クノロジーへのアーリー・アクセスを得るために動いている。それは、この Q2 になるまで、得ることのできないものであった。

Facebook itself is working on some storage specifications it would like to  talk about for its next round of contributions. “Storing data at this scale has some unique challenges. We’ll work on those contributions and with the rest of the community on this,” he said.

Facebook 自身は、いくつかのストレージ仕様に取り組んでおり、次のコントリビューション・ラウンドで話題にされるだろう。 「このスケールにおいて、データをストアすることは、いくつかの固有の課題を要する。 この領域において、私たちはコントリビュータとなり、その他のコミュニティにも協力していくだろう」と、彼は言う。

The OCP remains focused on the compute platform itself, although Frankovsky didn’t rule out possible future forays into other parts of the data center universe.

OCP がフォーカスするものには、コンピューティング・プラットフォーム自体があるが、データセンターの外へと広がるパートに対して、影響力を及ぼしていいく可能性を、Frankovsky は排除していない。

Asked if networking was on the agenda, he said:  ”Andy Bechtolsheim has a lot of interest in networking but for now we’ve excluded networking from Open Compute. There’s already ONF [the Open Networking Foundation] and we don’t want to compete, but if the community thinks we should look at the physical layer of Open Compute, that’s a possibility.”

そのアジェンダに、ネットワーキングは存在していたのかという質問に対して、「Andy Bechtolsheim はネットワーキングに強い興味を示しているが、現段階の Open Compute からは、ネットワーキングを外している。 すでに ONF[Open Networking Foundation]が存在しており、私たちは競合を望まない。 しかし、そのコミュニティが、Open Compute の物理レイヤに注目すべきと考えるなら、何らかの可能性が生じてくる 」と、彼は答えている。

Related research and analysis from GigaOM Pro:

ーーーーー

imageAgile_Cat でも取り扱いましたが、OpenStack は Rackspace が一歩引いた形となり、OpenStack Foundation に権限が移行しています。 何らかのスタンダードを考える場合、そのための組織を引っ張る主要ベンダーは、どこかで役割を終えなければならないというのは、真実を突いているのかもしれません。 しかし、Open Compute で面白いのは、Facebook はあくまでも ユーザーの立場であり、Open Compute の成果物でビジネスを展開するベンダーではないという点です。この動きには、これからも継続して、注目していきたいですね。ーーー __AC Stamp 2

ーーーーー

<関連>

Efficient Data Centers with the Open Compute Project
詳細な解説つきの Facebook Oregon DC フォト・ツアー
Facebook の Open Compute Summit が開催される
VMware の Paul Maritz が、Facebook の特許問題を語る
Facebook の OPC と Open Data Center Alliance がコラボ?
オープンなハードウェアは、データセンターに地殻変動を起こせるのか?

Facebook メッセージを支えるストレージ・インフラを解説 – James Hamilton

Posted in .Selected, Big Data, Facebook, James Hamilton by Agile Cat on November 2, 2011

Storage Infrastructure Behind Facebook Messages
Tuesday, October 25, 2011
http://perspectives.mvdirona.com/2011/10/25/StorageInfrastructureBehindFacebookMessages.aspx

facebook_logo

One of the talks that I particularly enjoyed yesterday at HPTS 2011 was Storage Infrastructure Behind Facebook Messages by Kannan Muthukkaruppan. In this talk, Kannan talked about the Facebook store for chats, email, SMS, & messages.

昨日(10/24)の HPTS 2011で、とりわけ興味深かった話として、Kannan Muthukkaruppan による Storage Infrastructure Behind Facebook Messages がある。 そこで、Kannan は、チャット/電子メール/SMS/メッセージのための Facebook ストアについて話をした。

imageThis high scale storage system is based upon HBase and Haystack. HBase is a non-relational, distributed database very similar to Google’s Big Table. Haystack is simple file system designed by Facebook for efficient photo storage and delivery. More on Haystack at: Facebook Needle in a Haystack.

このハイ・スケールなストレージ・システムは、HBase と Haystack をベースにしている。 HBase は、Google の Big Table に極めて類似した、Non Relational な分散データベースである。 Haystack は、効果的な写真ストレージと配達のために、Facebook によりデザインされたシンプルなファイル・システムである。 Haystack の詳細については、Facebook Needle in a Haystack を参照して欲しい。

In this Facebook Message store, Haystack is used to store attachments and large messages. HBase is used for message metadata, search indexes, and small messages (avoiding the second I/O to Haystack for small messages like most SMS).

この Facebook メッセージ・ストアにおいては、アタッチメントと長いメッセージをストアするために Haystack を使用する。  HBase に関しては、メッセージ・メタデータおよび、サーチ・インデックス、短いメッセージのために使用される(大半の SMS のような短いメッセージのために、Haystack に2番目の I/O を儲けることを回避)。

Facebook Messages takes 6B+ messages a day. Summarizing HBase traffic:

Facebook Messages は、1日あたり 6B 以上のメッセージを処理する。以下は、HBase トラフィックの概要である:traffic:

  • 75B+ R+W ops/day with 1.5M ops/sec at peak
  • The average write operation inserts 16 records across multiple column families
  • 2PB+ of cooked online data in HBase. Over 6PB including replication but not backups
  • All data is LZO compressed
  • Growing at 250TB/month

The Facebook Messages project timeline:

Facebook Messages プロジェクトの年譜は、以下のとおりである:

  • 2009/12: Project started
  • 2010/11: Initial rollout began
  • 2011/07: Rollout completed with 1B+ accounts migrated to new store
  • Production changes:
    • 2 schema changes
    • Upgraded to Hfile 2.0

クリックで拡大 ⇒

They implemented a very nice approach to testing where, prior to release, they shadowed the production workload to the test servers.

彼らは、リリースに先立つテストにおいて、そのプロダクション・ワークロードからテストサーバーへと追尾する、とても素晴らしいアプローチを実装している。

注記)動詞の Shadow は[追尾]で良い?

After going into production the continued the practice of shadowing the real production workload into the test cluster to test before going into production:

プロダクション・フェーズに入った後も、現実のプロダクション・ワークロードを追尾する、継続的なプラクティスが実践され、次のプロダクションを検査するためのテスト・クラスタに、その結果が取り込まれていく:

クリックで拡大 ⇒

The list of scares and scars from Kannan:

心配事のリストと、Kannan による痕跡は、以下のとおりである:

  • Not without our share of scares and incidents:
    • s/w bugs. (e.g., deadlocks, incompatible LZO used for bulk imported data, etc.)
      • found a edge case bug in log recovery as recently as last week!
  • performance spikes every 6 hours (even off-peak)!
    • cleanup of HDFS’s Recycle bin was sub-optimal! Needed code and config fix.
  • transient rack switch failures
  • Zookeeper leader election took than 10 minutes when one member of the quorum died. Fixed in more recent version of ZK.
  • HDFS Namenode – SPOF
  • flapping servers (repeated failures)
  • Sometimes, tried things which hadn’t been tested in dark launch!
    • Added a rack of servers to help with performance issue
      • Pegged top of the rack network bandwidth!
      • Had to add the servers at much slower pace. Very manual .
      • Intelligent load balancing needed to make this more automated.
  • A high % of issues caught in shadow/stress testing
  • Lots of alerting mechanisms in place to detect failures cases
    • Automate recovery for a lots of common ones
    • Treat alerts on shadow cluster as hi-pri too!
  • Sharding service across multiple HBase cells also paid off

Kannan’s slides are posted at: Here

–jrh

James Hamilton
e: jrh@mvdirona.com
w
: http://www.mvdirona.com
b
: http://blog.mvdirona.com / http://perspectives.mvdirona.com

ーーーーー

TAG indexそれぞれのメッセージに対して、適切なストレージを割り当て、さらにはプロダクションとシャドウの上手い関係を構築してという、とても緻密な運用に驚かされます。 一見、大雑把に見える Facebook ですが、いつものとおり、洗練されていますね! でも・・・ 先週の Open Compute Summit では、Agile_Cat の名前がエントリーされていなくて、一瞬 こわばりましたが、同じ境遇の人もたくさん居たみたいで、その場で名札をバンバン印刷して、来た人をドンドン入れてくれちゃいました。 やっぱり、大雑把 :)  それと、会場には James Hamilton さんが居て、がんばれ Agile_Cat と応援してくれたのには、大感激してしまいました。 ーーー ac-stamp-21

ーーーーー

<関連>

Facebook の規模は、2004年当時のインターネット全体に匹敵する
ソーシャル・メディアの今を切り取る、とても面白いインフォグラフです
Google や Facebook は、Linux と OSS に借りがあるはずだ
Facebook 出資者が語る – ソーシャルが終わっている理由を説明しよう
30 P Bytes の Hadoop HDFS を、どのようにして Oregon へ移動したのか
Facebook は正攻法で、Billion 単位のメッセージを処理していく
Facebook が目指す、リアルタイム分析のインフラとは?
20分間で、2.7M Photos/10.2M Comments/4.6M Messages を処理!

%d bloggers like this: