Windows Azure Platform速習シリーズ Windows Azureのローンチに向けて知っておくべき4つのこと Windows Azure Community　市川 龍太 2009/10/28

Page1 Page2 Page3 Page4

　マイクロソフトのクラウド戦略の中核をなすクラウドOS「Windows Azure」と、そのサービス・プラットフォームである「Azure Service Platform」。同社がこれらを発表したのは2008年10月に米ロサンゼルスで開催された「PDC（Professional Developer Conference）2008」なので、本稿執筆時点でほぼ1年がたとうとしている。

　その間、Windows Azureに先行してサービスを開始していたAmazon EC2／S3、Google App Engine、Force.comがもたらしたクラウド旋風をある人は対岸の火事として、そしてまたある人は歯がゆい思いで見ていたことだろう。しかしそのような状況も2009年11月17日から開催される「PDC 2009」において終わりを告げ、Windows Azureはいよいよローンチ（＝正式スタート）を迎えることになる。

　そこで本稿では、Windows Azureの現在の状況について整理するとともに、ローンチに向けて最低限これだけ知っておけば大丈夫という以下の4つのポイントについて解説していこうと思う。

• Windows Azureとは何かを知る
• Windows Azureを取り巻く環境（現状）を知る
• Windows Azureの制約について知る
• Windows Azureの効率的な勉強方法を知る

　なお、これらすべての内容を詳細に解説していくと、かなりのボリュームになってしまうため、本稿では要点のみを押さえるにとどめ、それ以上の詳細な内容についてはリソースの紹介という形を取らせていただくことにする。それではまず、Windows Azureとはいったい何なのかについて見ていこう。

Window Azureとは何かを知る

　Windows Azureを一言でいい表すなら、

「マイクロソフトのクラウド向けオペレーティング・システム」（以下OS）

ということになる。そしてWindows Azureとともに複数のクラウド・サービス（SQL Azure、.NET Servicesなど）も提供され、これらを総称して「Windows Azure Platform」（以前まではAzure Service Platform）と呼称する。以下にWindows Azure Platformの概念図を示す。

Windows Azure Platformの概念図

※PDC 2008でアナウンスされたLive ServicesとSharepoint Services、Dynamics CRM Servicesについては、明確な発表はないものの、Windows Azure Platformの公式ページから記載が削除されている。

　以降では、Windows Azure Platformを構成する主要な構成要素について解説していく。本稿では、ローンチ時点で提供開始が予定されているWindows Azureと.NET Services、SQL Azureを取り上げる。

●Windows Azure

　Windows Azureは、OSといってもWindows 7やWindows Server 2008のように1台のサーバにインストールされる物理的なOSというわけではなく、実際はデータセンターに存在する複数のサーバの上で動作する一種のサービスという形をとっている。データセンターに配置されている個々のサーバにインストールされているOSはWindows Server 2008にほかならない。

　Windows Azureは大きく以下の2つのサービスによって構成されている。

• Windows Azureコンピュート・サービス
• Windows Azureストレージ・サービス

　コンピュート・サービスは、Windows Azure上でアプリケーションを動作させるためのサービスであり、内部的にはさらにWebロールとWorkerロールに領域が分けられている。このうち、Webロールは従来のWebアプリケーションが動作する領域であり、WorkerロールはWindowsサービスのようなUIを持たないバックエンドで動作するアプリケーション用の領域である。これらは1ロールあたり1つの仮想マシンが割り当てられ、サーバ仮想化機能「Hyper-V」によってホストされる。

　ストレージ・サービスは、文字どおりアプリケーションのデータを格納するためのサービスであり、ブロブ（BLOB：Binary Large Object）、テーブル、キューの3つの方式が存在する。これら3つの方式の特徴について下表に示す。

ストレージ方式	機能概要
ブロブ	大容量のバイナリ・データの保存に適している。最大容量は50GBytes
テーブル	Key-Value形式の構造化ストレージ。レコード（Entity）は複数のサーバに分散して配置することができる
キュー	主にロール間のメッセージのやり取りに使用される
Windows Azureストレージ・サービスのストレージ方式の一覧

　ここで1つ注意してもらいたいのは、ストレージ・サービスのテーブルは従来のSQL Serverのようなリレーショナル・データベース（以下RDBMS）でいうところのテーブルとは構造が異なり、リレーショナルな構造を持たないKey-Value方式を採用している。

　Key-Value方式は、データをキーと値の組み合わせとして保存するため、複数のサーバに簡単に分散できるというメリットがある。その半面、例えば親テーブルに関連のあるほかのテーブルにリレーションシップを張るといった概念がなく、SQL文も利用できず、JOIN句により結合を行うといったこともできない。

　それでは、ストレージ・サービスがなぜこのような非リレーショナルな構造になっているのか。それは、クラウド・コンピューティングにおけるストレージが、データを1カ所に集約するのではなく、複数の場所に分散して保持することで、スケーラビリティを飛躍的に向上させるという考え方をベースにしているからだ。その場合、シンプルな構造のKey-Value方式の方がよりスケールしやすいという理由である。現にグーグルが提供する分散データ・ストアであるBigTableでも同様のKey-Value方式を採用しており、アマゾンもAmazon SimpleDBというKey-Value方式のデータベースを採用している。

　ストレージ・サービスへのアクセスには、ADO.NET Data Servicesのクライアント・ライブラリ（LINQも利用可能）や、ストレージ・サービスが提供するREST（Representational State Transfer）APIを直接使用する方法がある。

【コラム】クラウド・コンピューティング向きのCAP定理とBASE特性

従来のリレーショナル・データベースではACID特性（＝「原子性：Atomic」「一貫性：Consistent」「独立性：Isolated」「持続性：Durable」の4特性）が前提であることはいうまでもないが、Key-Value方式のような分散してデータを保持するモデルでは、特にこのうちの一貫性を維持することが難しい。例えば、カリフォルニア大学バークレイ校のエリック・ブリューア教授は、分散型のデータ保持モデルでは一貫性（Consistency）、可用性（Availability）、分散性（Partition）の中で、同時に実現できるのはこの内の2つだけであるというCAP定理を発表している。 　そのため、クラウドの世界ではBASE特性という新しい概念が注目されている。BASEとは、「Basically Available、Soft state、Eventually consistent」（基本的にいつも利用可能で、ソフト・ステートで（＝一時的に一貫性のない状態となり）、最終的に一貫性を持つ）の頭文字を表しており、これはつまり「一貫性をある程度あきらめる代わりに、可用性とスケーラビリティ（＝分散性）を優先する」という考え方である。 　一見すると乱暴に見えるかもしれないが、クラウドの特性を考えると非常に合理的な考え方ともいえるのである。なお、BASE特性やCAP定理については早稲田大学大学院の丸山先生の資料で分かりやすく解説されているので、興味があるなら読んでみるとよいだろう。 解説資料「Cloudの技術的特性について」

●Windows Azureファブリック

　クラウド・コンピューティングでは、運用側がハードウェアの物理構成やCPU／メモリなどのリソースを特に意識することなくアプリケーションを動作させられるのが特徴である。Windows Azureでは、仮想ロード・バランサや仮想スイッチ、仮想サーバなどを含めた基盤部分をWindows Azureファブリックという論理的な単位ごとに構成し、これをWindows Azureファブリック・コントローラが管理するという仕組みになっている。

　ファブリック（＝Fabric）は「織物」という意味であり、日本人にはあまりなじみのない言葉であるが、例えばSAN（Storage Area Network）などにおいては、ファイバ・チャネル・スイッチなどで接続されたネットワーク構成を「SANファブリック」と呼称する。ファブリックとは、そういったインフラ構成のことを指すと考えればよいだろう。そしてこのWindows Azureファブリックの上でコンピュート・サービスやストレージ・サービスが稼働するのである。

　ちなみに本稿執筆時点ではまだ使用できないが、将来的にはWindows Azureファブリックの構成をXML形式のモデルとして定義し、これをファブリック・コントローラが解釈することで自動的に構成を変更することが可能になるといわれている。

　以下にWindows Azureファブリックの概念図を示す。

Windows Azureファブリックの概念図

●SQL Azure

　SQL Azureは、一言でいえば「クラウド上で動作するSQL Server」ということになるのだが、正式版では「SQL Azure Database」と「データ同期」の2つの機能が提供される予定である。これら2つの機能の特徴について下表に示す。

機能名	機能概要
SQL Azure Database	クラウド上でSQL Serverと同等のRDBMS機能を提供する
データ同期	オンプレミス（＝社内）とSQL Azure Database（＝クラウド）を同期させる機能を提供する
SQL Azureの提供機能一覧

　SQL Azure Database（以前まではSQL Data Servicesと呼称）は、従来のSQL Serverに近いデータベース機能を提供する。この機能はPDC 2008時点では、ストレージ・サービスのKey-Value方式に似たデータ・モデルを採用していた（その方式の中で一部のリレーショナルな機能を提供する予定だった）。しかし「既存のオンプレミス・アプリケーションを、あまり手を加えることなくクラウドへ移行したい」という開発側の意向を採用する形で、従来のSQL Serverに近い、リレーショナルな構造化ストレージ方式を採用することになったという経緯がある。

　しかし、本来クラウド・コンピューティングは、膨大な数の既存リソース（サーバやストレージ）を活用することを前提にしている。そのため、スケーラビリティを向上させる場合は、スケール・アップよりもスケール・アウトの方がそのメリットを生かしやすい。しかしSQL Serverのようなリレーショナル・データベースは、その構造ゆえにスケール・アップによるスケーラビリティの向上という道を歩んできたため、ここに矛盾が生じていることも事実である。

　それゆえ、上述したGoogleのBigTableは依然としてKey-Value方式のデータベースのみを提供し、「リレーショナルなデータベースについては提供する予定はない」と公言している。このように、クラウド提供者の間でも見解が分かれている。

　スケーラビリティの解決策として、データベース自体をスケール・アウトするのではなく、データをメモリ上にキャッシュして複数のサーバに分散配置させる分散メモリ・キャッシュ技術が注目されており、マイクロソフトは同様の技術としてVelocity（Velocityはコード名で現在はCTP段階）を公開している。公式にはSQL AzureでVelocityが使用可能になるとの発表はされていないが、開発は進められているようなので注目しておいてもよいだろう。

●.NET Services

　筆者がWindows Azure Platformの中で今後最も重要になってくると考えているサービスが.NET Servicesである。.NET Servicesは、比較的エンタープライズ向けのサービスであり、マイクロソフトのBizTalk Serverに近い機能を提供する。正式版では「サービス・バス」「アクセス・コントロール」の2つの機能が提供される予定である。

　これら2つの機能の特徴について下の表に示す。ちなみにPDC 2008では、これらのほかにワークフロー機能もアナウンスされていたのだが、どうやらローンチ時点では提供されないようである（次期.NET Frameworkリリース時に提供予定）。

機能名	機能概要
サービス・バス	オンプレミスのサービスをクラウドに公開するための仕組みを提供する
アクセス・コントロール	クレーム（申告）ベースの認証によってアクセス制御を行うための仕組みを提供する
.NET Servicesの提供機能一覧

　サービス・バスは、クラウドやオンプレミスにあるWebサービスの探索やルーティング、メッセージの中継などの機能を提供する。

　具体的には、Webサービスの提供側がサービス・バスにサービスのエンドポイントを登録しておけば、利用側はサービス・バスを経由してそのWebサービスを見つけ出すことができ、WCF（Windows Communication Foundation）を介してメッセージをやり取りできるようになるのである。ここで特徴的なのは、企業内のファイアウォールやNAT（Network Address Translation）の設定を変更することなく、サービスを公開できるという点である。下はその概念図だ。

.NET Servicesが提供するサービス・バス機能の概念図

　アクセス・コントロールは、Webサービスを利用するユーザーの認証や、Webサービス間でシングル・サインオンを実現するための機能を提供する。認証を行う場合は、Windows Live IDのほかにも、フェデレーション・サービスを利用することでオンプレミスのActive Directoryと連携させることが可能であり、ほかにもCardSpaceを使用したクレーム・ベースの認証方式にも対応している。

　先ほど.NET Servicesが重要になってくると書いたが、今後既存システムのクラウド化が進んだとしても、すべてのシステムがクラウド上に移行するわけではなく、いずれはクラウドとオンプレミスが共存していくような環境になると筆者は考えている。そうなるとクラウド上のシステムとオンプレミスのシステムを連携させなければならないケースが多くなってくるため、.NET Servicesのようなシステム連携や認証のための機能を提供するサービスが、より重要性を増してくるというのがその理由である。

　続いて次のページでは、Windows Azureを取り巻く環境（現状）を説明する。

INDEX
	Windows Azure Platform速習シリーズ
	Windows Azureのローンチに向けて知っておくべき4つのこと
	1．Window Azure とは何かを知る
	2．Windows Azureを取り巻く環境(現状)を知る
	3．Windows Azureの制約を知る
	4．Windows Azureの効率的な勉強方法を知る

「Windows Azure Platform速習シリーズ」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）