データセンター視点で比較したクラウドの内側

データセンター視点で比較したクラウドの内側

日経コンピュータ編集部

中田敦

日本 Java ユーザグループ（JJUG） 2009年10月8日クロスコミュニテゖカンフゔレンス 2009 Fall

講演者

中田敦（なかだあつし）

「日経コンピュータ」編集部所属

1998年4月日経BP社入社、「日経レストラン」編集部に配属

2000年9月 ITニュースサト「BizTech」編集部に異動

2002年10月「日経Windowsプロ」編集部に異動

2006年1月 ITニュースサト「ITpro」編集部に異動

2008年4～6月米国でクラウド・コンピューテゖング事情を取材

2008年10月「日経コンピュータ」編集部に異動

2009年4月「クラウド大全」刊行

日経コンピュータのクラウド担当

2009年7月8日号

2008年11月15日号

2009年4月29日号

日経コンピュータのクラウド担当

日経BP社発行

2520円Amazon

Google

Salesforce.com

Windows Azure

楽天、Yahoo!

全部入ってます

中田も

執筆しています

Googleは異形のメーカー

本日の内容（1）

1. Googleは“異形”のメーカー

世界屈指のサーバー生産台数、基盤ソフトは全て内製

2. コンピュータ業界の主導権は、メーカーからサービス事業者へ

Microsoftもサーバーの自社開発開始

Amazon.comは「ITベンダー」

3. コンテナ型データセンターの中身

Yahoo!米国本社駐車場で運用するコンテナ型データセンター

本日の内容（2）

4. クラウドのコスト構造

Google、Microsoft、Amazonのサーバー台数

データセンターの消費電力効率は、コンテナ型で「PUE=1.2」

標準型で「PUE=1.35～1.45」が標準に

5. クラウドはGoogleが定義した

スケールゕウト、ハードウエゕに一切頼らないフォールトトレランス、

キー・バリュー型データストゕ、関数型言語、

エラー忘却型コンピューテゖング、Warehouse Scale Computing

6. Googleを追従するAmazon、Microsoft、Salesforce.com

第一世代はGoogle、第二世代はAmazon、第三世代はMicrosoft

「Oracleが無くなっても問題ない」と言い切るSalesforce.com

問題意識

デスクトップ検索 Web検索

Outlook 2007 Gmail

カーナビ Google Maps

RSSリーダー Googleリーダー

Windowsフォトギャラリー Picasa Webゕルバム

ユーザーはなぜクラウド・コンピューティングのサービスを使うのか？

（誤解） Webブラウザで使えるから（誤解）安価だから

（正答）クラウドが提供するゕプリケーションの方が高速だから

「サーバーで動かすソフトウエゕ」のどこがいいのか？

例えば

Gmail

●巨大な容量無料版でも最低5Gバト

●高速な検索どんなに大量にメールがあっても1～2秒で検索

●どこからでも使えるWebブラウザ携帯電話機


例えば

Google Maps

●巨大な容量全世界の地図全世界の航空写真主要都市の街頭写真

●高速な検索全世界の地図を1～2秒で検索

●どこからでも使えるWebブラウザ携帯電話機

Webブラウザ以外でのゕプリケーション利用が可能に

Windows Mobile携帯電話機

タッチパネルでGoogle Mapsが利用可能


パソコン用ソフトウエゕの危機

単体プロセッサの性能向上が止まった

プロセッサは「マルチコゕ」「メニーコゕ」化へ

• Pentium 4 / 3.8GHz（2004年11月）

Intel製プロセッサの最高動作周波数

• Core i7 / 3.33GHz（2009年6月）

現状のハエンド・プロセッサ

パソコン用ソフトウエゕの危機

単体ハードデゖスクの性能向上が止まった

•2000年2月

3.5型ハードデゖスクが毎分1万5000回転に到達した時期は？

•ノートPC：4200回転～7200回転

•デスクトップPC：7200回転

•サーバー：7200回転～1万5000回転）

現状のハードデゖスク・ランナップ

なぜサーバーの方が速いのか？

Googleには

大量のサーバーが

あり

大量のサーバーで

並列分散処理をしているから

問題意識（つづき）

Googleが提供するアプリケーションは、なぜ高速なのか？

Ken Thompson氏（ AT&Tベル研究所でUNIXを開発した一人。2006年からGoogleに所属）が日経コンピュータのンタビューに答えて曰く、

－－－ I guess for Google it is some sort of Cloud Computing, some sort of – not Cloud Computing but a Cloud Computer;something that is always there and always be accessed and always store data and always give it back. I think that is very hard.

重要なのは、Googleに「クラウド・コンピュータ」があるということでは、「クラウド・コンピュータ」とはどのようなものなのか？


サーバー生産台数・世界3位

New York Times 2006年7月3日「A Search Engine That's Becoming an Inventor」Google was the world's fourth-largest maker of computer servers, after Dell, Hewlett-Packard and I.B.M.

New York Times 2006年7月3日

Dell、Hewlett-Packard、IBMに続いて「台数ベースで世界4位」

日本の経営雑誌「FACTA」2009年9月号「スマートグリッド」でも出し抜かれる日本

－－傍聴し続けるグーグルは自社サーバーを内製化している。生産台数で見ればグーグルは世界3位のサーバーメーカーになる


英Financial TimesのRichard Waters記者が公開した3月6日のブログ

－－－－－－－－－－－－－－－－－－米Microsoft ResearchのトップであるRick Rashid氏によれば、全世界で出荷されるサーバーの20％を、ごく少数の企業が購入している。Microsoft、Google、Yahoo!、Amazon.comだ。－－－－－－－－－－－－－－－－－－

4社で150万台のサーバーを1年で購入？

ネタ本はThe Datacenter as a Computer

GoogleのトップエンジニゕによるThe Datacenter as a Computer

Luiz André Barroso氏http://www.barroso.org/GoogleのDistinguished Engineer

Urs Hölzle氏Googleのデータセンター運営担当副社長「Google's First vice presidenf otengineering」


Googleが4月1日に開催したEfficient Data Center Summit

・2005年11月からコンテナ利用・コンテナは水冷・冷却に使った水は、

「冷却塔」（チラー）で再冷却・2009年4月にベルギーで

「チラーレスデータセンター」運用開始

・サーバーは自作・12Vのバッテリー内蔵・UPS（無停止電源装置）は

使用しない

http://www.google.com/corporate/green/datacenters/summit.html

Googleは2005年11月からコンテナ型データセンターを運用

サーバー自作の目的

米CNET NEWS 2009年4月1日から引用「Google uncloaks once-secret server」

ノートPCのように「12V」のバッテリーを内蔵

Pentium 4世代のマザーボード？

↓

つまり2005年から、サーバーを自作している（今はどうなってるんだろう……）

サーバー自作の目的

日経コンピュータ2009年9月2日号「グーグルは異形のメーカー」

データセンター効率化の指標

PUE（Power Usage Effectiveness）

データセンター全体の消費電力をサーバーなどのIT機器の消費電力で割った値

全部IT機器が消費＝ PUE 1.0

半分を冷却装置などが消費＝ PUE 2.0


• PUE 2.3～2.5

日本の標準的なデータセンター

• PUE 1.8

日本IBMの最新鋭データセンター

• PUE 1.6

日立製作所の最新鋭データセンター


Google

PUE 1.21（6カ所平均）

PUE 1.13（あるDCで）

業界の主導権はメーカーからサービス事業者へ

日経コンピュータ2009年7月8日号クラウドコンピューテゖング8つの新しい真実

Amazonの雲はどれぐらい巨大？

米Rackable Systemsの年次報告書（Annual Report）から類推可能

●ご注意Rackable Systemsは09年5月米SGIを買収し、社名を「SGI」に変更しております

Rackable Systems（現：SGI）とは？

米Microsoftや米Amazonに高密度サーバーを供給するサーバー・メーカー

←コンテナサーバーもやってます


総額 Amazonがしめる割合 Amazonの調達

Rackableの売上高（2008年12月期）

2億4743万ドル 35％ 8669万ドル

Rackableのサーバー出荷台数

（2008年12月期）6万8490台 35％ 2万4000台

2008年12月期 2007年12月期 2006年12月期

Amazon 35％ 16％ 10％未満

Microsoft 14％ 36％ 34％

Yahoo! 10％未満 12％ 26％

●Rackableの主要顧客の売上高が、全体に占める割合

●Amazonが調達した実数（推定）

Amazon.com、Rackable Systemsの年次報告書から日経コンピュータが作成


●Amazonの投資動向（2008年12月期）

Amazonの固定資産購入（社内で使用するソフトウエアや

Webサイトの開発を含む）

Rackableからの調達額割合

3億3300万ドル 8660万ドル 26％

調達するサーバーの大半はRackableか？

年間サーバー調達台数：2万4000台以上

運用するサーバーの台数は、7～10万台規模か？

Amazon.com、Rackable Systemsの年次報告書から日経コンピュータが作成

米Yahoo!本社のコンテナ型データセンター

海上輸送などに使用する国際規格の幅8フゖート（2メートル44センチ）、長さ40フゖート（12メートル20センチ）のコンテナ


コンテナの壁に沿って、サーバーがギッシリと詰め込まれています


ラックとラックの間にある銀色の箱は「ラジエター」。中に水が循環する細いパプが張り巡らされています。中にある大きなフゔンで風を起こして、サーバーが発する熱を流し込み、ラジエターの中を流れる水によって熱を冷やす仕組み


サーバーの電源はラックの上部に集約されています。サーバーのマザーボードには電源は実装されていません。そのため電源が発する熱がサーバー内にこもらない仕組み


コンテナには水を供給・排出するホースが合計2本接続されています。導入された水によってサーバーの熱を冷やし、温まった水がコンテナ外に排出される仕組み

コンテナ型データセンターの規模

米SGI「ICEcube」の仕様（コンテナ1台当たり）

サーバー台数最大2400台

プロセッサ数最大4800個

プロセッサコゕ数最大2万2400個

ストレージ容量最大11ペタバト

水の温度セ氏18度

Microsoftの場合

シカゴの最新鋭データセンター

コンテナ

200台

サーバー台数

約50万台

Microsoftの場合

シカゴの最新鋭データセンター

コンテナ

200台

112台

サーバー台数

約50万台

22万4000台（コンテナのみ）

「Data Center Knowledge」より引用

Microsoftの場合

「第4世代データセンター」構想

コンテナを全面採用もはや「建屋」すら無い

2008年12月に発表

各社から続出するコンテナ型データセンター

HP

DELL

IBM

シカゴデータセンターの規模感

• 55万300台（ノークリサーチ調査）

日本のPCサーバー出荷台数（2007年度）

• 30～40万台（コンテナ＝20万台、その他＝10～20万台？）

Microsoftのシカゴ・データセンター

• 60Mワット（PUE = 1.2 → IT機器の消費電力は50Mワット）

シカゴDCの消費電力

• 110億円（東京電力/家庭用電力の場合）、10～20億円（シカゴの場合）

50Mワットの年間電気料金

• 100～150ワット（3月にデルが発表したAtom搭載サーバー（未発売？）は30W！）

1サーバー当たりの消費電力

Googleの非常識データセンター

米Googleの2009年4月1日発表資料「Insights into Google's PUE Results」より

チラー（水冷用の冷却水を冷やす装置）の

無いデータセンターをベルギーで「運用中」

PUEは「1.1以下」


データセンター省電力化の手段の一つとして

サーバールームの温度を上げればいい

米Googleの2009年5月の論文「The Datacenter as a Computer」より


セ氏50度未満なら

ハードデゖスク温度と故障率に相関関係は無い

米Googleの2007年2月の論文「 Failure Trends in a Large Disk Drive Population」より

クラウドのコスト構造

• 5000台

Microsoftで1人の管理者が管理するサーバー台数

• 壊れたサーバーはその時点で修理/交換しない

• 定期的なメンテナンス時にのみ交換する

Amazon.comでのサーバー管理ポリシー

クラウドはGoogleが定義した

日経コンピュータ2009年9月2日号「グーグルは異形のメーカー」

クラウドはGoogleが定義した

独自に建造したデータセンター

分散ロックシステム

Chubby

分散フゔルシステム

Google File System（GFS）

並列プログラミングモデル

MapReduceキー・バリュー型データストゕ

BigTable

プログラミング言語

Sawzall

グーグルプラットフォーム

Web検索ログ解析 GmailGoogle Maps

ゕプリケーションサービス

論文：Interpreting the Data: Parallel Analysis with Sawzall（2005年）

論文：MapReduce: Simplified Data Processing on Large Clusters（2004年）

ホワトペーパー：The Datacenter as a Computer. An Introduction to the Design of Warehouse-Scale Machines（2009年）

論文：Bigtable: A Distributed Storage System for Structured Data（2006年）

論文：The Google File System（2003年）

論文：The Chubby lock service for loosely-coupled distributed systems（2006年）

論文：Failure Trends in a Large Disk Drive Population（2007年）

Datacenter as a Computer名言集

• 巨大なクラスタ（システム）を保有し

ないサードパーテゖ・ソフトウエゕ・

プロバダが、ソフトウエゕのテスト

やチューニングを十分な水準で行うの

は困難だ」

自前主義


• OSレヤーがあるとすれば、それは「Cluster-Level

Infrastructure」のことだ

• Datacenter must be a general-purpose computer

system.

• There is substantial risk that by the time a

specialized hardware solution is implemented, it

is no longer a good fit

自前主義


• ProLiant is about four times more cost-

efficient than the Superdome.（ストレージ

も含むと20倍）

• （我々の）ワークロードはあまりに巨大なので、

どんな大きなSMPサーバーでも1台ではまかな

いきれない（レテンシはLANに集約される）

スケールゕウト


• 価格性能比を考えると、安いCPUしか

使わない

• プロセッサ使用率は高いほど消費電力

効率が良い → 安い・遅い方が良い

スケールゕウト


• メニーコゕが進めば、サーバーが数十台入る「ラック」に、

現在のデータセンターに匹敵するマシンが収まることにな

る。「Warehouse Scale Computinge（WSC）」は全デー

タセンター運営者の現実となる

メニーコゕ

• Computation is moving into the cloud, and thus into

WSCs

WSC


• データセンターの建造コストは「10～20ドル

/W」（建造コストは消費電力で測れ）

• Tier IIは「99.7％」、Tier IIIは「99.98％」、

Tier IVは「99.995％」

• データセンターの最適温度は「摂氏25～27度」

• 「サーバーPUE」も測れ

データセンターの基本


•データが再生成できない、失われた、喪失した状態

Corrupted （喪失）

•サービスがダウンしている、ユーザーがサービスに到達できない

Unreachable （未到達）

•サービスは利用できるが、状態が劣化している

Degraded （劣化）

•障害は発生しているが、ソフトウエゕ/ハードウエゕによる耐障害対策によって

ユーザーから完全に見えない状態になっている

Masked （隠蔽）


•MTBF（平均故障間隔）が30年というサー

バーがあったとしても、それが1万台あれば1

日に1台は故障が起きる

•いくらRAIDでデゖスクを冗長化しても、電源

装置やストレージOSなどが「単一障害点」と

して残る

ソフトウエゕベースの耐障害性対策


•もっともECC付きDRAMは使っている。2000

年までECCを使っていなくて酷い目にあった

• In summary, near perfect reliability is not

universally required in Internet services.

ソフトウエゕベースの耐障害性対策

ソフトウエゕによる耐障害性対策

ハードウエゕによる耐障害性対策

・プロセサの多重化・RAIDによるミラーリング、パリテゖ付きストラピング

▼ハードウエゕ投資の高騰▼ハードウエゕ利用率の低下▼消費電力効率の低下


・サーバーのクラスタリング・データのレプリケーション

△低価格ハードウエゕが利用可能△ハードウエゕ利用率の向上△運用の効率化

（故障したサーバーは交換するだけ）▼ソフトウエゕの複雑化

その結果

その結果

「いくらRAIDでデゖスクを冗長化しても、電源装置やストレージ装置のOSなどが『単一障害点』として残る」

「MTBF（平均故障間隔）が30年（30年に1年か故障しない）というサーバーがあったとしても、それが1万台あれば1日に1台は故障が起きる」

複雑化するソフトウエゕは自社開発でカバー

「The Datacenter as a Computer」におけるグーグルの主張


メモリー

データ

メモリー

データ

スレッドスレッドスレッド

手続き型言語でマルチスレッドを実行する場合関数型言語でマルチプロセスを実行する場合

各スレッドがメモリーを共有する

プロセスプロセスプロセス

データデータデータ

コピーコピー

コピー

メッセージ交換各プロセスは自分用にデータをコピーして計算を行う

分散システムの実装に「関数型言語のゕデゕ」を投入


GFS

データ

Map処理

データA

Map処理

データA

Map処理

データA

Reduce処理

データB

Reduce処理

データC

抽出結果

抽出結果

抽出結果

コピー

集約

GFS

データ

計算結果

計算結果

Map処理ではデータ抽出を行う Reduce処理

では計算を行う

保存

「関数型言語のゕデゕ」を拝借して開発した「MapReduce」の仕組み


• 故障予測はコストに合わない。Diskのような小さなサブ

セットに関してのみ故障予測を行っている

• サーバーが故障しても、急いで修理しない。「リペゕ」

バッチでしか行わない。その方が管理コスト抑制になる

故障に対する接し方

• We must treat the datacenter itself as one massive

computer

結論

Googleの中の人曰く

• some sort of – not Cloud

Computing but a Cloud Computer;

something that is always there and

always be accessed and always

store data and always give it back.

ケン・トンプソン氏


• I think that is very hard. There is two types

of jobs; one where you want to do something

huge, （略） one job that takes thousands of

computers to do or you want to do thousands

of little jobs and never fail. And those are

almost like two separate problems, like

MapReduce（略）



• I am actually more interested in the second, in trying to

get small jobs, the kind of jobs that a user at home will

be restore a file, look at his date book, or pull a video,

little small jobs that are much more reliable than anything

he can do at home.


• スループット指向の処理とレスポンス指向の処理を、両方でき

なくてはならない

要約


• 2002年にGoogleに入社してすぐに、プロ

グラミング言語「Sawzall」のデザンを

始めた。クエリ・ログやパフォーマンス・

ログといった分散データの並列的な解析を、

数千台のマシンを連携させて行う際に、そ

れを容易な言語で扱えるようにするものだ。

ロブ・パク氏


• Sawzallは、正確には関数型言語ではない

が、関数型言語のプロパテゖ（特性）を使

用している。つまり、複数のコンピュテー

ション・ピース（プロセス）がデータを

シェゕしないようにするという特性だ。

ロブ・パク氏


• 何が新しいのか？ MapReduceは確か

に古いモデルだが、とんでもないス

ケールで利用されているという点が新

しい。MapReduceが成功したのは2つ

の要因による。

ロブ・パク氏


• 一つは、とてもシンプルなプログラミング

モデルなので、理解が容易であり、膨大な

台数のマシンを使って簡単に問題を解決で

きるのだ。何事もMapとReduceに落とし

込めば、安全に並列処理ができる。

ロブ・パク氏


• もう一つは、あまり語られていないことだ

が、耐障害性だ。マシンが2000～3000台

あって、それらが連携しながら何時間もか

けて処理を成功させていることが、

MapReduceというモデルがうまくいって

いる要因だ

ロブ・パク氏

その影響はSalesforce.comにも

•最近、ンフラストラクチャを全面刷新した。かつてはSun Microsystemsの「SunFire

E25K」という最大112プロセッサの非常に巨大なサーバーを使用していた。E25Kを8台

も所有し、とても高価だった。しかし現在はデルの「PowerEdge 1950」に移行した。

Intel Nehalemは大変なコスト削減になったし、それでいて高速だ。私はこれが、業界の

総合的なトレンドだと感じている。皆、よりコモデゖテゖなハードウエゕに移行している。

これはとても大きな変化だ。

Salesforce.com CTO パーカー・ハリス氏


• 我々は現在、ドキュメントはコモデゖテゖ・ハードウエゕ

に保存している。これはある意味、Googleにとても似て

いるやり方だ。我々は今、巨大なスケールのデータボ

リュームを検証中で、Oracle Databaseではない別の、ク

ラウドベースの並列処理技術を採用したストレージを活用

できないか考えている。「Hadoop」のようなものだ。



• 今は、ゕクテゖブなデータをOracleに、ヒストリカルなデー

タを非Oracleのシステムに保存している。今後は顧客データ

も、マスターはOracleに、トランザクショナルなデータは非

Oracleのシステムに保存する可能性がある。請求書や注文書

といったトランザクションは、処理が終了すればさして重要

なデータではない。これらのデータは、Oracleから別のシス

テムに移行するだろう。



• もしかしたら将来、Oracleが（我々のデータセンター内

から）無くなるかもしれない。5年や10年後には、クラ

ウド・ベースのデータベースシステムの時代が到来する

だろう。クラウドベース・データベースは、今日のやり

方、OracleやIBMなどのやり方とは大きく異なる。今は、

革命的な変化が起きている。



• Salesforce.comのような巨大なクラウド事業者が、そ

の問題を解決するかもしれないし、データベース事業者

やその他の事業者が解決するかもしれない。


GoogleからAmazon、Microsoftへ

第一世代グーグル

第二世代ゕマゾン

第三世代マクロソフト

ソフトウエア名GFS、MapReduce、BigTable

データ分散方式マスター・スレブ方式

データの保存先ハードデゖスク中心

ソフトウエア名Amazon Dynamo

データ分散方式コンシステントハッシング

データの保存先メモリー中心ハードデゖスク併用

ソフトウエア名Windows Azure

データ分散方式分散ハッシュテーブル

データの保存先メモリー中心ハードデゖスク併用

開発時期：1998年～実用時期：2000年代初期～

開発時期：2000年代前半実用時期：2007年～

開発時期：2006年～実用時期：2009年末～

結論

• ネットワークでサービスが利用できれば「クラウド」ではない

• 分散処理、並列処理の時代がついにやってきた

• 安価なハードウエゕ、自前で作ったソフトウエゕがIT業界を支配する

以上、ありがとうございました

Technology

データセンター視点で比較したクラウドの内側