【IIS6.0】アプリケーションプール(AppPool)について

Question

IIS6.0から追加された「アプリケーションプール」の機能について質問があります。

書籍やネット上の記事を読んで、「アプリケーションプールを分けることのメリット」については理解できました。

逆に「アプリケーションプールを分けることのデメリット」、
つまり「アプリケーションプールをまとめるメリット」は何なのでしょうか。

http://www.atmarkit.co.jp/fdotnet/dotnettips/247aspworkerproc/aspworkerproc.html
そこまで記述しているものが見つけられません。しいて言えばこちらの記事にある2点でしょうか。
　・リソースの消費量が小
　・WSA(WebAdministrationSystem)で提供されるワーカプロセスのプロパティ値を一元管理できる

アプリケーションプールをまとめるメリットが判然としないとなると、
ひとまず最小単位まで（それこそ極端に言えばアプリケーションごとに）
アプリケーションプールを分けたほうがいいのでしょうか。。。

ご教示お願いいたします。

Answer 1

少し違うアプローチで書きますが、有用だと思うのでご容赦ください。それはIIS7でどうなっているかという点からです。

 

IIS7 の Windows Server 2008 での既定値はサイト作成時に同名のアプリケーションプールを作るようになっています。Webアプリケーション単位では従来通り選択するようになっています。これはホスティングで利用する大きなWebサーバーを意識してユーザー間での干渉を防御する意味を持っています。ホスティングについては実はガイドラインが出ているのでそちらを参照ください。

 

IIS 7.0 ホスティング展開ガイド [ドラフト v1]

 

いくつか要点があると思いますが、私は下記だと考えています。

 

- アプリケーションプールは実行プロセスに紐づいている（通常は1つ、Webガーデン構成は複数）

- プロセス毎に実行ユーザーを変更することができる
ガイドラインにも書いてありますが、アプリケーション間での干渉を最小にするためには各プロセスのユーザーをすべて違うもので実行することで分離が最大化（最もセキュア）されます。

- プロセスを分離することでアプリケーションへの影響が考えられる
Windows（Webも）アプリケーションのパフォーマンスを考慮する際に最もみなが注意するのはプロセスを超えてやりとりを行うことをできるだけ避けること。なので、アプリケーションプールAからアプリケーションプールBのアプリケーション（サービス）を呼び出すのはプロセス内で実行するよりもコストが高い。故にプロセス（≒アプリケーションプール）を分ける単位は呼び合いの起こらないことがはっきりしている単位で分けるのが良い。

 

- Webガーデン構成は32ビットの壁で1プロセスあたりの2GB上限を超えてアプリケーションを動作させたい時によく使われているようですが、今度はこれで同一アプリケーションでプロセスが異なる可能性がでてきてしまうので今度はプロセス内のメモリを共有するようなアプリケーションも動作がおかしくなる可能性が出ます。逆に言うとプロセスの32ビット上限が気になりだしたら分けたくなるとも言える。

 

というアプリケーションの種類と実行要件（どれだけメモリ使うか、アクセス負荷がどれだけあるか）がすごく絡んでくるので上記基本ルールをベースに考えるといかがでしょうか。 

 

ASP.NETやASPでない場合、例えばFastCGI構成を推奨しているPHPなんかではレスポンスを生成するのに別プロセス（CGIなんで）がまた発生しているのでもう少しわかりにくくなるかもしれません。

Answer 2

＞ 奥主さま

お答えいただき、どうもありがとうございます。

    > 奥主さま
    > IIS7 の Windows Server 2008 での既定値はサイト作成時に
    > 同名のアプリケーションプールを作るようになっています

つまりIIS7の規定値では、

    > キュウ
    > 最小単位まで（それこそ極端に言えばアプリケーションごとに）
    > アプリケーションプールを分け
   
という状態である、という理解で相違ないでしょうか。そして、

    > 奥主さま
    > Windows（Webも）アプリケーションのパフォーマンスを考慮する際に
    > 最もみなが注意するのはプロセスを超えてやりとりを行うことをできるだけ避けること

という観点から、まとめられる（＝まとめた方がいい）ものはまとめていく、と。

アプリケーションプールを超えてSessionが維持できるのだろうか？
もしできないとしたら、そういうアプリケーションは同じアプリケーションにまとめるべき？
などと考えておりました。（ステートサーバでSession管理させれば関係ないか…などなど）

提示いただきましたサイトの記事を読んで、勉強します。
（現時点での私の知識では、少し難しいので何べんも読み直してみます…）

ありがとうございました。

Answer 3

うーん ちょっと誤解があるかもしれませんので

 

IIS7の既定値は サイトを作成する際の既定が推奨であるサイト毎の（サイト名と同じ）アプリケーションプールを作成するようになっています。

 

つまり IIS7では

サーバー

　－ サイト　←ここに同名のアプリケーションプールを割り当てます。ポート番号が異なる単位。　ただし、もちろん変更も可能。

　　－ アプリケーション（ここの既定はIIS6同様DefaultAppPoolになります。）

　　－ 仮想ディレクトリ（ここにはアプリケーションプール設定はありません。）

なので、ちょっとおっしゃられているのとは違うと思います。

 

全部わかれているので後で接着していくという構造にはなっていません。むしろ分離させていくのだと思います。ただ、サイト単位では分けることが推奨です。ということですね。

Answer 4

＞奥主さま

ご指摘ありがとうございます。サイトとアプリケーションを混同していました。

なるほど、サイトごとにアプリケーションプールを作られるのが規定なので、
さらにサイト内のアプリケーションでプールを分けられるものは分けていく、という流れなのですね…

重ね重ねありがとうございます。

Answer 5

こんにちは、nagioです。

 

元々の質問であるアプリケーションプールを分けることのデメリット、まとめることのメリットとしては、

以下が考えられるかと思います。

 

-1. 管理の煩雑さ

アプリケーションプールごとにリサイクルの設定やサービスアカウントを管理する必要が

生じますので、まとめることで管理の手間を軽減することができます。

 

-2. メモリの使用量

アプリケーションプールごとにワーカープロセスが起動しますので、プロセス数が減ることで、

多少（実際はごくわずかと思われますが）メモリが節約できるでしょう。

 

このぐらいでしょうか。

 

本番サーバは、セキュリティを考えるとアプリケーションプールを分けるべきでしょう。

共有の開発サーバは、ワーカープロセスのクラッシュを考えるとアプリケーションプールを

分けるべきでしょう。

ですので、私個人の考えですが、少人数で使う開発サーバや、部門内の本番サーバなどで、

管理の手間を減らしたい場合以外は積極的にアプリケーションプールをまとめるべきでは無いと

思います。

 

ご参考になれば幸いです。

 

Answer 6

nagioさん

ご意見をいただきありがとうございます。

　　　> 私個人の考えですが、少人数で使う開発サーバや、部門内の本番サーバなどで、

　　　> 管理の手間を減らしたい場合以外は積極的にアプリケーションプールをまとめるべきでは無い

なるほど、確かにメリット・デメリット考えた場合、より分けていった方が「セーフティ」なことは確かですね。

管理の煩雑さとセーフティさを天秤にかけた場合、明らかに後者を優先したいひとが多数でしょうし。

　　　> 少人数で使う開発サーバや、部門内の本番サーバなどで、管理の手間を減らしたい場合

余談ですが、開発環境で不具合が発見されやすくなるかもしれませんね.笑