またまたMDCの話題を一つ。

とかくイベントで話すそのタイミングは華やかなんですが、準備は猛烈に地道な作業であることが多いです。Technet 側でITプロの皆さんを支援させていただいているITプロエバンジェリストのみならず、Windows Presentation Foundation、その他WinFX周りの機能をご説明してできるだけいいデモを見ていただきたいという強い思いと雰囲気が事務所内に充満しています。朝から早朝まで頑張っているメンバーもいます。それでも事務所と当日会場の環境違いでデモがうまくいかないケースも多々あり、話す方もそれは大変な思いをしています。

私の準備はと言うと うーん IISとASP.NETの機能が融合したあたりで壁にあたってます。特にメンバーシップデータベース（ASPNET_REGSQLとかを実行する辺り）とIISの新たな融合している点は素晴らしいんですが、まだ十分に安定して動いてくれてません。BetaとBetaの狭間の色々なビルドを試して最も安定しているところから探したり、米国で実際にデモをしている連中に問い合わせりしながら暗中模索、七転八倒しながら準備を進めています。

今週の開催であるし、そろそろダメなものはダメと諦めるデモを決めないといけません。エバンジェリストってイベントだけではありませんが、特に目立つ仕事の舞台裏を少し書かせていただきました。さあ頑張ろう・・・

Good luck to me..　ということで。

IIS7に関する大きな二つの変化について既にふれました。Microsoft Developer Conferenceに来られる方は是非2日目のKeynoteや私のセッションを見ていただきたいですが、このブログでも引き続きこの辺りの話を書いていこうと思います。

IIS5で今日時点のセキュリティ更新プログラムを検索すると深刻度Allで30件ヒットします。Windows 2000の出荷時点ではやはりここ数年の歴史が証明したようにセキュリティに関して十分な配慮がなされていたとは言えないのだと思います。しかし、IIS6では製品デザインと製品開発プロセスを見直したことにより、緊急で0件、重大がWebDav系で1件という状況です。IISという観点では客観的に見てよくがんばっている、お客様から数え切れないほどセキュリティをなんとかしろとフィードバックをいただいた甲斐あったという状況だと考えられるのではないでしょうか。

実はインストールのGUIは結構ころころデザインがDecember CTPとその後のビルドで変化しているので、あるタイミングで見たデモがその後のデモでGUIが変わってしまっているようなことが今後何度か発生するかもしれません。前に書いているように、WebDavをそもそも使っていないお客様はWebDavのモジュールをそもそもインストールしないという方策をとることがIIS7ではできますが、この機能自身はGUIが変わろうとも変わりません。WebDavをそもそもインストールしておらず、IIS6の品質以上を目指せば適用対象モジュールが0件というゴールに到達できるはずであり、そのように社員が全員がんばっている状況です。

セキュリティという大きな命題をクリアしつつ、IIS7の開発にあたってようやく本質的な運用をする際の利便性を考慮する余裕が出たのかなと機能の多くを見ていると思います。また、CTP（Community Technology Preview）という考え方で製品の開発途上においてお客様に実際どのようなものが出来上がってくるのか見ていただける仕組みを作ったことはものすごく良かったと感じています。無論、MSDNやTechnetなどのチャネルが無いと入手できませんが、イベントでも配布したりしていますし、出荷後の製品でないと評価をする時間が現場ではとれないことは理解しつつ、技術的な検証をするバックの部隊の方であれば早期に新製品の動向が把握できるこの仕組みを私は評価しています。もしIISのセキュリティが採用のキーいるのであればIIS6の上記の状況をご理解いただければと思いますし、時期的に余裕がおありなのであれば IIS7 を一度ご覧いただければと思います。

個人的なお話をすると私はマイクロソフトの企業向けの製品サポート契約（プレミアサポート）を結んでいただいているお客様向けの担当者を3年ほどやっていた経験があります。その後 マネージャー（課長クラス）もやった訳ですが、まあ そんなことは置いておいて、今回は何を言いたいかというとこういうことです。マイクロソフトのアプリケーションプラットフォームは内部で問題が発生した際に高スキルの開発者やマイクロソフト内で解析ができる人にとってはデバッギングレベルのツールがいくつかあって辿り着きたいところに辿りつけるんですが、初見で何が起きているかをとりあえず知りたい運用現場ではこれでは厳しいと思います。これはマイクロソフトの開発陣も理解しており、製品開発のデザインにこの辺りをなんとかしようと Longhorn Server に向けては色々と考えて実装に向かってます。で、話をタイトル通りに戻すと IIS7 にもこの発想で Failed Request Tracing という機能がつきます。

何ができるかというと 例えばCPUが100%になっているサーバーがあると警告が上がってサーバールーム、あるいは監視できる端末のところに行ったとします。今までであれば動けばタスクマネージャーやパフォーマンスモニタを見てプロセスを特定する方向で見ていくでしょう。まあ IIS7 でもここは同じかもしれません。違うのは、IIS7で実装される新しい管理ツール内でトレースを有効にし、アプリケーションプール単位で消費しているCPUやメモリーの状態を確認でき、さらに最新でどのURLをワーカープロセスが処理しているかを見ることができます。これは大きいです。いきなりアプリに近いところでアタリがつきますので。ただ現在のビジネスアプリは部品化を進めている関係上、そのURLをアクセスするのが色々なルートからだったりするでしょう。これにはFailed Request Tracing をオンにしてもっと深いトレースをとります。

Failed Request Tracing はWebが返す例えば404あるいは500系のエラーなどでフィルターしてトレースを出力できます。そしてリクエストがされてからパイプライン上に乗ってくるすべてのリクエストをトレースできます。これは何を意味するかというと一連の処理の流れが全部記録することができるということであり、アプリ的にどのように流れたかを追うのではなくて IIS が実際に処理した内容を順に見れるようになるということです。無論、多くをトレースすることによるディスク消費やパフォーマンスの低下を考慮して環境に最適なフィルターを調整しなければいけませんが、今までのように再現を繰り返して問題を起こすより前にもっと情報が取得できるようになります。

「メモリダンプ、あるいは当該プロセスのダンプを取得いただけないでしょうか？」というお願いを何度したか記憶できないくらい回数が多いですが、IIS7やLonghornの監視機能を使えばお客様がそもそもマイクロソフトに問合せる前にもっとサーバーの状態がわかるという言うみんなハッピーな状態がようやく実現できそうな感触で私は個人的にすごくうれしいです。ただ、実践の現場はそれほど甘くないことも知っていますので問題解析のフローを考える際にこんなのがあるとか言ってたなと覚えていただけていれば幸せです。

IIS7 のなんといっても一番の特徴はコンポーネント化、あるいはモジュール化です。ですが、そのことを語る前にふれなければいけないのがセキュリティとIISの取り組みだと考えています。

IISでよく言われているポイントとしては攻撃がされやすい構造でセキュリティ面が不安ではないかという点です。IIS6 そしてそれを含む Windows Server 2003 では開発の段階からセキュリティを第一義に考えたデザイン（Secure By Design）になっており、実際に下記のサイトでご確認いただけるように「緊急」レベルのパッチは製品出荷以来 ご提供することなくお客様に運用いただける製品レベルとなっております。

製品/テクノロジーで「Internet Information Services 6.0」を選択して検索してみてください。
http://www.microsoft.com/japan/technet/security/current.aspx

※セキュリティに関しては弊社日本のセキュリティチームのブログがこちらにございますので、Technetのセキュリティページと合わせご参照いただき、最新の情報を入手ください。

しかし、マイクロソフトではもっとIISを改善することができると考えて Longhorn Server の開発のうち、IISのデザインをする上で大きな構造変更をすることにしました。それがモジュール化です。

何故モジュール化をすることでセキュリティに関して改善ができるかと言えば、パッチを適用するシチュエーションを考えていただければわかりやすいです。パッチが提供された場合にまずはご利用のサーバーでそれを適用する必要があるかどうかをアセスするフェーズを実施なさっていると思います。その際の判断としてどの機能に脆弱性があるのかというアプローチをとります。具体的な例で言えば例えばHTMLコンテンツを処理する機能に脆弱性が見つかったとします。IIS6では残念ながら一枚岩な構造になっており、簡単に言えば 多くの機能を含むプログラムファイルの交換をする必要が出てしまいます。しかし、モジュール化されていれば、HTMLコンテンツを処理する機能を含むモジュールを交換すれば済むことになります。

一方で、モジュール化されていることによってそもそも不必要な機能についてはモジュールをエンジンにプラグインしないため、メモリー上にも存在しない状態を作れます。メモリーにロードされている状況に対する攻撃であってもこの背景から構造面から予防することができます。メモリー上にロードされないことによって より軽装なWebサーバーともなり、リソース消費の面でも有利になります。さらに今までサーバー本体機能のカスタマイズを行う場合、ISAPI（IISのAPI）を利用して実装する必要がありましたが、IIS7では開発チームが利用するAPIは公開されたものとなり かつ、.NETによるマネージドコードで開発できることになります。このことにより、サーバー本体機能を司る独自モジュールの開発も可能となり、利用に最適なサーバーを組み立てることが容易にできるようになります。マイクロソフト以外のベンダーが有用なモジュールを提供するモデルも考えられ、多くの人のビジネスチャンスが広がります。

他にもメリットがありますが上記を総合的に判断し、モジュール化を決定した訳です。Windows Vista （一部Edition）でも搭載されますから入手可能な方は是非 一度お試しいただくことをお奨めいたします。

直近の話題と言えば Microsoft Developer Conference 向けの準備です。私は Windows Vista と Windows Codename "Longhorn Server" に搭載される新しいWebサーバーであるIIS7のセッションを二つ担当する予定です。アプリケーションの開発という観点でも運用管理の観点でも数々の改良がなされるこのサーバー機能は特に Visual Studio で開発をなさっている方であれば新しいビジネスチャンスの可能性でもあり、IIS7をエンジンとして色々な可能性が見えます。技術的な観点でIIS7に関して色々と書いていきますのでご期待ください。

Windows Vista と言えばMicrosoftのVistaの日本語ページはまだ十分な情報が掲載されているとは言えない状況です。担当者の代弁をすると鋭意準備中です。エバンジェリストとしての視点でもWebcastなり、ホワイトペーパーなりでご支援させていただけるようなものを企画したいと思います。