先日紹介したnaoyaさんのTechknow Movable Typeの最近の回でMTにおける中〓大規模サイトでのシステム構成という記事があります。
Blogに関しては完全にユーザーの視点からしか見てきてなかったので(本業では関わってませんので)、一転して設計者/運用者側からの視点としてなかなか面白く読みました。
その中での、MTにおける三層モデルによるスケーラビリティへの対応策を見て、考え込んだことがあります。
それはMTでの大規模サイト構築は本当に可能なのだろうか、ということです。
* 以下、これは批判ではなく、考察として捉えて下さい。

いや、可能かと問えば物量を持ってすれば、(経験上でだけですが)どんなシステムでも可能でしょう。より正確には、果たして根本的なアーキテクトとして本当に大規模システムに向いているのだろうか、というのが私の疑問なのです。
この記事を読めばMTサイトの高負荷要因は二点あることが分かります。一点目は再構築による負荷、二点目は閲覧ユーザーによるアクセス負荷です。
MTでは動的なコンテンツ生成ではなく再構築というステップによりこの両者の負荷を切り分け、それぞれへの対処を可能にしているというのが大きな特徴でしょう。結果的にですが、この記事にもあるようにアプリケーションサーバーとWebサーバーで負荷が分割できることがメリットとなっています。
しかし私が引っかかるのは、その結果必要となるファイルサーバーが実は全てのパフォーマンス要因を握る結果ともなっている点です。
ファイルサーバーへのI/Oがボトルネックとなれば、アプリケーションサーバーによる再構築にもユーザーからの閲覧にも影響が出るのは必至です。また、今日的な観点からはディスクアクセス改善こそが最もコストパフォーマンスと効率の悪いチューニングポイントであることは自明の理ではないかと思います。
もちろんここのみが問題となるのであれば数億程度の投資でRaid-Arrayシステムでも何でも投入すればいいのですが、もしハードウェアによる補填をせざるを得ないシステムであれば、その前に何らかのアーキテクト的な問題が潜んでいるはずではないか？というのが正直な感覚でもあるのです。
同時に、以下のような点も背景として存在しているはずです。

• 少なくともMTはPerlベースのCGIを前提としたオーソドックスなWebアプリケーションサーバーの延長線であること。つまりコンテンツの頻度の高い動的生成はパフォーマンス上致命傷に大いになり得る(これは他の考え得るまたは既存の他の実装モデルと比較して)ことを前提に捉えている
• 結果的に、Webサーバーとアプリケーションエンジンを分離するのは基本的には困難。これは例えばJ2EEベースのサーブレットコンテナのようなWeb-アプリケーションサーバー間ゲートウェイプロトコル(AJPなどのような)が存在していないためでもある。
  三層モデルを採用した場合に、Web-アプリケーションサーバー間連携をファイルサーバー経由とするのは苦肉の策とも見える。

つまりMT(に実際は限らない話であることはお気づき頂いているかもしれませんが)は、所謂アプリケーションエンジンとして実装されるべきではないか、と思うのです。
Webサーバーと完全に切り分けられ、かつリアルタイムに連携でき、アプリケーション実装も再構築に依存するぐらいならよりLightWeightな実装(別にPerlが悪いという意味ではありません)もあり得るのでは。実際世の中には多くが動的生成な大規模サイトも既に数多く存在している訳ですから。
動的生成に対する負荷については、より対象範囲が広くしかもユーザー自身が実施してしまう再構築よりは、よりピンポイントに必要箇所のみを生成できるという見方もできるでしょう。
また動的生成だからと言って毎回閲覧時に発生するとも限りません。必要なければ(変更されていなければ)行わない、というオプションも当然技術的には可能でしょう。
同時に、もしWebサーバーにファイルサーバーを連携させるのではあれば、キャッシュサーバーとして動作させることも考えられます。動的コンテンツだからキャッシュに向かない、ということはありません。記事でも指摘されているように、爆発的に投稿記事や管理頻度が高くならない限り(コンテンツの新鮮度が極端に高くならない限り)はキャッシュはより有効に働くでしょう。
特に、全てのコンテンツを保持するようなファイルサーバーよりはよりコストも安くなり、コストパフォーマンスの面からも優位と思われます。
言い訳がましいのですが、私はそれほどこのBlogの業界やシステムに詳しい訳でもありません。
既にどこかで言い尽くされた議論なのかも知れませんし、こうした発想のシステムというのは既にどこかに存在しているかも知れません。
(というか、可能性は高い。zopeベースのシステムなどはそうなのでしょうか。もしもそうなのであれば、ぜひ私まで教えて頂ければ幸いです)
しかしMTは取りも直さず、今後もBlog製品としてのリファレンス・モデル足り続けることは想像に堅くありません。実際、世のBlog製品の多くはMTをお手本に発展してきた、またはこれからもリファレンスし続けるのは間違いないでしょう(ちょっと、言い過ぎかな・・)。
と同時に、現在のBlogという分野は必然的にCMS(Contents Management System)として再構築されつつある過程ではないかとも思っています。
つまり、クライアントもブラウザだけではなく、各種Blogクライアントによるより綿密なコンテンツ管理や、他社Webサービス、プロトコルなどの連携などというのも当然視野に入ってくるはずです。
その時にポイントとなるのはアーキテクトとして柔軟性を持ちうるかどうかです。どのようなシステムにおいても、こここそが拡張性やメンテナンス性、品質を左右するのは変わらないからです。
果たしてMTがどのような選択を今後行っていくのか(若しくは利用ユーザーが、も含めて)、興味深く眺めていきたいと思っています。
# 因みにここまで書いて、どこかのBlogで「何故ココログはあんなにいろいろなDNSドメイン名でBlogを運営しているのだろう」という疑問を書かれていたことを思い出しました。
DNSドメインを分ける理由は幾らでもあるとは思うですが、ひょっとすると内部的にも複数の物理ドメインに分けざるを得ない(分けた方が効率がいい)理由がどこかにあった・・というのは穿った見方過ぎでしょうか。。