PTT幹事の田中哲朗@東京大学 です. 9月25日に行われたPTTのメモを流します．

----------------------------------------------------------------------
第 292 回 PTTメモ

日時: 2003年9月25日 (木) 18:30 から 

場所: 慶應義塾大学理工学部（矢上キャンパス）

題名: 自発的グループ内での複製にもとづく適応型ウェブサーバ

話者: 福田 浩章 (慶応義塾大学)

出席者： 伊知地宏(ラムダ数学教育研), 鈴木信吾, 寺田実(電通大),
         石畑清(明大), 飯島正, 篠沢佳久(慶大),
         副田俊介, 松崎公紀, 田中哲朗(東大)

概要:

 インターネットのトラフィックは増加の一途をたどっている．その過半数
以上を占めるのがWWWのサービスであり，アクセスの増加によってユーザの
待ち時間，サーバの負荷も増大している．しかし，一般にコンテンツによって
アクセスパターンが異なるため，あらかじめそれを予測することは困難であり，
予想を上回るアクセスがあると極端にスループットが悪くなり，最悪な場合
サービスそのものが停止する．

 そこで事前に予測できない環境において，リクエストが急激に増えた場合に，
処理能力に余裕のあるウェブサーバを一時的に利用し，コンテンツを複製，
リクエストをリダイレクトすることによって実行時に処理を分散させる
システムの提案と実装，その効果を報告する．

質疑応答:

Q. friendsというグループを組むことへの参加者へのモチベーションをどう引
き出せるのか？P2Pなどでもどう参加者を募るかが問題．ホットスポット状態
（リクエストの異常な集中状態）を避けたいということだけで十分な動機にな
るのか？

A. 発表の中でも申しましたが、常時接続のPCも増え、個人のホームページを持
つユーザも増えつづけております。個人でサーバを立ち上げるユーザはもちろん、
複数のユーザのコンテンツを管理するISPなどでは、どのコンテンツがどれくら
いの頻度でリクエストされるか知ることは困難であり、かといってそのコンテン
ツのためにサーバ上のすべてのコンテンツを複製しておくのはコストがかかりま
す。本システムを導入することによって、コストをかけずにサーバ側の処理でリ
クエストを分散できるため、参加者のメリットも大きいと考えています。また、
ホットスポット状態に対してだけではなく、通常状態においても頻繁にアクセス
されるコンテンツは自動的に分散していき、Server SelectionやContent
Placementのポリシーを工夫することで、クライアントに必要とされているコン
テンツをインターネットのウェブサーバに最適に配置するシステムとしても利用
できると考えています。

---

Q. 実験では帯域幅を1/10にしているがこれだけでよいのか？他のいろいろな
もの（メモリスピードやCPU内バス速度など）も遅くしないといけないのでは？

A. コンテンツが大きい場合、応答時間の大部分がコンテンツの転送にかかる
時間であるため、メモリスピードやバス速度が遅くなろうとも複製による応答
時間の向上にあまり影響ないと思います(実際の実験でもコンテンツが大きい
場合はCUP負荷、メモリ負荷ともに10%程度でした)。また、コンテンツが小さ
い場合はそれらの要素が影響を与えると思いますが、むしろ遅ければ遅いほう
が複製した場合とそうでない場合の差がはっきり出ると思います。

--- 

Q. レプリケーションだとクッキーを扱えるとあったが，それは本当か？

A. キャッシングではコンテンツがread-onlyであって、クッキーも扱えないが、
レプリケーションならばやり方によっては扱えるという意味です。しかし、ご
質問にあったように、クッキーなど個人に依存するようなものを本システムの
ような不特定多数が参加するシステムで扱うことは適切でないと考えます。も
う少し限定されたコミュニティで、お互いが信頼できるような場合であればレ
プリケーションでクッキーなどを扱うことができると思います。


---

Q. サーバが，自分のコンテンツについて，どれが複製するべきもので，どれ
が複製できないものであるということを熟知していなければならないのでは？

A. 今回対象といたしましたコンテンツは、jsp, cgiといった動的に生成され
るものではなく、テキスト、画像、動画といった静的なものに限ります。それ
が前提でサーバの設定ファイルなどで、拡張子などをキーにして複製の許可、
不許可を管理者に設定してもらうことで、解決できると思います。そもそもこ
れら静的なコンテンツはどのサーバに配置されても、内容は変化しないので。


---

Q. DNSのセカンダリサーバのように決まった相手同士で複製を持ち合ったら？
バックアップとは違うのか？

A. 本システムは動的にこのバックアップを行うものとも考えることができま
す。DNSのセカンダリなどではあらかじめ決められた相手だけでしか複製を持
ち合えませんが、本システムは実行時の状況に応じて、コンテンツごとにバッ
クアップを行うことができるシステムです。


---

Q. プライマリからレプリケーションにアクセスを切り替えたとき，レプリケー
ションへの通信が途絶していたら，また，オリジナルに問い合わせに行くよう
な設計も出来そう...でも，それでは，無限に右往左往を繰り返してしまう．

A. ご指摘のとおり通信が途絶え、オリジナルに問いあわせた結果再びリダイ
レクトといった状態になることが考えられます。その場合、ClientProxyにと
AdaptiveWebServer間でメッセージをやり取りし、一度通信が途絶えたものに
はリダイレクトさせないようなメカニズムを導入することによって解決できる
と考えます。

-
東京大学情報基盤センター 田中哲朗
http://www.tanaka.ecc.u-tokyo.ac.jp/~ktanaka/