2004-08
30
07:41:00
MTによる大規模サイト構築は本当に可能か


先日紹介した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ドメインを分ける理由は幾らでもあるとは思うですが、ひょっとすると内部的にも複数の物理ドメインに分けざるを得ない(分けた方が効率がいい)理由がどこかにあった・・というのは穿った見方過ぎでしょうか。。

MTによる大規模サイト構築は本当に可能か」への3件のフィードバック

  1. ビューを生成する方法についてですが、MTでは静的生成の他に、今ではほとんど保守されていないようですがCGIによる生成(mt-view.cgi)と、PHPによる生成(MT3.1からサポート)が用意されています。

  2. naoyaさん、始めまして。いつも記事を読ませて頂いています。また、コメントをありがとうございます。
    >・Movable Type はコンテンツ部分は動的生成ではなく静的
    >生成 (記事投稿時に html ファイルを作成する) のですが、
    >ここでの動的とはどういった点にあたるのでしょうか。
    もちろんMTで動的生成が行われているという意味ではありません。
    ここではCGIなどで逐次HTMLを生成するような一般的な動作のことを示しています。MTの再構築による静的生成への対語として使用しています。
    >・まだ Techknow Movable Type には書いていないのです
    >が、Movable Type は mod_perl ハンドラとしても動作し
    >、その場合 reverse proxy と組み合わせて使うことで
    >J2EE の AJP プロトコルと同様のアーキテクチャを取ること
    >ができます。また、そのこととファイルサーバの I/O とが
    >どのように関係するのかがよくわからないのですが、ご教示
    >いただけますか?
    一点確認させて下さい。
    静的生成、動的生成の話とも絡んでくる訳ですが、mod_perlハンドラを有効にした運用であっても、コンテンツの閲覧は静的生成されたコンテンツが対象になる訳ですよね。(でないとすると、私の考えは全く持って間違っていることになるのですが)
    であるからこそ、三層構造化した場合、ファイルサーバーの位置付けが重要となってくる。つまり、静的生成が全ての前提である以上、ユーザーによる閲覧はMT(この場合のアプリケーションサーバー)には関わらず、前面のWebサーバーとファイルサーバーに閉じたものになるはずであり、また静的生成においては(再構築リクエストなどがWebサーバー(reverse proxyということにもなるでしょうか)を経由するにしても)MTがファイルサーバーに対して実施することになるはず。故に、この三層構造が問題なく動作するためにはファイルサーバーのI/Oボトルネックが起こらないことが前提となるはず、という理屈です。
    # 頂いているご質問を読む限り、かなり分かりにくい文章になっているようですね。
    すみません(ペコリ
    >手前味噌ですが、ココログや Blogzine などは Movable Type を
    >ベースとした TypePad のシステムで、数万人ユーザに対して数億
    >アクセスを先の Techknow Movable Type の記事とよく似た
    >アーキテクチャで実現していますので、Movable Type でも同様の
    >スケーラビリティを確保することは可能だと思います。
    なるほど、実績としては全く問題ない訳ですね。これは強いですよね。
    事実ココログでは大きなトラブルも聞きませんし。
    ただ、これはちょっとキャッチャー過ぎたタイトルを付けた私が悪いのですが、
    この文章で論点にしたかったのは、大規模向けを想定した場合に、アーキテクトから考えるとすると他にもより良い選択肢があるかも知れない、何故ならオールマイティーにベストなシステムなんてものは無いでしょうから。ではそのポイントはどこにあるだろうか、ということなのです。
    # ど素人の戯言にお付き合い頂いて恐縮です。
    今しばらく、ご意見交わさせて頂ければ大変幸いです。

  3. こんにちは、興味深く読ませていただきました。
    何点かわからない点がありましたので質問させてください。
    ・Movable Type はコンテンツ部分は動的生成ではなく静的生成 (記事投稿時に html ファイルを作成する) のですが、ここでの動的とはどういった点にあたるのでしょうか。
    ・まだ Techknow Movable Type には書いていないのですが、Movable Type は mod_perl ハンドラとしても動作し、その場合 reverse proxy と組み合わせて使うことで J2EE の AJP プロトコルと同様のアーキテクチャを取ることができます。また、そのこととファイルサーバの I/O とがどのように関係するのかがよくわからないのですが、ご教示いただけますか?
    手前味噌ですが、ココログや Blogzine などは Movable Type をベースとした TypePad のシステムで、数万人ユーザに対して数億アクセスを先の Techknow Movable Type の記事とよく似たアーキテクチャで実現していますので、Movable Type でも同様のスケーラビリティを確保することは可能だと思います。

コメントを残す

メールアドレスが公開されることはありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)