• 検索結果がありません。

修 士 論 文 概 要 書

N/A
N/A
Protected

Academic year: 2021

シェア "修 士 論 文 概 要 書"

Copied!
2
0
0

読み込み中.... (全文を見る)

全文

(1)

修 士 論 文 概 要 書

CD 2008年 2月提出 学籍番号 3606U064–4 専攻名(専門

分野) 情報・ネットワーク

氏 名 土居幸一朗 指 導

後藤滋樹 印

研究指導名 情報システム工学 教 員

研 究

題 目 HTTPセッションハンドオーバによるWEBロードバランス 1. 本研究の概要

Webサービスの提供者は、一般的に複数のサー バを用いることで多数のリクエストに対応する。

各バックエンドサーバに適切な比率でリクエスト を配分する機構として、種々のロードバランシン グ手法が利用されているが、データ転送中にサー バを切り替えることができないという問題があ る。これに対して、本論文ではHTTPセッション ハンドオーバを用いることによって、各サーバへ の負荷分散の精度を増し、ユーザの利便性向上に 貢献する手法[1]を提案する。さらに、実験を通し て、提案手法が多くのwebサーバと親和性が高く、

導入によるオーバヘッドが十分に小さいこと、さ らに、単純な例を用いて、実際に性能を改善させ られることを示す。

2. 提案手法

2.1 提案手法の概要

提案手法では、リバースプロキシ型のロードバ ランサと同様のネットワーク構成(図1)によって、

ロードバランサとなるノードを配置する。ロード バランサはリバースプロキシとして、アプリケー ション層でクライアントからのリクエストを受信 した上で、バックエンドサーバから取得したデー タを返送する。

図 1: 提案手法のネットワーク構成 このデータ転送中に、クライアントがデータ取得 を打ち切った場合など、転送開始時にバックエン ドサーバを割り当てる際に前提となっていた条件 が変化すると、バックエンドサーバへの負荷配分 が偏ってしまう可能性がある。提案手法は、その 際にデータ転送(HTTPセッション)をバックエ ンドサーバ間でハンドオーバする事によって負荷 を再配分し、期待した比率に従って各サーバの負 荷を適正にすることを目的とする。

2.2 ハンドオーバ機構

HTTPの仕様を定めるRFC2616 [2]には、web サーバ上のリソースうちの一部データ (partial content)だけを指定して要求するための機構 (以 下、「部分的リソース要求」とする)が定められて いる。提案手法では、HTTPセッションハンドオ ーバを実現するために、この部分的リソース要求 を利用する。

図2に示したメッセージシーケンス図のよう に、相対的に負荷の高いサーバ(Server A)から 相対的に負荷の低いサーバ(Server B)へのデー タ転送をハンドオーバする際に、ロードバランサ

は、まずServer Aからのデータ転送を中止させ

て、次にServer Bに対して、要求リソースのデー

タのうち未転送の部分をリクエストする。その際 に部分的リソース要求を用いて、必要な転送部分 を指定する。

図 2: 提案手法のメッセージシーケンス 3. プロトタイプ

性能評価などを行うために、提案手法によるプ ロトタイプを作成した。実装には、実装の容易さ を重視してRuby言語のTCPsockライブラリを使 用した。一般に、Ruby言語で書かれたプログラム はC言語などのコンパイル型言語で作成されたプ ログラムに比べて低速である。本プロトタイプで 十分な性能を確保できれば、ほかの言語を用いる ことで、さらに性能を向上させられることになる。

4.実証実験

4. 1 各種webサーバとの互換性

提案手法で利用する部分的リソース取得要求は 対して再接続を実施した場合(1, 2, 3回)」の、そ

(2)

RFC2616 [2]に定められた仕様であるものの、実装 は個別のwebサーバに委ねられており、すべての ソフトウエアに実装されているとは限らない。そ こで、Netcraftの統計[3]により、使用されている 割合が高いとされているwebサーバソフトウエア について提案手法との互換性を確認した。その結 果、webサーバとして広く使用されている4製品

(シェア合計88.01%) について、部分的リソー ス要求機能が実装されており、提案手法が利用で きる事を確認した。(表1)。

表 1: 各種webサーバとの互換性 開発主体 Webサーバ名称 互換性の有無 Apache Software

Foundation Apache Http

Server あり

Microsoft Internet Information Service (IIS) 6.0

あり Sun

Microsystems Sun Java System

Web Server あり

Jun Kneschke lighttpd あり

4. 2 ハンドオーバによるオーバヘッド

提案手法では、2種類のオーバヘッドが生じると 考えられる。まず、ロードバランサがリバースプ ロキシとしてデータ転送を中継する事により生じ るコストがある。これは、提案手法に限らず、一 般的にリバースプロキシ型のロードバランサを用 いる場合は不可避のコストである。次に、ハンド オーバによって、データ転送を切断し再接続する ための時間的コストがある。

まず、前者のオーバヘッドを計測するために、

ロードバランサを経由する場合と経由しない場合 で、ファイルサイズを変化させながらファイルを ダウンロードする実験を行った。その結果、両者 で、ファイルのダウンロードに必要な時間に大き な違いはなく、他の要素に比べて、オーバヘッド は十分位小さい事が分かった。(図3)。

図 3: ファイルサイズとファイル転送時間の関係 次に、1GB のファイルをダウンロードするのに 必要な時間を、「ロードバランサを使用しない場 合」、「ロードバランサを使用するもののハンドオ ーバを発生させない場合」、そして、「ハンドオー バを発生させて、同一のバックエンドサーバに

れぞれの場合で計測した。その結果、HTTPセッ ションハンドオーバによる時間的コストは非常に 小さいため、オーバヘッドが十分に小さい事が分 かった。(図4)。

図4: ハンドオーバ回数と転送時間の関係 4.3 性能改善の例

ベンチマークツールによって、標準的な構成の

Apache httpd に対して多数のリクエストを発生

させ、同時接続数とリクエストごとのデータ転送 速度の関係を調べた。そのデータを元に、2 台の バックエンドサーバの間で、接続しているクライ アント数が偏った場合を仮定して、提案手法によ ってクライアント数を平滑化した場合の、データ 転送速度の平均と最低値の変化を計算した。その 結果、それぞれ最大で、データ転送速度が18%、 31%向上し、ユーザの利便性が向上することがわ かった。

5.結論

既存のロードバランシング手法では不可能な、

データ転送中にバックエンドサーバを切り換える 手法を導入したことで、効果的な負荷分散を行う 手法を提案した。この切り換え機構にはRFCに定 められた標準仕様を応用しており、Ruby言語によ り実装したプロトタイプによって、実際にほとん どのwebサーバソフトウエアに対して互換性を持 つことを確かめた。また、提案手法を導入するこ とによるオーバヘッドは十分に小さいことを示し た。さらに、単純な構成のwebサイトにおいて、

提案手法を用いて、クライアント接続数を平滑化 することで、平均データ転送速度、最低データ転 送速度の双方を改善させられることを確認した。

参考文献:

[1] Koichiro Doi, Shigeki Goto, “Load Balancing with HTTP Session Handover”, CORE

University Seminar, Jeju, Korea, October 2007.

[2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee,

“Hypertext Transfer Protocol – HTTP/1.1”, RFC 2616, June 1999.

[3] Netcraft, “Octover 2007 Web Server Survey”

http://news.netcraft.com/archives/2007/10/11/oct over_2007_web_server_survey.html

参照

関連したドキュメント

どがあくまで IP マルチキャストの拡張・発展形といった のものが多い。ネットワーク層で動作する IP

一人一人にあった商品を、検索・購買履歴からお客

大規模な Java Enterprise Edition (Java

1 Mobile IPv6 について 1.1 Mobile IPv6 の機能 インターネットで通信に用いられるIP アドレスは、

る.下の図 2 に流れを示す.C2P はプラン長を n とした プランニンググラフを作成後,CNF に変換する.それを c-sat で解く.SATISFIABLE

ハイパー グラフは , 数学におけるグラフを一般化 ( 拡張 ) したもので あり , エッジ ( ハイパーエッジ ) が任意個数のノードを連結

動き検出の 検出の改善 複数フレームの合成では誤った領域を合成すると画像 劣化の原因となるため、動き検出の性能が手法全体の

非暗号化状態の SIP と RTP 、既存の音声暗号化シ ステム、提案手法、それぞれの通信確立手法を比較 評価する。RTP