 |
|||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Microsoftの戦略的クラウド「Azure（アジュール）」を見る【第二回】 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Azureの基盤「Windows Azure」
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
前回は、Azureの概要を説明した。今回はAzureの基盤となるクラウド上のWindows OS「Windows Azure」に関して説明する。このWindows Azureには、Windows OSとして動作するためのコンピューティング環境、基本的なストレージサービス、クラウドOSとして動作するために必要な管理環境などが用意されている。 ■ 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は外部のWebサービスと連携するように設計されているため、オンプレミスに専用のサーバーを構築して、Windows Azureの処理を補助することもできる。 つまり、Windows Azureは、Windows OSをベースとはしているが、クラウド向きに開発されたコンピューティング環境だといえる。よくできているのは、クラウド環境（Azure）とオンプレミス（社内）環境を混在して利用することができることだ。Webサービス（SOAP、Atom、Feed、RESTなど）をプログラミングインターフェイスとして、自社で運用しているサーバーと連携できる。このため、クラウドでは処理しきれないサービスは、オンプレミスのサーバーを利用するといった、現実的なシステムが構築できる。
Webロールは、IIS 7を搭載しており、インターネット経由のリクエストを処理することができる。プログラミングとしては、ASP.NETを利用することができる。 Workerロールは、キューからリクエストを読み込み、処理をして、インターネットなどに結果を出力することができる。インターネットからの入力を直接Workerロールに引き渡すことはできない。 Webロールは、HTTPリクエストに応じてプロセスが作成されるが、Workerロールはプロセスはずっと生成されており、キューのリクエストで処理が行われる。いわば、バッチジョブといったイメージだ。 Webロールは、インターネットとの入力/出力をサポートしたプレゼンテーション層で、Workerロールはビジネスロジック層などのプログラミングを行うことになる。Webロールでは、HTMLを利用したWeb UIを構築することもできるし、クライアント側にSilverlightやFlashなどのRIAを構築するアプリケーションが入っていれば、SOAPやAtomなどのインターネットスタンダードのインターフェイスを利用して、クライアント側でより高度な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ブラウザで直接表示できる。インターネットスタンダードを転送プロトコルとして利用しているため、できることといえる。
ブロブは、大容量のバイナリファイルを保存する仕組みだ。例えば、写真やビデオなどの大容量のバイナリファイルを保存するときに利用する。現在のCTPでは、最大50GBの容量が用意されている。 ブロブは、Windowsのファイルシステムのようにツリー構造によって構成されている。つまり、アカウント名がWindowsにおけるコンピュータ名にあたり、その下にコンテナ（いわゆるディレクトリ）があり、コンテナ内部に複数のブロブ（バイナリファイルの実体）が存在する。また、コンテナにはポリシーを設定できるため、アクセスできるユーザーを制限したり、書き込みを制限したりすることも可能だ。 ブロブでは、大容量のビデオデータなども扱うことができる。ただ、インターネットでのデータ転送となるため、大容量のデータを一括して転送するには、エラーが起こる可能性が高い。そのため、大きなデータをブロック単位に分割して、転送することができる（エラー時のリトライ機能もある）。これにより、データ転送時のエラーを起こりにくくしている。また、データ転送をシリアルに行うのではなく、パラレルに実行するため、回線効率もアップしている。 パラレルにデータ転送が行われるため、ブロック単位に分割されたブロブには、ブロックごとにIDが付与されている。このIDを使って、ばらばらに送られてきたブロブを受信側で並べ直す。また、同じブロックIDのデータが複数送信された場合は、最後に送信されたブロックを採用する。1つのブロックは、4MB単位。もし、ブロブをブロックに分割しない場合は、1つのブロブの最大データ容量は64MBとなる。Windows AzureのSDKをインストールしたVisual Studio 2008では、さまざまなライブラリが用意されているため、開発者はブロブの細かなコントロールを気にしなくても、ライブラリを使用するだけで簡単に開発できる。また、ブロブはデータ転送に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）
（ 山本 雅史 ）
|
