Windows Azure Storage の新機能

5月28日に、Windows Azure Storage の新機能をリリース

偶然にも、msdn Forum でやり取りしていた Brad Calder さんから、Windows Azure Blog にポストがありました －－－ A.C.

Entity Group Transactions for Windows Azure Table – 同一のテーブルおよびパーティション内にストアされたエンティティをまたいで、トランザクションを実行するようになった。それにより、アプリケーションからストレージ･システムへのシングル･バッチ･リクエストで、マルチ･エンティティに対するマルチ Create/Update/Delete 操作が可能となる。ただし、バッチ処理の対象となるエンティティが、同一のパーティション･キーを持ち、同一のテーブル内に配置されていることが条件となる。 この機能によりアプリケーションは、（a）システムに対するシングル･リクエストにおいてInsert/Update/Delete バッチを操作（バッチごとに 100エンティティまで）し、（b）多数のエンティティをまたいだ atomic 操作を実行する。

Copy Blob for Windows Azure Blob – 同一のストレージ･アカウントを用いたアプリケーションによる、ソース Blob からディスティネーション Blob へのコピーに対応。それにより、Blob 全体のコピーおよび、メタデータ、プロパティ、コミット済みの block list もコピー。この機能によりアプリケーションは、（a）コンテナ間での Blob のコピーと、（b）コンテナ間での Blob の移動、そして、（c）Blob のリネームを実現。

Get Get Block List for Windows Azure Blob – コミットされたブロックのリストと同様に、コミット前のブロックのリストを取り出す機能を GetBlockList に加えた。それにより、クラッシュしたブロックの再送が可能に。

• Committed Block List – 複数のブロックに関するリストであり、前提となる Blob に対する PutBlockList の一部として、コミットに成功している。GetBlob の実行において、読み込みが可能な Blob を構成するブロックのリストになる。
• Uncommitted Block List – Blob に対して PutBlock を用いることで、アップロードされている状態のブロックのリスト。それらのブロックは、コミット前の暫定的なものである。アプリケーションから、このリストを読み出すことのメリットは、クライアントがクラッシュした場合に、継続的なアップロードを容易に実施できることである。たとえば、ブロックをアップロードするクライアントがクラッシュし、リスタートした場合に、すでにアップロードされているコミット前のブロック･リストを抽出する。 また、リストが廃棄されている場合には、アップロードを継続する。

このほかにも、バージョニングのための機能などが追加されています。 詳しくは、↓ で ど～ぞ

http://blogs.msdn.com/windowsazure/archive/2009/05/28/new-windows-azure-storage-features-may-2009.aspx

 

Bing と Steve Wozniak

Bing-Test-Drive

Channel 9 で Bing-Test-Drive が 見れますよ～～～

普段とはチョッと違うノリで、派手目のオネエさんがインタビュアーで少々やかましいですが、Bing のセマンティック･サーチ (?) が紹介されています。 30分くらいのビデオですが、お時間があったらお勧めです。

それと、Bing に関する Steve Wozniak のインタビューも面白いですよ。 かなりコーフンしているようで、インタビューアーの “落ち着いてください” という感じが笑えます。

 

 

この盛り上がりを見ると、Bing の登場が待ちどおしくなります。 6月 3日でしたっけ？？？    それにしても、久々の Woz さんでした。

 

 

Cosmos in msdn Forum

msdn Forum で Cosmos について

msdn Forum で Cosmos などについて尋ねてみましたら、Brad Calder さんが親切に答えてくれました。”Azure XStore I believe is a reference to Windows Azure Storage” なんだけど、詳細は話せないので、PDC のセッションを見てほしいとのことでした。

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

Agile Cat Thursday, May 28, 2009 11:10 PM

Hi Brad, thank you for your reply.
According to Mihai Budiu’s another PPT,,,

• DryadLINQ and Scope compete with Sawzall, Pig and Hive.
• Dryad competes with Map-Reduce and Hadoop.
• Cosmos, Azure and SQL Server compete with GFS, BigTable, HDFS and S3.

Please find his those figures at below:
http://agilecat.wordpress.com/2009/05/28/dryadlinq/
In addition, there is Azure XStore.
If you have additional info, please let me know.

Thanks,
-A.C.

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

Brad CalderMSFT, ModeratorThursday, May 28, 2009 11:56 PM

Azure XStore I believe is a reference to Windows Azure Storage.
At this time, the only public information we have disclosed about Windows Azure Storage is in the following talk (there are a few slides at the end of the talk about durability, availability and scalability):

http://channel9.msdn.com/pdc2008/ES04/

The storage components have been built to provide a durable, scalable and highly available storage system for the Cloud, to provide Azure Tables, Blobs and Queues.    We make heavy use of replication, partitioning and load balancing of your data to make sure we can meet the traffic needs for your application’s data.
Thanks,
Brad

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

Brad さんが伝えたいのは、このあたりかなぁと、、、

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

よかったら、msdn の What’s Cosmos スレで、ご質問を ど～ぞ。

Azure Core Scenario _1

コア･シナリオ_1 ： スケーラブルな Web アプリケーションの作成

以前に紹介したように、David Chappell さんが Introducing Windows Azure というタイトルの新しいホワイトペーパーを提供しています。 今年の 1月に、TechDays で配布されたホワイトペーパーの続編にあたるもので、Fabric の機能と、アプリケーション･シナリオについて説明されています。4 回に分けて、それらのシナリオ部分の抄訳を掲載していきます。

なお、このホワイトペーパーは、MIX 09 にタイミングを合わせて公開されています。 つまり、Relational SDS へのシフトを前提に記述されていると捉えることができます。Relational SDS はそれとして、Azure におけるスケールアウトの戦略を読み取ることができるでしょう。

 

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

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

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

インターネット･アクセスが可能な Web アプリケーションについて、その作成を望む組織は多いはずだ。今日における一般的な選択は、組織内のデータセンターもしくはホスターに配置されたアプリケーションを動作させることである。 しかし、Windows Azure のようなクラウド･プラットフォームが、多くの場合における最適な選択枝となる。

たとえば、多数のユーザーを同時に取り扱うアプリケーションが必要とされる場合には、そのための処理を明確にサポートするように設計されたプラットフォームを基盤とすることで、本質的な解決がもたらされる。Windows Azure に備えられた、アプリケーションとデータをスケールアウトしていく機能を用いることで、これまでの多くの Web テクノロジーと比較して、さらに大きな負荷を処理できるようになる。さらに、アプリケーションにおける負荷が、連続した低負荷の状態から、不定期にピークを迎える状況についても検討すべきだ。たとえば、オンラインの発券サイトや、ホットなトピックを配信するニュース･ビデオなどが、このパターンを示すことになる。言うまでもなく、どちらのサイトも、特定の時間帯で利用されることが多い。従来からのデータセンターにおいて、この種類のアプリケーションを運用するためには、余裕を持ってピークに対応するマシンを手元に置かなければならない。しかし、そのシステムの大部分が、通常では利用されないことになってしまう。それに替えて、Windows Azure を基盤としたアプリケーション構築では、必要とされるときにだけ、使用するインスタンス数を拡張し、ピークが去った後にはインスタンス数を縮小することが可能となる。 Windows Azure における課金が、使用ベースであるため、使用されない大量のマシンを保持するよりも、費用は安くなるだろう。

Windows Azure 上でスケーラブルな Web アプリケーションを作成するには、Web ロールとテーブルを利用する。Figure 6 で、その様子をシンプルに図示する。

Figure 6: A scalable Web application can use Web role instances and tables.

ここで示される例では、ブラウザがクライアントになる。そして、ASP.NET などの Web テクノロジーを用いて、アプリケーション･ロジックが実装されるだろう。 それにより、RESTful もしくは、WCF を使用した SOAP ベースの Web サービスを公開する、スケーラブルな Web アプリケーションの作成が可能になる。どちらの場合においても、実行されるアプリケーション･インスタンス数がデベロッパーにより明示され、また、それに対応する数の VM が、Windows Azure ファブリック･コントローラーにより作成される。 前述のとおり、ファブリック･コントローラーからのモニタリングにより、要求されたインスタンス数が常に利用可能であることが確認される。なお、このアプリケーションが使用するデータス･トレージは、膨大なデータ量の処理をスケールアウトする、Windows Azure Storage となる。

Hadoop DFS _ Introduction

 

 

Hadoop DFS Architecture

このホワイトペーパーは、Apache のサイトからダウンロードしたものであり、HDFS（Hadoop Distributed File System）のアーキテクチャについて説明するものです。 4月の末から、7回に分けてポストしてきましたが、ようやく最後までたどり着きましたので、順番に読めるように整理しました。

以下の目次から個別のチャプタを参照することも可能ですし、右のカテゴリ ”Hadoop WP” から連続ものとして参照することも可能です。

DryadLINQ や、Cosmos、Scope などについて考えるときの指標として、Hadoop は意味のある対象だと思います。 ご利用ください。— A.C.

 

＜目次＞ーーーーーーーーーーーーーーーーーーーー

Introduction _1

Assumptions and Goals

Hardware Failure
Streaming Data Access 
Large Data Sets 
Simple Coherency Model 
“Moving Computation is Cheaper than Moving Data” 
Portability Across Heterogeneous Hardware and Software Platforms

NameNode and DataNodes _2

The File System Namespace _3

Data Replication

Replica Placement: The First Baby Steps 
Replica Selection 
Safemode

The Persistence of File System Metadata _4

The Communication Protocols _5

Robustness

Data Disk Failure, Heartbeats and Re-Replication 
Cluster Rebalancing 
Data Integrity 
Metadata Disk Failure 
Snapshots

Data Organization _6

Data Blocks 
Staging 
Replication Pipelining

Accessibility _7

FS Shell 
DFSAdmin 
Browser Interface

Space Reclamation

File Deletes and Undeletes 
Decrease Replication Factor

References

DryadLINQ と Cosmos

Cluster Computing with DryadLINQ

Mihai Budiu
Microsoft Research, Silicon Valley
Cloud computing: Infrastructure, Services, and Applications
UC Berkeley, March 4 2009

nsharp さんに教えてもらった DryadLINQ を探してみたら、こんなのが見つかりました。Microsoft Research と UC Berkeley でやっているみたいです。この図を見る限り、MapReduce と Hadoop に対抗するものと捉えてよい感じですね。

以下の図では、Dryad の下に4つのファイル・システムを統合しているように受け取れます。

Ray Ozzie が、JP モルガンを相手に Cosmos に言及したということは、GO なのでしょうね。。。。

Azure Core Scenario _2

コア･シナリオ_2 ： 並列処理アプリケーションの作成

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

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

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

 

CREATING A PARALLEL PROCESSING APPLICATION

スケーラブルな Web アプリケーションは有用であるが、Windows Azure の持つ意味は、それだけではない。 並列処理アプリケーションによる膨大な計算能力を、時として必要とする組織について考えてみよう。 グラフィックの特殊効果や、製薬会社における新薬開発、銀行における金融モデリングなど、たくさんのケースが挙げられる。 この、稀に生じるニーズを充たすために、大規模なクラスタ･マシンを維持することも可能だが、それは高価なものになる。  Windows Azure は必要に応じて、それらのリソースを提供し、オンデマンドのスーパー･コンピュータのような利用形態を実現する。

この種類のアプリケーションを開発するためには、Worker ロールを利用することになる。 それが唯一の選択枝というわけではないが、一般的な平行処理のアプリケーションでは、大規模なバイナリ･データ･セットを用いるケースが多い。 Windows Azure では、そのことを Blob の使用と表現する。 Figure 7 が示すのは、この種類のアプリケーションが機能するための、シンプルな方式である。

Figure 7: A parallel processing application might use a Web role instance,
many Worker role instances, queues, and blobs.

このシナリオでは、それぞれの Blob データを用いるWorker ロール･インスタンスが、同時に実行することで並列処理を達成していく。インスタンスの実行時間について、Windows Azure が関与することがないため、それぞれのインスタンスは任意の作業量を実行できる。 そして、この アプリケーションとインタラクトするユーザーは、単一の Web ロール･インスタンスに依存することになる。 そのためのインターフェイスを介して、ユーザーは実行されるインスタンス数や、それらの開始と終了などについて決定し、その結果を得ることになる。 Web ロール･インスタンスと Web ロール･インスタンスを結ぶ通信については、Windows Azure のストレージ･キューに依存することになる。

さらに、それらのキューに対して、オンプレミス･アプリケーションからダイレクトにアクセスすることも可能となる。 Windows Azure 上で実行される Web ロール･インスタンスに依存するのではなく、ユーザーはオンプレミス･アプリケーションを介して、Worker ロール･インスタンスとインタラクトする。 その様子を、Figure 8 に示す。

Figure 8: A parallel processing application can communicate
with an on-premises application through queues.

この例においても、多数の Worker ロール･インスタンスが、キューを介して外の世界と相互作用しながら同時に実行されることで、前述のように並列処理が達成されていく。 ただし、この処理においては、オンプレミス･アプリケーションからキューに対して、リクエストがダイレクトに入力される。 このようなシナリオでは、オンプレミス･アプリケーションが、Windows Azure での並列処理に依存していることに、ユーザーは気づかないかもしれない。

クラウド･ビギナーのためのサゼッション

Microsoft’s Beginner’s Guide To Cloud Computing

Infromation Week より
Posted by John Foley @ 11:18:AM | May,20, 2009

http://www.informationweek.com/cloud-computing/blog/archives/2009/05/microsofts_five.html?catid=cloud-computing

Microsoft VP の CIO Ron Markezich から、クラウド･ビギナーのためのサゼッション。

1: あなたの会社の IT アーキテクチャにフィットするクラウド･サービスが、どのようなものであり、どこになるのか、それを調べなさい ーーー それは、IT 部門が最初にクラウド･サービスを利用するときに重要なポイントであり、複数のプロバイダーと契約するときには、さらに重要になる。

2: クラウド･サービスを取り入れるために、あなたの会社を変化させなさい ーーー 会社の調達と法務を取り込んだかたちで、エンド･ユーザーの準備を整える。クラウド･サービスは、従来からのアウトソーシングとは異なる。すべての顧客に対応するために、たとえば、カスタマイズなどが制限される可能性がある。

3: ID 管理システムに注意しなさい ーーー ユーザー･アクセスや、セキュリティ、オンプレミスとの統合などで、最新のクリーンな ID管理システムが必要とされる。

4: 軽いアプリケーションを選びなさい ーーー大半の企業は、クラウドへの移行を徐々に進めるため、そのスタート･ポイントが重要になる。

5: クラウド･プロバイダーを慎重に選びなさい ーーーサービスを継続する能力や、エンタープライズのノウハウ、規模の提供などを、吟味する必要がある。

ーーー

MS の宣伝は省いてしまいましたが、ためになることが、シンプルに書かれているのではないでしょうか？ ーーー A.C.

 

Azure Core Scenario _3

コア･シナリオ_3 ： バック･グラウンド･プロセスを用いた Web アプリケーションの作成

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

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

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

 

 

Creating a Scalable Web Application with Background Processing

おそらく、今日における大多数のアプリケーションが、ブラウザ･インターフェイスを提供していると思われる。 ブラウザ･リクエストを受け付けて応答する以外には、何もしないアプリケーションは有用であるが、いくつかの厄介な事柄も残される。 リクエスト／レスポンス部分から独立したバック･グラウンド処理を、Web アクセスに対応するソフトウェアから開始するケースとしては、たくさんの状況が考えられる。

例として、ビデオ共有の Web アプリケーションについて考えてみよう。 そのようなアプリケーションは、多数のユーザーによるブラウザ･リクエストを、同時に受け入れる必要がある。 いくつかのリクエストは、新しいビデオをアップロードするためのものだろう。そして、それぞれのビデオは処理され、後のアクセスのためにストアされなければならない。この処理が完了するまで、ユーザーを待たせることに意味はないだろう。 その代わりに、対象となるアプリケーションのブラウザ･リクエストを受け付けるパートは、その作業を実行するバックグラウンド･タスクの開始できるようになるべきだ。

Windows Azure の Web ロールと Worker ロールを組み合わせることで、このシナリオに取り組むことができる。Figure 9 が示すのは、この種類のアプリケーションが動作する様子である。

 Figure 9: A scalable Web application with background processing might use all of Windows Azure’s capabilities.

このアプリケーションでは、以前に説明したスケーラブルな Web アプリケーションのように、いくつかの Web ロール･インスタンスを用いて、ユーザー･リクエストを処理していく。 そして、多数のユーザーを同時にサポートするために、情報をテーブルにストアすることになる。 バックグラウンド･プロセスに関しては、キューを介して Worker ロール･インスタンスにタスクが受け渡される。 この例では、Worker インスタンスにより Blobデータに取り組んでいるが、他のアプローチを用いることも可能である。

この例で示されるのは、Windows Azure が公開している、Web ロール･インスタンスや、Worker ロール･インスタンス、ブロブ、テーブル、キューといった、すべての基本的な機能を、アプリケーションから利用する方式である。 すべてのアプリケーションが、これらすべてを必要とするわけではないが、それらを利用することで、このように複雑なシナリオを本質的にサポートできる。

Hadoop DFS Architecture_1

Introduction

System（HDFS）は、普及品であるハードウェア上で稼動するように設計された、分散型ファイル･システムである。 このファイル･システムは、既存の分散型ファイル･システムと数多くの類似性を持っている。 しかし、他の分散型ファイル･システムに対して、きわめて重要な相違点もある。 HDFS は高度なフォールト･トレランス性を持ちながら、低価格なハードウェア上に実装できるようにデザインされている。 また、アプリケーション･データに対する高度なスループット･アクセスを提供し、大規模なデータ･セットを持つアプリケーションに適している。 さらに、ファイル･システム･データへのストリーミング･アクセスを実現するために、いくつかの POSIX 要件を緩和している。 HDFS は元々、Apache Nutch Web サーチ・エンジン･プロジェクトのための、インフラストラクチャとして構築された。そして、Apache Hadoop コア･プロジェクトの一部となっている。 プロジェクトの URL は http://hadoop.apache.org/core/ である。

Assumptions and Goals

Hardware Failure

ハードウェアにおける障害は、例外的なものではなく、一般的なものであると捉えるべきだ。HDFS インスタンスは、何百あるいは何千というサーバー･マシンで構成されることもあり、それぞれのマシンが、このファイル･システム･データの一部をストアすることになる。 膨大な数のコンポーネントが存在し、それぞれのコンポーネントが障害について些末とは言えない可能性を持つという事実は、HDFS におけるコンポーネントの中には、機能していないものも含まれることを指す。 したがって、欠陥の発見および、そこからの迅速で自動化されたリカバリは、HDFS のコアとなるアーキテクチャ上のゴールとなる。

Streaming Data Access

HDFS 上で稼動するアプリケーションは、データ･セットに対するストリーミング･アクセスを必要とする。 それらのアプリケーションは一般的に、多目的なファイル･システム上で実行される、汎用的なアプリケーションではない。 つまり、HDFS のデザインは、ユーザーとの対話型よりも、バッチ処理のために定義されている。そのため、データ･アクセスにおける遅延を低減するというより、データ･アクセスにおけるスループットを高めることに注力されている。 POSIX が課している数多くの厳格な要件は、HDFS を対象とするアプリケーションにとっては、不要なものとなる。したがって、いくつかの重要な領域における POSIX セマンティクスは、データのスループット･レートを高めるものに置き換えられている。

Large Data Sets

HDFS 上で実行するアプリケーションは、大規模なデータセットを持つ。 HDFS 上の一般的なファイルは、テラバイトあるいはギガバイトというサイズになる。 したがって、大容量ファイルをサポートするように、HDFS は調整されている。 そして、シングル･クラスタ内の何百というノードに対して、高度なデータ集約を実現するための、帯域幅とスケールを提供するはずである。 つまり、シングル･インスタンス内で、何千万というファイルをサポートするはずである。

Simple Coherency Model

HDFS アプリケーションは、ファイルの対する write-once-read-many アクセス･モデルを必要とする。一度、作成され、記述され、クローズされたファイルを、変更する必要がないことが前提となる。 この仮定は、データの一貫性に関する問題を単純化し、高いスループットによるデータ･アクセスを可能にする。Map/Reduce アプリケーションや、Webクローラー･アプリケーションは、このモデルと完全に適合する。ファイルに対する追記をサポートする、将来における計画がある。

“Moving Computation is Cheaper than Moving Data”

アプリケーションが要求する計算は、その対象となるデータの近くで実行されるときに効率的になる。とりわけ、対象となるデータセットのサイズが大きなときに、その傾向は顕著になる。 つまり、ネットワークに対する負荷が最小となり、システムの全体的なスループットが向上する。アプリケーションが実行される場所にデータを移動するよりも、データの近くで計算を実行するほうが、大半のケースで効率がよいという仮定がある。 HDFS が提供するインターフェイスにより、データのある場所の近くに、アプリケーション自身が移動される。

Portability Across Heterogeneous Hardware and Software Platforms

あるプラットフォームから、別のプラットフォームへ向けた、容易な移行を実現するように HDFS はデザインされている。 大規模なアプリケーション･セットのための、プラットフォームの選択として、この機能は広範囲におよぶ HDFS に適用される。

 

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