Loading
|
|
|
|
Loading
|
| ＠IT > Webアプリケーション・プラットフォームとしてWindowsを選択する7つの理由＜前編＞ |
 |
企画：アットマーク・アイティ
営業企画局 制作：デジタル・アドバンテージ 掲載内容有効期限：2005年2月14日 |
|
|
|
Webアプリケーションを構築するならば、Unix／Linux＋J2EE（Java2 Platform, Enterprise Edition）という先入観は根強い。 なるほど、Unixはインターネットの黎明を支えてきた伝統的なプラットフォームであった。J2EEが、いち早くWebアプリケーション・プラットフォームのデファクト・スタンダードの地位を確立し、企業におけるレガシー・マイグレーションの流れの中で着実に地歩を築き上げたのも記憶に新しい。 片やWebアプリケーション・プラットフォームとしては後発であるWindowsには、訳もなく「実績がないので信用できない」という先入観がつきまとうようだ。これに拍車をかけたのが、かつてWindows＋IIS（Internet Information Services）に打撃を与えたCode RedやNimdaといったワームの存在であったろう。読者諸兄も、Windowsを嫌う人間がこういうのをよく聞くことだろう。「Windowsはセキュリティ的に脆弱である」と。 しかし、これらの評価は果たして正しいものなのだろうか。実際には、LinuxよりもWindowsの方が優れたソリューションを提供する局面は少なくない。そして、Linuxにもまた、Windowsにはないさまざまな（顕在化しにくいという意味では、より重大な）リスクが存在する。これらから目を背けて、よくある先入観にのみ盲目的に身をゆだねるのは、だれにとってもハッピーではないはずだ。 本稿では、中小規模のWebアプリケーション・プラットフォームとして、いま、Windowsを選択する理由を7つ挙げ、前後編に分けて紹介する。具体的には以下のとおりである。
J2EEでは、いまや定番ともいえる商用アプリケーション・サーバ製品が存在する。例えば、IBM WebSphereやBEA WebLogicなどが代表的なそれだ。しかし、これらはもっぱら大規模システムの開発をターゲットとした製品であり、中小規模のWebアプリケーション・プラットフォームとしては、オープンソース・コミュニティが提供するJBossやJakarta Tomcatなどのプロダクツを組み合わせることが多いのではないだろうか。本稿では、これら無償で利用可能なJava製品を総称して「フリーJava（製品）」と呼ぶことにする。これらフリーJava製品を組み合わせることの利点は、ソフトウェアのライセンス・コストを考慮する必要がないため、設計やソフトウェアの配置が比較的柔軟に決められるという点だ。 片やWindows＋.NET Frameworkの組み合わせでは、OSそのものやCAL（Client Access License）、周辺のデータベース・サーバ製品などのライセンス・コストだけでも、それなりの規模になる可能性がある。当然、設計やソフトウェアの配置においても、ライセンス・コストに伴うイニシャル・コストの発生を考慮する必要に迫られるだろう。 これが「Windows＋.NET Frameworkの組み合わせは高くつく」といわれる所以だ。しかし、実のところ、これは正当な評価とはいえない。というのも、当然のことながらアプリケーション／システム開発にかかるコストは、製品価格やライセンス・コストなどのイニシャル・コストからのみ構成されるわけではない。ここに大きな落とし穴がある。 以下は、Windows＋.NET FrameworkとLinux＋フリーJavaとによるアプリケーション構成を図示したものだ。
この図からWindows＋.NET FrameworkとLinux＋フリーJavaとの顕著な違いが明らかになる。 それは、Linux＋フリーJavaの世界では、製品の組み合わせパターンがいくとおりも存在するという点だ。「製品選択の自由がある」、または「柔軟性に優れる」といってしまえば、いかにも聞こえは良いが、システム設計／開発の局面においては、むしろ設計者／開発者に対して余計な負担の原因となるケースの方が多い。 一例を挙げてみよう。 例えば、最近ではJSP（JavaServer Pages）環境で利用可能な標準タグ・ライブラリとしてJSTL（米SunのJSTLのホームページ）が注目されているが、これらの機能はアプリケーション・フレームワークであるStrutsが提供するStrutsタグ・ライブラリと多分に重複する。JSTLとStrutsを組み合わせる場合、より標準的なJSTLをStrutsタグ・ライブラリに優先して採用するのが正しいアプローチである。しかし、どの部分が重複しており、どの部分をJSTLで置き換えるべきなのか、という点については、使用している製品やバージョンの組み合わせによって大きく変動するものであり、開発者自身が常にそれぞれの製品のステータスを理解していないと、なかなかに把握しきれないところもあるだろう。ましてや、システム開発ともなれば、こうした情報が開発プロジェクト内の全員に周知徹底されていなければならないのだ。適切な記法が採用されているかどうかによっては、後々のバージョンアップに際して、既存のコードを大幅に修正しなければならないような事態も起こりうるので、これは大変重要なポイントでもある。 このような取捨選択、ルール作りの責任が、Linux＋フリーJavaの世界では、常にあなた自身に委ねられているということだ。中小規模システムの開発で、そのときどきの適材適所を適確に判断できるだけのスキルを持った技術者がどれだけ望めるだろう。 また、各製品から最大パフォーマンスを引き出すために、設定すべきパラメータが多岐にわたるというのも、Linux＋フリーJavaの傾向だ。当然、これらパラメータを適切に設定することができるならば、環境や状況に応じたチューニングが可能だ。しかし、多くの場合に、多岐にわたる製品の一連のパラメータに精通している技術者は、そう多くは望めない。製品として「可能」であるということと、それが現実的に「可能」であるということには、明確な一線が存在することを認識するべきだ。 一方のWindows＋.NET Frameworkは、いうなれば「オールインワン」タイプのプラットフォームだ。Windows＋.NET Frameworkでは、「Framework」というその名のとおり、最初から高水準のAPIやクラス・ライブラリなど、アプリケーションの骨組み一式があらかじめ提供されている。Windows Server 2003を利用しているならば、Windows標準のWebサーバであるIIS（Internet Information Services）と.NET Frameworkとが標準で搭載されているから、それこそ「何ら余計なことは考えることなく」アプリケーション開発に取り掛かることができるのだ。特定された環境のもとであらかじめ最適な状態が作られているから、開発者が設定すべきパラメータがLinux＋Javaの世界に較べてはるかに少ないのも、Windows＋.NET Frameworkの特徴といえるだろう。 例えていうならば、Windows＋.NET Frameworkは「内装・外装ともに整えられた普及車」であるが、Linux＋フリーJavaは「内装もボディすら持たない、しかし、工場で精密な検査をクリアしてきた生のエンジン」だといえる。とにかく「走らせる」という当初の目的を追求するならば、なにも生のエンジンを持ってくることはない。多くのユーザーにとって、普及車を利用する方がはるかに理にかなっているのだ。スピードや足回りに絶対のこだわりがあるならば、生のエンジンから作り上げる選択肢ももちろんあるが、その場合、最終的に「走る」という目的に到達するまでには、多くの労苦もコストも伴うことを覚悟するべきだ。
Linux＋フリーJavaにせよ、Windows＋.NET Frameworkにせよ、統合開発環境（IDE:Integrated Development Environment）の利用は必ずしも必須の代物ではない。コーディングからビルド、デプロイ、デバッギングまでを、すべてテキスト・エディタとコマンド・プロンプトやターミナル上で行うのも良いだろう。しかし、多くの場合、これらの作業は定型的でもあれば、本来の開発という視点から見れば付随的な作業でもある。原始的な作業を意識させず、本来のコーディング作業に集中させてくれる統合開発環境の存在は、開発生産性を左右する重大な一要素であるといって良いだろう。 Linux＋フリーJavaの世界では、統合開発環境と呼ばれるものは数多くあれど、いわゆるデファクト・スタンダードとされる製品は長く不在であった。敢えていえば、ここ数年になって、急速に台頭してきた「Eclipse」（Eclipseのホームページ）がそれに当たるだろう。Eclipseは、「プラグイン」と呼ばれる拡張ソフトウェアを導入することで、単なる開発ツールとしてだけではなく、UMLモデリングやデータベース設計のような上流工程から下流のテスト工程までを広範にサポートできる点が人気を博した。最初に登場したのが2001年11月と、まだまだ歴史が浅いことを考えれば、その急速な普及は注目に値するものだ。
しかし、Eclipseの基本はあくまでコード・エディットであるといってよい。実に、Eclipseは前バージョンの2.xまではGUIをビジュアルに開発するインターフェイスを持っていなかった。2004年9月にようやく、Visual Editorプラグインがリリースされたことから、Swing／SWT（Standard Widget Toolkit）の開発が、コンポーネント部品のドラッグ＆ドロップでできるようになったとはいうものの、まだまだGUI開発といった意味では、ようやく端緒についたところといって良い。 いずれもマイクロソフトが開発元であることから当然ともいえるが、片やWindows＋.NET Frameworkの世界で統合開発環境といえば、Visual Studio .NET（以降、VS .NET）が圧倒的な存在感を誇っている。そのほか、フリーの開発環境としてWeb Matrix（Web Matrixのホームページ）や、サード・ベンダから提供されているボーランド社のDelphi 2005（Delphi 2005のホームページ）、SharpDevelop（SharpDevelopのホームページ）などもある。.NET Frameworkが高水準のフレームワークを提供するため、いずれの開発ツールも使いやすいビジュアル開発の機能を実装できている。しかし機能性や普及度、安定性などを総合的に考慮すれば、事実上、VS .NETがWindows＋.NET Frameworkのスタンダードな統合開発環境と考えて間違いないだろう。
Windows＋.NET Frameworkの「オールインワン」型の精神は、ここでも活きてくる。つまり、Eclipseがプラグイン・アーキテクチャを特徴とするのに対して、VS .NETでは導入したその場ですべての開発環境が整っている。VS .NETでは、変化の多いフロントエンドを、Webアプリケーション、Windowsアプリケーション、モバイル・アプリケーションを問わず、同一の感覚で、しかも、コントロールをフォーム・デザイナ上にドラッグ＆ドロップするだけで簡単に構築することができるのだ。 昨今では、Sun Java Studio Creator（日本サンのSun Java Studio Creatorの解説ページ）やEclipse上で動作するIBM Rational Software Development Platform（日本IBMのIBM Software Development Platformのページ）など、統合的な開発、RAD（Rapid Application Development）を強く意識した製品群も登場しつつあるが、フォーム・デザインのこなれた操作性は、やはりVS .NETに一日の長がある。 さらに、VS .NETを使うことで、リッチ・クライアントにも容易に対応できるという点は、大きな魅力だ。Webアプリケーションが業務系システムとして採用される機会が多くなってきた昨今、ブラウザの操作性の低さが現場の入力生産の低下に直結しているケースを多く見かける。このような場合の新たな選択肢として、近年注目を浴びているのが「リッチ・クライアント」なのだ（リッチ・クライアント導入の利点、問題点などについては、「リッチ・クライアントから見るWebアプリケーション開発の将来（Wingsプロジェクト）」などが参考になる）。 Windows＋.NET Frameworkは、それ自体、リッチ・クライアントにネイティヴに対応するプラットフォームだ。例えば、Windowsアプリケーションとして開発していた「クライアント・サーバシステム」をWeb展開するならば、「スマート・クライアント」（Insider.NETのスマート・クライアント関連記事）」を利用することでシームレスに移行できる。VSTO（Visual Studio Tools for Office）を導入すれば、Office連携のWebシステムも簡単に作成できるのだ（Insider.NETのVSTO関連記事）。VSTOは次期Visual Studio 2005で更に強化される予定で、Visual Studio上でExcelワークシートの設計も統合的に行うことができるようになる。
Webアプリケーションが、いわゆる従来のデスクトップ・アプリケーションと大きく異なる点がある。それは「ユーザー数が必ずしも事前に想定できないこと」だ。つまり、従来のアプリケーションではあらかじめユーザー規模を想定したインフラ投資を行うことが可能であった。もちろん、Webアプリケーションでも、あらかじめユーザー数を想定した上で設計／インフラ投資を行うのは当然であるが、必ずしも現実がそれに伴うとは限らない。いざシステムをカットオーバーしてみたら、当初予想していたよりもはるかに多くのユーザーがアプリケーションを利用し、結果として、期待するパフォーマンスが発揮できないというケースはまれではないのだ。Webアプリケーションを構築する上で、開発者はパフォーマンスとスケーラビリティに腐心するのはこのためだ。 Windows Server 2003に搭載されている最新のWebサーバIIS 6.0は、外面的なインターフェイスこそIIS 5.xからさほどの変化は見られないものの、内部的なアーキテクチャはほぼ全面的に刷新され、処理パフォーマンス、堅牢性ともに格段の進化を遂げている。以下図は、IIS 6.0の内部アーキテクチャを示したものだ。
IIS 6.0では、IIS 5.xでInetinfo.exe単体により実装されていたコア・モジュールが「HTTPリスナ（Http.sys）」「Web管理サービス（WAS）」「ワーカー・プロセス（w3wp.exe）」の3つに分離されている。 HTTPリスナは、Webサーバの基本的な入出力の部分を担うモジュールだ。図を見てもお分かりになるように、IIS 6.0ではHTTPリスナがカーネルモードで動作する。これによって、処理に際してユーザモードに切り替えるオーバヘッドを最小限に抑えることができる。特にコンテンツ・キャッシングが有効になっている場合、ユーザモード上のワーカー・プロセスへの問い合わせが発生しないため、大幅なパフォーマンスの向上が期待できるというわけだ。 また、個々のアプリケーション・プロセスをつかさどる「ワーカー・プロセス」がHTTPリスナから完全に独立しているのも大きなポイントだ。ユーザー・アプリケーションが動作するワーカー・プロセスは、サーバ運用の上で最も「信頼できない」部分でもある。これをサーバのコアから独立することで、サーバの安定性を向上することに成功している。 そして、これらワーカー・プロセスを上位から常時監視するのが「Web管理サービス（WAS）」の役割だ。WASを利用することで、異常なプロセスをリサイクルしたり、プロセスそのもののタイムアウトを管理できるため、サーバ・リソースを最大限効率的に利用できる（WASによる監視の詳細については、「［ASP.NET］IIS 6.0でワーカー・プロセスの挙動をカスタマイズするには？（Insider.NET／.NET TIPS）」などを参照いただきたい）。 これら内部アーキテクチャの刷新によって、IIS 6.0はわずかなパラメータの設定のみで絶大なパフォーマンスとスケーラビリティを実現することができるようになった。IIS 6.0を搭載したWindows Server 2003とLinuxとのWebサーバ性能比較については、VeriTest（Lionbridge Technologies, Inc.の一部門）によるレポートが詳しいので、興味のある方は合わせて参照してみると良いだろう。本レポートによれば、静的コンテンツにして276％、動的コンテンツにして63％、Windows Serverがより高いスループットを記録したという。
|
|
