スケーラビリティをとるか、性能をとるか--トレードオフを考える

　読者はスケーラビリティを備えたアプリケーションを作っているだろうか。私も作っている。私の長年の心の葛藤の1つは、スケーラビリティを確保するためにアプリケーションに加えるレイヤの1つ1つが--特にウェブアプリケーションでは--そのアプリケーションの性能低下に繋がるということだ。

　よくあるパターンは、データベースとやりとりするデータアクセスレイヤとやりとりするビジネスロジックレイヤとやりとりするプレゼンテーションレイヤにクライアントとやりとりさせる、というものだ。これは筋が通っている。そして各レイヤの将来の拡張に向けた相互運用性と再利用性のためには、結局は最低でもXML、あるいはSOAPやそれに類するもの（CORBAを覚えている人はいるだろうか？）を使うことになる。これも筋が通っているので、またいくつかのレイヤを付け加えることになる。また、もしアプリケーションに十分な数のユーザーが付けば、各レイヤ内で状態を共有する手段が必要になるため、各レイヤにクラスタリング技術を付け加えることになる。最終的に、大量の同時要求を処理するために、セッションレイヤやアプリケーションレイヤなどでサーバ間での状態やロックを管理を行う必要が生まれる。

　現実を直視しよう。ビジネスロジック処理サーバを加えることを考えなければならないほど大きさのシステムを考えているが、プレゼンテーションロジックサーバを加える必要がなければ（これらのスケールは異なる割合で増大する）、それは、ある程度の冗長性、フェイルオーバー、負荷分散などを必要とするだけの大きさと重要さを持ったアプリケーションだ。そしてそれは、共有される「もの」のクラスタリングが必要であることを意味する。

　この規模のアーキテクチャが必要であり、2、3のXMLトランザクションのエラーの追跡と（最低限）3つの論理サーバ（それらはすべて同じハードウェア上にあるかも知れない）、そして監視ソフトウェアが必要だと仮定して考えてみよう。

　厄介なことになった。言うのは簡単だ。「では、アプリケーションロジックとプレゼンテーションロジックとデータアクセスロジックを全部同じレイヤに入れよう。もしハードウェアが落ちたら、セッションは失われるけどな」。しかし、われわれは顧客に99.999％の信頼性とSLAと性能指標と仕事を売る世界に住んでいる。われわれのアプリケーションは高速で、スケーラブルで、かつ堅牢でなくてはならない。そして「スケーラブル」であることと「堅牢」であることは、「速さ」にはマイナスだ。

　Javaのフレームワークの大失敗がよい例だ。一般的なJavaアプリケーションサーバ上でアプリケーションを構築し、その上に世に出ている無数のフレームワークを乗せたとする。Spring、Struts、FacesといったJavaのキーワードはいくらでもある。そして、例えばわざとNullPointerExceptionを起こし、スタックトレースを調べるようなばかなことをしたら何が起こるだろうか。このヌルの値は、例外処理に渡される前に80以上ものレイヤを通ることになる。ここでは例外が起こったことを問題にしているわけではない。私が問題にしているのは、その変数を処理するのにどれだけのオーバーヘッドが必要になるかということだ。PerlやPHPやRubyの小さなスクリプトで同じことをやれば、この変数がランタイムの例外レベルに到達するまでに、通り抜ける関数の数は少数だろう。

　これが、.NetやJavaが決してネイティブコードほど速くならない理由だ。ネイティブコードを書ける人は、OSとアプリケーションの間に2、3以上のレイヤを置くことは滅多にない。これらの何でも詰め込もうとする大量のフレームワークでは、何かをやる度に50から150のデータをスタックにコピーする。