Part 2. Web サイトサービスの内部動作アーキテクチャ

Part 1. のエントリでは、Web サイトサービスがどのようなサービスであるかについて解説しました。引き続き本エントリでは、この Web サイトサービスの内部動作アーキテクチャについて解説したいと思います。

• 内部動作アーキテクチャ
• 2 種類の配置モデルと 3 種類の課金モデル

［内部動作アーキテクチャ］

Web サイトサービスを理解する上で最も重要なのは、どのような形でアプリケーションが物理インフラ上に配置されるのか、という点です。要点としては以下の 3 つがあります。

• 複数のユーザが、複数のアプリケーションを配置できるが、各アプリケーションは、同一仮想マシン内で論理的に隔離される。
• インターネットからの HTTP リクエストは、セッションアフィニティつきで自動的に負荷分散される。
• アプリケーションが複数マシンに展開されていても、実際のコンテンツは物理的に共有されている。

これらについて順に解説していきます。

① 複数のユーザが、複数のアプリケーションを配置できるが、各アプリケーションは、同一仮想マシン内で論理的に隔離される。

Windows Azure では、Web サイトサービス用にサーバクラスタを保有しており、ここに、複数のユーザが、複数のアプリケーションをアップロードすることができます（※ 共有型の場合、占有型については後述）。各アプリケーションは URL で識別され、フロントンエンドにあるロードバランサが、実際にアプリケーションの乗っている Web サーバにリクエストを転送する形で処理を行います。

この際、Web サイトサービスでは、アプリケーション隔離のための仮想マシン分離は行われていません。下図は、Windows Azure のレンタルサーバサービスである、Web サイトサービスと、クラウドサービス（コンピュートサービス）とを比較したイラストです。後者のクラウドサービスでは、各ユーザのアプリケーションは別々の仮想マシンを利用することになるため、分離性は高くなりますが、その一方で、アプリケーションの集積度を高められないため、コストがどうしても割高になります（1CPU あたりざっくり \8,000/月 ぐらい）。しかし、Web サイトサービスは、ひとつの仮想マシンを複数ユーザが共用するため、より安価なサービス提供が可能になります（最も安価なものはフリー、その次がざっくり \1,500/月ぐらい）。

（参考） なお、Web サイトサービスでは仮想マシン分離は行われていませんが、だからといって、自分のアプリが隣のアプリから丸見えになってしまう、なんていうことはありません。仮想マシン分離は行われていませんが、かわりに Drawbridge と呼ばれる技術によりアプリケーション分離が行われています。この Drawbridge という技術は、Microsoft Research で開発されているアプリケーションのサンドボックス化による仮想化技術で、仮想マシンよりも小さいプロセスの単位での隔離機能を提供します。アプリケーションが Full Trust 権限を持ちながらも、他のアプリと隔離された状態で動作しているのはこの仕組みによるもので、これにより、より高い集積度でサービスを動作させることができ、結果的により安価なサービス提供ができるようになっています。

② インターネットからの HTTP リクエストは、セッションアフィニティつきで自動的に負荷分散される。

Web サイトサービスの特徴のひとつに、自分が開発したアプリケーションを最大 3 台の Web サーバまでスケールアウトできる、という点があります。上図で示したように、クライアントからのリクエストは自動的に複数の Web サーバに負荷分散してくれるようになっているのですが、Web サイトのこの負荷分散の仕組みにはもう一つ特徴があります。それは、セッションアフィニティ（同一ユーザからのリクエストを常に同一のサーバにルーティングし続ける機能）つきでの負荷分散を行ってくれる、という点です。

セッションアフィニティつきで負荷分散が行えるのは、Web サイトでは、Azure の負荷分散の仕組みをそのまま使っているのではなく、中間にもう一層、リバースプロキシ層を設けているためです。下図が内部アーキテクチャです。

ご存じの方も多いかと思いますが、Windows Azure のクラウドサービス（コンピュートサービス）で利用している Azure のロードバランサは、セッションアフィニティを持ちません。しかし、Azure の外部向けロードバランサと、Web サイトサービスの間に ARR リバースプロキシ層が設けられています。この ARR 層は普通に Web サイトサービスを使っている限り意識することはありませんが（ユーザが触ることはできません）、この層があるおかげで、セッションアフィニティが実現されています。

（参考） ARR （Application Request Routing ）とは、IIS の機能拡張モジュールのひとつです。様々な機能を持っていますが、代表的な利用方法のひとつとして、こちらで解説されているようなリバースプロキシの構築、というものがあります。私も以前、震災対応の際にリバースプロキシ構築作業を行ったことがあり、その際にこちらの ARR を利用しました。

なお、ARR によるセッションアフィニティは、ARR によるクッキー発行により実現されています。Web サイトにアクセスしている際の HTTP リクエストをツールで解析してみるとすぐにわかりますが、ARRAffinity と呼ばれるクッキーが発行されており、これにより、ルーティング先となるサーバが固定化されるようになっています。

③ アプリケーションが複数マシンに展開されていても、実際のコンテンツは物理的に共有されている。

さて、Web サイトサービスでは複数のマシンによるスケールアウトが可能であることをここまで説明してきたわけですが、スケールアウトの際に問題になるのが、実際の物理的なファイルの配置方法です。例えば、3 台のサーバでスケールアウトする場合、通常、Web アプリケーションは各サーバにコピー配置する必要があります。しかし、Web サイトサービスでは、実際の物理的なコンテンツファイルは、下図のように同一のストレージにより共有されています。

これにより、Web サイトでは以下のような動作が実現できるようになっています。

• コンテンツはあたかもローカルディスク上にあるかのように見えるが、どのマシンからローカルディスクに書き込んでも、他のマシンから同じ内容が読み出せる。
• FTP で Web サイトに接続すると、あたかもサーバが 1 台だけしかないように見える。（が、実際には複数のサーバで負荷分散処理される）

このように、Web サイトサービスには、プロセス隔離やセッションアフィニティつき負荷分散、ストレージ共通化などの機能が備わっています。この結果として、我々は非常に簡単に、Web アプリケーションをアップロードし、負荷分散しながら処理することができるようになっている、というわけです。

とはいえ、やはり他のユーザと同一サーバ上にアプリを共存させたくない、というケースもあるでしょう。そのようなケースに応えるために、別の配置モデルも用意されています。それが、次に述べる占有型配置モデルです。

［2 種類の配置モデルと 3 種類の課金モデル］

Web サイトサービスでは、2 種類の配置モデル（インスタンスモデル）を利用することができます。ひとつが共有型、もうひとつが占有型です。下図に比較を示します。

共有型モデルでは、事前にマイクロソフト側が用意しているサーバ群を、複数のユーザが共用する形で利用します。このため、サービスの利用料金は相対的に安価で、（利用量に関する上限設定は比較的厳しいですが）フリーで利用可能なサービスも提供されています。これに対して、占有型モデルでは、あるユーザ（サブスクリプション）専用のサーバ群を用意することができ、そこに自分のアプリケーションを展開することが可能です。この場合には、占有するサーバ分の料金を支払う必要がありますが、かわりに他のユーザのアプリケーションとサーバを共有することがなくなります。

2 つの配置モデルの違いをまとめると、以下のようになります。

共有型（Shared）に関しては、あるユーザのアプリケーションがサーバリソースを使い切らないようにするため、リソース利用量に関して上限設定（クォータ設定）がなされています。共有型はさらに Free, Paid の 2 種類に分類されており、それぞれでクォータ設定が異なります。2012/10/19 時点では、クォータ設定および利用料金に関しては、以下のようになっています。見ればわかるように、フリー共有型（Free Shared インスタンスモデル）は比較的厳しいクォータ制限がかかっています。（が、ちょっと遊んでみる程度の用途であれば十二分すぎるほどの量ですね。） （※ フリー共有型を利用する場合、Web サイトはフリーになりますが、SQL データベースの方については課金が行われることには注意してください。100MB までであれば約 \500 /月、～1GB であれば約 \900 /月です。）

上記のクォータを超えたアプリケーションに対しては、一時的にアプリが利用停止状態になります。現時点でどの程度のリソースを利用しているのかに関しては、Windows Azure のポータルサイト（管理画面）から簡単に確認することができるようになっています。

また、これらの配置モデルについては、アプリケーションを配置した後でも切り替えることができます。このため、Free Shared でまずはサイトを立ち上げたのち、キャパシティが不足するようであれば Paid Shared、さらに必要に応じて Reserved に変えていくとよいでしょう。

なお、一点注意すべきこととして、同一サブスクリプション内では同一の配置モデルを使う必要があります。同一サブスクリプション内において、アプリ A は Free Shared、アプリ B は Paid Shared、アプリ C は Reserved、といった使い分けはできませんので、ご注意ください。

というわけで、以上が Web サイトサービスの内部動作なわけですが、引き続き、この Web サイトサービスの上で動作するアプリケーションを開発する際の注意点について、少し解説していきたいと思います。