Cosmos + Scope で Google を追撃か？

Cosmos と Scope と MapReduce と Hadoop と ・・・

Ray Ozzie から Cosmos というアナウンスがあったので、あっ そうそう、と思い出したのが Scope です。長いホワイトペーパーなので放っておいたのですが、あらためて眺めてみると、ここに Cosmos が居ましたよ。 以下の図に示されるように、Scope が言語処理系で、Cosmos がファイル･システムという組み合わせのようです。（Axum は、パラレルといっても計算機能のためのもののようです ・・・）

ーーーーーーーーーーー

SCOPE: Easy and Efficient Parallel Processing of Massive Data Sets

・・・より抜粋

ーーーーーーーーーーー

1. INTRODUCTION

Microsoft は、膨大なデータ･セットのストアと分析のために、Cosmos という分散コンピューティング･プラットフォームを開発している。 Cosmos は、無数の普及品サーバーにより構成される、大規模なクラスタ上で動作するようにデザインされている。 つまり、それらのサーバーにアタッチされたディスクにより、このストレージは分散されることになる。 Cosmos プラットフォームのためにデザインされた高次元での目的としては、以下の項目が含まれる：

1. Availability: Cosmos は、多数のハードウェア障害に対する弾力性を持つことで、システム全体の停止を回避する。ファイル･データは、このシステム全体に何度もリプリケートされる。また、2f+1 台のサーバーによる選択されたグループにより、ファイル･メタデータを管理することで、f 回の障害に対する弾性を持つ。

2. Reliability: Cosmos のアーキテクチャは、システムの機能低下を回避するために、一時的なハードウェア･コーディネーションを見分ける。 システム･コンポーネントは、End-to-End でチェックされ、障害を持つコンポーネントを停止するためのメカニズムを適用する。

3. Scalability: Cosmos のデザインは、ペタ･バイト･オーダーのデータをストアし処理する能力を持つ、スケーラブルなシステムを実現するために、ゼロからデザインされている。 そのクラスタにサーバーを追加していくことで、ストレージとコンピューティングのためのキャパシティを、容易に拡張できる。

4. Performance: Cosmos を実行するクラスタは、無数の独立したサーバーで構成される。 データは、3台のサーバー上に分散される。ひとつの Job は、小さなコンピューティングの単位に分解され、大量の CPU とストレージ･デバイスに分散される。 それにより、Job を完了する時間が、大幅に短縮される。

5. Cost: Cosmos は、同様の問題に対する従来からのアプローチと比較して、安価な構築と、運用と、拡張を実現する。 そこでは、費用対効果を高めるために、低価格サーバーを大量に利用するが、この考え方は、少数の高額サーバーによるアプローチの対極にある。

Figure １ が示すのは、Cosmos platform の主要な構成要素である。

1. Cosmos storage: きわめて膨大なシーケンシャル･ファイルを、信頼性と効率に基づいてストアするためにデザインされた、分散ストレージ･サブ･システムである。

2. Cosmos execution environment: 分散アプリケーションを、ディプロイし、実行し、デバッグするための環境である。

3. SCOPE: データ分析ジョブを記述するための、ハイレベルなスクリプティング言語。 この、SCOPE のコンパイラとオプティマイザにより、スクリプトを効果的なパラレル実行プランへと展開。

このドキュメントでは、SCOPE とコンポーネントにフォーカスしており、Cosmos については簡潔に説明するだけである。 Cosmos platform の詳細は、このドキュメントの対象外となる。

ーーーーーーーーーーー

ここまで読んでみて、Hadoop に かなり近いぞ、、、というか、同一のベクトルとコンセプトに思えます。 そして、6章ですが ・・・

ーーーーーーーーーーー

6. RELATED WORK

SCOPE is heavily influenced by SQL but its target applications and execution environment differ from traditional database systems. SCOPE is designed for easy and efficient processing of massive amounts of data stored in distributed, sequential files. It provides efficient query processing functionality. The execution strategies used owe much to earlier work on query processing in parallel and distributed database systems [9].

All companies operating internet-scale services have the need to store and process massive data sets and have developed their own system for this purpose. Google popularized the mapreduce programming model. Based on what has been published in the open literature, their software stack consists of Google File System [8] and Bigtable [3] for storage, the MapReduce execution environment [5] with users writing MapReduce applications in C++ or Sawzall [11].

A MapReduce application written in C++ takes many more lines of code than the corresponding application expressed in SCOPE. For example, the word count application used as an example in [5] requires about 70 lines of C++ code but only five or six lines of SCOPE code.

Yahoo! also has a software stack designed for distributed processing of massive data sets. Users write applications in a language called Pig Latin [10] [1]. A Pig Latin program is compiled by the Pig system into a sequence of MapReduce operators that are executed using Hadoop [1], an open-source implementation of MapReduce. Pig Latin is a dataflow language using a nested data model. Each step in a program specifies a single, high-level data transformation. A complex computation is expressed as a series of such transformations. Yahoo! also has a more powerful Map-Reduce-Merge execution environment but it is apparently not the execution environment used by the Pig system. Both Google and Yahoo! use a MapReduce execution environment. MapReduce is very rigid, forcing every computation to be structured as a sequence of mapreduce pairs. The Cosmos execution environment is significantly more flexible, handling execution of any computation that can be expressed as an acyclic dataflow graph.

ーーーーーーーーーーー

おおっ！ これは Map-Reduce と Hadoop への挑戦状ではないですか！ Azure の説明に欠けていた、とてつもなく大きな領域が、これで埋まることになるのだと思います。

ーーーーーーーーーーー

Azure Cosmos : 新しいファイル･システム？

Microsoft’s Ozzie defends Microsoft’s aggressive online spending

All about Microsoft より

From <http://blogs.zdnet.com/microsoft/?p=2826#more-2826>

May 20th, 2009

Posted by Mary Jo Foley @ 6:54 am

ーーーーーーーーーーーー

昨日の Ray Ozzie のコメントですが、Online Systems Business への継続的な投資を約束するだけではなく、“Cosmos” という Azure のためのファイル･システムについても言及したそうです。高度なスケールを持つファイル･システムとのことですが、Relational SDS で適度なスケーラビリティを持つクラウドをサポートしつつ、たとえば MapReduce に対抗するようなスケールを Cosmos で提供していくのでしょうか？ Azure に対して、いまいち迫力が感じられなかったのでは、この無限のスケールを持つファイル･システムの領域が語られていなかったからです。 もちろん、Relational SDS によるエンタープライズのサポートは現実的なものであり、そこからクラウドへの移行が始まるのでしょうが、それだけじゃぁ夢がないですよね。 Cosmos に期待です！ ーーー A.C. （ Hadoop 特集も読んでくださいね ）

ーーーーーーーーーーーー

Microsoft の Chief Software Architect である Ray Ozzie は、オンライン･システム市場における膨大で継続的な投資を維持し、Online Systems Business の赤字が、Microsoft 全体の戦略におよぼす影響は少ないと断言した。

2009年5月20日に開催された Morgan Technology, Media and Telecom Conference のスピーチで、Ozzie はお気に入りのトピックスについて触れた。 つまり、Software + Services と、3つのスクリーン（モバイル、PC、TV）とクラウド、そして、クラウド･コンピューティングにおける Microsoft の能力を示すための、コンシューマ･サービス市場の重要性である。

しかし、まだ利益を生み出さないオンライン･サービス部門に、それほどの資金を、なぜ注ぎ続けるのかという質問は、Ozzie にとって想定外だったようだ。(Microsoft の OSB は、2009年 1～3 月期に 5億 7500万ドルの赤字を計上している。直近のレイオフは、OSB に対しても適用されたが、相対的に少人数であったとされている) それに対して、Windows Live Hotmail から 発表直前の Live Search へといたる、Microsoft Live Services に関する研究と投資は、その営業実績が示すものより、大きなメリットをもたらすと Ozzie は答えている。

Microsoft は Exchange Online や SharePoint Online といった、エンタープライズ･サービスにフォーカスすることで、数多くのクラウド要件について学んできた。 そして、コンシューマ･サービスへの投資はで、スケールというものについて、重要なことについて学んだと、Ozzie は続ける。

Microsoft のコンシューマ･サービスを、ディプロイし実行するために構築されたインフラストラクチャは、全社的なサービスをサポートするために拡張されているとも言う。 Ozzie が指摘した “Cosmos” という高度なスケールを持つファイル･システムは、最終的に Microsoft におけるコンシューマと、エンタープライズ、デベロッパーの全てをサポートする、Microsoft の Azure クラウド･プラットフォームの一部になる。そして、現時点での Microsoft のクラウド･サービスにおける、すべてのマネージメント･システムは、コンシューマ･オンライン･サービスを管理することから得られたものだとも指摘している。

クラウド市場における Microsoft の主要なアドバンテージは、「プラットフォームとアプリケーションの両方を構築するという現実」であると、Ozzie 信じている。（この世界は、どのように変化してきたのだろうか。 Microsoft は 1990年代に、独占禁止法における訴訟を食い止めるために、オペレーティング･システムとアプリケーションのビジネスの間に、厳格なカベを作っていると主張してきた）

この秋に、最終的なかたちでの提供が予定される、Azure のオペレーティング･システムとサービス･プラットフォームに対して、Microsoft は相当な投資を行ってきた。

Azure は Microsoft の 20～30 年後を託したものであり、他のクラウド･ベンダーとは異なるクラウド･オペレーティング･システムの構築に取り組んでいるとも発言している。

Microsoft のオンライン･サービスと言えば、Kumo とコードネームの、新しい検索サービスのリリースについて言及し始めている。 来週の “All Things D” カンファレンスでは、Kumo のオフィシャルなデモが計画されている。実際の発表が 6月初旬まで、ずれ込むこともないだろう。

検索サービス部門の担当者である Danny Sullivan は、デモのと実際のデビューにおける内容が、異なるものになるという。すべてのサインは Kumo/Bing（あるいは他のもの）を指し示している。つまり、6月 2日ごろから提供される、新しい検索サービスのことである。

 

Azure Core Scenario _4

コア･シナリオ_4 ： オンプレミスあるいはホストされているアプリケーションからのクラウド･ストレージの利用

以前に紹介したように、David Chappell さんが Introducing Windows Azure というタイトルの新しいホワイトペーパーを提供しています。 そこで解説されている、最後のアプリケーション･シナリオの抄訳です。

Windows Azure のコンポーネントを理解することは重要ですが、それだけでは充分ではありません。このプラットフォームを適切に理解するためのベストな方法は、それが利用される形態を知ることです。 Windows Azure を利用するための、4つのコア･シナリオがあります：

① スケーラブルな Web アプリケーションの作成
② 並列処理アプリケーションの作成
③ バック･グラウンド･プロセスを用いた Web アプリケーションの作成
④ オンプレミスあるいはホストされているアプリケーションからのクラウド･ストレージの利用

Using Cloud Storage from an On-Premises or Hosted Application

前述における、複雑なクラウド･プラットフォームのシナリオは、有用なものになり得る。しかし、Windows Azure における１つの機能だけを、アプリケーションが必要とする場合もある。例えば、膨大な量のデータをストアするための、オンプレミスあるいはホストされたアプリケーションについて考えてみよう。コストの低減を望むエンタープライズは、メールへのアクセスを可能にしながら、古い電子メールをストレージに保存するかもしれない。同様に、ホスティングされているニュース Web サイトが、膨大なのテキストや、グラフィックス、ビデオ、ユーザー･プロファイルなどの情報をストアするために、グローバルなアクセスが可能なスケーラブルな場所を必要とするかもしれない。写真共有サイトが、信頼できるサードパーティに情報をストアするという課題に、取り組むかもしれない。

Windows Azure Storage により、これらすべての状況に取り組むことができる。 Figure 10 に、このアイデアを図示する。

Figure 10: An on-premises or hosted application can use Windows Azure blobs and tables to store its data in the cloud.

この図が示すように、オンプレミスあるいはホストされたアプリケーションは、Windows Azure のストレージにダイレクトにアクセスできる。このアクセスでは、ローカル･ストレージと比較して時間が掛かるだろうが、さらに安価であり、スケーラブルであり、信頼性も高くなるだろう。いくつかのアプリケーションにとって、このトレードオフは明確な価値を持っている。

ーーー

これまでに説明してきた 4つのシナリオのサポートが、Windows Azure CTP における基本的なゴールとのことです。 ただし、このクラウド･プラットフォームが成長するにつれて、そこで取り扱う課題も拡大すると期待してほしい、そして、ここに記したシナリオは重要がストーリーの終わりというわけではない、とも言っています。

 

Hadoop DFS Architecture_2

NameNode and DataNodes

HDFS は、マスター／スレーブのアーキテクチャを持っている。 HDFS は単一の NameNode により成り立つ。 この NameNode とは、ファイル･システム名前空間を管理し、クライアントによるファイル･アクセスを規制するための、マスター･サーバーのことである。 それに加えて、 数多くの DataNodes が、クラスタ内のノードごとに存在する。それにより、DataNodes を実行するノードに、アタッチされたストレージが管理される。 HDFS は、ファイル･システム名前空間を公開し、また、ファイルへのユーザー･データのストアを実現する。 その内部を見ると、ファイルが複数のブロックに分割されることになり、それらのブロックが一連の DataNodes にストアされることがわかる。 NameNode は、ファイルとディレクトリに対して、opening、closing、renaming といったをファイル･システム名前空間に関する操作を実行する。 さらに、DataNodes に対するブロックのマッピングも決定する。 DataNodes は、ファイル･システムのクライアントからの、読み書きに関するリクエストの実現に対して責任を持つ。 DataNodes は、NameNode におけるインストラクションに基づいて、ブロックの作成、削除、模写も実行する。

NameNode と DataNode は、普及品であるマシン上で動作するようにデザインされたソフトウェア･ピースである。そのためのマシンは、一般的には GNU／Linux OS を実行する。 また、HDFS は Java 言語を使って構築されているため、Java をサポートする各種マシンで、NameNode や DataNode を実行できる。 きわめて移植性の高い Java 言語の使用により、広範囲におよぶマシン上に HDFS をディプロイできる。 一般的なディプロイメントにおいては、NameNode ソフトウェアだけを実行する専用マシンが用いられる。 クラスタ上の個々のマシンが、ひとつの DataNode ソフトウェア･インスタンスを実行する。 このアーキテクチャでは、同一マシン上におけるマルチ DataNodes の実行は妨げられないが、現実的なディプロイメントにおいて、それは稀なケースとなる。

クラスタにおける シングル NameNode の配置は、システムのアーキテクチャを大幅に簡素化する。 NameNode は、すべての HDFS メタ･データのための、仲介者とリポジトリとして機能する。 このシステムは、ユーザー･データが NameNode に絶対に還流しないように設計される。

 

Hadoop DFS _ Introduction
Hadoop DFS Architecture _1
Hadoop DFS Architecture_2
Hadoop DFS Architecture _3
Hadoop DFS Architecture _4
Hadoop DFS Architecture _5
Hadoop DFS Architecture _6
Hadoop DFS Architecture _7

サーバー保有台数ランキング

Who Has the Most Web Servers?

DataCenter Knowledge より
May 14th, 2009 : Rich Miller

Web サーバーの保有台数ランキングであり、Netcraft server count のレポートからの情報です。

• 1&1 Internet: 55,000 servers (company)
• OVH: 55,000 servers (company)
• Rackspace: 50,038 servers (company)
• The Planet: 48,500 servers (company)
• Akamai Technologies: 48,000 servers (company)
• SBC Communications: 29,193 servers (Netcraft)
• Verizon: 25,788 servers (Netcraft)
• Time Warner Cable: 24,817 servers (Netcraft)
• SoftLayer: 21,000 servers (company)
• AT&T: 20,268 servers (Netcraft)
• Peer1/ServerBeach: 10,277 servers (company)
• iWeb: 10,000 servers (company)

ただし、保有する Web サーバーを公表していない企業も、もちろんあります。オーバー50000台クラブのメンバーは、以下のとおりです。

• Google: 3年前の調査で、450,000 台を保有するとなっています。 最近では、コンテナ型のデータセンターを展開しており、さらなる上積みが、かなりの規模であるはずです。
• Microsoft: 2008年半ばの調査で、218,000 サーバー を保有するとされています。 また、新しいシカゴのデータセンターには、300,000 台のコンテナ型が導入されると言われています。
• Amazon: あまり、データセンターに関する情報が出てきませんが、2009年には Rackable 社から 8千6百万ドル 分のサーバーを調達したとされています。S3 には、400 億個のオブジェクトが、ストアされているとの情報があります。
• eBay: eBay と PayPal は 1億 6千万人のユーザーを抱え、系列の Skype には 4億 4千万人がいるとされています。 そのデータセンターには、 8.5 ペタ･バイト のデータがストアされているそうです。
• Yahoo: ほとんど情報が出てきていませんが、Google と Microsoft に次ぐ、三番手の規模と予測されています。
• GoDaddy: 最大規模のドメイン登録サイトで、3千 5百万のドメインを管理しています。
• HP/EDS: 180ヶ所のデータセンターに、380,000 万台のサーバーを保有とのことです。
• IBM: 情報がありませんが、オーバー50000台クラブのメンバーであることには、間違いないとのことです。
• Facebook: 同社の発表によると、 10,000 サーバー に過ぎないとのことですが、2008年4月の時点で、2億人のユーザーを抱え、400 億枚の写真を蓄積しているとのことです。