スケーラブルWebサイトでの総称データストリームとユーザ固有データストリームの対比

作者 Gavin Terrill, 翻訳者 編集部 投稿日 2008年3月9日 午後12時5分

コミュニティ

Architecture

トピック

パフォーマンス&スケーラビリティ

タグ

Caching,

ロードバランシング

著者であり、ITコンサルタントのGojko Adzic氏(サイト・英語)が、拡張が容易なWebアプリケーション向けの静的コンテンツを分割するアーキテクチャー上の利点に関して、動的コンテンツとの比較を交えて、興味深い記事(source)を書いた。

拡張が容易なWebサイトプロジェクトで早期にしなければならない、重要なアーキテクチャー上の決断は、データフローを2つに分割することである。1つはユーザ固有で、もう1つは総称である。

このようにデータを区分する主な論理的根拠は、それぞれのデータ使用に関する制約がそれぞれ別のキャッシュと状態管理アプローチに基礎を置いているからである。

たとえば、ほとんどの総称データフローは完全にステートレスだが、ユーザ固有のアクションはステートフルであることがよくある。この2つのフローが明確に 分けられていれば、総称アクションをステートレスサービスやサーバで処理することができる。ステートレスサービスはステートフルサービスよりも管理および スケールがずっと容易であるが、それはシステム操作に影響を与えずに簡単に置換されるからである。パワーがさらに必要な場合、さらに多くのチープサーバを スタックして、ラウンドロビンや単純なロードバランシングで要求することができる。ステートフルサービスはそのように簡単にスケールできないのか?リソー スロックに依存し、ロードバランサーは1つのセッションにつきすべての要求を同じサーバに送信しなければならない。ステートフルサーバが利用不可になる と、システム操作に明らかに影響が出る。そこでこれらのサービスは、ステートレスサーバよりも相当回復力がなくてなならない。

Gojko氏は、データストリームを分ける方法について説明している。2層アプリケーションの場合、別のデータソースを作成する。静的データがあるデータ ストリームの場合、キャッシュをオンに、トランザクションをオフにする。3層アプリケーションではさらに複雑な設定が提案されている。

3層アーキテクチャーでは、最初からミドルウェアをユーザ固有および総称サーバに分けるようにしている。Webサーバが最上位に、最初のミドルウェアグ ループから総称データを取得 し、2番目のミドルウェアグループを使用してトランザクションを処理する。総称データフローのサーバは容易にクラスターおよびスケール可能で、難しい設定 などは一切なしでロードバランシングシステムは適切に作動する。システムに一切影響を与えることなく、リスタートや、クラスターから取り出したり、元に戻 したりできる。透過キャッシュをこれらのサーバに簡単に適用することができる。その一方、ユーザ固有のサーバはこの点においてさらに扱いにくく、決して透 過的にキャッシュされるべきではない。この分割は今後のスケーリングやキャッシュのための準備である。総称データサーバは製品の範囲やタイプによって領域 的に分割し、キャッシュサーバの層の下に置かれ、垂直に分けられるからである。ユーザ固有のサーバに関する機能は、集約かつ隔離されている。それであとで パーティションが必要になったときに、それほど集中しないですむ。

AJAXでユーザ固有のコンテンツを総称ページにロードしたり、 各ページの上部に表示されるユーザの詳細をCookieで保存するテクニックを引用しながら、Gojko氏は可能な限り総称サーバに移行して、キャッシュ のパワーを利用することを提案している。総称データストリームは、LightHttpd(サイト・英語)などの高性能httpサーバによって運用される。

原文はこちらです：http://www.infoq.com/news/2008/03/twostreams

• 次へ >