第5回　柔軟性と機能性を大幅に高めたIIS 7.0（後編）：Windows Server 2008の基礎知識（2/3 ページ）

　IISのみならず、Windowsは内部で何が動いているか分からないという声を現場で何度か聞いたことがある。実際にはパフォーマンス・モニタやイベント・ビューアなどを駆使してさまざまな健康状態を測ることはできるのだが、テクニックとしては煩雑になりがちだ。筆者は、こうした計測データの収集後に自分なりに検討するためにデータベースに入力したり、Excelを駆使したりしている光景を何度も見たことがある。また筆者自身も、アプリケーションのプロセス内の動作を調査するために、顧客に何度もダンプ取得を依頼したという苦い経験がある。

　ここではIIS 7.0に焦点を当てて、Windows Server 2008やWindows Vistaでは診断システムがどう変わるのかを見ていく。

■クライアント側でのエラー情報収集
　まず、Webアプリケーションでエラーが発生したことを想定してみよう。開発者が工夫をしていない、あるいは想定外のエラーが発生したことによってブラウザに真っ白い画面が出てしまった。ヘルプ・デスクにコールが入り、エラー画面の画面ショットを送付してもらう。しかし、何のエラーだかまったく分からない…。現場では、こうした想定外のことが常に起こりうる。

　こういう状況に対して、IIS 7.0では何ができるか。

　障害発生が試行期間中なら、エラー画面を開放して、クライアントでより詳細なエラー情報を出力させるという方法が考えられる。デフォルトではサーバ上のブラウザだけに出力される詳細なエラー情報を、試験用PCでも表示されるようにすれば、そこで問題の情報収集ができる。できれば打鍵試験を実施する際に情報収集できるとなおいい。

IISマネージャにおけるエラー・ページの設定画面
デバッグ時には詳細なエラー情報をクライアントのブラウザに返すように、この画面で設定できる。
　 （1）機能一覧から［IIS］−［エラー ページ］を選択してから、このリンクをクリックする。
　 （2）（1）によってこのダイアログ・ボックスが表示される。

　IIS 7.0の提供するエラー画面は情報が豊富だ。どのURLに対してリクエストしたのか、どのモジュールが処理しようとしていてエラーが発生したのか、どのユーザーの権限で実行しようとしていたのかなど、従来は相当数のコードを埋め込まないと取得できなかった情報が標準で閲覧できる。

IIS 7.0のエラー・ページの例
これはクライアント側のブラウザに表示されるエラー・ページの例。エラーが発生したモジュールやハンドラ、リクエストしたURLなどの情報を取得できる。

■「失敗した要求トレース」による詳細なエラー情報の収集
　上記はクライアントだけの情報収集だが、次に「失敗した要求トレース」という機能を見ていこう。これは文字どおりトレースを仕掛ける機能で、コンテンツの種類や発生するエラー番号でフィルタをかけたり、実行時間の長いものにしきい値を指定してトラップを仕掛けたりできる。トレース結果はXML形式で出力され、デフォルトでもXSLによって見やすい画面で表示される。もちろんスタイルシートを改良するとトレースの出力ももっと見やすくなる。いわば進化するトレース機構といえる。

トレース結果の出力例
前出のクライアント側でのエラー・ページに比べ、実行にかかった時間など詳しい情報が得られることが分かる。

　さらに、リクエストの実行状況を内部動作レベル（モジュール動作の開始／終了の時点など）で順番にタイムスライスで整理したビューが用意されていて、それぞれ何msecかかったのかまで分かりやすい形で出力できる（以下の画面）。エラー番号に「リクエスト成功」を表す「200」を指定すれば当然、異常系の試験用だけではなく正常系の内部経過時間調査にも使えるわけだ。このカスタマイズ機能を利用して、運用にかかわる技術者が自分のチーム向けに情報収集用のXSLを作っておくなどもできる。

リクエストの実行過程をトレースした出力例
リクエストの内部処理の過程を経過時間とともに表示できる。これにより、例えばどの内部処理で時間がかかっているか、といったことを簡単に把握できる。

　ASP.NETでこれを使っている場合にはなおよい。ページ・トレース・ディレクティブを書いてページ・トレースを有効にし、さらにTrace.WarnやTrace.Write（デバッグ用の警告／通知ステートメント）をコードに埋め込むと、この内部経過時間にそのタイミングが記録される。そこで処理内容が分かるような文字列を指定しておけば、何の処理にどれだけ時間がかかったのか、1つのトレースだけでかなり把握することができる。

　余談だが、IIS開発チームは、いまもこの失敗した要求トレースをFREB（Failed Request Error Buffering）という当初の名前の略称で呼んでいる。エラーの記録を残したいという開発者たちの気持ちがとても分かるいい名前だと思って、私も継続してこの機能をFREBと呼んでいる。

・Insider's Eye：Windows Serverの無償パフォーマンス監視ツールが登場

■新しいトレースのフレームワークに対応
　実はこの機能はOSの新しいトレースのフレームワークのうえに成り立っている。IIS 6.0向けに提供されたETW（Enterprise Tracing for Windows）の新機構がOSに組み込まれているのである（ETWについては以下の関連記事を参照）。このフレームワークは本番環境で問題が発生した際に本番サービスを止めることなく、できるだけ負荷をサーバにかけずに有用なトレースを取れるように考えられた。そのため、高速で軽量に動作するべくカーネル・モードでトレースが実行されるように設計されている。

　FREBはこのETWをベースにIIS 7.0用にコンシューマ（トレースの出力を制御するプログラム）を用意したものになる。もちろんIIS 7.0は何かを実行する際にETWの取り決めに基づいてイベントを発生させるから、そのトレースも取得できる。この仕組みはIIS 6.0の時代ではかなり後付けで提供されたが、Windows Server 2008やWindows Vistaでは診断機能の一部としてGUIもデフォルトで用意されている。

Windows Server 2008のトレース設定画面
Windows Server 2008／Windows Vistaには標準でトレースを設定するためのGUIが提供されている。IISに限らず、このトレースのフレームワークに対応したコンポーネントであれば、そのイベントの情報を収集できる。

　今後はイベント・ビューアやパフォーマンス・モニタだけでなく、このETWを使いこなすのがWindowsの問題解析では重要になってきそうだ。具体的には［信頼性とパフォーマンス モニタ］内の［データ コレクタ セット］という項目をじっくり見てほしい（上記の画面）。そこに［イベント トレース セッション］というものがあり、IISのイベントだけでなく、このフレームワークに対応した多くのイベントがここで情報収集可能になっていることを確認できる。