[技術解説]

2010年5月18日(火)関田 文雄

リスト

Windows AzureはWindows Server 2008がベースになっているので、既存の資産を最大限に生かすことができる。ただし、Windows Azureはいくつかの点でWindows Serverとは異なる。例えば、Active DirectoryやRights Management Services、ターミナルサービス、ファイル共有など自社運用のWindows Serverシステムで必ず用いられるような機能の多くが、Windows Azureにはない。その代わりWindows Azureはアプリケーションをスケーラブルに実行する環境やストレージ、自動管理の機能を備えている。

Windows AzureとWindows Serverはどこが違うのか。大きく3つの点について解説しよう。

リソース管理の自動化や可用性が高いストレージ

第1はリソース管理である。Windows Azureはサーバーを追加したりストレージを拡張するといったリソース管理をすべて自動化している。一方、Windows Serverではハードウェアの変更はユーザーの責任である。

2番めはアプリケーションを実行する環境だ。Windows ServerがWebサーバーやNTサービスなどの実行環境を用意しているのに対し、Windows Azureでは、Webアプリケーションなどを実行するために必要な環境を仮想インスタンス（イメージファイル）として用意する。この仮想インスタンスのことを「ロール（Role）」と呼ぶ。

3つめはストレージである。Windows Azureでは、Windows Serverのようにハードディスク上に構築されたファイルシステムではなく、スケーラビリティと可用性を備えたクラウド専用のストレージサービスを提供する。

2種類のロールで多階層アプリも構築

Windows Azureは、Windows Server 2008とハイパーバイザー「Hyper-V」をベースに構築した仮想環境で動作する（図3-1）。実際には、ハイパーバイザー上の仮想マシンに1個、2個、4個、8個のCPUコアやメモリーが割り当てられ、その上で仮想インスタンス、すなわちWindows Azureの各種ロールを実行している。

図3-1　Windows Azure Platformにおける仮想化と管理の概要。
Windows Azureはハイパーバイザー上のゲストOSとして稼働する

Windows Azureには「Webロール」と「Workerロール」の2種類のロールがある。Webロールはインターネット経由のリクエストを処理するのはもちろんのこと、IISを備えWebサイトやWebサービスを実行する（表3-1）。これに対してWorkerロールは、ストレージサービス上のキューやTCP経由のリクエストをバックエンドプロセスとして実行する。シンプルなアーキテクチャではあるが、これら2種類のロールだけで単純なWebアプリケーションから多階層の複雑なアプリケーションまで構築可能だ。

なお、これらのロールはマイクロソフトが用意したもので、その構成をユーザーが変更することはできない。しかし、カスタマイズ可能な「VMロール」も将来提供する予定だ。現時点でロールに制約を設けたのは、アプリケーションのスケーラビリティを確保するため。Windows Azure Platformを使ってシステムを運営するユーザー側の管理効率を高める狙いもある。

構成変更の自動処理や耐障害性能にも配慮

マイクロソフトのデータセンターでは管理用ソフト「Azure Fabric Controller」が動いている。これはWindows Serverのカーネルの役割の一部を担うもので、Windows Azure Platformを構成するデータセンター内のコンピュータやスイッチ、ロードバランサのリソース管理、仮想マシンの稼働監視、アプリケーション展開を可能な限り自動化している。

ユーザーがWindows Azure Platformの管理ポータルからリクエストを出すと、Azure Fabric Controllerがリクエスト内容に応じてハードウェアやアプリケーションの展開、ソフトウェアの構成変更などを実行する。

例えば、稼働中のロールの仮想マシン数を変更すると、Azure Fabric Controllerは(1)「ノード（サーバーのコア）をアロケート」、(2)「ロールをコピー」、(3)「アプリケーションイメージをコピー」、(4)「ロールを起動」の処理を自動で実行する。

Azure Fabric Controllerはすべての仮想マシンと通信しながら稼働状態を監視することで、システム全体の耐障害性能を高めている。ある仮想マシンに問題が生じると、最初に仮想マシンの再起動を試みる。再起動できない場合は、すぐさま上記の処理を実行してサービスを再開する。

ユーザーから複数の仮想マシンのリクエストがあった場合は、部分的なハードウェア障害がシステム全体の停止につながらないように論理的なドメインを構成し、仮想マシンを分散配置する。当然だが、サービスを停止せずにアプリケーションを更新することも可能だ。

既存資産を無駄にしないストレージサービス

Windows Azureのストレージはデータを複数ノードに分散して持つため、論理的には容量の制限がない（システム的には100TBが上限）。また、Windows Azure側で複製を3つ持つので、1ノードが壊れてもデータを守れる。

ストレージへは、URIによってアクセスする「REST」を用いる。つまり、.NETのみならず、Javaをはじめとする他の開発環境からアクセスできる。しかもクラウドだけでなく自社運用環境からもアクセス可能だ。ただし、セキュリティ上の考慮から、すべてのリクエストが256ビットシークレットキーで署名されていなければならない。

Windows Azureのストレージには、階層構造を持つファイルストレージ「Blob」と、データ容量や処理速度を高めやすいKVS（キーバリューストア）「Table」、Workerロールとの通信に使う「Queue」、NTFSに相当する「Drive」がある。いずれもWindows Azureのために新たに開発したもので、クラウドに最適化されたストレージだ。Driveについては2010年2月に実施した機能拡張により、既存アプリケーションからの移行を容易にしている。