非ハッカーが読むPaul Graham

Graham氏がWebベースへのシフトの理由としてまず挙げるのは、配布の容易さです。

この新世界における最も重要な変化のひとつは、リリース方法だ。デスクトップソフトウェアビジネスでは、リリースはでっかい頭痛の種だ。会社を挙げて頑張って、ひとつの巨大なコードの塊を仕上げる。それと比べてみれば、開発プロセスと結果の製品の両方で、変化を見て取ることができる。

サーバベースのソフトウェアでは、自分用に書いているプログラムとほとんど同じような感じで変更を加えることができる。ソフトウェアのリリースは、たまにある爆発のようなものではなく、段階的な変更の連続になる。普通のデスクトップソフトウェア会社は、年に1～2回、リリースするだろうか。Viawebでは、ときには1日に3～5回のリリースをすることがあった。

これは企業向けシステムの場でも同じことで、Webベースへのシフトの理由として広くコンセンサスを得ています。ただ、Graham氏はもうひとつ、ハッカーの視点で面白い指摘をしています。

コンピュータの価格がこれだけ下がったため、我々がやったように、誰もがデスクトップコンピュータをサーバとして使って始めることができる。安価なプロセッサはワークステーションの市場をすっかり喰い尽くし(今では「ワークステーション」という言葉を聞くことさえ滅多になくなった)、そしてサーバの市場にも大きく食い込んでいる。インターネット上でおそらく最も多くの負荷をさばいているサーバのひとつであろうYahooのサーバは、デスクトップマシンが使っているのと同じ、安価なIntelプロセッサを使っている。

今では銀行が使うような超巨大コンピュータシステムと(H/Wの性能以外は)基本的に変わらないシステムを、高校生でも持つことが出来ます。当然、新しいアイデアやテクノロジーはそういった層から発生します。大企業の社員しか使わないようなテクノロジーがインターネットの世界でメインストリームを維持することはないことは、直感的に理解できます。

もう一つ、Graham氏の指摘で興味深いのは、彼がプログラムと(OSやH/Wなどの)インフラストラクチャを、一体のものとして扱うべきと指摘していることです。

しばしば、WebベースソフトウェアはISPをリセラーとして提供される。これは悪いアイディアだと思う。自分でサーバを管理すべきだ。それによって、ハードウェアとソフトウェアの両方を常に改良してゆくことができる。サーバへの直接の制御を手放したら、Webベースアプリケーションを開発する利点の多くを手放すことになる。

たしかに、Webベースの特徴であるスピード感を最大限に活かそうと思えば、それは必須でしょう。サーバの運用をISPに委託すれば、そこに『リリース』の負荷が生じます。ただこういったプログラマ自身がサーバを運用する形のビジネスでは、Graham氏も指摘するとおり、プログラマが常に機器のトラブルに脅かされ過大な負担を負う可能性が高いといえます。

これに対する解答は、Googleが示しています。

CNET Japan　いま明かされる、グーグル・データセンターの秘密

　同社は、Google File Systemと呼ばれる自前のファイルシステムも開発した。これは、64Mバイトという巨大なデータブロックの処理に最適化されている。このファイルシステムがディスクの障害やネットワークケーブルの抜けといった障害を想定した設計になっているのも重要な点だ。

　データも3重に複製されて、それぞれ別の場所に保存されている。また、キーワードのインデックスといったデータについては、オリジナルが使用不能になった場合に、複製の在処を探し出せる「マスター」マシンも用意されている。

　「ソフトウェアが障害に耐えられるようにしておくことが重要だ。障害が想定できれば、低価格のコモディティPCでもインターネットサービスに使える」

アプリケーションとインフラストラクチャが融合しつつ、その融合によるテクノロジーが運用の負荷を著しく軽減させているという点で、GoogleはGraham氏の指摘を超えて時代の先端を走っていると感じます。ただ、これはGoogleというスーパーギーク集団だからできることであって、同じ思想のシステム開発がどこのソフト会社でもできるというわけでは、もちろんありません。

僕がこの文章を読んで気になったのは、Graham氏がJ2EEについて全く言及していないことです。ただ僕が先に挙げた「低いコストでその技術に触れられる」「アプリケーションとインフラストラクチャが統合されている」という点について考えると、現在のJ2EEはその正反対の方向を向いているような気がします。

まず、使ったことのある方はご存知の通り、商用のJ2EEアプリケーションサーバは非常に重たいものです。普通のPCでJ2EEアプリケーションサーバとRDBMSを動かそうと思うと、メモリには1GBあっても足りません。またJ2EEはある程度大きなプログラム開発を想定された仕様であり、小さなアプリケーションでは(つまりWebアプリケーションの特長が活かされる程度の大きさでは)無駄が生じやすいのです。

もうひとつ、システム運用をするものにとっては、J2EEはアプリケーションとインフラストラクチャを分離するものである、という事実があります。どんなアプリケーションであれ、そのアプリケーションがJ2EEであれば、システム運用担当者はJ2EEアプリケーションサーバを運用すればよく、その上にどんなアプリケーションが載っていようが関係ありません。これはシステム運用担当者にとってはありがたいことですが、Webアプリケーションの特長についてのGraham氏の指摘とは全くの正反対です。

こう考えると、J2EEはかつてメインフレームがたどった道を歩んでいるのではないか、と感じます。それは単に『滅びる』ということではなく、代替の利かないある領域ではしっかりと生き残るが、その領域は次第に狭まっていくだろう、という意味です。

この文章は2001年の作ということですが、その指摘は本質を突いていて今でも非常に刺激的です。ハッカーだけではなく、僕のようなシステムエンジニアなヒトにもぜひ読んでみていただきたい文章です。