AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう。
前回は、Web Appsサービスの概要を解説し、WordPressアプリのインストールまで行ってみました。今回は、作成したWeb Apps(WordPressアプリ)がAzure上でどのように動作しているのか、ちょっと中を見てみましょう。
Web Appsは、PaaS(Platform as a Service)型のサービスであることを解説しました。PaaSでは、OSやミドルウェアなどはマイクロソフト側で管理されており、ユーザーが関知する必要はありません。ユーザーは、その上で動作しているアプリケーションやデータのみを管理します。
IaaSとPaaSの違いは、図を見れば確かに分かったような気になりますが、実際にはどうなっているのでしょうか?
前回導入したWeb AppsのWordPressは、Windows OSベースのプラットフォーム上にインストールしたため、上の図(右側)のWindows/ミドルウェアの部分にはWindows OSとIIS(もしくはそれらの派生品)が使われているのは確かでしょう。次のTIPSを見ると分かるように、オンプレミスのIISと同じように管理できるようなので。
そこで気になるのは、Web Appsの実行環境がオンプレミスのWindows OS+IISとどれくらい違うのか、という点です。オンプレミスの方はハードウェアから何から完全な専有なのに対し、PaaSであるWeb Appsは(どれくらいかよく分からないけど)いくらかのリソースが複数のユーザーによって共有されているはずなので、どこかに違いがあるはずです。
というわけで、今回はちょっとこのあたりの仕組みを少し踏み込んでのぞいてみましょう。
Web Appsではどのようにしてアプリケーションの実行環境を用意しているのかを調べたところ、以下のような情報が公開されていました。
簡単にまとめると、Web AppsやMobile Appsなどを隔離して実行するための「Sandbox(サンドボックス)」実行環境を作り、その中でIISのワーカープロセスであるw3wp.exe(とその派生プロセス)を動作させる、という仕組みです。
サンドボックス(砂場)とは、プログラムやデータなどを他のプロセスから隔離して、外部からの不正なアクセスの防止や、逆に外部への不正アクセス予防なども目的とする保護/隔離メカニズムです。JavaやJavaScriptの実行環境などでよく使われています。システム全体をセキュアにするよりも容易だし、標準化も行いやすい(どのシステム上でも同じように実行できる環境を提供できる)、(余計な機能があまりないので)ユーザーも使いやすくなる、などのメリットがあります。Azureの場合は、ワーカープロセスごとに、例えばPHP-CGI.EXEやJAVA.EXE、NODE.EXEなどを実行してサービスを提供しています。
IIS 7.x(Windows 7/Windows Server 2008 R2)以降では、それ以前のIISで使われていたプロセス実行モデルを改善し、ワーカープロセスごとに異なるID(プロセス実行用のアカウント)を使ってセキュリティ的に厳密に分離して実行できるようにしました(アプリケーションプールID実行モデル。詳細はTechNetの「アプリケーション プール ID」参照)。
AzureのWeb Appsはこの実行モデルを拡張して、利用できるAPIやリソースにも制限を付けて、安全でお互いに隔離された実行環境をWeb Appsに提供しているようです。主な制限機能としては、次のようなものがあります(詳細は先のProject Kuduのページ参照)。
AzureのApp Serviceでは、サンドボックスという仕組みを使って、個々のアプリを安全に隔離して実行しています。このあたりが、オンプレミスのWindows OSとの大きな違いになります。
Copyright© Digital Advantage Corp. All Rights Reserved.