#292 PTT
Tetsuro Tanaka
----------------------------------------------------------------------
第 292 回 PTT のお知らせ
--- Programming Tools and Techniques ---
日時: 2003年9月25日 (木) 18:30 から
場所: 慶應義塾大学理工学部（矢上キャンパス）
25棟601教室(いつもと同じ部屋です)
●矢上キャンパスまでの案内
・東急東横線日吉駅より徒歩15分程度．
綱島街道を渋谷方向に進み，２つめの信号（仲の谷交差点）
で右折．細い道に入って直進してください．しばらく行くと，
矢上キャンパス入り口の緩い坂道があります．
地図は下記にあります．
http://www.st.keio.ac.jp/contents/images/Keio-Map-j.pdf
・もしくは，JR横須賀線，新川崎駅よりタクシーで5分程度．
●矢上キャンパス内の案内
・キャンパス内地図は，上記の坂道を登った先の階段手前にあります．
入構に際して警備室（階段の先）にお寄りになる必要はありません．
適当な場所に案内板を置いて会場の教室まで誘導いたしますが，
わからないときには警備室でお聞きください．
話者: 福田 浩章 (慶応義塾大学)
題名: 自発的グループ内での複製にもとづく適応型ウェブサーバ
概要:
インターネットのトラフィックは増加の一途をたどっている．その過半数
以上を占めるのがWWWのサービスであり，アクセスの増加によってユーザの
待ち時間，サーバの負荷も増大している．しかし，一般にコンテンツによって
アクセスパターンが異なるため，あらかじめそれを予測することは困難であり，
予想を上回るアクセスがあると極端にスループットが悪くなり，最悪な場合
サービスそのものが停止する．
そこで事前に予測できない環境において，リクエストが急激に増えた場合に，
処理能力に余裕のあるウェブサーバを一時的に利用し，コンテンツを複製，
リクエストをリダイレクトすることによって実行時に処理を分散させる
システムの提案と実装，その効果を報告する．
--------------------------- 備考 ----------------------------
PTTは東京近辺の大学を中心に構成された私的な研究会です. 東大・東工大・
慶應大・早稲田大・電通大・農工大などを会場にして月に一回, 持回りでで発
表を行い自由なスタイルで議論を行う形式で運営されています.
毎回異なる話者・分野を発表するので, 専門分野外の知識を広げたり, 逆に
自分の専門分野に近いところで深い議論に参加することもできます.
毎回10～20人程度の参加者で, 少人数のアットホーム的なスタイルで会を運
営しています. 特に, 会費等は徴収しておりません. 気にいったテーマ等があ
るときに, お気軽に参加してください. 事前の申込等は一切必要ありません.
毎月上旬に fj.org.ptt にプログラムを掲示しますが, 興味のある方は,
ptt-...@ipl.t.u-tokyo.ac.jpまでメールで連絡すれば, 毎月のプログラム
を emailにて配送したします. また,
<http://www.tanaka.ecc.u-tokyo.ac.jp/~ktanaka/ptt/>に案内を載せている
のでそちらも参考にして下さい.
--
-
東京大学情報基盤センター 田中哲朗
http://www.tanaka.ecc.u-tokyo.ac.jp/~ktanaka/
Tetsuro Tanaka
----------------------------------------------------------------------
第 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間でメッセージをやり取りし、一度通信が途絶えたものに
はリダイレクトさせないようなメカニズムを導入することによって解決できる
と考えます。