第 292 回 PTT のお知らせ

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

場所: 慶應義塾大学理工学部（矢上キャンパス）25棟601教室(いつもと同じ部屋です)

　●矢上キャンパスまでの案内
　　・東急東横線日吉駅より徒歩15分程度．
　　　綱島街道を渋谷方向に進み，２つめの信号（仲の谷交差点）
　　　で右折．細い道に入って直進してください．しばらく行くと，
　　　矢上キャンパス入り口の緩い坂道があります．
　　　地図は下記にあります．
　　　　http://www.st.keio.ac.jp/contents/images/Keio-Map-j.pdf
　　・もしくは，JR横須賀線，新川崎駅よりタクシーで5分程度．
　●矢上キャンパス内の案内
　　・キャンパス内地図は，上記の坂道を登った先の階段手前にあります．
　　　入構に際して警備室（階段の先）にお寄りになる必要はありません．
　　　適当な場所に案内板を置いて会場の教室まで誘導いたしますが，
　　　わからないときには警備室でお聞きください．

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

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

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

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

第 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間でメッセージをやり取りし、一度通信が途絶えたものにはリダイレクトさせないようなメカニズムを導入することによって解決できると考えます。