5.4.1 実験3の概要 実験3の目的
実験1と実験2を通して、提案手法が様々なサーバで利用可能であること、また、そのオーバ ヘッドが十分に小さいことが分かった。
実験3では、まずwebサーバに対して同時接続数が増えるに従って、クライアントに対する データ転送速度が低下し、一定のファイルをダウンロードするのに必要な時間が増加することを 確かめる。次に、その結果を利用して、バックエンドサーバ間で処理するリクエストを再分配す る提案手法による性能改善の程度を検討する。
実験3の手順
標準インストールの設定が施されたApache httpdに対して、gigabit Ethernetによって接続 された別マシン上のベンチマーキングツールによって、同時接続数 (concurrency)を変化させな
がら300MBのファイルに対するGETリクエストを発行し、ファイルを取得するのに必要な1
リクエストあたりの時間を計測した。ベンチーキングツールにはApache Foundationの開発し ているApatch benchmark tool (ab) [19]を使用した。
Apache httpdを実行したマシンのスペックを表5.3に示す。
表 5.3: Apache httpdサーバを実行したマシン Linux kernelバージョン 2.6.23.8 (Fedora 8)
CPU Intel Core 2 Duo E6850
メモリ 2.0GB (DDR2-800)
NIC Intel 82566DC Gigabit Ethernet LAN controller httpdバージョン Apache/2.2.6
実験3の結果
結果を図5.4に示す。棒グラフが1クライアントあたりのデータ転送速度、折れ線グラフが全 クライアントの合計転送速度を表す。同時接続数が5に達して以降は、合計転送速度が900Mbps 弱で頭打ちとなっており、同時接続数が増えるに従って、1クライアントあたりのデータ転送速 度が低下し、ダウンロードに必要な時間が増大することが確認できた。
第 5 章 実証実験
図 5.4: 同時アクセス数とダウンロード時間の関係
次に、2台のバックエンドサーバを利用するwebサイトを考え、2台の間で接続クライアン ト数に偏りが生じた場合を想定する。提案手法によってHTTPハンドオーバを行い、クライア ント数の多いサーバから、クライアント数の少ないサーバへクライアントへのデータ転送を移し 替えることによるファイル転送速度の平均値と最低値の変化を、図5.4の結果をもとに計算した (表5.4) 。
特に、クライアント数が少ない状態において、バックエンドサーバ間で接続クライアント数に 偏りが生じた場合、提案手法によってクライアントの接続先サーバを動的に変更することで、最 低転送速度、平均転送速度が、それぞれ最大で31%、19%向上することがわかった。
表 5.4: HTTPハンドオーバ (HO) による性能改善の例
HO前のクライアント数 HO後のクライアント数 平均速度の改善率 [%] 最低速度の改善率 [%]
1台:3台 2台:2台 18.70 31.14
2台:5台 3台:3台 8.29 22.56
3台:5台 4台:4台 5.93 19.11
4台:6台 5台:5台 3.69 16.05
第 6 章 まとめ
6.1 結論
第1章で述べたように、従来のWebサーバのロードバランシング技術では、クライアントか ら到来するリクエストを各バックエンドサーバに対して、適当な割合で分散させることで、負荷 の適切な配分を期待する事が主な目的であった。DNSロードバランシングをはじめとした種々 の手法が提案され、多数の商用ロードバランサも利用されている。
しかし既存の手法では、サービス提供者の側で、あらかじめクライアントのネットワーク回線 の帯域を知ることができないといった理由や、あるいは接続中のクライアントが転送完了前に切 断を行う可能性があるといった理由により、バックエンドサーバの間で負荷を期待通りに配分す ることが難しい問題があった。
それに対して、本研究では、リバースプロキシ型のネットワーク構成を前提として、新しい手 法を提案した。リバースプロキシ型には第3章で述べたように、ロードバランサにおける処理能 力がボトルネックとなりやすいという短所がある一方で、すべてのトラフィックがロードバラン サを通過し、なおかつアプリケーション層において処理を行うために、柔軟な負荷分散が可能で あるという長所がある。
提案手法は、RFCに定められたHTTPの部分的リソース要求を応用する。具体的には、相対 的に高負荷のサーバによるデータ転送を切断した上で、負荷の軽いサーバに対して、新たに部分 的リソースとして転送データの残りを要求し、HTTPによるデータ転送の最中でありながら、
データを提供するバックエンドサーバを変更することにより、従来方式の欠点を補い、精度の高 い負荷分散を実現する方式を考案した。
本研究では、実際に提案手法のプロトタイプをRuby言語によって実装した。そして、広く使 われている各種webサーバ・ソフトウエアに対して、作成したプロトタイプを使用し、そのすべ てに対して提案手法が機能することを確認した上で、実験ネットワーク環境において、ロードバ ランサを使用するオーバヘッドを計測した。その結果、提案手法によるオーバヘッドは、十分に
第 6章 まとめ
小さいことが確認できた。
なお、プロトタイプの実装に用いたRuby言語は実装が容易な反面で、C言語などに比べて実 行速度が遅いことが指摘されており、C言語などで実装を最適化することによって、さらにオー バヘッドを縮小することができる。
さらに、単純な構成のwebサーバに対してベンチマーキングツールによって同時接続クライ アント数を増加させつつファイルを同時取得する実験を実施し、データ転送速度の変化を計測し た。その結果から計算し、バックエンドサーバに対する接続クライアント数に偏りが生じた場合、
それを提案手法によって平滑化することによって、平均転送速度、最低転送速度、ともに向上さ せられることがわかった。