Enterprise Watch
バックナンバー

Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第二回】

Azureの基盤「Windows Azure」

 前回は、Azureの概要を説明した。今回はAzureの基盤となるクラウド上のWindows OS「Windows Azure」に関して説明する。このWindows Azureには、Windows OSとして動作するためのコンピューティング環境、基本的なストレージサービス、クラウドOSとして動作するために必要な管理環境などが用意されている。


Windows Azureのコンピューティング環境

Windows Azureは、Azureの最下層で、Azureの基盤となっている。ここから、Windows Azureは、クラウドOSともいえる
 Windows Azureは、既存のWindowsプラットフォームをベースにしているため、Windows環境に慣れている開発者ならスムーズに移行できる、とMicrosoftは語っている。しかし、Windows Azureの詳細を見てみると、アーキテクチャそのものがWindowsとWindows Azureでは異なっており、開発者にとってハードルは存在している。つまり、社内のサーバーで動作させているアプリケーション(オンプレミス)を、そのままWindows Azureにアップすれば、クラウドで動作するわけではないことは理解しておいたほうがいい。

 Windows Azureは、Hyper-V Serverをベースとした仮想環境上にWindows Azureとして必要な機能が構築されている。Windows Server 2008がベースとはいえ、ファイルアクセスなど、さまざまな部分がWindows Azure独自のシステムになっている。

 現在提供されているAzureのCTP(PDC 2008後に公開されているモノ)で提供されている仮想環境は、1.5~1.7GHz相当のCPU、1.7GBのメモリ、Windows Server 2008 x64環境、とそれほど高速なサーバー環境ではない。このCTPで提供されている仮想環境が、Windows Azureのプログラミングの基本となる。


Windows Azure上で、ユーザーのアプリケーションが動作する。Windows Azureでは、基本的なストレージに関するサービス・管理などを提供している
Windows OSとWindows Azureの違い
現在提供されているCTPでは、このようなハードウェアスペックが、仮想サーバー一台に割り当てられている

 単体の仮想環境はそれほど速くはないので、構築するアプリケーションの設計をきちんと行い、複数のサーバーを連携して、パフォーマンスの最適化を図る必要がある。開発者は、仮想環境を複数追加することでサーバーのスケールアウトを行い、パフォーマンスをアップすることになる。また、スケールアウトにより大量のユーザーをさばいたり、大量のデータを処理するために、システム上のボトルネックも意識した設計を行う必要があるだろう。なお、Windows Azureは外部のWebサービスと連携するように設計されているため、オンプレミスに専用のサーバーを構築して、Windows Azureの処理を補助することもできる。

 つまり、Windows Azureは、Windows OSをベースとはしているが、クラウド向きに開発されたコンピューティング環境だといえる。よくできているのは、クラウド環境(Azure)とオンプレミス(社内)環境を混在して利用することができることだ。Webサービス(SOAP、Atom、Feed、RESTなど)をプログラミングインターフェイスとして、自社で運用しているサーバーと連携できる。このため、クラウドでは処理しきれないサービスは、オンプレミスのサーバーを利用するといった、現実的なシステムが構築できる。


Windows Azure上のプログラムは、ロールといわれている。現在、WebロールとWorkerロールの2種類がある。1つの仮想サーバーでは、1つのロールしか動作しない
 Windows Azureでは、1つの仮想環境上にWebロール、Workerロールというプログラムを動かすことになる。注意が必要なのは、1つの仮想環境で1つのロールしか動かせないという点。スケールアウトする場合は、それぞれのロールのインスタンスを増やすことで、スケールアウトする。

 Webロールは、IIS 7を搭載しており、インターネット経由のリクエストを処理することができる。プログラミングとしては、ASP.NETを利用することができる。

 Workerロールは、キューからリクエストを読み込み、処理をして、インターネットなどに結果を出力することができる。インターネットからの入力を直接Workerロールに引き渡すことはできない。

 Webロールは、HTTPリクエストに応じてプロセスが作成されるが、Workerロールはプロセスはずっと生成されており、キューのリクエストで処理が行われる。いわば、バッチジョブといったイメージだ。

 Webロールは、インターネットとの入力/出力をサポートしたプレゼンテーション層で、Workerロールはビジネスロジック層などのプログラミングを行うことになる。Webロールでは、HTMLを利用したWeb UIを構築することもできるし、クライアント側にSilverlightやFlashなどのRIAを構築するアプリケーションが入っていれば、SOAPやAtomなどのインターネットスタンダードのインターフェイスを利用して、クライアント側でより高度なUIを構築することもできる。


Webロールは、インターネットからのデータを受け取り、処理する。いわば、WebアプリケーションがASP.NETなどを使って構築できる
Workerロールは、インターネットからデータを受け取ることはできない。データは、Windows Azure内部のキューだけから受け取る。このロールは、UIを伴わないビジネスロジックのインプリメントに使われる

 Azure CTPでは、.NET Framework 3.5ベースのアプリケーションが動作できるようになっている。このため、C#、VB.NETなどの.NET Frameworkベースのプログラミング言語での開発が行える(開発環境としてもっとも充実しているのはC#)。3月に開催されたMIXでは、FastCGIをサポートしたことが表明された。これにより、PHPやRubyなどのプログラミング言語がAzure上で利用できるようになった。将来的には、C++などのアンマネージドコードをWindows Azureで動作させることも計画されている。そのほか、Java、Pythonなどのプログラミング言語を利用することも計画されている。このように、Windows AzureはMicrosoftのプラットフォームだけでなく、さまざまなオープンプラットフォームが利用できるように考えられている。

 Microsoftでは、プログラミングのモデリング化を進めており、スケールアウトすることでも、高いパフォーマンスを示すシステムが容易に設計できるように考えている。これらを支援するツールとして、Visual Studio 2010などが利用されていくだろう。


Windows Azureのストレージ

 Windows Azureには、サービスとしてデータベースのSQL ServerをベースとしたSQL Servicesが用意されている。しかし、Windows OSが利用するファイルI/Oのすべてをデータベースで置き換えることはできない。そのため、Windows Azure上には、ブロブ(Blob=Binary Large Object)、テーブル、キューの3つのストレージ方式が用意されている。Windows Azureストレージは、RESTやADO.NETといったプログラミングインターフェイスでアクセスできるので、開発者は使い慣れたAPIでプログラミングできる。

 Windows Azureストレージには、アカウントと256ビットのシークレットキー(HMAC-SHA256アルゴリズム)が用意されている。これを使って、ユーザー専用のWindows Azureストレージエリアにアクセスする。このため、ほかのユーザーが自分のストレージエリアに勝手にアクセスされるということもない。もちろん、シークレットキーは、ユーザーのリクエストにより、何度も変更できる。

 また、ブロブ、テーブル、キューといったAzureのストレージサービスには、エンドポイントと呼ばれるURLが個々に付与されている。このエンドポイントのURLとシークレットキーを組み合わせたモノをWebブラウザのアドレスバーに入力することで、Webブラウザから直接データを読み込むこともできる。例えば、ブロブにいれたJPEGの写真を、エンドポイントとシークレットキーを組み合わせたURLを入力することで、特殊なプログラムを必要とせずWebブラウザで直接表示できる。インターネットスタンダードを転送プロトコルとして利用しているため、できることといえる。


Windows Azureのストレージは、ブロブ、テーブル、キューの3つがある
ブロブ、テーブル、キューなどの用途
Windows Azureのストレージは、アカウントとシークレットキーを組み合わせてアクセスする。これにより、データのセキュリティが保たれている

ブロブは、コンテナにデータとして保存される。ブロブの最大データ量は50GB
・ブロブ

 ブロブは、大容量のバイナリファイルを保存する仕組みだ。例えば、写真やビデオなどの大容量のバイナリファイルを保存するときに利用する。現在のCTPでは、最大50GBの容量が用意されている。

 ブロブは、Windowsのファイルシステムのようにツリー構造によって構成されている。つまり、アカウント名がWindowsにおけるコンピュータ名にあたり、その下にコンテナ(いわゆるディレクトリ)があり、コンテナ内部に複数のブロブ(バイナリファイルの実体)が存在する。また、コンテナにはポリシーを設定できるため、アクセスできるユーザーを制限したり、書き込みを制限したりすることも可能だ。

 ブロブでは、大容量のビデオデータなども扱うことができる。ただ、インターネットでのデータ転送となるため、大容量のデータを一括して転送するには、エラーが起こる可能性が高い。そのため、大きなデータをブロック単位に分割して、転送することができる(エラー時のリトライ機能もある)。これにより、データ転送時のエラーを起こりにくくしている。また、データ転送をシリアルに行うのではなく、パラレルに実行するため、回線効率もアップしている。

 パラレルにデータ転送が行われるため、ブロック単位に分割されたブロブには、ブロックごとにIDが付与されている。このIDを使って、ばらばらに送られてきたブロブを受信側で並べ直す。また、同じブロックIDのデータが複数送信された場合は、最後に送信されたブロックを採用する。1つのブロックは、4MB単位。もし、ブロブをブロックに分割しない場合は、1つのブロブの最大データ容量は64MBとなる。Windows AzureのSDKをインストールしたVisual Studio 2008では、さまざまなライブラリが用意されているため、開発者はブロブの細かなコントロールを気にしなくても、ライブラリを使用するだけで簡単に開発できる。また、ブロブはデータ転送にRESTも利用できるので、非常に簡単にデータ転送が可能になっている。


ブロブの概念。アカウントの下にコンテナがあり、コンテナの下にブロブ本体がある。ブロブのデータが大きい場合は、ブロックに分割して格納する
ブロブのデータが大きいときには、ブロック分割を行って、アップロード/ダウンロードする
ブロブは、RESTなどのインターフェイスで取り扱える

テーブルは、いわゆる表形式のデータを扱う

テーブルの構造
・テーブル

 テーブルは、Excelのような表形式のデータ。ただし、データベースのようなリレーショナル構造は持たない。つまり、非リレーショナルなデータベースといえる。

 テーブルは、ロー(Rows)とカラム(Columns)で構成されている。このあたりも、Excelなどの表とほとんど変わらない。ただし、Excelのように、セルに計算式を入れて、動的にデータが変更するといったものではない。セルに入るデータは静的なモノだ。セルに入れられるデータとしては、文字列(64KBまで)、バイナリ(64KBまで)、Bool、日付・時間、GUID、Int、Int64、Doubleなどがサポートされている。

 テーブルは、カラムとしては256個のプロパティを持つ。さらに、カラムには、パーティションキー(Partition Key)とローキー(Row Key)という項目が必須となる。そのほか、ユーザーが必要なプロパティが自由に作成できる。

 テーブルには、さまざまなデータが保存できるため、パーティションキーをデータを取り出すときの検索キーとして利用している。また、ローキーは、パーティションキーを使って取り出したデータをさらに、区別するために利用している。これは、テーブルにはデータベースのようなクエリといった機能がないためだ。効率よくデータを取り出すには、テーブルを効率よく設計しておく必要があるだろう。スケーラビリティ自体は、パーティションに対するトラフィックをWindows Azureが監視していて、自動的にロードバランシングを行ってくれるので、開発者自身はそれほど気にしなくてもいい。

 データアクセスには、ADO.NETやLINQなどのAPIが使用できる。このため、Microsoftの開発環境のVisual Studioからは、非常に簡単にWindows Azureのテーブルを利用することができる。次バージョンでは、セカンダリインデックス、エンティティグループなどの機能が追加される予定だ。


テーブルは、エンティティとプロパティによってできている
プロパティが扱えるデータ形式
テーブルでは、パーティションキーを使ってクエリを行うことができる

キューの概要
・キュー

 キューは、メッセージングなどのデータ通信時に、非同期にデータを交換するためのメッセージ配信システムだ。

 キューは、Workerロールでのデータの受け渡しに利用される。Workerロールは、キューからの入力を受け取り、さまざまな処理を行い、Webロールに受け渡したり、インターネット上のクライアントに送信したりする。つまり、Workerロールは、バックグラウンドで動作するビジネスロジック自体といえる。キューは、このビジネスロジックにデータを受け渡すための仕組みだ。

 キューに入れられるメッセージの最大サイズは8KB。メッセージの最大数の上限はない。ただし、キュー自体はFIFO(First In、First Out)になっており、キューに入れられたメッセージ順に処理されていく。ただ、メッセージには、タイムアウト付きでの読み出し機能が用意されている。これは、読み出したメッセージの処理を既定時間以内にできなければ、再度メッセージをキューに戻して、ほかのサーバーで処理させるというものだ。これは、メッセージを処理しているWorkerロールがクラッシュなどしたりして、処理が止まった場合、ロールバックができないとこのメッセージが飛んでしまうことになるため、プロセスがクラッシュしたときなどのために、メッセージをキューに戻して再度別のサーバーで処理させるというものだ。

 タイムアウトは、既定値として30秒間、最大値は2時間となっている。タイムアウトをうまく使えば、プロセスがクラッシュしないまでも、パフォーマンスに問題がある場合やロジックに問題があってデッドロックしているときなどでも、再度処理を戻すことができる。


アカウントの下にキューがあり、その下に実際のメッセージがある キューのメッセージ読み出しと削除は、読み出し後、処理が終了してから削除される。もし、処理中にタイムアウトがくれば、再度キューから読み出され、処理される

Windows Azureの信頼度

 クラウドサービスといえば、サーバーの安定性や信頼度などが気になるだろう。Windows Azureでは、多数の物理サーバーを運用するため、ラックにあるサーバーにトラブルが起こることを前提にして、クラウドサービスが構築されている。

 このため、開発者が用意したWebロールやWorkerロールの仮想サーバーは、常にバックアップとして複数用意されている。これにより、ハードウェア障害によって、サービスが停止しないようにできている。

 バックアップで用意されているサーバーは、同じ物理サーバー上に用意されるのではなく、別のラックの物理サーバー上に確保されている。これにより、ラックごとシステムが停止したりしたときでも、きちんとバックアップされる。もちろん、ファブリックのモデルを記述することで、バックアップのサーバーを別のラックに用意するだけでなく、別のデータセンターなどに分けることもできるだろう。

 また、Windows Azureのストレージサービス自体も、3つのストレージに書き込まれることになる。これにより、ストレージにトラブルがあったときでも、ほかのストレージでバックアップすることができる。もちろん、このストレージも同じラック上に用意されるのではなく、別のラック、別のデータセンターに用意される。今回のMIXでは、米国にある2カ所のデータセンターにユーザーが開発したシステムを明示的に二重化して運用できるようになったことも発表されている。

 こういった仕組みにより、膨大な数のPCサーバーを使用しても、安定性があり、信頼度が高いクラウドサービスを提供する。Windows Azureが、ハードウェアが壊れるということを前提にシステムが構築されているというのは、非常に面白い。逆にいえば、個々のサーバーは壊れても、全体として、キチンとサービスが提供できるということだろう。これこそクラウドサービスの真骨頂といえると思う。





 Windows Azureのアーキテクチャを見ていくと、インターネットという不安定なネットワーク、仮想サーバーという非力なサーバーという組み合わせで構築されているのがわかる。このため、シングルサーバーでのパフォーマンスは、それほど期待できない。また、仮想サーバーを多数用意してスケールアウトしたとしても、個々のサーバーの性能を考えれば、劇的にパフォーマンスがアップするというモノでもない。

 例えば、膨大な計算を必要とするHPCなどやリアルタイムにデータを処理するようなアプリケーションには、クラウドサービスは向かない。

 しかし、それほど処理時間がシビアでないアプリケーションや、人がインタラクティブに操作するWebアプリケーションなどは、クラウドサービスで十分な性能を出せるだろう。よりインタラクティブ性が必要な部分は、SilverlightなどでクライアントPC側の性能を生かすUIを構築したり、サービス自体もアーキテクチャをキチンと考え、スケールアウトできるロールをキチンと設計していかなければならない。また、Windows Azureでは、オンプレミスのサーバーと連携してサービスを提供することができるので、クラウド上のWindows Azureで処理が遅かったり、データの安全性を考えるなら、オンプレミスのサーバーを利用するといった、クラウドとオンプレミスをうまく考えたシステムのデザインが必要になる。

 もちろん、社内で提供しているサービスがスパゲティボールのような雑な作り方になっていると、これをそのままクラウドに持っていくことはできない。また、膨大なサーバーを利用するクラウドでも、下手なシステムデザインをすると、あまりにも遅くて使いにくかったり、ストレージ部分にボトルネックができてしまうこともある。

 このようなことを考えていくと、やはりWindows Azureを前提として、SOAという概念をきちんと取り込んだサービスのデザインが重要になってくるだろう。


関連記事
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第一回】(2009/03/23)
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第三回】(2009/03/25)
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【第四回】(2009/03/26)
  ・ Microsoftの戦略的クラウド「Azure(アジュール)」を見る【最終回】(2009/03/27)


( 山本 雅史 )
2009/03/24 09:03

Enterprise Watch ホームページ
Copyright (c) 2009 Impress Watch Corporation, an Impress Group company. All rights reserved.