WEB ロードバランス HTTP セッションハンドオーバによる

(1)

2007 年度修士論文

HTTP セッションハンドオーバによる

WEB ロードバランス

提出日： 2008 年 2 月 4 日

指導：後藤滋樹教授

早稲田大学大学院理工学研究科情報・ネットワーク専攻学籍番号： 3606U064-4

土居幸一朗

(2)

図一覧

2.1 HTTP GETリクエストの例 . . . 11

2.2 HTTP GETに対するレスポンスの例 . . . 12

3.1 DNSロードバランシングの構成 . . . 15

3.2 リバースプロキシ型ロードバランサの構成 . . . 16

4.1 提案手法のメッセージシーケンス . . . 20

4.2 Partial content取得の例 (リクエスト) . . . 22

4.3 Partial content返却の例 (レスポンス) . . . 22

5.1 実験2のマシン構成 . . . 25

5.2 ハンドオーバ回数とファイル転送時間の関係 . . . 26

5.3 ファイルサイズとファイル転送時間の関係 . . . 27

5.4 同時アクセス数とダウンロード時間の関係 . . . 29

(5)

表一覧

2.1 HTTPの代表的なメッセージ . . . 10

2.2 レスポンスのステータスコード . . . 12

5.1 各種webサーバと提案手法の互換性 . . . 24

5.2 ハンドオーバ回数とファイル転送時間の関係 . . . 26

5.3 Apache httpdサーバを実行したマシン . . . 28

5.4 HTTPハンドオーバ (HO) による性能改善の例 . . . 29

(6)

第 1 章序論

1.1 研究の背景

インターネット利用は世界的な規模で拡大しつつあり、いまだに衰えを見せていない。日本においては、高機能携帯電話経由での接続も含めて、平成18年の時点ですでに8,754万人がインターネットを利用しており、人口普及率は68.5%に達している[2]。

インフラストラクチャーの発展を受けて、インターネットの利用形態も大きく変化した。変化の一つは、利用のモバイル化・ワイヤレス化である。1992年のNTTドコモによるiモードサービスの開始以来、従来のショートメッセージサービスから、インターネット上の電子メールと直接やりとりのできる電子メールへの移行が進展し、インターネット利用人口の一大セグメントに成長している。また、無線LANや携帯電話網をアクセス系として利用するモバイルコンピューティングも普及の兆しを見せており、2007年12月21日には、KDDI[4]を主体とするワイヤレスブロードバンド企画とウィルコム[5]の2陣営が2.5GHz帯の利用認定を受け、次世代無線アクセス系のサービス開始に向けて準備を進めている。

しかし、モバイル化・ワイヤレス化以上に利用者への影響が大きかったのは、アクセス系の広帯域化である。日本におけるインターネット接続環境には、ほとんどの一般家庭で広帯域の回線を低廉な料金で利用できるという大きな特徴がある。平成19年の情報通信白書[2]によると、

全世帯のうち、FTTHやCATVなど、何らかのブロードバンドが利用できる世帯の割合は 2007年3月末で95%に達している。過去韓国などの後塵を拝していた日本のインターネット利用環境は、総務省のe-Japan政策などにより劇的に向上し、今日の隆盛を見るに至った。中でも Fiber to the home (FTTH)の普及率は世界的にも類を見ない高さとなっており、FTTHサービスは、ブロードバンドサービス契約数全体の4割に当たる1,052万件の契約数がある。

アクセス系のブロードバンド化を受けて、webサイトに掲載される写真などの高解像度化が進み、静的なページにおける容量の拡大が進展したほか、音楽や動画の配信サービスなども広く利用されるようになった。さらには、ブロードバンド環境を前提としたいわゆるAjaxやRIAと

(7)

第 1 章序論

いったweb開発技術が発展し、従来は手元にあるPCで利用する事が常識的だったアプリケーションソフトウエアをネットワーク越しに利用したり、場合によってはデスクトップ環境そのものをインターネット越しに利用するといったweb上のサービスが実現されはじめている。これらのサービスの多くは、Windowsなどの一般的なOS上で動作するアプリケーションと比べても遜色のない操作性の高いGUIを備えているのが特徴である。

また、機能の面では新しいものではないものの、かつては非現実的だったDVD-ROMのISO イメージファイルのように数GBを超える大容量ファイルをwebサーバやFTPサーバを通じてインターネット上で配布することも常識的になった。

こうしたwebサイトでは、

• 単一のサーバでは、処理する事の出来ない数のリクエストを処理する必要がある

• 1台のサーバのみで単独運用するのに比べて、複数サーバでサイトを構成した方が、サーバ障害によるサービス停止の可能性を低くする事ができるため、サイトの冗長性を確保しやすい

• 特殊なハードウエアを備えていたり、高性能であったりする反面、高価なサーバマシンを用いるよりも、すでに市場でコモディティ化が進行した安価なサーバを複数使用して、同等の性能を確保した方が、費用対効果の面で有利である

といった理由により、複数のサーバマシンをバックエンドサーバとして使用する構成が取られることが多い。

1.2 研究の目的

前項で述べたように、スケーラビリティ、冗長性、コストパフォーマンスなどの面で、多くの webサイトでは、複数のバックエンドサーバが用いられる場合が多い。

複数のバックエンドサーバでwebサイトを構成する場合、クライアントからのリクエスト (負荷)をバックエンドサーバに適切に配分して処理を行う必要があるが、このリクエストの配分については、以下の2つの問題がある。

まず、サービスの可用性についての問題がある。これは、複数のwebサーバによってスケーラビリティを確保しようとする場合、たとえ合計した処理性能の点でバックエンドサーバの数が十分であっても、各サーバに対するリクエストの配分が適切に行われないと、処理負荷が集中してしまったサーバにおけるレスポンスが遅延したり、場合によっては、配分されたリクエスト数が処理能力を超過してしまうことで、そのサーバに配分されたリクエストに対するサービスの提供が不可能になってしまうという問題がある。

(8)

第 1 章序論

次に、サービス性能ないし計算機資源の利用効率の面での問題がある。CPUやハードディスクのようなハードウエアにおいては、同時処理数が増加するにしたがって、有限な処理能力を、

各処理で分け合う必要があるため、個別の処理性能は低下することが知られている。

そのため、バックエンドサーバにおける処理負荷が適切に配分されていないと、負荷の小さいサーバではレスポンスが早くなる反面で、相対的に負荷の大きなサーバでは、十分な処理性能が発揮できず、クライアントに対するサービス品質が低下してしまう問題がある。

以上の問題に対して、ロードバランサと呼ばれる負荷分散機構が広く利用されている。現在のロードバランシング技術は、何らかの方法で、到来するリクエストを相対的に負荷の低いサーバに順次割り当てることによって、結果として各バックエンドサーバにて均等な処理負荷が発生することを期待するものである。しかし、既存の手法では、何らかの原因でサーバ間の負荷に偏りが生じた場合に、それを是正する手段が存在しない。

これに対し、本研究では、従来の負荷振り分け方式と併せて運用することを念頭に置いて、

HTTPのセッションをデータ転送中にハンドオーバする手法を用いて、負荷再分配機構を提案する[1]。

本論文では、Ruby言語によって実装したプロトタイプを通して、HTTPセッションのハンドオーバ時のオーバーヘッドが十分に小さいこと、また、一般的に利用されている各種のweb サーバソフトウエアで動作検証を行い、提案手法の実用性を示す。さらに、冒頭に挙げた問題の後者について、接続数が偏ったバックエンドサーバ間でクライアントに対するデータ転送をハンドオーバすることによって、平均および最悪の場合の転送時間が短縮し、サービス品質が改善する様子を実際の計測データをを用いて考察する。

1.3 本論文の構成

本論文は以下の章により構成される。

第1章序論

本研究の背景と、それに基づく目的を述べ、本論文を概説する。

第2章 Hypertext Transfer Protocol

提案手法の基本となるHypter Text Transfer Protocol (HTTP)の動作の概要に加え、

TCP/IPプロトコルスタック上での位置づけを解説する。

第3章既存のロードバランシング技術

既存のロードバランシング技術を概観し、それぞれの特徴を解説する。

第4章提案するロードバランシング技術

(9)

第 1 章序論

本研究で提案する手法について、概念と振る舞いの説明に加え、プロトタイプの実装について概説する。

第5章実証実験

提案手法のプロトタイプを用いて、提案手法の実用性を示した後、実測したデータに基づいて、実際にクライアントに対する平均的および、最悪の場合のサービス性能を向上させられることを示す。

第6章まとめ

本研究の結論を述べるとともに、今後の課題について考察する。

(10)

第 2 章

Hypertext Transfer Protocol

2.1 HTTP の役割

2.1.1 TCP/IPの4層モデル

TCP/IPは4層からなるプロトコルスタックによってモデル化されている。各層では、それぞ

れの層の機能に加えて、上下の層との間のインタフェースが規定されている。開発者は、そのインタフェースに従って各層のプロトコルを実装することにより、ある層の実装を変更する場合でも、他の層への影響を限定することができる。たとえば、最上位層であるアプリケーション層では、最下位層であるネットワークインタフェース層において、データが光ファイバーによって運ばれているか、あるいは電波として空中を運ばれているかといった違いについて、関知せずに実装することができる。以下に、TCP/IPのプロトコルスタックの各層の役割を下層から順に示す。

ネットワークインタフェース層通信回線の物理的な接続形態や信号形式を定める。光ファイバやネットワークインタフェースカード（NIC）のようなハードウエアに加え、デバイスドライバが該当する。

インターネット層アドレス形式や転送方式などを定め、データ転送の方式を定める。インターネット層にはInternet Protocol (IP) などが所属し、パケットの形式や、目的ノードまでのルーティング方式などが定められている。

トランスポート層エンド・ツー・エンドでのデータのやりとりを司る。Transmission Control Protocol (TCP) やUser Datagram Protocol (UDP) が所属し、ホストで動作しているアプリケーションごとに識別して受け渡す機能を持つ。特に、TCPはデータの正しさや送信順序の正しさを保証する機能や、ネットワーク回線でシリアライズされたデータを、正しい順番でアプリケーション層に受け渡す機能を持つ。

(11)

第 2章 HYPERTEXT TRANSFER PROTOCOL

アプリケーション層下層の機能を利用し、人間にとって具体的な意味を持つソフトウエアや、

別のソフトウエアを助けるソフトウエア（ミドルウェア）が動作する層。HTTP、FTP そしてSMTPはアプリケーション層のプロトコルである。

2.1.2 HTTPの位置づけ

Hypertext Transfer Protocol (HTTP)は、TCP/IP プロトコルスタックにおけるアプリケーション層のプロトコルであり、いわゆるハイパーテキスト (hypertext) を転送することを目的として作られた。HTTPはトランスポート層にTCPを用い、well-known portとして80番のポート番号が用意されている[7]。

HTTPによる通信は、クライアントから送信されるリクエスト (request)と、サーバが送信するレスポンス (response)の送受信によって成立する。ここで、HTTPにはステートレス (state-

less)であるという特徴があり、同じクライアントとサーバの間でのやりとりであってもそれぞれ

が一連のリクエストであることが、プロトコル上は自明には分からない。そのため、ユーザに応じて異なるコンテントを返却するようなサービスを提供するためには、HTTPの仕様外の方法によって、接続を識別する手法が必要になり、cookieと呼ばれる識別子をヘッダに埋め込む手法などが用いられている。

また、HTTPでは必要となる情報をクライアントが随時取得するため、クライアント側に存在するデータをサーバ側から更新する機会がない。そこで、HTTPを利用するwwwはプル型のサービスであると言われる。

HTTPは、名前の示すようにHyper Text Markup Language（HTML）で記述されたハイパーテキストや、それに付随する画像ファイルなどの転送に用いられることが多いが、従来は File Transfer Protocol (FTP)が担ってきたファイル配布サーバなどにおいても、データ転送用のプロトコルとして使用される機会が増えている。

2.2 HTTP のメッセージ

HTTPによる通信で、サーバとクライアントの間でやりとりされるリクエストとレスポンスを総称して、HTTPのメッセージという。HTTPメッセージは、ヘッダ (header) と、それに続くメッセージボディ(message-body)からなり、ヘッダとボディは、間に挿入された空行で区別される。ただし、リクエストやレスポンスの種類により、ボディが存在しない場合もある。以下、HTTPリクエストとレスポンスについて概要を説明する。

(12)

2.2.1 HTTPリクエスト

HTTPのリクエストは、メソッド (method) と呼ばれるコマンドと、それに付随する各種のパラメータをクライアントに伝達する。もっとも典型的なHTTPリクエストはGETメソッドを用いるものであり、サーバに対して、サーバ上のリソースを転送するように要求するメッセージである。

また、サーバ上で動作するCGIやwebアプリケーションに投稿記事などのデータを送信する際などにはPOSTメソッドが使用される。POSTメソッドでは、クライアントからサーバに送信するパラメータ群をボディに収めて送信する。HTTPでは、URLの中で、ドメイン名と絶対パスの末尾に、クエリ文字列 (query string)を付加して、サーバにパラメータを送信することができることも仕様に定められている (RFC 2396)ものの、POSTメソッドではURL長の制限を受けずにデータを送信できるので、電子掲示板 (BBS) への文章投稿やデータファイルのアップロードといった比較的大きなデータの転送を伴う用途にも使用することができる。

GETやPOSTのほかにも、コンテントの存在確認や、更新状況を調べるなどの目的でヘッダ情報のみを取得するHEADメソッドなどのメソッドがある。表2.1に、HTTPの主なメソッドと機能をまとめる。

表 2.1: HTTPの代表的なメッセージメッセージ名メッセージの機能

GET URIで指定したリソースやリソースの処理結果を要求する HEAD GETと同じレスポンスのHTTPヘッダのみを要求する

POST URIで指定したリソースに対して、HTTPボディに格納したデータを送信する

CONNECT proxyサーバに対してSSLなどの暗号化された通信のトンネリングを要求する

図2.1に、典型的なHTTP GETリクエストの例を示す。この例では、www.example.comというホスト上のindex.htmlというリソース (http://www.example.com/index.html) を取得している。この例に含まれているヘッダのフィールドには、クライアントの種類 (User-Agent) や、

レスポンスとして期待する言語や文字符号形式 (Accept-Language, Accept-Encoding) などの情報が含まれている。

2.2.2 HTTPレスポンス

HTTPレスポンスは、リクエストのメソッドに対して、サーバの応答を返すメッセージである。すべてのレスポンスのヘッダには、応答の状態を表現する3桁の数字によるステータスコー

(13)

GET /index.html HTTP/1.1\r\n Host: www.example.com\r\n

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11\r\n

Accept-Language: ja,en-us;q=0.7,en;q=0.3\r\n Accept-Encoding: gzip,deflate\r\n

Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7\r\n Keep-Alive: 300\r\n

Connection: keep-alive\r\n

Cookie: B=3vrs3qp3mrgi5&b=3&s=1m; FPS=dl; HP=1\r\n

\r\n

図 2.1: HTTP GETリクエストの例

ドが付記される。たとえば、通常のデータ転送要求であるGETメソッドによるリクエストに対して、サーバが正常にデータを返却する場合は、ヘッダに成功を意味する200番というステータスコードを付加した上で、リクエストされたデータをボディに格納したレスポンスが返却する。

図2.2に、図2.1のリクエストが成功した場合の、典型的なレスポンスのヘッダを示す。この例では、ステータスコード200によって、リクエストが成功したことのほか、サーバで動作しているソフトウエアの名称 (Apache) 、バージョン (1.3.39)、要求されたリソースが修正された時刻 (Wed, 26 Sep 2007 23:36:33 GMT)、ファイルの容量 (911バイト)や種類(text/html)が情報として含まれている。

ここで、Kee-Aliveフィールドには、クライアントから複数のHTTPリクエストを発行する

場合に、1回ずつTCPコネクションを確立せずに、同じTCPコネクションを使い回すことのできる機能についてのパラメータを格納している。

最後に、表2.2に、代表的なステータスコードを示す[8]。なお、ステータスコードは3桁目が大まかな意味を表すようになっており、以下のような意味を持つ。

2xx クライアントによるリクエストがサーバによって正しく受信され、成功した 3xx リクエストの目的を達成するために、クライアントは追加の動作を行う必要がある 4xx クライアント側が原因のエラーが発生した

5xx サーバ側が原因のエラーが発生した

(14)

HTTP/1.1 200 OK\r\n

Date: Fri, 12 Oct 2007 07:40:03 GMT\r\n Server: Apache/1.3.39 (Unix)\r\n

Last-Modified: Wed, 26 Sep 2007 23:36:33 GMT\r\n Accept-Ranges: bytes\r\n

Content-Length: 911\r\n

Keep-Alive: timeout=3, max=8\r\n Connection: Keep-Alive\r\n

Content-Type: text/html\r\n

\r\n

（以下、具体的なデータがボディとして格納されている）

図 2.2: HTTP GETに対するレスポンスの例

表 2.2: レスポンスのステータスコード

コード意味説明

200 OK 要求が成功した

201 Created 要求によってコンテントが生成された

206 Partial Content partial contentの取得を受け入れた

301 Moved Permanently 要求されたリソースのURLが恒久的に変更されている

304 Not Modified リソースは変更されていない

400 Bad Request リクエストの構文が不正であり、サーバが解釈できなかった

401 Unauthorized リクエストに応答する前に認証が必要である

403 Forbidden リクエストの処理がサーバで禁止されている

404 Not Found サーバ上に要求されたリソースが存在しなかった

500 Internal Server Error リクエストに応答する過程でエラーが発生した

(15)

第 3 章

ロードバランシング技術

本章では、webロードバランシングの役割を述べるとともに、代表的なロードバランシング技術について解説する。

3.1 ロードバランスの目的

ロードバランシングを行う目的は、クライアントからのリクエストによる負荷 (load) を、複数のバックエンドサーバに適切に分散させることで、1台のサーバで処理可能なリクエスト数を上回るリクエストを処理することを可能にすることである。また、ロードバランシングには、各サーバのCPUやストレージなどの計算機資源の使用効率を向上させることによって、結果として応答速度などの性能指標を改善し、ユーザの利便性を向上させる目的もある。

3.2 代表的な手法

既存のロードバランシング技術には、大きく分けて2通りの方法がある。

3.2.1 DNSロードバランシング

1つはDNSを利用した手法 (図3.1) で、本論文ではDNSロードバランシングと呼ぶ。

DNSサーバ（ネームサーバ）は、ドメイン名（domain name）とIPアドレス（IP address）の対応表を持ち、クライアントのDNS リゾルバ（DNS resolver）からの問い合わせに対して、

問い合わせられたドメイン名に対応するIPアドレスを返答する役割を担う。DNSサーバには、

あるドメイン名を持つホストで提供するサービスの冗長性を確保するために、単一のドメイン名に対して、あらかじめ複数のIPアドレスを割り当てておき、その中から一つのIPアドレスを選んで応答する機能がある。通常、Webで提供される資源を要求するクライアントは、アクセスに先立って、ドメイン名の名前解決（name resolution）を実施する。

(16)

第 3 章ロードバランシング技術

DNSロードバランシングでは、以上の動作を応用して負荷分散を実現する。具体的には、クライアントからのリソース要求に先立って行われる名前解決において、返却するIPアドレスの優先順位を順次変更することによって、結果として各クライアントがHTTPリクエストを送信する対象となるサーバを複数のサーバに分散させる。バックエンドサーバに順次リクエストを割り当てることからDNSラウンドロビン (round-robin) とも呼ばれる。

DNSロードバランシングには、以下の長所と短所がある。

DNSロードバランシングの長所

• クライアント、サーバともに特別な設定を行う必要がない

• セカンダリサーバの仕組みなど、DNSサーバが持つ冗長性確保のための機構をロードバランシング機能そのものの冗長性確保に利用できる

• アプリケーション層のプロトコルに依存しないため、DNSによる名前解決を利用するアプリケーションであれば、透過的に多様なソフトのロードバランシングを実現できる

DNSロードバランシングの短所

• 振り分け方式として、単純なラウンドロビンを用いているため、サーバ間に性能の違いがあっても、リクエストを振り分ける比率を調整できない

• バックエンドサーバの状態を負荷の配分に反映することができない

• クライアントとバックエンドサーバが直接通信する必要があるため、バックエンドサーバの数だけグローバルIPアドレスを用意する必要がある

• 特定のクライアントからの接続を、常に同じバックエンドサーバに振り分ける処理ができない

• 多くのwebブラウザがDNSロードバランシングによって複数のIPアドレスを取得している場合に、あるバックエンドサーバに障害が発生してリクエストに失敗すると、アクセスに失敗したサーバの直後に登録されているIPアドレスに対して再接続を試みるため、そのサーバにかかる負荷が期待値の2倍に達するため、処理性能を上回ってしまうおそれがある[13]

• クライアントのDNSリゾルバは、名前解決の結果のキャッシュを保持するため、同じドメイン名に対するリクエストについて、繰り返し名前解決を行わない場合が多く、連続したリクエストに対して十分な負荷分散が期待できない

(17)

図 3.1: DNSロードバランシングの構成

3.2.2 リバースプロキシ型ロードバランシング

リバースプロキシ型ロードバランシングとは、ロードバランサと呼ばれる専用のリバースプロキシノードを利用する方法であり、本論文中では、そのノードの果たす役割から「リバースプロキシ型」のロードバランシングと呼ぶことにする。

リバースプロキシ型のロードバランシングを利用する場合は、図3.2のようなネットワーク構成を取る。図中でクライアントとバックエンドサーバ群の中間にあり、トラフィックを中継する役割を果たす装置がロードバランサである。このノードは、アプリケーション層で中継を行い、

クライアントに対しては単体のwebサーバのように振る舞う一方で、バックエンドサーバに対してはクライアントのように振る舞う。

以下に、リバースプロキシ型ロードバランシングの長所と短所を説明する。

リバースプロキシ型ロードバランシングの長所

• すべてのトラフィックがロードバランサを通過するため、柔軟なロードバランシングが可能

• アプリケーション層で負荷分散を行うため、アプリケーションの動作と連携した負荷分散が可能

• SSL/TLSの通信をロードバランサで処理することで、バックエンドサーバではSSL/TLS

を意識した設定を施す必要がない

(18)

図 3.2: リバースプロキシ型ロードバランサの構成リバースプロキシ型ロードバランシングの短所

• すべてのトラフィックが単一ノードであるロードバランサを通過するため、ロードバランサの性能がボトルネックになりやすい

• ロードバランサの動作がプロトコルに依存するため、アプリケーションごとにプロキシを実装する必要がある

3.2.3 レイヤ4スイッチ

レイヤ4スイッチと呼ばれる装置は、バックエンドサーバ群に対してリバースプロキシ型ロードバランサと同じネットワーク上の位置を占めながら、アプリケーション層ではなくトランスポート層 (レイヤ4)において、クライアントからの通信をバックエンドサーバに配分することで、ロードバランシングを実現する。一般に負荷分散装置と言う場合、レイヤ4スイッチを指すことが多い[13]。商用装置のハードウエア製品の他に、LinuxではLinux Virtual Server (LVS) と呼ばれる仕組みを利用して、レイヤ4スイッチを構築することができる。

レイヤ4スイッチは、クライアントとバックエンドサーバとの間の通信の方法により、NAT 型とダイレクトルーティング型の2種類に分類できる。NAT型においては、レイヤ4スイッチがNAT箱の機能を持ち、すべての通信がレイヤ4スイッチを経由する。一方のダイレクトルーティング型では、クライアントからのリクエストのみをレイヤ4スイッチを通してバックエンドサーバに分配した上で、サーバからのリスポンスのデータなどは、別のネットワークで直接クライアントに送信する方式をとる。

レイヤ4スイッチの長所と短所としては、以下のような内容が挙げられる。

(19)

レイヤ4スイッチの長所

• DNSロードバランシングと同様に、アプリケーション層に対する制約が小さいため、様々なTCPアプリケーションに利用可能

• ダイレクトルーティング型では、サーバからのデータ送信が単一ノードを通過する必要がないため、ネットワーク帯域の制限を回避しやすい

• すべてのリクエストをレイヤ4スイッチで中継するので、停止したサーバをバックエンドサーバから除外するなど、柔軟なロードバランシングが実現できる

レイヤ4スイッチの短所

• NAT型では、すべてのトラフィックがレイヤ4スイッチを通過するため、レイヤ4スイッチの資源、特にネットワーク帯域がシステム全体のボトルネックとなりうる

• ダイレクトルーティング型では、バックエンドサーバにおける設定が通常のサーバとは異なるため、複雑になりがちである

(20)

第 4 章

提案するロードバランシング技術

本研究で提案するロードバランシング技術について解説する。

4.1 基本概念

前章で説明したように、既存のロードバランシング技術は、いずれも、クライアントから新しく発行されたリクエストを、適切なバックエンドサーバに割り当てることを目的としているが、

2つの問題点がある。

まず、ユーザがインターネット接続に利用するアクセス系の帯域や、リクエストに対してサーバがプログラム的な処理を行う場合のCPU負荷など、注目している負荷指標を事前に予測するのが難しい場合に、リクエストがサーバ側のネットワークに到着した時点で対応するサーバを決定してしまうと、結果として負荷を十分に分散できないという問題がある。

また、無線LANや無線WANを利用してインターネットに接続しているクライアントが無線の圏外に移動したことによって接続が切断された場合など、バックエンドサーバからのデータ転送中に、リクエストを配分する際に前提になっていた負荷の分布状況などが変化すると、負荷が偏ってしまう問題がある。

これらの問題に対して、本研究では、前章で説明したリバースプロキシ型のロードバランシング手法と併用することを前提に、相対的に負荷の高いサーバから負荷の低いサーバへ、目下処理中のデータ転送を移し替える（ハンドオーバさせる）ことで、瞬間的に生じた負荷の偏りを是正し、既存のロードバランシング技術の短所を補うとともに、負荷分散の精度を向上させることを目的とした手法を提案する。

(21)

第 4 章提案するロードバランシング技術

4.2 動作

前項で示した目的を実現する方法として、本研究では後述するHTTPの部分リソース(partial

content) 要求機能を利用する。部分的リソース要求機能は、HTTPの仕様であるRFC2616[12]

に定められており、サーバ側のリソースの指定した部分のみをクライアント側から要求し、データ転送をうけることができる。

ネットワーク構成としては、リバースプロキシ型のネットワークを前提とする。リバースプロキシ型と同様に、クライアントとバックエンドサーバ群の間に、ロードバランサを置き、これが負荷切り替えの役割を担う。

また、webサーバによって提供するサービスとしては、単純なファイル配布サービスを仮定する。実装を簡単にするために、各バックエンドサーバのwebサーバは、別の方法で同期された同じファイル群を持ち、各サーバで同じファイルは、お互いに同一の絶対パスによって取得できるものとする。

以下、例として、バックエンドサーバとしてsvr Aとsvr Bをもつwebサイトwww.example.com

(10.0.0.1) に対して、クライアントがfoo.zipという名称のファイルを取得するという状況を想定

して、提案手法の動作を説明する。

• クライアントのDNSリゾルバがwww.example.comの名前解決を行い、IPアドレス10.0.0.1 を得る。

• クライアントのユーザエージェント (ブラウザ) が、10.0.0.1に対して、foo.zipの転送を

要求するHTTP GETリクエストを発行する。

• ロードバランサは、GETリクエストを受信したタイミングで、あらかじめ定められた法則によって、バックエンドサーバ群から、1つのサーバ (ここではsvr A) を選び出し、そのサーバに対してGETリクエストによってリソースを再要求する。

• svr Aがロードバランサに対して、foo.zipのデータ転送を開始する。ロードバランサは、

受信したデータを中継し、そのままクライアントに対して送信する。

• ここで、何らかの原因により、バックエンドサーバの間で負荷に不均衡が生じ、svr Aの相対的な負荷が高まり、svr Bの相対的な負荷が低下したと仮定する。

• ロードバランサは、すでにクライアントに転送済みのブロック数を元に未転送部分を判断し、まだ転送していないファイル部分を、部分的リソース要求機能によるGETリクエストによってsvr Bに対して要求すると同時に、svr AとのHTTP接続を切断する。

• svr Bがfoo.zipのデータ転送を開始し、相対的な負荷の差が小さくなる。

(22)

図 4.1: 提案手法のメッセージシーケンス

• ロードバランサは、svr Aからのデータを中継したのと同様に、svr Bからのデータをクライアントに対して中継して送信する。この間に、クライアントのユーザエージェントではバックエンドサーバが切り替わったことに応じて、動作を変化させる必要がなく、単体のwebサーバから継続的にファイルデータを受信し続けたのと同じように処理を続けることが可能である。

以上の動作のメッセージシーケンスを、改めて図4.1に示す。

提案手法は、RFC標準を使用しているため、クライアント側のユーザエージェントや、サーバ側のネームサーバやバックエンドサーバに使用するwebサーバなど、既存のソフトウエアと親和性が高いと考えられる。

4.3 プロトタイプ

本研究では、Ruby言語によって提案手法によるプロトタイプを実装した。以下に、実装の詳細として、プロトタイプにおける切り替え機構の実装、Ruby言語およびHTTPの部分的リソース要求について、解説する。

このプロトタイプのソースコードを付録Aに収録している。

(23)

4.3.1 切り替え機構

Webサービスにおいては、CPUやディスクIOといった種々の計算機資源に加えて、クライアント側のネットワーク帯域など、さまざまな要素がサービス性能を制限するボトルネックとなりうる。そのため、特定の環境における、特定の指標の改善のみをもって、一般的にwebロードバランスの性能を改善したと主張することは困難である。

そこで、本研究の実装では、提案手法のプロトタイプとして、具体的に特定の負荷を軽減することを目的とせず、ロードバランサに接続したキーボードの特定のキーを打鍵することによって、

HTTPセッションのハンドオーバが行われるような切り替え機構を実装した。

4.3.2 Ruby

Ruby言語は1994年11月にまつもとゆきひろ（matz）によって開発が開始されたオブジェクト指向型スクリプト言語である。「楽しいプログラミング」を目標に開発された。XMLによる複雑な設定ファイルなどを排除した結果、J2EEなどと比べてアジャイル開発と親和性の高いWeb アプリケーションフレームワーク”Ruby on Rails”[10]が開発されたことをきっかけに、国外でも広く普及し、幅広いユーザを獲得している。

本研究のプロトタイプ作成に際しては、Rubyの標準ライブラリであるTCPServerを利用し

た。TCPServerは、Rubyでソケットプログラミングをする際に、TCP以上のレイヤのアプリ

ケーションを実装するためのスケルトンであり、TCPServerを利用することで、マルチスレッド機能などを簡単に利用することができる。

Rubyなどのスクリプト言語の現在の実装は、一般にC言語などのコンパイル言語に比べて動作が低速であると言われている[17]。したがって、Rubyを使用した本プロトタイプで十分な実行速度が達成できれば、言語を変更したり、チューニングを施すことで、さらなる性能改善を期待することが可能であるということができる。

4.3.3 HTTPの部分的リソース要求

HTTP/1..1には、リクエストするデータの全体だけではなく、GETメソッドによって、サー

バに対して部分的リソース(partial content)のみを部分的に要求し、返答する仕組みが用意されている。これによって、データの取得中にネットワークが切断された場合などに、すでに取得済みのデータを重複して受信し直すことなく、未受信の部分からデータの取得を再開することができる。前述のように、本提案手法では、クライアントから要求されたファイルについて、途中からデータを取得するためにHTTPの部分的リソース要求を使用している。

部分的リソースの取得には、リクエストとレスポンスそれぞれ特別なヘッダフィールドを使用する。リクエストにおいては、Rangeフィールドによって、要求するデータ範囲をバイト数で

(24)

指定する。また、レスポンスにおいては、Content-Rangeフィールドによって、実際に返却するデータの範囲を伝達する。以下、部分的リソースを取得するGETメソッドのリクエストを図 4.2に、部分的リソースを返すレスポンスを図4.3に示す。

GET /big.zip HTTP/1.1\r\n Host: www.example.com\r\n Range: bytes=501-1000\r\n

\r\n

図 4.2: Partial content取得の例 (リクエスト)

HTTP/1.1 206 Partial content\r\n

Date: Wed, 28 Nov 2007 05:58:11 GMT\r\n

Last-Modified: Mon, 26 Nov 2007 22:13:09 GMT\r\n Content-Range: bytes 501-1000/1000\r\n

Content-Length: 500\r\n

Content-Type: application/zip\r\n

\r\n

(以下、ボディ部に格納された送信のデータが続く)

図 4.3: Partial content返却の例 (レスポンス)

この例においては、クライアントは、サーバ上のbig.zipというファイルのうち、501バイト目から1000バイト目まで、合計500バイトをpartial contentとして転送するように要求しており、サーバからは、指定されたデータが返送されている。

(25)

第 5 章実証実験

5.1 実験の方針

まず、バックエンドサーバとして様々なwebサーバを用いた場合でも、提案手法が透過的に機能することを示す実験を行う。

次に、本研究で作成したプロトタイプ・ソフトウエアを用いて、提案手法においてバックエンドサーバを切り替える際に生じる時間的なオーバヘッドが、十分に小さいものであることを示す。

最後に、ユーザ側の性能指標として、ファイルのダウンロードの際のデータ転送速度を取り上げ、提案手法による負荷分散の効果を確認する。はじめに、defaultの状態でセットアップされたwebサーバにおいて、同時アクセス数と1クライアントあたりのデータ転送速度の関係を計測し、同時アクセス数の増加に伴うダウンロード時間の変化を調べる。次に、その結果を用いて、

バックエンドサーバの間で接続クライアント数に偏りが生じた場合に、クライアントへの接続をハンドオーバすることによる性能改善の程度を検討する。

5.2 実験 1

5.2.1 実験1の概要目的

HTTPを規定しているRFC2616においては、プロトタイプで使用している部分的リソース要求GETの実装は必須とされていないため、webサーバの実装によっては、部分的リソース要求に対応していない可能性がある。そこで、代表的なwebサーバに、実際に部分的リソース要求機能が搭載されており、本研究で作成したプロトタイプが正常に機能する事を確認する。

(26)

第 5 章実証実験

手順

各種のwebサーバソフトウエアに対して、プロトタイプをリバースプロキシとしてネットワークを構成し、webブラウザにデータを転送中にHTTPハンドオーバを発生させた上で、ダウンロードが完了したファイルが元のデータと一致している事を確認した。

サーバソフトウエアの選定にあたっては、は2007年秋のNetcraftによる統計[20]で、カスタマイズされたアプリケーションなどが含まれる「その他 (Other)」を除いて、個別名称が与えられているソフトウエア5本のうち主にblogサイト[11]のホスティングに用いられている“Google”

を除く4本で、それぞれ普及していると考えられるバージョンを対象とした。2007年11月時点での4者のシェアの合計は88.01%である。

5.2.2 結果

表5.1に示したように、今回調査したすべてのサーバに、部分的リソース要求機能が実装されており、実際に提案手法のプロトタイプが正常に動作することが確認できた。

表 5.1: 各種webサーバと提案手法の互換性

開発主体 Webサーバ名称互換性の有無

Apache Software Foundation Apache Http Server あり

Microsoft Internet Information Service (IIS) 6.0 あり

Sun Microsystems Sun Java System Web Server あり

Jan Kneschke lighttpd あり

以上の結果より、HTTPの部分的リソース取得リクエストはRFCにおいては実装が必須とされていないものの、市場シェアで合計約9割をしめるwebサーバで実装されており、本研究の提案手法が、実用上ほぼすべてのwebサーバに対して適用可能であることが分かった。

5.3 実験 2

5.3.1 実験2-1の概要目的

本実験においては、提案手法によるオーバヘッドを計測する。

実験2-1では、提案手法によってHTTPセッションのハンドオーバを行った際に、バックエンドサーバの切り替えによって生じる時間的なオーバヘッドの大きさを計測した。

(27)

図 5.1: 実験2のマシン構成

実験2-2では、提案手法のプロトタイプを用いて、リバースプロキシ型のロードバランサがデータ転送を中継することにより、ファイルのダウンロード時間に生じるオーバヘッドの大きさを計測した。

実験2-1の手順

2台のマシンを用意し、図5.1に示すように、マシンA上でプロトタイプをリバースプロキシとして動作させた上で、マシンB上でApache httpdを動作させた、

その上で、マシンA上からユーザエージェントとしてwgetコマンドを使用し、マシンB上の

ファイル(1024MB)を取得する試行を各5回繰り返し、ファイルの取得に要する時間を計測して、

その平均を求めた。さらに、ファイル取得中に1回から3回のハンドオーバを生じさせた場合の時間も計測し、平均を求めた。

なお、切替のタイミングとしては、wgetのダウンロード進捗バーを目視し、それぞれ切替回数に応じて、200MBごとにキーを打鍵して手動でHTTPハンドオーバを発生させた。

5.3.2 実験2-1の結果

実験2の結果を表5.2と、図5.2に示す。

なお、図5.2においては、「LBなし」がプロトタイプを使わずに、直接ファイルをダウンロードした場合、“0 SW”が、プロトタイプを使用したものの、一度もハンドオーバを発生させなかった場合、“1 SW”から“3 SW”が、それぞれ1, 2, 3回のハンドオーバ（スイッチング）を発生させた場合のダウンロード時間を表す。

以上より、ハンドオーバの数によってダウンロードに必要な時間が微増傾向にあるものの、実

(28)

表 5.2: ハンドオーバ回数とファイル転送時間の関係

切替回数転送時間 [秒] ロードバランサなしとの時間差 [秒]

ロードバランサなし 91.75 –

0 91.60 −0.15

1 91.63 −0.12

2 91.74 0.01

3 91.80 0.05

図 5.2: ハンドオーバ回数とファイル転送時間の関係

(29)

図 5.3: ファイルサイズとファイル転送時間の関係

際にはロードバランサを経由しない場合のダウンロード時間を下回る場合もあり、提案手法によるHTTPハンドーバによる時間的なオーバヘッドは、非常に小さいことが分かった。

5.3.3 実験2-2の手順

実験1と同様の構成で、マシンAが取得するファイルのサイズを2MBから4GB (4096MB) まで変化させて、データ転送中のハンドオーバを1度も発生させずにロードバランサを中継する場合と、直接ダウンロードする場合の時間を計測した。

5.3.4 実験2-2の結果

図5.3に結果を示す。ファイルサイズが8MB未満である場合を除いて、ロードバランサを経由した場合と直接ダウンロードした場合では、ダウンロードに必要な時間に大きな違いはなかった。実際に、ロードバランサを経由した場合の時間が直接ダウンロードする場合に比べて短い場合もあったことから、8MB以上では、データ転送中のCPUやディスクI/Oの負荷状況などの別の要素に比べて、提案手法による相対的なオーバヘッドは十分に小さいことが分かった。

(30)

5.4 実験 3

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クライアントあたりのデータ転送速度が低下し、ダウンロードに必要な時間が増大することが確認できた。

(31)

図 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

(32)

第 6 章まとめ

6.1 結論

第1章で述べたように、従来のWebサーバのロードバランシング技術では、クライアントから到来するリクエストを各バックエンドサーバに対して、適当な割合で分散させることで、負荷の適切な配分を期待する事が主な目的であった。DNSロードバランシングをはじめとした種々の手法が提案され、多数の商用ロードバランサも利用されている。

しかし既存の手法では、サービス提供者の側で、あらかじめクライアントのネットワーク回線の帯域を知ることができないといった理由や、あるいは接続中のクライアントが転送完了前に切断を行う可能性があるといった理由により、バックエンドサーバの間で負荷を期待通りに配分することが難しい問題があった。

それに対して、本研究では、リバースプロキシ型のネットワーク構成を前提として、新しい手法を提案した。リバースプロキシ型には第3章で述べたように、ロードバランサにおける処理能力がボトルネックとなりやすいという短所がある一方で、すべてのトラフィックがロードバランサを通過し、なおかつアプリケーション層において処理を行うために、柔軟な負荷分散が可能であるという長所がある。

提案手法は、RFCに定められたHTTPの部分的リソース要求を応用する。具体的には、相対的に高負荷のサーバによるデータ転送を切断した上で、負荷の軽いサーバに対して、新たに部分的リソースとして転送データの残りを要求し、HTTPによるデータ転送の最中でありながら、

データを提供するバックエンドサーバを変更することにより、従来方式の欠点を補い、精度の高い負荷分散を実現する方式を考案した。

本研究では、実際に提案手法のプロトタイプをRuby言語によって実装した。そして、広く使われている各種webサーバ・ソフトウエアに対して、作成したプロトタイプを使用し、そのすべてに対して提案手法が機能することを確認した上で、実験ネットワーク環境において、ロードバランサを使用するオーバヘッドを計測した。その結果、提案手法によるオーバヘッドは、十分に

(33)

第 6章まとめ

小さいことが確認できた。

なお、プロトタイプの実装に用いたRuby言語は実装が容易な反面で、C言語などに比べて実行速度が遅いことが指摘されており、C言語などで実装を最適化することによって、さらにオーバヘッドを縮小することができる。

さらに、単純な構成のwebサーバに対してベンチマーキングツールによって同時接続クライアント数を増加させつつファイルを同時取得する実験を実施し、データ転送速度の変化を計測した。その結果から計算し、バックエンドサーバに対する接続クライアント数に偏りが生じた場合、

それを提案手法によって平滑化することによって、平均転送速度、最低転送速度、ともに向上させられることがわかった。

6.2 今後の課題

今後の課題としては、以下の2点が挙げられる。

まず、バックエンドサーバ切替手段の自動化である。本研究で作成したプロトタイプでは、キーボードの打鍵によって手動でバックエンドサーバを切り替える機構を実装した。しかし、ロードバランサとして実環境で使用するためには、ソフトウエアの処理によって自動的に接続を切り替える機構を実装する必要がある。なお、実装にあたっては、既存のリバースプロキシ型のロードバランサに本研究の提案手法を組み込む方法が、実現性が高いと考えられる。

次に、提案手法による性能改善のさらなる検討が必要である。実際のwebサイトは、様々なハードウエアやネットワークによって構成されている。また、単に静的なHTMLページだけでなく、サーバ上でアプリケーションが動作し、データベースサーバなどと連携して、動的なコンテントを提供している場合も多く、個々のサイトによって、ボトルネックとなりうる要素が異なる。

本研究では、個別のボトルネック要素を仮定せずに、接続クライアント数をサーバ間で平均化することで、特にクライアントが少数である状況で、性能が向上することを確認したが、ボトルネック要素によっては、性能変化の特性大きく異なる可能性が高い。個々のサイトに提案手法を適用する上では、ボトルネック要素を詳細に分析し、適切な切替機構を実装した上で運用にあたる必要がある。

(34)

謝辞

本論文の作成にあたり、日頃より御指導を頂いた早稲田大学理工学術院の後藤滋樹教授に深く感謝いたします。

竹谷賢二さん、山田大輔さん、河野真也さん、時光潤さん、鈴木幹也さん、夏目祐輔さん、板倉弘明さん、岸本和之さん、魏元さん、下田晃弘さん、の皆様にも、後藤研での生活全般でお世話になりました。

また、大学院在学中に奨学金を貸与し、生活を助けていただいた独立行政法人日本学生支援機構および日本政府と納税者のみなさまに感謝いたします。

最後に、私の無能力さを強く確信しながらも、学費を支払い、書籍を毎年買い与え続けてくれた父と母に感謝いたします。

(35)

参考文献

[1] Koichiro Doi and Shigeki Goto, “Load Balancing with HTTP Session Handover”, CORE University Seminar, Jeju, Korea, October 2007.

[2] 総務省, “平成19年情報通信白書”

http://www.johotsusintokei.soumu.go.jp/whitepaper/ja/h19 [3] 総務省, “ブロードバンドサービスの契約数等（平成19年9月末）”

http://www.soumu.go.jp/s-news/2007/071218_4.html [4] “KDDI”

http://www.kddi.com/

[5] “ウィルコム”

http://www.willcom-inc.com/

[6] Wold wide web consortium, “XHTML2 Working Group Home Page”

http://www.w3.org/MarkUp/

[7] Internet Assigned Numbers Authority, “PORT NUMBERS”

http://www.iana.org/assignments/port-numbers

[8] Internet Assigned Numbers Authority, “HTTP Status Code Registry”

http://www.iana.org/assignments/http-status-codes [9] “Ultra Monkey”

http://sourceforge.jp/projects/ultramonkey/

[10] “Ruby on Rails”

http://www.rubyonrails.org/

[11] “Blogger”

http://www.blogger.com/

(36)

参考文献

[12] 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.

[13] デージーネット『Linux アドバンストネットワークサーバ構築ガイド HAサーバ構築編』

秀和システム, Dec 2005.

[14] Douglas E. Comer著, 村井純・楠本博之訳『TCP/IPによるネットワーク構築原理・プロトコル・アーキテクチャ』共立出版, Aug 2002.

[15] V Cerf, R. Kahn, “A Protocol for Packet Network Interconnection”, IEEE Transaction on Communication, vol. COM-22, pp.637–648, May 1974.

[16] H-Hash, “Studying HTTP”

http://www.studyinghttp.net/

[17] ささだこういち, “YARV: Yet Another Ruby VM”

http://www.atdot.net/~ko1/tmp/yp.pdf

[18] Rubyコミュニティ, “Rubyリファレンスマニュアル – TCPServer”

http://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=TCPServer [19] Apache Foundation, “ab – Apache HTTP server benchmarking tool”

http://httpd.apache.org/docs/2.0/programs/ab.html [20] Netcraft, “October 2007 Web Server Survey”

http://news.netcraft.com/archives/2007/10/11/october_2007_web_server_

survey.html

[21] 西田佳史, 日本ネットワークインフォメーションセンター編, ”TCP 詳説” www.nic.ad.jp/jp/materials/iw/1999/proceedings/C03.PDF

[22] W.Richard Stevens, “TCP/IP Illustrated, Volume 1: The Protocols”, Addison-Wesley, 1994.

[23] David A. Patterson, John L. Hennessy, “Computer organization and design 3/e”, Morgan Kaufmann, 2005.

[24] アンドリュー・S. タネンバウム『構造化コンピュータ構成第4版』ピアソンエデュケーション, 2000.

[25] Andrew S. Tanenbaum, “Computer Networks 4/e”, Prentice Hall, 2003.

(37)

参考文献

[26] Nicholas G. Carr, “Does IT matter?”, Harvard Business School Press, 2004.

[27] Ben Laurie, Peter Laurie, “Apache 3/e, The definiteve guide”, O’Reilly, 2003.

[28] まつもとゆきひろ,石塚圭樹『オブジェクト指向スクリプト言語Ruby』 ASCII, 1999.

[29] 竹下隆史, 村山公保, 荒井透, 苅田幸雄『マスタリングTCP/IP 入門編第4版』オーム社, 2007.

[30] 砂原秀樹, 知念賢一,中田秀基, 松岡聡, 後藤滋樹『岩波講座インターネットネットワークアプリケーション』岩波書店, 2003.

[31] 後藤滋樹, 外山勝保『電子情報通信レクチャーシリーズインターネット工学』コロナ社, 2007.

[32] George Apostolopoulos, Vinod Peris, Prashant Pradhan, Debanjan Saha, “L5: A Self Learning Layer-5 Switch”, IBM Research Division, 1999.

[33] Andy Oram, Greg Wilson, “Beautiful Code”, O’Reilly, 2007.

(38)

付録 A

プロトタイプのソースコード

require ’socket’

require ’gserver’

$running = true

class LoadBalancer < GServer

PORT = 8080

HOST_ADDR = "192.168.0.20"

AUDIT = true

MAX_CONNECTIONS = 1

#バッファが大きい方が転送効率が高いが、バックエンドサーバとの

#切断と再接続のタイミングが少なくなる BUF_SIZE = 1024 * 1024

def initialize(port=PORT, host=HOST_ADDR, *args) super(port, host, MAX_CONNECTIONS, *args) end

def serve(io)

#ブラウザのHTTPメッセージを受信 req_str = []

(39)

付録 A プロトタイプのソースコード

resource = ""

while s = io.gets req_str << s

if s[0..2] == "GET" #リソース名を保存 arr = s.split(/ /)

resource = arr[1]

end

break if req_str.last == "\r\n"

end

#ブラウザのHTTPメッセージをサーバに対して再送信

#Rangeフィールドを追加したりするので、末尾の\r\nはpopして除去

log("[ " << resource << " ] サーバにHTTPメッセージを発行中\n") req_str.pop

sock = issue_GET("192.168.0.30", 80, req_str)

#以下、サーバからの応答をブラウザに返す

log("[ " << resource << " ] サーバデータをブラウザに転送中\n")

#ヘッダの処理 Content-Lengthを読み取って切断タイミングを計る

#これがないと、どこまで読み取ったらいいか分からないのでタイムアウトまで時間がかかる

total = 0 #リソースの合計データ長（オクテット）

len = 0 #読み取ったデータ長（オクテット）

reconnect = false #ハンドオーバによる再接続であるか

while true

#TODO: 元々がRangeだった場合は、レスポンスがContent-Rangeとなるので、その場

合も考慮する必要がある。

#HTTP/TCP再接続 if reconnect

additional = []

(40)

additional << "Range: bytes=" << (len) << "-" << total << "\r\n"

sock = issue_GET("192.168.0.30", 80, req_str, additional)

log(’[ ’ << resource << ’ ] 部分取得済...: ’ << len.to_s << ’/’ \\

<< total.to_s << "\n") end

#TODO: パターンマッチをする前に先頭数文字（[0..3]）を比較すれば計算量を減らせ

る

#再接続の時は、sock.getsではなく、前回の接続先から帰ってきたHTTPメッセージをそのまま返す

log("[ " << resource << " ] HTTPヘッダを転送中\n") if !reconnect while s = sock.gets

if !reconnect

if /^HTTP\/.* (\d+ .*)$/ =~ s

log("[ " << resource << " ] オリジナルレスポンスコード: " << \\

$1.chomp! << "\n")

elsif /^[Cc]ontent-[Ll]ength: (\d+)\r\n/ =~ s total = $1.to_i

log("[ " << resource << " ] データ長: " << $1 << "\n") end

end

#HTTPのレスポンスヘッダは、再接続後は無視して破棄

io.write(s) if !reconnect break if s == "\r\n"

end

if total > 0

log("[ " << resource << " ] ブラウザにHTTPボディを転送中\n") while len < total && $running

if total - len > BUF_SIZE s = sock.read(BUF_SIZE) else

(41)

s = sock.read(total - len) end

io.write(s) len += s.size end

elsif

log("[ " << resource << " ] HTTPボディなし\n") end

sock.close

log("[ " << resource << " ] 切断\n") if total > len

$running = true reconnect = true

log("[ " << resource << " ] 再接続中...\n") else

break end end

log("[ " << resource << " ] サーバデータをブラウザに転送終了\n") end

def issue_GET(host, port, req_str, additional=nil) sock = TCPSocket.open(host, port)

req_str.each{|line|

sock.write(line) }

if additional != nil additional.each{|line|

sock.write(line) }

end

sock.write("\r\n")

(42)

log("再接続 to " << host << ":" << port.to_s << "...成功\n") return sock

end end

server = LoadBalancer.new server.audit = true

server.start

GServer.in_service?(8080) server.stopped?

print "***** Hit ’s’ key to switch the back end server *****\n"

while comm = gets if /^s.*$/ =~ comm

$running = false

print "COMMAND: switch servers\n"

end end

WEB ロードバランス HTTP セッションハンドオーバによる

2007 年度 修士論文

HTTP セッションハンドオーバによる