Part 2. Windows Azure Platform 概要 その2


その 1 のエントリからの続きです。(エントリが長すぎてポストできなかったため、分割しています。)

[① Windows Azure コンピュートサービス]

Windows Azure コンピュートサービスとは、カスタムアプリケーションのホスティングサービスです。OS とミドルウェアがプリインストールされたマシンが提供されますので、そこにカスタムアプリケーションを乗せて実行する、という形になります。利用可能なサーバタイプとして、以下の 2 種類が用意されています。

  • Web Role サーバ : .NET Framework と IIS がインストールされた Web サーバタイプのサーバ
  • Worker Role サーバ : .NET Framework のみがインストールされたバッチアプリケーション用のサーバ

image

実際のシステムでは、この 2 種類のサーバを組み合わせて、ひとつのシステムを構成します。例えば、Web アプリケーションと Web  サービスとバッチアプリケーションから構成されるシステムは、上記の 2 タイプのサーバを組み合わせて、以下のように組み上げることができます。

image

※ (注意) 上記の図では各サーバがあたかも物理マシンであるかのように書かれていますが、実際にはデータセンタ内では Hyper-V を使った仮想マシン(VM, Virtual Machine)として配置されます。

※ (参考) Worker Role サーバは、もともとバッチアプリケーション動作用のサーバを想定して開発されたために上述のような書き方をしました。しかし現在では、ポートをあけることによって、インターネット上から直接 TCP/IP 通信を受け付けることができるようになっているため、このタイプのサーバは比較的汎用性の高いサーバとして使うことができます。例えば、バッチアプリケーションに WCF ランタイムをホストさせれば、このサーバはアプリケーションサーバ化して使える、ということになります。

さて、Windows Azure コンピュートサービスは、「OS やミドルがプリインストールされており、アプリをそこに転送してインターネット上で動作させられる」という点において、各種のコンシューマ向け Unix/Linux 系レンタルサーバ(共用ホスティングサービス)に似ています。しかし決定的に異なるのが、各ユーザのアプリケーションが仮想マシンレベルで分離されている、という点です。

image

実際に Windows Azure コンピュートサービスを利用する場合には、以下の手順で利用します。

  • 起動する仮想マシンのベースとなる OS イメージを選択する。
    (※ 現在は Web Role サーバと Worker Role サーバの 2 種類のみが利用可能。)
  • そこに、パッケージ化されたアプリケーションをアップロードして動作させる。

Part 1. のエントリの FAQ の項で解説したように、このアプリケーション展開は、ファブリックコントローラと呼ばれるシステムにより行われます。こちらにも図を再掲しますが、Windows Azure コンピュートサービスの実態は、要するに仮想マシン(VM)のイメージのコピーと、アプリケーションを自動展開するシステムです。展開された各仮想マシンは、CPU やメモリとバインドされて動作する(通常は 1 インスタンスあたり 1 CPU がバインドされる)ため、サービスレベルの保障がしやすい形で動作することになります。

image

※ (参考) この割り当ての仕組みをプロビジョニング(Provisioning)と呼ぶのですが、プロビジョニングを司っているシステムがなぜ「ファブリックコントローラ」と呼ばれるのかも、この仕組みを知っているとわかりやすいと思います。「ファブリック(Fabric)」とは「織物」という意味なのですが、Windows Azure コンピュートサービスでは、「空いている物理マシンを探してそこに VM イメージのコピーを行い、Web Role サーバや Worker Role サーバなどを起動し、ひとつのシステムを組み立て上げる」という作業を行います。これはまさに、織物を組み立て上げるような作業と言えるでしょう。

なお、Windows Azure コンピュートサービスに関して真っ先に知っておくべき点として、ユーザが各マシン(仮想マシン)に直接デスクトップログオンして操作することができない、ということがあります。一般的な Unix/Linux 系のコンシューマ向けホスティングサービス(レンタルサーバ)では、

  • FTP を使って、1 つずつファイルをアップロードしたり、書き換えたりすることができる。
  • リモートシェルを使って、ファイルを読み書きしたりすることができる。

といったことが可能ですが、これらは Windows Azure コンピュートサービスでは一切できません。理由は様々にあるのでしょうが、一番大きな理由は、VM インスタンス数を簡単に増減できるようにするため、でしょう。一般的な Unix/Linux 系のコンシューマ向けホスティングサービスでは、1 台の Web サーバを複数のユーザが共有する、という形を取ります。このため、複数の Web サーバに負荷分散させるといったことはまったくできません。しかし、Windows Azure コンピュートサービスでは、各マシンにログインしたり、各マシンを個別にいじったりすることができないかわりに、以下のようなことができます。

  • システムの処理キャパシティを上げたくなったら、VM インスタンス数を増やす。
  • システムの処理キャパシティを下げたくなったら、VM インスタンス数を減らす。

特に、大規模トランザクションを処理するようなオンラインシステムの場合には、ピーク時のトラフィックと平常時のトラフィックに大きな違いがあるようなシステムが少なくありません。このようなシステムでは、従来ではピーク時のトラフィックに併せてサーバ台数を決定する、という設計を行っていましたが、これではお金がかかりすぎます。このため、その時点時点に見合ったリソースを用意すること、すなわちトラフィック量に併せて処理キャパシティを動的に増減させる(=繁忙期や繁忙時間帯のみ、仮想マシンの数を増やして処理キャパシティを一時的に増やす)ことでコストを抑えることがとても重要になります。このようなユーティリティコンピューティングを簡単に実現できるように設計されているのが、Windows Azure コンピュートサービスです。

※ (参考) これは私個人の感想なのですが、最初にこの仮想マシン割り当ての仕組みを見たときには、「なんて乱暴なシステムなんだ;;」と思ったのが正直なところです。というのも、オンプレミス型の Windows Server (IIS)の場合には、1 つの OS 上に複数のアプリケーションを配置する際、様々な配置オプションを提供していました(Web アプリケーション化による分離、アプリケーションプール/ワーカプロセスによる分離、CPU とワーカプロセスのバインド、Hyper-V、などなど)。ところが、Windows Azure コンピュートサービスは、「1 個の Web アプリケーションには 1 個の OS、1 個のワーカプロセス、1 個の CPU を割り当てる」(※ 厳密には VM サイズが指定できるのですが)、という極めて割り切られた設計がなされています。この結果、例えばスケーラビリティを向上させようと思った場合、オンプレミス型では非常に多くのオプション(スケールアップ、スケールアウト、プロセス数増加、スレッド数増加、etc.)が存在するのですが、Windows Azure コンピュートサービスでは、基本的に仮想マシンのインスタンス数を増加させるというオプションしか存在しませんこの割り切り設計は非常に乱暴ですが、半面、極めて単純なスケーラビリティ調整システムが実現できるというメリットがあり、なるほどそう考えると極めてよく出来たシステムだなぁと思いました。(スケーラビリティに限らず、いろんなところにこの割り切り設計の良さが表れていますので、考えてみるとよいと思います。)

[② SQL Azure データベースサービス]

さて、Web アプリケーションの多くは RDBMS を利用しますが、Windows Azure Platform データセンタの場合には、SQL Azure データベースサービスと呼ばれる RDBMS を利用することができます。

image

※ (注意) SQL Azure データベースサービスで利用されるマシン群は、Windows Azure コンピュートサービスで使われるマシン群とは別物です。イメージとしては、同一データセンタ内の別のマシングループを使っている、と考えるとよいでしょう。(実際のところはどうなっているのかは私も知りませんが....) Windows Azure コンピュートサービスのインフラ上に、SQL Azure データベースサービスが乗っているわけではないので、ご注意ください。

(細かい違いを言い出せばキリがないですが、ざっくり言えば)SQL Azure データベースサービスは、物理的には、オンプレミス版の SQL Server 2008 に対して、いくつかのカスタマイズと制限事項を加えることによって作られたものです。このため、以下のような特徴があります。

  • 通常のオンプレミス型の ASP.NET Web アプリケーションと同様に、ADO.NET を使って SQL Azure データベースにアクセスすることができる
  • SQL Server Management Studio から、Azure データセンタ内にある SQL Azure データベースサービスにつないで、データベースを管理することができる。(※ 現時点ではツールに一部制限あり)

非常に面白いのは、データベースアプリケーションの開発スタイルが従来の方式とほとんど変わらないという点です。例えばオンプレミス型の SQL Server に接続する場合やファイルアタッチデータベースを使う場合は、

  • Server=sqlsvr2008;Initial Catalog=pubs;User Id=sa;Password=xxxxxxxx;Trusted_Connection=false;
  • Server=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\pubs.mdf;Integrated Security=True;User Instance=True

といった接続文字列を使います。これに対して、SQL Azure を利用する場合には、これを

  • Server=tcp:mbkz90u87g.database.windows.net;Database=pubs;User ID=nakama@mbkz90u87g;Password=xxxxxxxx;Trusted_Connection=False

といった接続文字列に変更します。たったこれだけの作業で、SQL Azure データベースにアクセスすることができます。ですから、コンソールアプリケーションから SQL Azure データベースサービス上に作成した pubs データベースにアクセスするためには、以下のようなコードを使うだけで OK です。従来のコードとほとんど変わりがないことがわかるかと思います。

   1: SqlConnection sqlcon = new SqlConnection(
   2:     "Server=tcp:mbkz90u87g.database.windows.net;Database=pubs;
   3:      User ID=nakama@mbkz90u87g;Password=xxxxxxxx;Trusted_Connection=False;");
   4: SqlDataAdapter sqlda = new SqlDataAdapter("SELECT * FROM authors", sqlcon);
   5: DataSet ds = new DataSet();
   6: sqlda.Fill(ds, "authors");
   7: Console.WriteLine(ds.GetXml());

通常の業務アプリケーション開発の場合には、まずファイルアタッチデータベースを使って開発を進めておき、運用環境に移行するタイミングになったら、接続文字列を上記のような SQL Azure データベースサービス用のものに変更する、という形にすればよいでしょう。

※ (注意) 実際に SQL Azure データベースサービスにアクセスするためには、SQL Azure に対して TCP/IP 接続ができなければなりません。このため、① SQL Azure データベースサービス側のファイアウォール設定を変更する② (イントラネットからアクセスしたい場合には)社内のファイアウォールを超えられるように設定をしたりツールをインストールしたりする、という作業が必要になります。自宅などで検証作業を行う場合には②の点は問題にならないでしょうが、多くの企業では、社内から社外に対する直接の TCP/IP 通信を認めていません。このため、みなさんの会社の中(イントラネット)から SQL Azure データベースサービスを使いたい場合には、何らかの対処が必要になることが多いです。

さて、SQL Azure データベースサービスに関してまず知っておくべきポイントとしては、以下の 2 つがあります。

  • 1 アカウント(1 インスタンス)あたりの容量上限が比較的厳しい。
  • データが 3 台のマシンに複製されており、99.9% のサービス可用性が保障されている。

まず、1 つ目のポイントに関してですが、ユーザは 1 つのアカウント(SQL Server でいうところのインスタンスに対応)内に複数のデータベースを作成できますが、その最大容量は Business Edition でも 10GB となっています。このため、データ量が多いシステムの場合には、以下のような対処が必要になります。

  • 直近取り扱うデータのみを SQL Azure 上に置き、履歴データなどはオンプレミスの SQL Server 上に移すようにする。
  • 取り扱うデータを分割し(例:顧客 ID 1,000 人ごとにグループ化し)、別々の SQL Azure データベースで取り扱う。(=アプリケーションレベルからデータをパーティショニングする。)

また 2 つ目のポイントですが、SQL Azure データベースサービスでは、ひとつのデータベースのデータを、物理的には 3 台のマシンに複製した形で保持します。これにより、どこか 1 台のマシンが破損しても、他のサーバで処理を引き継ぐことが可能になっており、99.9% のサービス可用性(ひと月あたりのダウンタイムが約 5 分)が保障されるようになっています。内部的には、以下のように動作しています。

  • 外部からの TCP/IP 接続(SQL Server のネイティブ通信プロトコロである TDS プロトコルによる接続)は、いったん SQL TDS と呼ばれるサーバが受け付ける。このサーバがロードバランサとなり、特定のマシン(当該データベースを持っているマシン)に接続をルーティングする。(※ フェイルオーバ時は、この SQL TDS による接続ルーティング先が変更される。)
  • クライアントから行われる更新処理に関しては、更新内容が 3 台のマシンに自動的に複製される。
  • データ複製には、Microsoft がカスタムに作り込んだ特殊なレプリケーションシステムが使われている。(=ログシップやデータベースミラーリング、あるいは従来のデータベースレプリケーションなどを使ってデータが複製されているわけではない)

image

※ (参考) なお上記のデータ複製は、同一データセンタ内で行われます。このため、ディザスタ時(災害時、例えばデータセンタが地震で潰れた等)にはデータがロストすることになります。ディザスタを回避するためのデータバックアップや、別拠点へのデータバックアップについては、現時点では自力で行う必要があります。(将来的には同一データセンタ内またはデータセンタまたがりでデータベースを簡単にコピーできるようなツールやコマンドが提供される予定です。)

※ (参考) ちなみに、従来からあるデータベースレプリケーションの場合には、データ更新が別マシンに遅延反映されますが、SQL Azure データベースサービスで利用されているデータ更新はリアルタイムに行われます(=アプリケーションに対してコミット応答を返したときには 3 台のマシンに反映が終わっている)。このため、マシンクラッシュ時であっても、コミットされたトランザクションがロストすることはありません。となると、データベースエンジンとしての性能が気になるところですが、実際には、① データは同一データセンタ内の別マシンへ複製されている(=極端に離れたところに複製しているわけではない)、② データベースの最大容量が 10GB に制限されている、などの理由により、それほど大きな性能劣化にはなりません。

※ (参考) これらのことから分かるように、そもそも SQL Azure データベースサービスのようなクラウド型のデータベースサービスというものは、極めて高い性能要件(特に応答速度要件)を満たすことが原理的に難しいものです。SQL Azure データベースサービスはそもそも SAN のような高価なディスクストレージを利用していないでしょうし(おそらくただの 2.5” HDD でしょう)、さらにデータベースサーバ自体、複数のユーザによって共用されています。こうしたことを考えると、応答速度の保障が求められるようなシステム(例えばオンライントレードシステムのようなもの)には、クラウド型データベースは原理的に不向きである、と言えるでしょう。(ちなみに、極端に負荷の高い処理をしているユーザを強制的に遮断・切断する仕組み(スロットリングシステム)は持っていますので、タチの悪い他のユーザによってデータベースが使えなくなる、といったことがないようにはなっています。)

これ以外にも、データベースに関して様々な制約事項(分散トランザクションが使えない、ヒープテーブルが使えない、etc.)がありますが、これらについては後ほど記述します。ただ、制約事項はそれなりにありますが、一般に、高可用性データベースの運用というのは非常に難しく、コストもかかるものです。SQL Azure データベースでは、99.9% のサービス可用性を持つデータベースを、月額 10,000 円程度+トラフィック課金で利用できるわけですが、このサービスを使えば、データベースの監視もフェイルオーバ対策もぜんぶ Microsoft にお任せ可能。これは TCO 的な観点からすると激安である、と考えられるのではないでしょうか? 制限事項はあれど、使える部分には積極的に使っていきたいサービスではないかと思います。

では最後に、Windows Azure ストレージサービスについて解説します。

※ エントリが長いので分割しました。その 3 に続きます。


Comments (0)

Skip to main content