Agile Cat — in the cloud

Redshift により データ・ウェアハウスの魔法を解く:James Hamilton

Posted in .Selected, Amazon, Data Warehousing, James Hamilton by Agile Cat on December 4, 2012

Redshift: Data Warehousing at Scale in the Cloud

Wednesday, November 28, 2012

_ perspectives

I’ve worked in or near the database engine world for more than 25 years. And, ironically, every company I’ve ever worked at has been working on a massive-scale, parallel, clustered RDBMS system. The earliest variant was IBM DB2 Parallel Edition released in the mid-90s. It’s now called the Database Partitioning Feature.

私の 25年以上にもおよぶキャリアは、データベース・エンジンの世界で、あるいは、その周辺で培われてきた。 そして、皮肉なことに、私が働いてきたすべての企業が、大規模スケール/パラレル/クラスター RDBMS システムに取り組んでいる。 最も初期の派生物は、90代半ばにリリースされた、IBM DB2 Parallel Edition であった。 いまでは、Database Partitioning Feature と呼ばれているものである。

Massive, multi-node parallelism is the only way to scale a relational database system so these systems can be incredibly important. Very high-scale MapReduce systems are an excellent alternative for many workloads. But some customers and workloads want the flexibility and power of being able to run ad hoc SQL queries against petabyte sized databases. These are the workloads targeted by massive, multi-node relational database clusters and there are now many solutions out there with Oracle RAC being perhaps the most well-known but there are many others including Vertica, GreenPlum, Aster Data, ParAccel, Netezza, and Teradata.

大容量のマルチノード並列方式は、スケーラブルな・リレーショナル・データベースシステムを実現する唯一の方法であるため、それらのシステムは、きわめて重要なものとなり得る。 もちろん、大規模スケールの MapReduce システムは、大量のワークロードを処理するという意味で、素晴らしい対案となる。 しかし、いくつかの顧客とワークロードは、ペタバイト・サイズのデータベースではなく、アドホックに SQL クエリーを実行するための、柔軟性と機能を必要とする。そこには、大容量マルチノードのリレーショナル・データベース・クラスターが、目標として定めたワークロードがある。そして、最も有名なのは Oracle RAC だとも思われるが、VerticaGreenPlumAster DataParAccelNetezzaTeradata などを含む、多様なソリューションも提供されている。

What’s common across all these products is that big databases are very expensive. Today, that is changing with the release of Amazon Redshift. It’s a relational, column-oriented, compressed, shared nothing, fully managed, cloud hosted, data warehouse. Each node can store up to 16TB of compressed data and up to 100 nodes are supported in a single cluster.

それら、すべてのプロダクトに共通する問題は、大規模なデータベースが、とても高価であるということだ。 しかし、いま、Amazon Redshift のリリースにより、それが変化している。 それは何かということであれば、リレーショナルであり、また、カラム指向で、圧縮機能を持ち、シェアード・ナッシングで、フル・マネージに対応する、クラウドにホストにされたデータ・ウエアハウスとなる。 それぞれのノードは、最大で 16 TB の圧縮データをストアすることが可能であり、また、最大で 100ノードが、シングル・クラスター内でサポートされる。

Amazon Redshift manages all the work needed to set up, operate, and scale a data warehouse cluster, from provisioning capacity to monitoring and backing up the cluster, to applying patches and upgrades. Scaling a cluster to improve performance or increase capacity is simple and incurs no downtime. The service continuously monitors the health of the cluster and automatically replaces any component, if needed.

Amazon Redshift は、データ・ウエアハウス・クラスターの、設定/運用/スケールに必要な、すべての作業を管理する。それは、クラスターのモニタリングとバックアップのためのキャパシティ・プロビジョニングから、パッチとアップグレードの適用にまで至る。 パフォーの改善と容量を増大するための、クラスターのスケーリングは、シンプルでありダウンタイムを引き起こさない。 このサービスでは、対象となるクラスターの健康状態が継続的にモニターされ、また、あらゆるコンポーネントの置き換えであっても、必要に応じて自動的に処理される。

The core node on which the Redshift clusters are build, includes 24 disk drives with an aggregate capacity of 16TB of local storage. Each node has 16 virtual cores and 120 Gig of memory and is connected via a high speed 10Gbps, non-blocking network. This a meaty core node and Redshift supports up to 100 of these in a single cluster.

それそれの Redshift クラスター上のコア・ノードは、24 台のディスク・ドライブを取り込み、16TB のローカル・ストレージの容量をアグリゲートしていく。 それぞれのノードは、16 の仮想コアと 120GB のメモリを持ち、また、10 Gbps/non-blocking の高速ネットワークに接続される。 Redshift はシングル・クラスター内で、このリッチなコア・ノードを、最大で 100 までサポートする。

There are many pricing options available (see for more detail) but the most favorable comes in at only $999 per TB per year. I find it amazing to think of having the services of an enterprise scale data warehouse for under a thousand dollars by terabyte per year. And, this is a fully managed system so much of the administrative load is take care of by Amazon Web Services.

数多く価格オプションが提供されているが(詳細については を参照)、TB を年に $999 だけで利用するパターンが、最も推奨できる。 私が驚いたのは、年に $1000 もかけずに、エンタープライズ・スケール向けの、TB データ・ウエアハウス・サービスが実現されることだ。 そして、フル・マネージド・システムが提供されるため、アドミニストレータが対応すべき大半の負荷が、Amazon Web Services により処理されていく。

Service highlights from:

以下の各項目は、AWS 日本語サイトにアップされると思います:

Fast and Powerful – Amazon Redshift uses a variety to innovations to obtain very high query performance on datasets ranging in size from hundreds of gigabytes to a petabyte or more. First, it uses columnar storage and data compression to reduce the amount of IO needed to perform queries. Second, it runs on hardware that is optimized for data warehousing, with local attached storage and 10GigE network connections between nodes. Finally, it has a massively parallel processing (MPP) architecture, which enables you to scale up or down, without downtime, as your performance and storage needs change.

You have a choice of two node types when provisioning your own cluster, an extra large node (XL) with 2TB of compressed storage or an eight extra large node (8XL) with 16TB of compressed storage. You can start with a single XL node and scale up to a 100 node eight extra large cluster. XL clusters can contain 1 to 32 nodes while 8XL clusters can contain 2 to 100 nodes.

Scalable – With a few clicks of the AWS Management Console or a simple API call, you can easily scale the number of nodes in your data warehouse to improve performance or increase capacity, without incurring downtime. Amazon Redshift enables you to start with a single 2TB XL node and scale up to a hundred 16TB 8XL nodes for 1.6PB of compressed user data. Resize functionality is not available during the limited preview but will be available when the service launches.

Inexpensive – You pay very low rates and only for the resources you actually provision. You benefit from the option of On-Demand pricing with no up-front or long-term commitments, or even lower rates via our reserved pricing option. On-demand pricing starts at just $0.85 per hour for a two terabyte data warehouse, scaling linearly up to a petabyte and more. Reserved Instance pricing lowers the effective price to $0.228 per hour, under $1,000 per terabyte per year.

Fully Managed – Amazon Redshift manages all the work needed to set up, operate, and scale a data warehouse, from provisioning capacity to monitoring and backing up the cluster, and to applying patches and upgrades. By handling all these time consuming, labor-intensive tasks, Amazon Redshift frees you up to focus on your data and business insights.

Secure – Amazon Redshift provides a number of mechanisms to secure your data warehouse cluster. It currently supports SSL to encrypt data in transit, includes web service interfaces to configure firewall settings that control network access to your data warehouse, and enables you to create users within your data warehouse cluster. When the service launches, we plan to support encrypting data at rest and Amazon Virtual Private Cloud (Amazon VPC).

Reliable – Amazon Redshift has multiple features that enhance the reliability of your data warehouse cluster. All data written to a node in your cluster is automatically replicated to other nodes within the cluster and all data is continuously backed up to Amazon S3. Amazon Redshift continuously monitors the health of the cluster and automatically replaces any component, as necessary.

Compatible – Amazon Redshift is certified by Jaspersoft and Microstrategy, with additional business intelligence tools coming soon. You can connect your SQL client or business intelligence tool to your Amazon Redshift data warehouse cluster using standard PostgreSQL JBDBC or ODBC drivers.

Designed for use with other AWS Services – Amazon Redshift is integrated with other AWS services and has built in commands to load data in parallel to each node from Amazon Simple Storage Service (S3) and Amazon DynamoDB, with support for Amazon Relational Database Service and Amazon Elastic MapReduce coming soon.

Petabyte-scale data warehouses no longer need command retail prices of upwards $80,000 per core. You don’t have to negotiate an enterprise deal and work hard to get the 60 to 80% discount that always seems magically possible in the enterprise software world. You don’t even have to hire a team of administrators. Just load the data and get going. Nice to see.

ペタ・バイト・スケールのデータ・ウエアハウスにおいて、コアあたり $80,000 を上回るような価格戦略を、神経を使って使いこなす必要は、もはや無くなった。エンタープライズに対して、60%~80% のディスカウント価格を提供するという、無意味な努力など、もう、不要になったのだ。つまり、エンタープライズ・ソフトウェアの世界に、常に潜んでいた魔法が解けるのである。そして、アドミニストレータ・チームを雇うことさえ不要になる。 単純にデータをロードして、それを動かすだけで良いのだ。 素晴らしい、光景じゃないか。


James Hamilton
b: /


imageついに、AWS が、ここまで攻め込んできましたね。まぁ、スパコン(CC2)まであるのですから、何でもアリなのだと思いますが、データ・ウエアハウスでも徹底的な価格破壊が行われるのでしょう。 たしか、2010年から 2011年にかけて、数多くのデータ・ウエアハウスが垂直統合されたと記憶していますが、それもこれも、Amazon を怖れての事だったのかも知れませんね。image



James Hamilton 特集
EMC は新規のアプライアンスを武器に、Teradata と勝負、Oracle と勝負!
IBM が Netezza を $1.7 billion で買収と発表
Teradata と Cloudera が Hadoop で提携!
HP が Dell の 3割増をオファー – エスカレートする 3PAR 争奪戦
Cloudera と Netezza による、Hadoop の商用アプライアンスとは?
【速報】EMC も、ついにクラウドへ本格参入?

Comments Off on Redshift により データ・ウェアハウスの魔法を解く:James Hamilton

みんなの先生 James Hamilton 特集

Posted in .Selected, Amazon, Big Data, Data Center Trends, Hadoop, James Hamilton by Agile Cat on December 2, 2012

Agile_Cat にポリシーがあるなら、大きく影響されているはず・・・


James Hamilton という人を知ったのは、2009年の春のことです。 とある仕事の流れの中で、アメリカのデータセンター事情を調べることになり、ヤミクモに Google で検索していたら、彼のブログに辿り着いたのです。 そして、『 RDBMS Losing Workloads in the Cloud 』を紹介したのですが、振り返ってみれば、このポストが、その後の Agile_Cat の方向性を定めたことになります。日本語のタイトルは 『 役割を減じる Cloud での RDBMS 』 にしました。

imageたった数枚のスライドで構成されるブログ・ポストですが、スケールという面からみて、これまでのエンタープライズ・サーバーの延長線上にクラウドは成立せず、新たな角度からのアプローチが必要という、いまでは常識になっていることを、ハッキリと Agile_Cat に伝えてくれたのが、このポストなのです。

そして、その年の秋には、NYC で開催された Hadoop World に行く事になり、いわゆる Big Data の最前線を覗き見ることができました。 いま考えてみると、James Hamilton さんのブログを見なければ、NYC へ行く事もなかったでしょうし、その時に知り合った、いまの仕事仲間の人たちとも、ご縁がなかったことになります。 う~ん、どう考えても、Agile_Cat の恩人ですね! Winking smile

2010年には、彼の重要な論文である 『 Architecture for Modular Data Centers 』を、ITMedia から出してもらいました。Agile_Cat などというブログではなく、大手のメディアに紹介して欲しかったのです。日本語のマトメ・ページは、こちらになります。

・・・というわけで、前置きが長くなりましたが、James Hamilton 特集として、以下をポストをリスト・アップしました。 時間が経っている割には、訳せたポストが少ないのですが、それぞれの内容が、とても濃いというのが、その理由なのかもしれません。 お時間のあるときに、1本、1本、ぜひ、ゆっくりと お読みください。

Jan 17, 2010: プライベート・クラウドに未来はない
Mar 9, 2010: イベンチュアル・コンシステンシーはお好き?
Apr 14, 2010: Stonebraker と CAP Theorem と Databases
May 31, 2010: Blackberry のクラウドを探る
Nov 21, 2010: 46MW を湖水で冷却し PUE 1.1 :アルプスの巨大 DC
Dec 22, 2010: GPGPU を用いたソートについて考える
Jun 9, 2011:
Amazon データセンターについて
Oct 13, 2011: Microsoft が発表した、OSS クラウド・サービスとは?
Oct 25, 2011: Facebook メッセージを支えるストレージ・インフラを解説
Nov 2, 2011: 効率の良いデータセンター運用のコツとは?
Jan 18, 2012: Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚
Aug 12, 2012: Facebook と Google の サーバー保有台数を推測する


Agile_Cat_2012そんなわけで、James Hamilton 先生に引っ張られるかのように、どんどんとクラウド・インフラの世界に傾いていった Agile_Cat であり、2011年の秋には再び NYC を訪れることになりました。 この時は、Facebook の OpenCompute Summit だったのですが、そのキーノート・スピカーとしてアサインされていたのが、James Hamilton さんだったのです。恐る恐る自己紹介してみると、『 お前が Agile_Cat かぁ~ 』という感じで、とても気さくに対応してくれたのが嬉しかったです。 そして、その後も、Sakura Ishikari を紹介してくれたりと、いつも日本を気にかけてくれる James Hamilton 先生には、ほんと、心の底から感謝なのです。



みんなが 期待の Open Cloud 特集
みんなが 注目の SDN/OpenFlow 特集
みんなの 先生 James Hamilton 特集
みんなを 支える Data Center 特集
2012 – 2013 海外 マトメ・ポストを、マトメてみました 62本
泣いて、笑って、驚いて、今年も暮れる WeekEnd 特集

Comments Off on みんなの先生 James Hamilton 特集

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

Sunday, August 12, 2012


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台以上を保有している。


James Hamilton
b: /


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 ベースのクラウド・サービスとは?



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

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
Wednesday, January 18, 2012

_ 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 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/ といった、きわめてハイ・スケールな 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:
· DynamoDB detail Page:
· DynamoDB Developer Guide:
· Blog entries:
· Werner:
· Jeff Barr:
· DynamoDB Frequently Asked Questions:
· DynamoDB Pricing:
· GigaOM:
· eWeek:

· Seattle Times:

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:

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

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 なことである。



_ 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

Comments Off on Amazon DynamoDB の 超弩級 クラウド NoSQL 感覚 by 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
Barb Darrow Nov. 2, 2011

_ 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 が開催される


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

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


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


James Hamilton
: /


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 を処理!

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

Microsoft が発表した、OSS ベースのクラウド・サービスとは?

Posted in .Selected, Big Data, Hadoop, James Hamilton, Microsoft by Agile Cat on October 14, 2011

Microsoft Announces Open Source based Cloud Service
Thursday, October 13, 2011



We see press releases go by all the time and most of them deserve the yawn they get. But, one caught my interest yesterday. At the PASS Summit conference Microsoft Vice President Ted Kummert announced that Microsoft will be offering a big data solution based upon Hadoop as part of SQL Azure. From the Microsoft press release, “Kummert also announced new investments to help customers manage big data, including an Apache Hadoop-based distribution for Windows Server and Windows Azure and a strategic partnership with Hortonworks Inc.”

私たちが目にするプレス・リリースは、その大半が退屈なものである。 しかし、昨日のことだが、とても興味深いものを見つけた。 PaaS Summit カンファレンスで、Microsoft Vice President である Ted Kummertが、Hadoop ベースの Big Data ソリューションを、SQL Azure の一部として提供すると発表したのだ。 その、Microsoft のプレスリリースによると、「 Kummert のアナウンスには、Windows Server と Windows Azure での、Apache Hadoop ベース・ディストリビューションと、Hortonworks との戦略的パートナーシップが含まれており、Big Data を取り扱う顧客を支援するための、新たな投資が行われる」とされる。

Clearly this is a major win for the early startup Hortonworks. Hortonworks is a spin out of Yahoo! and includes many of the core contributors to the Apache Hadoop distribution: Hortonwoks Taking Hadoop to Next Level.

明らかなことは、スタートアップである Hortonworks に、大きな成功がもたらされることだ。 Hortonworks は Yahoo! からのスピンアウトであり、また、Apache Hadoop ディストリビューションにおけるコア・コントリビュータである: Hortonwoks Taking Hadoop to Next Level

imageThis announcement is also a big win for the MapReduce processing model. First invented at Google and published in MapReduce: Simplified Data Processing on Large Clusters. The Apache Hadoop distribution is an open source implementation of MapReduce. Hadoop is incredibly widely used with Yahoo! running more than 40,000 nodes of Hadoop with their biggest single cluster now at 4,500 servers. Facebook runs a 1,100 node cluster and a second 300 node cluster. Linked in runs many clusters including deployments of 1,200, 580, and 120 nodes. See the Hadoop Powered By Page for many more examples.

さらに、このアナウンスメントは、MapReduce プロセシング・モデルにとっての、大きな勝利を意味する。 最初に Google で考案され、そして MapReduce として提供された:Simplified Data Processing on Large Clusters 。 つまり、Apache Hadoop のディストリビューションは、MapReduce のオープンソース実装である。 Hadoop は、Yahoo! において、きわめて広範囲で利用されている。いまでは、40,000 以上のノードが実行され、最大のシングル・クラスタは 4,500 サーバーにまで至っている。 また、Facebook は、1,100 ノードのクラスタと、300 ノードクラスタを運用している。さらに、LinkedIn も、1,200/580/120 のノードのディプロイメントを含めて、多数のクラスタを実行している。その他の、多数の事例に関しては、Hadoop Powered By Page を参照して欲しい。

In the cloud, AWS began offering Elastic MapReduce back in early 2009 and has been expanding the features supported by this offering steadily over the last couple of years adding support for Reserved Instances, Spot Instances, and Cluster Compute instances (on a 10Gb non-oversubscribed network – MapReduces just loves high bandwidth inter-node connectivity)and support for more regions with EMR available in Northern Virginia, Northern California, Ireland, Singapore, and Tokyo.

クラウドにおいては、2009年の初頭より AWS が Elastic MapReduceの提供を開始し、この 2年の間に、着実に機能を拡張してきた。Reserved Instances や、Spot Instances、Cluster Compute Instances(on a 10Gb non-oversubscribed network – MapReduces just loves high bandwidth inter-node connectivity)を追加し、Northern Virginia/Northern California/Ireland/Singapore/Tokyo などのリージョンをサポートしている。

Microsoft expects to have a pre-production (what they refer to as a “community technology Preview”) version of a Hadoop service available by the “end of 2011”. This is interesting for a variety of reasons. First, its more evidence of the broad acceptance and applicability of the MapReduce model. What is even more surprising is that Microsoft has decided in this case to base their MapReduce offering upon open source Hadoop rather than the Microsoft internally developed MapReduce service called Cosmos which is used heavily by the Bing search and advertising teams. The What is Dryad blog entry provides a good description of Cosmos and some of the infrastructure build upon the Cosmos core including Dryad, DryadLINQ, and SCOPE.

Microsoft は「2011年の終わり」までに、Hadoop サービスのプリ・プロダクション・バージョン(彼らの言う “community technology Preview”)を持ちたいと望んでいる。  このことは、さまざまな点で興味深いものである。 第一に、MapReduce モデルが、広範囲で受け入れられ、その適用性が証明されたことになる。  さらに驚くべきことは、Microsoft による MapReduce 提供が、オープンソースである Hadoop ベースで行われることである。つまり、Microsoft が内製し、Bing サーチと広告チームで利用されている、Cosmos という MapReduce サービスを押しのけることになる。 What is Dryad ブログのエントリーには、Cosmos に関する丁寧な説明と、その上に構築された Dryad/DryadLINQ /SCOPE などの情報が提供されている。

As surprising as it is to see Microsoft planning to offer MapReduce based upon open source rather than upon the internally developed and heavily used Cosmos platform, it’s even more surprising that they hope to contribute changes back to the open source community saying “Microsoft will work closely with the Hadoop community and propose contributions back to the Apache Software Foundation and the Hadoop project.”

つまり、Microsoft 内部で開発され、各部門で利用されている Cosmos プラットフォームよりも、オープンソース・ベースのMapReduce の提供を計画している点は、驚くべきことである。そして、「Microsoft は Hadoop コミュニティと緊密に作業を進め、Apache Software Foundation と Hadoop Project に対してコントリビュートシていく」と言い、そこで得られた成果を、オープンソース・コミュニティに戻していきたいとしている点に、さらに驚かされる。

· Microsoft Press Release: Microsoft Expands Data Platform
· Hortonsworks Press Release: Hortonworks to Extend Apache Hadoop to Windows Users
· Hortonworks Blog Entry: Bringing Apache Hadoop to Windows

Past MapReduce postings on Perspectives:

· MapReduce in CACM
· MapReduce: A Minor Step Forward
· Hadoop Summit 2010
· Hadoop Summit 2008
· Hadoop Wins TeraSort
· Google MapReduce Wins TeraSort
· HadoopDB: MapReduce over Relational Data
· Hortonworks Taking Hadoop to Next Level

James Hamilton

b: /


TAG index昨年の夏に Ray Ozzie が去り、秋には Bob Muglia を解任してしまい、大事な時期に空白の数カ月をもたらしてしまった Microsoft ですが、久々に良いニュースが聞けて嬉しいですね。 また、最初の Hadoop World が開催されてから( 3回目の Hadoop World NYC は11月)、わずか 2年で、Hadoop も重要なポジションを確立しましたね。そちらの側から見ても、とても嬉しいニュースです。 なお、文中でも参照している Hortonworks に関する記事は、<関連>の先頭にありますので、よろしければ、ご参照ください。ーーー __AC Stamp 2



Yahoo! から派生した Hortonworks が 次期 Hadoop を語る by J.H.
Big Data を探せ! アメリカの 5つの具体的な事例とは?
クラウドで Big Data をハンドリングする 6 社の事例
OpenFlow と Big Data の 深い関係について
HP が $10B で 買収する Autonomy は、Big Data のスペシャリスト?


Amazon データセンターについて、James Hamilton が語る

Posted in .Selected, Amazon, Data Center Trends, James Hamilton by Agile Cat on June 22, 2011

A Look Inside Amazon’s Data Centers
June 9th, 2011 : Rich Miller

_ DC Knowledge

Amazon Web Services doesn’t say much about the data centers powering its cloud computing platform. But this week the company held a technology open house in Seattle, where AWS Distinguished Engineer James Hamilton discussed the company’s infrastructure. The presentation(PDF) included an image of a modular data center design used by Amazon, which is the first official acknowledgement that the company uses modular infrastructure.

Amazon Web Services は、そのクラウド・コンピューティング・プラットフォームにパワーを供給する、自身のデータセンターについて多くを語らなかった。 しかし、今週に同社は Seattle で、テクノロジー・オープン・ハウスを開催し、AWS Distinguished Engineer である James Hamilton が、そのインフラストラクチャについて説明した。 そのプレゼンテーション資料(PDF)には、Amazon が用いるモジュール式データセンターのデザイン・イメージが含まれている。そして、それにより同社は、モジュール式のインフラストラクチャを利用していると、初めてオフィシャルに認めたことになる。

imageA look at the Amazon Perdix container, included in a presentation at Amazon Technology Day ⇒

Hamilton also shared a factoid that provides a sense of the rapid growth of Amazon’s cloud platform. “Every day Amazon Web Services adds enough new capacity to support all of’s global infrastructure through the company’s first 5 years, when it was a $2.76 billion annual revenue enterprise,” Hamilton states in one of the slides.

さらに Hamilton は、Amazon クラウド・プラットフォームの急激な成長の示すための情報を提供した。 「 Amazon Web Services は、すべての グローバル・インフラストラクチャをサポートするために、毎日のように充分なキャパシティを加えている。それは、年商が  $2.76 billion であった、最初の 5年を通して実施されてきた」と、 Hamilton のスライドでは説明されている。

Growth Driving Data Center Expansion Plans

Even without the exact numbers, that’s an indicator of how rapidly Amazon’s infrastructure is growing, and why the company has recently began acquiring additional sites in Ireland, northern Virginia and Oregon for data center expansion.

仮に、正確な数字ではないにしても、Amazon インフラストラクチャの急速な成長を示しており、また、同社がデータセンターを拡大するのために、最近になって Ireland や、Northern VirginiaOregon などのサイトを、買収しているという事実の背景も示している。

In his research at Microsoft and now at Amazon Web Services, Hamilton has focused on cost models for operating hyper-scale data centers. His presentation at the Amazon open house reviewed cost assumptions for an 8 megawatt data center, which could include 46,000 servers.

以前の Microsoft と、今の Amazon Web Services での研究において、 Hamilton はハイパー・スケール・データセンターの、運用に関するコスト・モデルにフォーカスしてきた。 今回の Amazon オープンハウスにおける彼のプレゼンテーションでは、46,000 台のサーバーを含む 8メガワット・データセンターの、コストに関する仮説をレビューしている。

Hamilton estimated the cost at $88 million (about $11 million per megawatt), and presented a pie chart outlining monthly operating costs for a facility, which is dominated by the cost for servers (57 percent), followed by power and cooling (18 percent) and electric power (13 percent).

Hamilton は、$88 million(メガワットあたり $11 million)というコストを見積もっている。そして、そのためのファシリティにおける、月次の運用コストをパイ・チャートを用いて表現しているが、第 1 位がサーバー(57%)であり、続いて電源と冷却(18%)、配電設備(13%)という順になっている。

These percentages are consistent with Hamilton’s earlier published research on data center costs. His example assumes power costs of roughly 7 cents per kilowatt hour and a Power Usage Effectiveness of PUE, which both suggest that the example data center is a composite  of Amazon’s global footprint rather than its best-performing data center.

これらのパーセンテージは、Hamilton が以前にまとめた、データセンター調査の結果と一致している。 そして、彼が例として示している、約 7セント/1キロワット時というコストや PUE の値は、Amazon データセンターにおけるベストな値ではなく、そのグローバルなフットプリントを複合した結果だと思われる。

Amazon and Modular Design

Hamilton was an early advocate of using shipping containers to deploy large volumes of servers in a tightly-controlled environment, first discussing this approach in a series of 2007 presentations that preceded Microsoft’s decision to use modular units to deploy its cloud computing infrastructure. When Hamilton moved to AWS, it prompted speculation that Amazon might also be using containers.

Hamilton は、しっかりと制御された環境に、大量のサーバーディプロイするために、搬送用のコンテナを活用するという考え方の、早期からの提唱者であった。2007年における一連のプレゼンテーションで論じているアプローチは、クラウド・コンピューティングのインフラストラクチャをディプロイするために、Microsoft が用いたモジュール式のユニットのことである。 したがって、Hamilton が AWS に移籍したとき、Amazon もコンテナを使っていると推測された。

imageA slide of a data center from a presentation at the Amazon Technology Open House ⇒

At Tuesday’s open house Hamilton displayed a slide of modular data centers, including the Amazon Perdix. The unit appears to be a custom-built unit that is wider and taller than standard ISO containers. While it’s hard to glean much from the exterior, vents at the side and top suggest cooling is managed in the upper section of the unit, which is air-cooled. Why Perdix? It’s the name of a character in Greek mythology known for inventing useful tools.

Tuesday のオープンハウスにおいて、Hamilton は Amazon Perdix も含めた、モジュール式データセンターのスライドを示した。 そのユニットは、標準的な ISO コンテナより幅が広く背の高い、特注のユニットだと思われる。 外部から大量の空気を取り入れることは艱難であるが、上段のユニットにおいて冷却が行われるていることを、サイドとトップのベントが示唆している。なぜ、Perdix と世なれるのだろうか? それは有益なツールを発明するという、ギリシャ神話における神の名前に由来している。

Is this Amazon’s current technology? Perhaps not. An Amazon affiliate that builds the company’s data centers has submitted building plans for a new facility in Umatilla, Oregon featuring six modules, according to local media. Plans show the structures will be about 20 feet wide and 108 feet long, situated side by side on the property, according to the East Oregonian.

それは、Amazon の最新テクノロジーなのだろうか? おそらく、違うだろう。Oregon Umatilla の地元メディアによると、Amazon データセンターを構築する関連団体が、6つのモジュールを主たる特徴とする新しいファシリティの、建物計画を提出したとされる。 その East Oregonian 誌によると、計画における構造物は、横幅が 約20フィートであり、長さが 108フィートとなる。 そして、同敷地内に並べて配置されるという。

Amazon continues to deploy infrastructure on raised floor, as seen in this photo shared by Hamilton.

Hamilton から提供された写真によると、Amazon は上床式のファシリティ内に、ラックを配置し続けている。


ついに、Amazon がデータセンターに関する情報を流し始めましたね。 とてもスバラシイことですが、その背景には Facebook の Open Compute Project があるのかも知れませんね? James Hamilton さんも気になっていたようで、Perspective に以下をポストしていました。

Open Compute Project Thursday, April 07, 2011
Open Compute Mechanical System Design Saturday, April 09, 2011
Open Compute Server Design Wednesday, April 20, 2011

また、このポストの最後に書かれている、Oregon のデータセンターですが、続報が入ってきているようですので、近々に対訳をポストしたいと考えています。 ご期待ください! ーーー __AC Stamp 2




詳細な解説つきの Facebook Oregon DC フォト・ツアー
Facebook – Building Efficient Data Centers with the Open Compute Projec
Facebook – Oregon データセンターの写真が一挙公開!
データセンターのクラウド化を示す AFCOM の調査
Quincy に配置された Microsoft IT-PAC のフォト・ギャラリー


Comments Off on Amazon データセンターについて、James Hamilton が語る

%d bloggers like this: