Loading
|
@IT > Webアプリケーション・プラットフォームとしてWindowsを選択する7つの理由<後編> |
企画:アットマーク・アイティ
営業企画局 制作:デジタル・アドバンテージ 掲載内容有効期限:2005年2月28日 |
|
|
本稿では、中小規模のWebアプリケーション・プラットフォームとしてWindowsを選択する理由を、7つのポイントから解説している。開発生産性の観点から紹介した前編に引き続き、後編の今回は、運用/保守性の観点にフォーカスしてみよう。
ただ単に“Linux”といった場合、厳密にはカーネルのみを指す。前回掲載の図「Windows+.NET Framework/Linux+フリーJavaの構造」をご覧いただいても分かるように、Linuxをアプリケーション・サーバとして実運用させるには、開発主体が異なる複数のプロダクツを組み合わせるのが、なかば必須である。これは、開発時における選択の柔軟性という意味では有利な場合もあるが、運用/保守といった局面では、明らかにシステム管理者の負担となることの方が多い。 というのも、Linuxサーバを構成する複数のプロダクツが、必ずしも足並みを揃えて継続的にサポートを行う保証はないからだ。例えば、現在のJava環境におけるスタンダードなフレームワークと目されるApache Strutsですら、先年仕様が確定したJSF(JavaServer Faces、米SunのJSFの解説ページ)の登場によって、将来性を危ぶむ声は大きいのだ。そもそも、さまざまなプロダクツの統合体であるLinux+Javaシステムにおいて、各種プロダクツのサポート状況、将来的なロードマップをリアルタイムに追うだけでも、開発者にとっては大きな負担であろう。 そして、たとえ十分な現状追跡を行っていたとしても、これだけ変化の激しいLinux+フリーJavaの世界では、既存プロダクツの開発打ち切りという憂き目に遭うことも完全には避けられない。万が一、システムを構成するプロダクツの1つが開発を打ち切られたら、我々の選択肢は次のいずれかである。1つは、該当のプロダクツについては、以降のバグ/セキュリティ・フィックスを自前で行うこと。もう1つは、サポート対象外となったプロダクツを代替するほかのプロダクツを組み込むことである。しかし、いずれの選択肢も現実的でないことは、読者諸兄も直感的にお分かりになるはずだ。 自前でバグ/セキュリティ・フィックスを行うには、当然のことながら、そのプロダクツの構成を熟知している必要がある。不用意な修正は、新たなバグや新たなセキュリティ・ホールの温床にもなりかねないのだ。だが現実的に考えて、中小規模レベルの開発で、そこまでのスキルを持ったプログラマを確保するのは至難の業だ。よしんば、高いスキルを持った人間がいたとしても、すでにサポートが終了した「消え行く」プロダクツを保守するために、優れたプログラマの工数を費やしたいだろうか。否、このようなプログラマにお願いしたいことは、ほかにいくらでもあるはずだ。優れたプログラマを、そのような「後ろ向きの作業」にいつまでも従事させられるほど、ゆとりのあるプロジェクトは稀だろう。 一方、ほかのプロダクツで代替するという方法は、いかにも抜本的な解法にも思えるが、当然のことながら、異なるプロダクツ同士の組み合わせには、多くの不確定要素がはらむ。これまで問題なく動作していたシステムが、プロダクツをバージョンアップしただけでも動作しなくなったなどはよくある話だ。ましてや、同等機能を持つが、異なる背景や思想を持ったプロダクツで置き換えて、アプリケーションに何の影響も及ばないわけがない。運用中のプロダクツを入れ替えるには、影響個所の特定から検証作業、そのほか細部に渡る変更などを含め、相当に大きな工数を要することを覚悟しなければならない。 これに対し、Windows+.NET Frameworkの組み合わせは、あくまで高度に統合された「オールインワン」型のシステムだ。また、現行の.NET Framework 1.1から2005年後半に提供予定の.NET Framework 2.0、そして、Longhornで搭載されるWinFXと、すでに数年先までのロードマップが明確に示されている(詳細は関連記事)。バージョン間の互換性について詳細は不明であるものの、現行の.NET Framework 1.1をベースとした発展的バージョンアップが行われるものと思われる。長期的なシステム運用にも十分に耐えられる情報とアプリケーション基盤とが、すでにWindows+.NET Frameworkでは提供されているといってよい。
Webアプリケーションの運用管理といった側面で、Windows+.NET FrameworkとLinux+フリーJavaの決定的な違いは何だろうか。いうまでもない、設定やカスタマイズを行うのがGUIベースであるかどうかという点だ。 Windows+.NET Frameworkの世界では、原則として、Webアプリケーションに関する設定作業のほとんどを、以下の「インターネット インフォメーション サービス マネージャ」上で行うことができる。
なお.NET Framework 1.1では、テキスト・エディタ・ベースで編集しなければならなかった構成ファイル(machine.config/web.config)の設定についても、次バージョンである.NET Framework 2.0で追加される専用の管理ツールによってGUIベースの設定が可能になる予定である。さらにこの2.0では、Webベースのサイト管理ツール「ASP.NET Web Application Administration」も搭載される予定だ(これらツールについては関連記事」が詳しい)。
こういったツールを利用することで、必ずしも経験豊富でないシステム管理者であっても、一定レベルの管理/カスタマイズが可能となる。また、昨年末に発表されたMOM(Microsoft Operations Manager)2005を利用すれば、ネットワーク上の複数のWindowsサーバの運用監視を集中化することが可能だ。MOMには、管理対象となるコンピュータやアプリケーションごとに「管理パック」と呼ばれるアドインを追加するのだが、その気になれば管理パックは自作可能であり、独自のWebアプリケーション用の管理パックを開発すれば、これも合わせてMOM 2005で一元管理が可能になる(MOM 2005の詳細は関連記事を参照)。
片やLinux+フリーJavaの世界はどうだろう。例えば、最も代表的なWebアプリケーション・サーバであるApacheですら、標準的なGUIツールは存在しない(あえていえば、Comanche(COnfiguration MANager for apaCHE)のような管理ツールも存在しないではないが到底一般的に用いられているとはいえない)。多くのシステム管理者が設定ファイルを直接エディタ上で編集しているというのが実情だろう。また、JSP&サーブレット・コンテナとして有名なTomcatには、Tomcat AdministratorやTomcat ManagerなどWebベースのGUIツールもあり、徐々に現場でも利用されるようになってきている。しかし操作性という意味では、IISマネージャのような洗練された使い勝手にはなかなか及ばないのが実情である。 もっとも、設定ファイルを直接エディタで編集するのは悪いことばかりではない。Linux+フリーJavaの世界に精通している人間ならば、むしろツールの制限に縛られずに柔軟な設定ができるという利点もある。しかし、Apache標準の設定ファイルであるhttpd.confひとつをとっても、設定可能なパラメータ(ディレクティブ)の数は膨大だ。これらを適切に設定して、効率的かつ安全なシステム運用が可能かどうかは、システム管理者の技術レベルや経験、知識レベルに大きく依存することになる。 今後、ますます我々が扱うべき情報システムは増加するはずだ。その流れの中では、優れたシステム管理者を育てることももちろん重要である。しかしそれ以上に、管理者のレベルによらない平準的な管理を可能にするシステム環境を用意することが、結果としてシステム全体の信頼性や安全性、性能を向上し、TCOを低減させるうえで重要になってくる。
情報システムが、これだけ日常的な業務フローに密接なかかわりを持つようになった昨今、障害時の復旧をいかに迅速に行えるかは、システムの重要な要件の1つであるといってよい。例えば、顧客からの注文を受け付けている受注サイトならば、1分1秒のシステム・ダウンが機会損失にもなり得るのだ。もちろん、障害は発生そのものがあってはならないことであるが、万が一障害が発生した場合には、一刻も早く復旧させることが、システム部門には求められている。 このような障害対応にも「オールインワン」型のWindows+.NET Frameworkは大きな強みを発揮する。というのも、Windows+.NET Frameworkでは、障害発生時の原因もWindowsという単一のプロダクツにフォーカスできるからだ。つまり、マイクロソフトによるワンストップ・サポートが受けられるということである。プロダクツごとに、異なる窓口やアクセス手段、ルールに従いながら、試行錯誤を繰り返す必要はない。また、そもそもマイクロソフトでは、プロダクツの障害に対する解決方法や回避策、設定方法のちょっとしたヒントなどの膨大なデータベースを、「サポート技術情報」としてサイト上で公開している。これはシステム管理者にとっては嬉しいナレッジの蓄積だろう。このような情報が一元的にまとめられているのも、Windows+.NET Frameworkの優位点だ。 一方、Linux+フリーJavaのシステムは(繰り返し述べているように)複数のプロダクツから構成されるのが一般的だ。障害時の原因特定にも、まずは問題がどのプロダクツにあるのかを特定するだけでも苦労する場合がある。不具合の原因がプロダクツ間の連携や複数プロダクツにまたがる部分にある場合には、原因の特定は容易ではない。また、Linux+フリーJavaでは、プロダクツごとにドキュメントが散在するのは不可避であり、場合によってはそもそもドキュメントそのものが整っていないものもある。またドキュメントがあっても、手に入るのは英語ドキュメントだけで、読みこなすのに苦労するというケースの方が圧倒的に多い。 こうした差異を「単なる慣れの問題だ」と片付けられるシステム管理者は、おそらく相当に高度な管理能力を持った人だろう。しかし[その5]でも論じたように、現在のシステム管理に求められているのは、卓越した能力を持つ1人の管理者よりも、凡庸な100人の管理者でも運用可能なシステム基盤なのである。
前編の冒頭でも述べたように、俗にいう「Windows嫌い」の人の多くは、その理由として「Windowsがセキュリティ的に脆弱である」点を挙げることが多いようだ。確かにWindows+IISでは、大きな被害をもたらしたCode RedやNimdaなどのコンピュータ・ワームのイメージが強い。特にシステム管理者にとって、これらの影響はあまりに大きかったため、Windowsを否定するノックアウト・ファクター*として何かにつけて持ち出される結果となっている。しかし、これらの論評は果たして現在でも正しいのだろうか。
結論からいえば、これには大きな誤解がある。まず、CodeRedやNimdaの被害を受けたのはWindows Server 2003以前のWindows 2000 Serverの時代である。周知のとおり、Windows Server 2003では、さまざまなセキュリティ機能が強化されている。 また公開されているセキュリティ情報の数を見れば、決してLinuxが少ないわけではない。これは実際に米BugTraqによるセキュリティ情報一覧を見れば、厳然とした事実が見て取れるはずだ。
セキュリティ情報ベンダとして著名なSecuniaは、IISとApacheのセキュリティ情報の数を月別に集計して公表している。これを見ると、Windows Server 2003に付属するIIS 6では、ほとんどセキュリティ情報が公開されていないことが分かる。
また、こうした脆弱性が発見された場合に重要となってくるのが、セキュリティ・ホールの修正までにかかるリードタイムだ。LinuxやフリーJavaのようなオープンソース系プロダクツは、「ソースを自身で解読し修正できるから、対応が迅速に行える」という話を聞く。これもまた、もっともらしく語られる論説の1つであるが、到底現実的とはいえない。 ここまでにも何度か解説してきたように、オープンソースのコードを解析し、影響個所を適切に判断した上で修正を行える技術者がどこまでいるだろう。また、自社でそれだけの工数をかける余力がどれだけあるだろう。はたまた、そうした自前の修正が将来のバージョンアップの大きな障害になることを理解していながら、実行するメリットがどこまであるだろう。オープンソース製品であろうとも、結局は各ディストリビュータが正式に公開する更新プログラムを待つのが、現実的な解ではないか。 マイクロソフト、及びLinux各ディストリビュータの対応スピードの比較についてはForrester社のレポート「LinuxはWindowsより安全なのか(Is Linux More Secure Than Windows?)」が詳しいので、興味のある方は併せてご覧いただくとよい。本レポートによれば、(例えば)SUSE Linuxがおおよそ54日平均でセキュリティ・パッチを公開しているのに対して、Windowsでは25日平均で公開を行っており、その差は歴然としているといえるだろう。 ■ 以上、Webアプリケーション・プラットフォームとしてWindowsを選択する理由について、7つのポイントから解説した。 しかし、ここで勘違いしていただきたくないのは、本稿が決して「いついかなる場合もWindowsの選択が好ましい、と主張しているわけではない」ということだ。しごく当然のことではあるが、WindowsにはWindowsの、LinuxにはLinuxの適材適所がある。Windows+.NET Frameworkが、そして、Linux+フリーJavaがそれぞれの文化のもとでそれぞれの歴史を背負っている以上、それは当たり前のことだ。だが、ともすると、もっともらしいが確固たる根拠に欠ける論評や風評が、この当たり前の事実を見失わせてしまう場合がある。その典型が「中小規模のWebアプリケーションを安価に構築するならば、Linux+フリーJava」という主張だ。しかし今一度、落ち着いて考え直してみよう。Windows+.NETは本当に候補にならないのか。Linux+フリーJavaは本当に求める要求に応えてくれるのか。 プロジェクト予算が限られているからといって、目先のイニシャル・コストにとらわれるのは危険である。目先のコストに限定するならば、フリーJavaに軍配が上がるのは当然だ。しかし、現実的に考えてみていただきたい。システム開発にかかるコストは初期のライセンス・コストばかりではない。開発コストや技術者の学習コスト、カットオーバ後の運用/保守コストなど多岐にわたる。これらトータル・コストという観点から見たときに、はたしてフリーJavaに無条件に軍配があがるのか。 本稿が、先入観にとらわれず、ご自身にとって本当に最適なWebアプリケーション・プラットフォーム選びの一助になれば幸いである。
|
|