クラウドOS Azureの登場
AzureでのWebアプリケーションの実装
Windows Azureのwebアプリケーションの実装は、基本的にMulti-Tierの考えに基づいています。
ここでのWeb Role、Worker Roleは、前ページ図1の3層モデルでのWeb Server層、Business層に対応するものですが、その2つの層は切り離され、それぞれがデータベースを含むStorage Serviceに直接結びついています。
Azureでは、ユーザーが簡単にシステムのパラメータを変えるだけで、Web RoleもWorker Roleも、それぞれ複数個のインスタンスをデプロイすることができ、ニーズに応じてScale-outできます。
このことは、Windows Azureでのwebアプリケーション実装の最も重要な特徴の一つです。
複数のWeb Roleからのメッセージは、共通のキューに送られ、それを複数のWorker Roleが読みだす形になっています。Web Roleが一つ、Worker Roleが一つのシステムでは、こうしたQueuの介在はオーバーヘッドが高いように見えるかもしれません。
実は、このようにWeb RoleとWorker Roleとを直接結合させず、間にキューを置いて疎結合にすることが、Wen Roleがm個、Worker Roleがn個と、任意のm、n個にScale-outするシステムでは、非常に合理的な選択になります(図2-1参照)。
クラウドOSとしてのAzureの特徴
Azureは、クラウドOSとして登場しました。Googleもクラウドからのサービスを提供していますし、Amazonのサービスを利用すればAmazonのクラウド上のサービスを構築できます。
それでは、それらのクラウド・システムとAzureではどこが違うのでしょうか?
ここでは、Service Model、Fabric Controller、Azure Storageという3つの要素に注目して、クラウドOSとしてのAzureの特徴を見ていきたいと思います。
■Service Model
クラウドOSとしてのWindows Azureの第1の特徴は、Azureではクラウド上の任意のサービス管理がハードウエアの構成を含めて、自動化されていることです。Azureの利用者は、クラウド上で走るアプリケーションのコードとともに、サービスをどのように構成・管理するのかのルールを定義します。
クラウドの利用者がクラウドに与えるサービスの定義やそれが従うルールの集まりを、Azureでは「Service Model」と呼んでいます。これは、Azureにとって非常に重要な概念です。
人手が必要なのは、このService Modelとアプリケーションのコードを与えるところまでで、その後は、システムはService Modelを解釈して、自動的に物理的なハードウエアのレベルでシステムを構成し、その上にアプリケーションのコードをデプロイします。
デプロイされたアプリケーションが動き始めると、システムはアプリケーションの実行状況を監視し、サービスを管理します(図2-2参照)。
Windows Azureで標準的に推奨されているWebアプリケーションの模式図が図2-3で、この摸式図に対応したService Modelの定義が図2-4です。
■Fabric Controller
クラウドOSとしてのWindows Azureの第2の特徴は、あるサービスの実行環境をホスティングするために、クラウドのリソースの一部を切り出し、その内部の構成を自由に変化させる能力が備わっていることです。
クラウドは、たくさんの人がさまざまのタイプのアプリケーションを同時に実行するMulti-Tenant環境です。膨大な数のサーバーから構成されていますが、特定ユーザーの、特定アプリケーションのために、特定のサーバー群が割り当てられて、アプリケーションの実行環境として機能しなければなりません。
こうした、特定の用途のために関連付けられたクラウドのリソースを「Fabric」と呼びます。「織物」のイメージですね。
Azureは、いわば「素材」であるクラウド上の複数の物理サーバーを、アプリケーションの実行環境である「Fabric」に織り上げるのです。この機能を「Fabric Controller」が担っています。Azureの心臓部です。
先に見たService Modelは、Fabric Controllerに渡され、Fabric Controllerはそれに基づいてクラウド内のリソースをFabricに織り上げるのです。こうして、アプリケーションの実行が始まります。
ここでは、織り上げられたFabricは、自社内やデータセンター内のサーバー群とは異なり、一時的なものであることに注意しましょう。
あるアプリケーションの実行が終われば、Fabricはほどかれて、働いていたサーバーはもとの素材に戻ります。そして、その一部は必要に応じて、また別のFabricを形成します。
■Windows Azure Storage
クラウドOSとしてのWindows Azureの第3の特徴は、クラウドOSそのものに、ScalableでAvailableな大規模なクラウド・ストレージ・システムが組み込まれていることです。Windows Azure Storageがそれです。
Windows Azure Storageは、クラウド内でデータの永続性を担い、大きなデータを格納するBlobと、Key/Value型のデータベースであるTableと、サービス間のメッセージングを担うQueueの3つの構成要素からなっています。
Azureのサービス利用者は、Blob、Table、Queueのいずれにも自由にアクセスできます。次ページの図3をご参照ください。
他社クラウドでの永続性の担い手として、GoogleにはGFSとBigTableがあり、AmazonにはS3とSimpleDBがあります。このように、クラウドによって永続性の担い手の構成は異なっています。
クラウドOSの中で、永続性の担い手をどのように構成すべきか、デファクトの標準は、まだ形成されていないと思います。
こうした違いの一方で、BigTableとSimpleDBとWindows Azure Tableは、いずれも、リレーショナル・データベースではなく、Key/Value型のデータストアであるという共通点があるのは興味深いことです。
SimpleDBとAzure Storage Tableが、ともに、P2P起源のDHT技術を利用していることも目を引きます。