Windows プロセス アクティブ化サービス (WAS) の特徴

投稿者 Thomas Deml

IIS 7 の Windows プロセス アクティブ化サービス (WAS) は、プロセス モデルと構成機能を提供する主要なコンポーネントで、その対象は Web アプリケーションと Web サービスなどです。 WAS の主要なタスクは、アプリケーション プールの管理です。 アプリケーション プールとは構成コンテナーであり、URL のグループのホスティング環境を表しています。

HTTP クライアントが URL を要求すると、HTTP.SYS は、その要求を、アプリケーション プールの要求キューにマップします。 アプリケーション プール要求キューのワーカー プロセスは WAS によって起動され、このワーカー プロセスが、応答を送信するために必要なコードを実行します。 WAS の主なタスクの 1 つは、起動したたワーカー プロセスを管理することです。たとえば WAS は、これらのプロセスの正常性を監視したり、必要に応じてそれらをリサイクルしたりします。また、そこで消費されるリソースが、対応する AppPool 構成での指定より多くなることがないように管理します。 WAS は、パフォーマンス カウンター、サイト、アプリケーション プールの状態など、実行時および状態のデータの調停と収集も行ないます。

アーキテクチャの図

プロセス モデルの機能

10,000 以上の Web サイトを同一の物理マシン上でホストできるようにすることは、今日の大量ホスティング環境においては中心的な要求事項です。 これらの Web サイトで実行されているコードは、通常、充分にテストされているとは言えません。 これらの要件に対応するために、WAS では、強力なプロセス モデルと効率的なリソース管理を提供する必要があります。

効率的なリソース管理

オンデマンドのアクティブ化

マルチテナント シナリオにおいては、RAM や CPU などのリソースが不足します。 WAS は、特定の Web サイトまたは Web アプリケーションに対する要求が到着した場合に、一度のみ IIS ワーカー プロセスを開始します。

アイドル タイムアウト

WAS では、構成可能なアイドル タイムアウトに基づいて、Web アプリケーションをシャットダウンできるようになっており、日常的なリソース不足に対応しています。

正常性の監視

ワーカー プロセスの正常性を保証するため、 WASは 起動したプロセスの監視を行ないます。 正常性メッセージは、実行中の各ワーカー プロセスに定期的に送信されます。 ワーカー プロセスが構成された期間内で応答しない場合、そのワーカー プロセスはリサイクルまたは中止されます。 このように、そのワーカー プロセスを再起動することで、ワーカー プロセス内部での非検出のデッドロックが、自動的に修正されます。

スタートアップの制限

Rapid-Fail 保護機能の一部は、スタートアップを制限します。 ワーカー プロセスが、構成されたスタートアップ制限内で WAS にレポートを返さない場合、このプロセスは中止され、Rapid-Fail 保護カウンターがインクリメントされます。 Rapid-Fail 保護カウンターが、構成された制限時間内に構成された制限に達した場合、アプリケーション プールは停止され、それ以降ワーカー プロセスの再起動は試行されません。 これにより、起動時にワーカー プロセスがハングまたはクラッシュするようなシナリオが回避されます。

シャットダウンの制限

ワーカー プロセスは、構成可能な制限内でシャットダウンする必要もあります。 この期間内でシャットダウンが行われない場合、ワーカー プロセスは WAS によって中止されます。 これにより、シャットダウン フェーズでのプロセスのハングが原因で、リソースが過剰に使用されるのを防ぐことができます。 追加のシャットダウン設定を使用すると、割り当てられた時間内にシャットダウンが完了しない場合に、実行可能ファイル (デバッガーなど) を起動できます。

CPU アフィニティ

構成設定は、1 つ以上の CPU にアフィニタイズされたワーカー プロセスをWAS が起動することを許可します。 これにより、同じ物理マシンを共有しているテナント同士が、相互に干渉するのを防ぐことができます。

ユーザー プロファイル

ユーザー プロファイルを読み込むかどうかに関わらず、WAS はワーカー プロセスを開始できます。

セキュリティ

アプリケーション プール ID

IIS ワーカー プロセスは、カスタム アカウント、ビルトイン アカウント (LocalService、LocalSystem、NetworkService)、またはアプリケーション プール ID (既定) としても実行できます。 アプリケーション プール ID はパスワード管理を必要とせず、また、この ID は既に最小限の特権の原則に従っています。そのため、アプリケーション プール ID の使用が推奨されています。 またビルトイン アカウントも、パスワード管理を必要としません。 カスタム ユーザー ID が使用されている場合、パスワードは自動的に暗号化されます。 構成設定は、マシン間で構成暗号化キーを共有することで、複数のマシンにレプリケートできます。

ジョブ オブジェクトの機能

ジョブ オブジェクトは、管理者がワーカー プロセスを特定の CPU の上限に制限することを可能にします。 この CPU 上限が超過された場合は、構成されたアクションが実行されます。 ジョブ オブジェクトは、ワーカー プロセスによって起動されたプロセスが、確実に終了されるようにします。

構成の分離とセキュリティ

WAS は、アプリケーション プールとそのワーカー プロセスを起動する前に、そのアプリケーション プールのために一意の構成ファイルを生成します。 アプリケーション プールには、一意の ID の下で実行されるための構成設定もあります。 さらに、同じ ID が使用されている場合であっても、分離を達成することができます。 WAS は、アプリケーション プールごとに一意のセキュリティ識別子 (SID) を作成します。 アプリケーション プールの構成ファイルは、この一意の SID で保護されます。 これにより、アプリケーション プールの構成ファイルを読み取れるのは、管理者とそのアプリケーション プール自体のみに限定されます。 さらに、ファイルのアクセス許可も、この一意の SID を使用して構成できます。

診断および監視

イベント ログ

無効な構成、リサイクル、ワーカー プロセスの起動またはシャットダウンに関するイベントは、System Eventlog にレポートされます。

現在実行中の要求

WAS は、ランタイムと状態コントロールのインターフェイスを公開して、スクリプトとツールが特定のワーカー プロセスで現在実行中の要求を照会できるようにします。 これは、ハングしている要求や、完了に非常に長い時間がかかる要求を見つけるのに役立ちます。

パフォーマンス カウンター

すべての IIS パフォーマンス カウンターは、WAS を通じてファネルされます。 IIS カウンターはサイトベースであり、Web アプリケーションは異なるアプリケーション プールに存在することがあるため、WAS がこれらのパフォーマンス カウンターを収集しています。

リサイクル

リサイクルにより、ダウンタイムが原因で一切の要求を損失することなく、ワーカー プロセスを更新できます。 これは、"重複するリサイクル" と呼ばれる機能を介して実行されます。

重複するリサイクル

WAS は、まだ要求を処理している古いワーカー プロセスと並列に、新しいワーカー プロセスを生成することで重複するリサイクルを実行します。 起動された新しいワーカー プロセスは、要求キューから要求の取得を開始する一方で、古いワーカー プロセスは、WAS によって要求の取得を停止するように指示されます。 実行中のすべての要求を完了した古いワーカー プロセスは、シャットダウンします。 この機能は、"重複するリサイクル" と呼ばれます。 これにより、リサイクル中に 1 つの要求も失われないようにしています。

リサイクルの構成

リサイクル パラメータは、IIS の構成システム内で設定が行なえます。

スケジュールされたリサイクル

アプリケーションを、定期的なスケジュールに基づいてリサイクルしたい場合があります。 構成設定を使用すると、たとえば 4 時間ごとや、毎日午前 1 時など、リサイクルを定期的にスケジュールできます。

メモリ使用量に基づくリサイクル

アプリケーションは、時間の経過に伴いメモリをリークすることがあります。 WAS は、各ワーカー プロセスのメモリ消費量を監視して、事前に構成された制限を消費量が超えているワーカー プロセスが存在しないことを保証します。 仮想またはプライベート メモリが構成されたしきい値に達すると、ワーカー プロセスのリサイクルがトリガーされます。

要求の数に基づくリサイクル

リサイクルでは、特定のワーカー プロセスが処理した要求の数に基づいた構成を行なうこともできます。

カスタム リサイクル

カスタム コードでは、正常性の統計をカスタム化し、WAS ランタイムと状態 API の API 呼び出しを介してリサイクルをトリガーできます。

プロセスの孤立化

一部のエラーは運用環境でのみ発生します。 ワーカー プロセスを中止すると、アップタイムは確保されますが、これらのエラーのトラブルシューティング (失敗したワーカー プロセスをデバッグする必要がある場合など) が難しくなります。 WAS のプロセス孤立化機能を使用すると、失敗したワーカー プロセスを中止することなく、ワーカー プロセスをリサイクルできます。 現在これには、デバッガーのアタッチが可能です。 追加のプロセス孤立化設定で、孤立化が発生した場合にプロセス (デバッガーなど) を実行できるようになります。

アプリケーション プールの状態管理

アプリケーションをオフラインにする必要がある場合や、applicationhost.config ファイルで構成できるパラメーターとは異なるパラメーターに基づいてリサイクルする必要がある場合などは、一般公開されている API を介してアプリケーション プールを停止、リサイクル、または開始できます。

WAS のその他の機能

ロード バランサーの機能

HTTP.SYS によるネットワーク上でのリッスンは継続しているので、アプリケーション プールによって要求が取得されない場合は、500 HTTP エラー メッセージが返されます。 レベル 5 ロード バランサー (TCP/IP) にとっては、500 HTTP エラーが有効な TCP/IP 接続のように見えるため、これは問題となります。 WAS 構成設定を使用すると、HTTP.SYSで、HTTP 応答を送信する代わりに接続が拒否されるようにできます。

次の設定を使用すると、ワーカー プロセスを起動するように WAS を構成できます。

WoW64 サポート

WAS は、32 ビットまたは 64 ビットのワーカー プロセスを起動します。

.NET Framework の事前読み込み

WAS は、特定のバージョンの .NET Framework を事前に読み込むように構成できます。 これにより、バージョンの競合のトラブルシューティングがとても簡単になります。

Web ガーデン

Web ガーデンは、複数のワーカー プロセスを使用して実行されるアプリケーション プールを表す用語です。 要求は、ラウンド ロビン メカニズムを使用することで、これらのワーカー プロセス インスタンス間で分散されます。

WAS マルチ プロトコル サポート

WAS は HTTP スタックをホストするだけではありません。 リッスン アダプターとワーカー プロセス フレームワーク経由で、他のプロトコルをホストすることもできます。 WCF サービスでは、WAS のマルチプロトコル サポートを活用しています。 WCF プロトコルには、独自のリスナー (NET.TCP、NET.MSMQ または NET.PIPE リスナーなど) が付属しています。 これらのリスナーは、WAS が提供するリスナー アダプター インターフェイスを使用して WAS に接続します。

このインフラストラクチャを利用するアプリケーション プロトコルでは、通常の ASP.NET アプリケーションと同じ .NET アプリケーション ドメイン内で、カスタムのアプリケーション コードをホストできます。 またこれらのプロトコルでは、ASP.NET ホスティング環境が提供するプロトコルに依存しないサービス (オンデマンドコンパイル、構成サポートなど) を利用することもできます。