Windows Azureエンタープライズアプリケーション開発技法 Windows Azureプラットフォームの主要構成要素 ―― 第2章　Windows Azureプラットフォーム概要　2.3.1／2.3.2 ―― 日本マイクロソフト株式会社 コンサルティングサービス統括本部 赤間 信幸 2011/11/28

Page1 Page2

本コーナーは、日経BP社発行の書籍『Windows Azureエンタープライズアプリケーション開発技法』の中から、特にInsider.NET読者に有用だと考えられる章や個所をInsider.NET編集部が選び、同社の許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分（例：「上の図」など）や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『Windows Azureエンタープライズアプリケーション開発技法』の詳細は「目次情報ページ」や日経BP社のサイトをご覧ください。

ご注意：本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。

■Windows Azure Platformの主要構成要素

　Windows Azure Platform上では様々な機能が提供されているが、実際にシステムを開発する場合には、それらの中から必要な部分のみを組み合わせて使うことになる。このため、各サービスの概要や位置づけを正しく掴むことが大切である。ここではまず代表的なサービスを重点的に解説し、その後、付加価値的なサービスについては簡単に触れることにする（表 2-3）。

表 2-3　Windows Azure Platformの代表的なサービス

　なお、本章では各サービスの詳細や細かい実装方法などについては深入りしない。まず大きなところとして、各サービスのコンセプトや要点を掴んでいただければ幸いである。

　まずはWindows Azure Platformの代表的なサービスである、以下の3つのサービスについて解説する（図 2-10）。

図 2-10 　Windows Azure Platformの代表的なサービス

　誤解を恐れず、非常に大ざっぱに例えてみると、これらのサービスは以下のようなものである。

• Windows Azureコンピュートサービス → 「Webサーバー」 （のようなもの）
• SQL Azureデータベースサービス → 「DBサーバー」 （のようなもの）
• Windows Azureストレージサービス → 「ファイル共有サーバー」 （のようなもの*1）

*1　ここでは話を簡単化するために「ファイル共有サーバー」と例えたが、実際のWindows Azureストレージは読み書きの方法が通常のファイル共有サーバーとは全く異なるため、ファイル共有サーバーとして使うことはできない。しかしながら、「巨大なデータを蓄積しておく目的で使う」という意味においては、ファイル共有サーバーに近い特性を持っているため、このように例えてみた次第である。

　もちろん、厳密な意味では必ずしも同じものというわけではないが、このような対応関係を覚えておくとシステムの設計時に役立つのではないかと思う。以下、順番に解説を加えていく。

●2.3.1　Windows Azureコンピュートサービス

　Windows Azureコンピュートサービスとは、カスタムアプリケーションのホスティングサービスである。OSとミドルウェアがプリインストールされたサーバーマシンが提供されており、そこにユーザーがアプリケーションを載せて動かすことができるようになっている*2（図 2-11）。

図 2-11　Windows Azureコンピュートサービス

*2　この図では分かりやすさを優先させて、各サーバーがあたかも物理マシンであるかのように書いているが、実際には仮想マシンである（後述）。

○A.　利用可能なサーバーの種類

　利用可能なサーバーマシンとしては、以下の3種類が用意されている（表 2-4）。

表 2-4　サーバーの種類（ロール）

　Windows Azureコンピュートサービスは、「OSやミドルがプリインストールされており、アプリをそこに転送してインターネット上で動作させられる」という点において、各種のコンシューマー向けUNIX/Linux系レンタルサーバーサービス（共用ホスティングサービス）に似ている。しかし決定的に異なるのが、各ユーザーのアプリケーションが仮想マシンレベルで分離されている、という点である（図 2-12）。共用ホスティングサービスは1つの物理筐体上に1つのOSが載り、それを複数のユーザーが共用する形を取るため、一台のサーバー上にホストできるユーザー数が多い。このため利用コストは安くなるが、業務目的での利用には適さないだろう。一方、Windows Azureコンピュートサービスでは仮想マシンによる分離が行われているため、一台のサーバー上にホストできるユーザー数は少な目である。しかし、各ユーザーのアプリケーションが仮想マシンレベルから分離されているため、隣のユーザーとのより堅牢な分離が実現されている*3。

図 2-12　共用ホスティングサービスとWindows Azureコンピュートサービスとの違い

*3　仮想マシンによる分離によって、隣のユーザーアプリが直接見えないのは当たり前だが、隣の仮想マシンには、ネットワーク経由でもアクセスすることができないように制御されている。具体的には、各仮想マシンがネットワーク通信を行う際に、ホストOSがネットワークパケットを監視しており、同一ユーザー（同一テナント）の仮想マシン間の通信でない限り（正確にはサービスモデルに定義された通信でない限り）、通信を認めないように制御している。これにより、Azure環境内の他のユーザーのマシンにアクセスすることができないようになっている。

○B.　実際の利用手順と内部の物理的な動作

　実際のWindows Azureコンピュートサービスの利用手順は、以下の通りである（図 2-13）。

• 起動する仮想マシンのベースとなるOSイメージ（サーバーロール）を選択する。
• アプリケーションをパッケージングし、ポータルサイトからアップロードする。
• このようにすると、ファブリックコントローラーと呼ばれる制御コンピューターが、データセンター内の空きリソースを自動的に見つけ、そこに仮想マシンを構築し、起動してくれる。

図 2-13　Windows Azureコンピュートサービスの物理的な動作イメージ

　すなわち、Windows Azureコンピュートサービスの実態は、「仮想マシン（VM）のイメージのコピーと、ユーザーアプリケーションの自動展開を行うシステムである」と説明することができる。このマシン割り当ての仕組みはプロビジョニング（Provisioning）と呼ばれており、これが全自動で行われる（＝運用担当者の人手を介さなくて済む）ために、Windows Azureコンピュートサービスは安価にサービスを提供することができるようになっている*4 *5。

*4　プロビジョニングを司っているシステムが「ファブリックコントローラー」と呼ばれるのはこのためである。「ファブリック（Fabric）」とは「織物」の意味であるが、Windows Azure コンピュートサービスでは、「空いている物理マシンを探してそこに仮想マシンのHDDイメージをコピーして起動し、1つのシステムを組み立て上げる」という作業を行うようになっている。これはまさに、織物を組み立て上げるような作業と言える。

*5　内部動作の観点から見た場合、ファブリックコントローラーはWindows Azureコンピュートサービスの心臓部にあたるものである。そういう意味で、Windows Azureコンピュートサービスの実態はこのファブリックコントローラーである、と理解しておくとよい。なお、マイクロソフトがWindows Azureを語る際に、「Windows AzureとはデータセンターのOS（基本制御システム）である」という言い方をすることがあるが、これは上記のファブリックコントローラーの動作（＝データセンター内のサーバーリソースの管理や自動割り当て、負荷平準化などを行ってくれる）を考えてみると非常に良い例えであることがわかる。

○C.　複数サーバーの一括展開

　Windows Azureコンピュートサービスでは、複数のサーバー群をまとめて1つのパッケージとして展開することもできる。先に述べたように、Windows AzureコンピュートサービスはPaaS型のサービスであり、「サービスモデル」と呼ばれる、標準化されたインフラモデルを持っている。このサービスモデルに従って構成されたサーバー群に載せるアプリケーションを1つのパッケージに束ね、まとめて展開することができるようになっている*6 *7（図 2-14）。

図 2-14　Windows Azureコンピュートサービスによる複数サーバーの一括配置

*6　展開されるのはサーバーマシンイメージだけではないことに注意。実際にはさらにそれに加えて外部通信ポートの設定や、サーバー間通信の許可、ロードバランサーの構成なども行われるようになっている。

*7　PaaS本来の理想論から言えば、コンピュートサービスのみならず、SQL AzureデータベースやWindows Auzreストレージサービス、AppFabricなどの設定もまとめてパッケージング・展開・配置できることが望ましいが、執筆時点ではそこまでの機能は提供されていない。

　このような仕組みにより、Windows Azureコンピュートサービスは容易なサーバー展開とシステム管理ができるようになっている。例えばWindows Azureコンピュートサービスでは、容易にサーバーの台数を増やしたり減らしたりすることができる（図 2-15）。このように、サーバー台数を簡単に増やしたり減らしたりできる特性を、一般に伸縮自在性（elasticity）と呼ぶ*8 *9。

図 2-15　サーバー台数の調整（Windows Azureポータルサイトから調整）

*8　特に、インターネットWebサイトでは、ピーク時のトラフィックと平常時のトラフィックに大きな違いがあるようなシステムが少なくない。例えば、株取引のWebサイトでは寄り付き直後、出前注文を受け付けるWebサイトでは夕方の時間帯にアクセスが集中するが、こうした繁忙時間帯以外のトラフィックは極端に少ない。従来、こうしたシステムでは、ピーク時のトラフィック上限に併せてサーバー台数を決定する、という設計を行っていたが、これではコストがかかりすぎてしまう。このため、その時点時点に見合ったリソースを用意すること、すなわちトラフィック量に併せて処理キャパシティを動的に増減させる（＝繁忙期や繁忙時間帯のみ、仮想マシンの数を増やして処理キャパシティを一時的に増やす）ことでコストを抑えるのがとても重要になる。

*9　なお、現時点ではWindows Azureコンピュートサービスはサーバーの負荷に応じた自動的なサーバー台数調整機能（自動スケーリング、auto scaling）を備えていない。ここはAzureの弱点としてよく非難される点だが、Windows Azureでは、性能データを取得するためのAPIと、サーバー台数を動的に変更するためのAPIがある。このため、これらの間をつなぐアプリケーションを記述することで、自動スケーリングを実現することはできる。ただし、そもそも自動スケーリングには一長一短があることに注意が必要である。例えばシステムがDoS攻撃を受けた場合、トラフィックに併せて自動的にサーバー台数を増やすようにしていると、さらなるDoS攻撃を助長することに繋がりかねない。また、その負荷増大が一時的なものなのか、恒久的なものなのかによっても、またアプリケーションがWebアプリケーションなのかバッチアプリケーションなのかなどによっても、取るべきスケーリング方針は異なってくる。「特定の閾値を超えたらサーバー台数を増やす」といった単純な方法だと、必ずしもうまくいかないことがあるため注意が必要である。

○D.　サーバー操作に関する注意点

　前述の伸縮自在性は、クラウドコンピューティングならではの便利な機能であるが、この恩恵に預かるためには守らなければならない重要なルールが1つある。それは、「個々のサーバーマシン（サーバーインスタンス）を個別に手作業で設定してはならない」というルールである（図 2-16）。

　例えば、従来のサーバー管理では、リモートデスクトップでサーバーマシンに入り、サーバーマシンの設定を1つずつ行う、といったことを行っていたかもしれない。しかし、Windows Azureコンピュートサービスではこのようなことを行ってはならない。なぜなら、このようなことを行ってしまうと、仮想マシンを簡単に増減させることができなくなってしまうためである*10。

図 2-16　各サーバーインスタンスのカスタマイズに関する注意点

*10　ここでは説明を簡単にするため、サーバーの増減を例にとって解説したが、サーバー台数を増減しない場合であってもこの原則は守る必要がある。例えばWindows Azureでは、サーバー障害が発生した場合には自動的に仮想マシンを再構築し、フェールオーバーが行われるが、このようなことが起こると、仮想マシンの状態は展開された直後の状態に戻ってしまう。すなわち、リモートデスクトップを使って加えたサーバー設定は失われてしまうためである。

　確かに現在のWindows Azureコンピュートサービスでは、各サーバーにリモートデスクトップで接続することができるようになっているが、これはデバッグやトラブルシュートを容易にする目的で用意されたものである。サーバーを設定したりカスタマイズしたりするために用意されている機能ではないことに注意する必要がある。

　また同様の理由により、業務データやログデータは、基本的にローカルHDDではなく、SQL AzureデータベースサービスやWindows Azureストレージサービスに書き込まなければならない（図 2-17）。サーバーインスタンスを減らした場合（すなわち仮想マシンを削除した場合）や、ハードウェア障害により仮想マシンが別の物理サーバー上に移動された場合、ローカルHDDのデータが消失するためである*11。

図 2-17　データの保存場所

*11　なお、一時的な書き込み先としてローカルHDDを使うことは可能である。例えば、例外ログやトレースログなどをローカルHDDにいったん書き込んでおき、バックグラウンドタスクで定期的にWindows Azureストレージサービスに転送して保存する、といったことをよく行う。

○E.　VMロールサーバー

　コンピュートサービスで利用できる3種類のサーバーのうち、標準的に利用されるのはWebロールサーバーおよびWorkerロールサーバーである。これらのサーバーを使う場合、仮想マシンのイメージファイルの準備や保守はマイクロソフトが行ってくれるため、開発者はサーバー上に載せるアプリケーションの開発にのみ注力すれば済む。また、昇格特権と呼ばれる機能を利用すると、サーバーに対して追加ソフトウェアをインストールしたり、設定をカスタマイズしたりすることもできるため、ほとんどのケースでは、WebロールやWorkerロールのサーバーを使えば十分に事足りる。しかし特殊なケース、例えば特殊なソフトウェアのインストールを必要とするような場合には*12、VMロールと呼ばれるサーバーを使うこともできるようになっている。

*12　代表的なケースとしては、ランタイムやミドルウェアの追加インストールが必要で、かつそれが非常に長時間を要したり、ライセンスキー入力のためにUI操作を必要とするような場合である。

　VMロールサーバーとは、簡単にいえば、自力で仮想マシンのイメージを用意する方法である。図 2-18に示すように、まずオンプレミス環境でWindows Server 2008 R2 x64版をインストールした仮想マシンを作成し、そこに必要なソフトウェアやアプリケーションをインストールする。そして、作成した仮想マシンのイメージをAzure環境にアップロードし、これを展開して利用する。このようにすると、WebロールやWorkerロールでは実現できない、特殊なサーバーマシンを実現することができるようになる。

図 2-18　VMロールサーバーの利用方法

　VMロールサーバーは、確かに「仮想マシンのイメージを自由にカスタマイズできる」という意味においては、IaaS的な機能とも解釈できる。しかし、VMロールサーバーをIaaSであると説明するのは必ずしも正しくない。これは次のような理由による。

　このVMロールサーバーは、前述した「サービスモデル」の中に組み込んで使う必要がある。このため、VMロールサーバーを使う場合であっても、ロードバランサーを自動構成させることができるし、サーバーも自在に増減させることができる。すなわち、インフラ面から見ると、VMロールサーバーも、基本的にはWebロールサーバーやWorkerロールサーバーと同じく、「サービスモデル」のメリットをそのまま享受することができる（もちろん同時に、サービスモデルによる制約も受けることになる）。これは、インフラの標準モデル（サービスモデル）を含まないIaaSとは一線を画するものである。

　VMロールとは、PaaS型サービスであるWindows Azureコンピュートサービスにおいて、仮想マシンを自由にカスタマイズできる機能である、というのが最も正しい理解である*13。

*13　VMロールに関しては、「なんでもできる」という過度な期待感があるようにも思われるが、例えば以下のような制限がある。 Windows Server 2008 R2 x64のみサポート（Windows Server 2000, 2003, 2008（非R2）などはすべて非サポート）、 サービスモデルによる通信制約などを受ける（例えばUDP通信ができない）、 RDBMSなどをインストールして使うことができない（ノードの物理障害などによってローカルHDD内のデータが消失するため）。

　以上がWindows Azureコンピュートサービスの概要である。引き続き、SQL Azureデータベースサービスについて解説する。

INDEX
	［書籍転載］Windows Azureエンタープライズアプリケーション開発技法
	Windows Azureプラットフォームの主要構成要素
	1．Windows Azureコンピュート・サービス
	2．SQL Azureデータベース・サービス

「Windows Azureエンタープライズアプリケーション開発技法」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）