クラウドOS Azureの登場

2009年9月30日(水)
丸山 不二夫

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技術を利用していることも目を引きます。

昨年まで、20年間、北海道稚内に在住。元稚内北星学園大学学長。現在は、活動の拠点を東京に移して、様々のコミュニティ活動に参加している。早稲田大学客員教授。Cloud研究会代表。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています