Webサーバで動的負荷制御を行う為のシステム情報の検討

全文

(1)社団法人情報処理学会研究報告 IPSJ SIG Technical Report. 2006−OS−101（6） − 12006／2／16. Web サーバで動的負荷制御を行う為のシステム情報の検討加地智彦. 最所圭三. （香川大学）. ブロードバンドの発展によりインターネットは社会の基盤となっている。インターネットの利用目的の中心的存在となった Web サーバは以前よりも多大な負荷がかかるようになった。本研究では、Web サーバの負荷状況によりアクセス制御を行うことでサーバの可用性を上げ、かつアクセスを制限されたユーザに救済措置をとることでユーザの不満を低減させるサーバを開発する。本稿では提案の Web サーバの概要を述べ、さらに、負荷制御を行うための基礎情報を得るために行った高負荷時の応答時間や、応答時間とシステム情報の関連性について調査するための実験の結果について報告する。. Discussion on System Information to Control Load of Web Servers. T.Kaji and K.Saisho (Kagawa Univ.) The Internet is becomes a base of society by the development of broadband. Web servers, which is core of the internet, are used heavier than before. In this research, the server which has high availability by controlling access using server status is proposed. That reduces user’s compliant by helping to users rejected his access. This paper outlines this server, and reports results of two experiments. One is experiment to explain response time from server has high load to basic information to control load. The other is experiment to measure relation to response time and system information.. １．はじめに. 供できない状況である。このような状況に対応す. ブロードバンドの発展により、1 家に 1 台の. るためにミラーリングなどのサーバ負荷分散技. PC の時代になり、インターネットを楽しむ人々. 術が発展してきた。しかしながら、Web サーバ. が増えてきた。それに応じて、様々な新しいコン. へのアクセス要求は急な増減が多く、予測が困難. テンツが現れてきた。完全に社会インフラのひと. であるためせっかく投資したハードウェアが無. つとなったインターネットであるが、そのサービ. 駄になることも多い。また、ハードウェアを増や. スの最も大きな役割を果たす Web サーバには今. せば増やしただけ、そのために必要なハードウェ. までに無い多大な負荷がかかるようになってき. ア及びメンテナンスコストも増加する。このため、. た。多数のユーザからのリクエストが殺到するサ. コンテンツ提供者はハードウェアの追加投資に. ーバでは、ある時間帯ではまともにサービスを提. 慎重にならざるを得ない。その結果として利用者. −41− 1.

(2) はコンテンツを満足に閲覧することができない. ・ロードバランサ[3] 前述の DNS ラウンドロビンや DNS Balance. 場合が多くなる。そこで我々はシステムの負荷状況に応じて効果的なアクセス制御を行うことで、. は DNS サーバの一機能としてソフトウェア的に. 可用性が高くかつコンテンツを利用するユーザ. 実装されたものであり、負荷分散を専門として作. にとっても不満が発生しにくい Web サーバを開. られた機構ではない。負荷分散を目的としてハー. 発することにした。本稿では、その第一ステップ. ドウェアで実現された機構のひとつとしてロー. として Web サーバのサービス状況とサーバの負. ドバランサがある。DNS ラウンドロビンと似た. 荷状況の関連について実験を通じて得られた結. ような方法や、サーバのクライアント接続数や応. 果について報告する。２章で従来の負荷対策を紹. 答時間を監視して接続するサーバを決定する方. 介し、３章にて当研究で開発するシステムの概要. 法など、さまざまなアルゴリズムで負荷分散を行. を説明する。4 章と 5 章では、研究室内で行った. うものもある。複雑なアルゴリズムを実装してい. Web サーバへの負荷実験の結果を示す。. る機器ほど高価である。・Web サーバでのアクセスの制限[4] Web サーバでアクセスを制限することでサー. ２．関連研究本章では現在行われている過負荷に対応する. バにかかる負荷をコントロールしようと言う方. ための主な方法について述べる。. 法である。Apache モジュールの形で様々なもの. ・ミラーリングサーバを用いた負荷分散. が公開されている。例として mod_access_limit、. 大量のアクセスの負荷に対応するために、サー. mod_conn、mod_bwshare モジュールについて. バを複数用意し、それらサーバ群にアクセスを分. 述べる。これらモジュールを利用することによっ. 散して処理を行う方法である。サーバ群はデータ. て多少の応答時間の低下が起こる。また、それら. の同期が取られているミラーリングサーバであ. のモジュールはシステムの負荷状況を考慮する. る。大量のアクセスがあった場合、それらのクラ. のではなく、特定の条件に従って負荷制御を行っ. イアントにミラーリングサーバの IP アドレスを. ているに過ぎない。. 教えてリダイレクトさせることで負荷分散を行. ・mod_access_limit[5]. う。ミラーリングサーバの選択には、DNS ラウ. mod_access_limit モジュールは特定の URL. ンドロビン、DNS Balance などのソフトウェア. に対する同時アクセス数を制限する。設定値以上. 的な方法、ロードバランサ装置などの導入による. のアクセスがあった場合、その URL に対するア. ハードウェア的な方法がある。. クセスを拒絶する。ここでの同時アクセスの定義. ・DNS ラウンドロビン[1]. は、同じ URL を処理しているプロセス数である。. ひとつのドメイン名に対して複数の IP アドレ. 静的なページだけでなく、動的に生成されるペー. スを割り当て、DNS サーバに問い合わせがある. ジにも対応できるため、システムに負荷をかける. 度に違う IP を答えることで負荷分散を行う方法. ページが分かっている場合、そのページに対する. である。DNS サーバは登録順に IP アドレスを答. 同時アクセス数を制限することでサーバ全体の. えるだけなので Web サーバの負荷状況やシステ. 負荷を軽減することができる。バーチャルホスト. ムダウンの有無を反映できない。. やディレクトリ毎、ファイル毎のアクセス数の制. ・DNS Balance[2]. 限を行うことも可能である。. DNS ラウンドロビンを改良し、ユーザの IP ア. ・mod_conn[6]. ドレス、サーバの性能、ロードアベレージなどを. mod_conn モジュールはクライアントホスト. 元にランク表を作成し、それに従ってユーザが接. 毎の同時アクセス数を制限する。バーチャルホス. 続すべきサーバを指示する機構を追加したもの. トやディレクトリ、拡張子毎の設定も可能である。. である。ランク表は一定期間毎に更新されるため、. mod_access_limit モジュールとの違いは. 動的な負荷分散を可能としている。. mod_access_limit モジュールが特定 URL に対. 2 −42−.

(3) して全体のリクエスト数を制限するのに対し、. ③は、②で挙げたような仕組みを実装する際に、. mod_conn モジュールはあるファイルに対して. 指示した時間帯になればクライアントソフトウ. クライアントホスト毎のリクエストを制限する。. ェアが自動的にサーバにアクセス要求を出すな. ・mod_bwshare[7]. ど、サーバとクライアントがそれぞれの状態を考. mod_bwshare モジュールはクライアントホスト. 慮しながら協調して通信を行う仕組みを用意す. 毎に１秒当たりの転送量・同時アクセス数を制限. ることである。この時、クライアントソフトウェ. する。設定した時間の範囲内でクライアントが使. ア（本研究においては Web ブラウザ）を変更し. える転送量もしくは同時アクセス数（この場合、. なければならないが、プラグインの追加で実現す. 同時にダウンロード出来るファイル数と言い換. る予定である。. えた方が解りやすい）は制限されており、その回. ④については、サーバがサービス可能であり、. 数または転送量を使い切るとアクセスが拒否さ. クライアントがサーバにアクセス可能な状態で. れる。転送量あるいは同時アクセス数は時間を追. ある時に、現在クライアントが閲覧しているデー. うごとに回復する。回復する割合は設定できる。. タが Web サーバ上で更新ているなら、クライア. ステータス監視用のツールが付属している。アク. ントのデータを自動的に更新する仕組みを導入. セス拒否時には、クライアントに対してアクセス. することである。現在、似たような技術として. 可能になるまでの時間を伝える。. Ajax[8]があるが、サーバの基本機能として実装することにより、より効率的なサービスが出来る. ３．システムの概要. と考えている。. 本研究では以下の機能を持つ Web サーバシス. また、2 章で述べたような負荷分散やアクセス. テムの開発を目標としている。. 制御のための Apache モジュールなども共に利. ① サーバに負荷がかかるとアクセス制御を行. 用できる仕組みを実現しようと考えている。本稿では①を実装するために必要な情報を得. う。 ② アクセスを拒絶されたクライアントに対し. るための基礎的な実験を行い、実現のための方針を検討する。. ては何らかのサポートをサーバが行う。 ③ クライアントとサーバ間で協調してデータ. ４．負荷実験. 転送を行う。. 本研究では、アクセスが行われている際にサー. ④ サーバのデータが更新されれば出来るだけ. バにかかる負荷状態を把握する必要がある。そこ. 早くクライアントのデータも更新する。 ①は、2 章で紹介した Apache モジュール群と. で、実際にサーバに対し多数のアクセス要求を行. 似ているが、サーバの負荷状況を監視する点が大. って負荷をかけることにした。. きく異なる。管理者が設定した閾値を超えると、. 本章では、負荷状況の指標としてアクセスの応答. アクセス制御を行い、新しく来たアクセスを拒絶. 時間を用いる。 Web サーバデーモンに「Apache」[9]を用いる。. し、アクセス制御を行うまでに来たアクセスを処理することで、サーバがダウンすることを防ぎ、. サーバ上に掲示板 CGI プログラム「ASKA BBS」. かつ残っているアクセスに対して出来るだけ早. [10]を設置し、Microsoft 社の「Web Application. く処理が済むことを保証する。. Stress Tool」（以下 WAST）[11]を用いて、連続. ②は、アクセスが拒絶されたユーザに対して何. 書き込みを行った。「ASKA BBS」は連続書き込. らかの急性措置を取ることでユーザの不満を少. みを禁止しているので、今回の実験では連続書き. しでも和らげるためのものである。例えば、拒絶. 込み禁止処理の部分を無効にした。実験環境は表. されたユーザに対してはサーバが指示した時間. 1 の通りである。. 帯にアクセスすればその接続を保障する、などである。. 3 −43−. WAST の設定はソケット数を３０とし、テス.

(4) 表 1：実験環境. 100. サーバ. クライアント 1. クライアント 2. CPU. Xeon2.4Gx2. Athron64x2 4400+. CeleronD2.53G. Memory. 1GB. 1GB. 512MB. OS. FedoraCore3. WinXP Pro SP2. WinXP Pro SP2. Httpd. Apache 2.2. 処理時間(秒). 60 40 20. 100base/T. ト期間を 5 分間とした。ネットワークには. 30 0. 25 0. 20 0. 15 0. 10 0. 50. 0. 0. 応答時間(秒). 100base を用い、クライアントが１台のときと２. 図 1：クライアントが 1 台のとき. 台のときとについて実験を行ったが、Web サーバへのアクセス数はクライアント数に比例する。. 100. Apache のログに書かれる応答時間を解析するこ. 80 応答時間(秒）. とにより負荷状態を調べた。図１と図２は、そ. れぞれクライアントが１台のときと２台のときの実験結果を示す。また、表 2 は、1 秒未満で処理できたアクセスおよび 1 秒以上かかっ. 60 40 20. たアクセスの全体のアクセスに占める割合をこの表から、全体に占める 1 秒以上の処理が. 30 0. 25 0. 15 0. 10 0. 0. 50. 0. それぞれ示している。. 20 0. Network. 80. 経過時間(秒）. かかるアクセスの割合はそれほど大きくない。. 図 2：クライアントが 2 台のとき. 頻度の違いはあるが、どちらの場合も突発的に負荷が大きくなれば突発的に応答時間が長く. 表２：全アクセスに占める応答時間の割合. なるアクセス頻度が増加し、またそれらの応答時間自体も図 1 と図２を比較して解るように. クライアント 1 台. クライアント 2 台. 長くなる傾向があることが分かった。しかし、. 応答時間 1 秒未満. 93.6%. 88.3%. 単純に応答時間だけではサーバの負荷状況を. 応答時間 1 秒以上. 6.4%. 11.7%. 求めることが出来ないことがわかった。. 平均応答時間(秒). 0.30. 0.72. よって負荷制御が可能であると考え、その関連性. ５．システム情報の検討前章の結果を踏まえ、本章ではシステム情報を. を調べることにした。. 調べることにした。OS は、CPU 時間、ロード. Apache は、アクセス時間などをログに残すこ. アベレージなどの状況を保持しており、本稿では. とが出来るが、細かなシステム情報を残すことが. これらの情報をシステム情報と呼んでいる。今回. 出来ない。. の実験で使用しているサーバの OS である Linux. このため、我々は Web サーバ上でアクセス処. では、/proc ファイルシステム[12]によってシス. 理終了時にシステム情報をログに書き残す. テム情報を取得することができる。. Apache モジュール[13]を作成して実験した。 Apache は高度にモジュール分割されている。. 4 章の実験では、サーバに負荷をかけると突発的に応答時間が長くなるアクセスが現れて. その動作は図３に示すサイクルを持ち、開発者は. いるが、このようなアクセスとシステム情報に何. 作成した Apache モジュールをこのサイクルに. らかの関連があるのであれば、システム情報に. 組み込むことが出来る。今回の実験ではログ出力. −44− 4.

(5) ロードアベレージに関しては getloadavg 関数を. 子プロセス起動終了処理. 待機. リクエスト解析. 使用して現在の情報を得る仕組みを組み込んだモジュールを実装した。実験は表１と同じ環境を用い、クライアントは 2 台で行った。. URI変換. ログ出力. 図４は CPU 使用率およびロードアベレージと応答時間の関係、図５はディスク入出力、メモリ. コンテンツ出力. ヘッダ解析. 微調整. アクセス制御. ＭＩＭＥチェック. アクセス許可. 100 80. 認証. UserCPU(%). 60. ロードアベレージ. 図３：Apache ライフサイクル 40. 後にシステム情報のみを別にログに書き込むモ. 20. SystemCPU(%). 0. 応答時間(秒） 0 30. 0 25. 20. 経過時間(秒). 響すると思われる、CPU 時間、ロードアベレージ、メモリ残量、ネットワークでのデータの入出. 0. 0. 10. 15. 0. 50. ログに残すシステム情報として、応答時間に影. 0. ジュールを作成した。. 図４：CPU 関連. 力およびディスク入出力を選択した。これらの情報は、表４に示すファイルやシステムコールを用. 100 メモリ残量(1/10000)kB. いて取得できる。. 80. /proc/stat の CPU 使用率情報はサーバの起動時から user や system,idle に費やされた CPU 時間が記録されている。/proc/diskstats には起動時. データ送信(1/10000)B. 60. 40. 応答時間(秒). からのディスク入出力量が記録されている。また、 20. 30. 0. 0 25. 20. 15. 0. 0. 0 10. 0. モリ容量の割り当てが記録されている。メモリ残. データ受信(1/10000)B ディスク入力(1/10)block ディスク出力(1/10)block. 50. が記録されている。/proc/meminfo には現在のメ. 0. /proc/net/dev には起動時からのデータ送受信量. 経過時間(秒）. 量を得るためには Free の数値とキャッシュ、バ. 図５：メモリ及びデータ入出力関連. ッファ量の合計を計算する必要がある。以上のことから、CPU 利用時間、ディスク入 30. 関しては値の変化量を、メモリ残量に関しては Free,キャッシュ、バッファの合計を計算し、表４：システム情報の取得方法 CPU 使用率. /proc/stat. メモリ残量. /proc/meminfo. ディスク入出力. /proc/diskstats. ネットワーク送受信バイト数. /proc/net/dev. ロードアベレージ. getloadavg(3). ロードアベレージ変化量. 出力、ネットワークでの送信及び受信バイト数に. 20. 10. 0 0. 10. 20. 30. 40. 50. 60. 70. 80. -10. -20. -30. 応答時間（秒）. 図６：ロードアベレージ変化量との関連 −45− 5. 90.

(6) 残量およびネットワークでの入出力と応答時間. 今後の課題として、メモリやディスク、ネッ. の関係を示している。応答時間のグラフとスケー. トワーク帯域を逼迫する負荷をかけた場合の. ルを合わせるため、メモリ残量やディスク入出力、. 応答時間の傾向の調査や、ロードアベレージの. ネットワーク送受信バイト数に関してはスケー. 急激な変化があった場合にアクセス制御を行. ルを調整している。. ったときに効率的な負荷制御の効果があるか. 図４のグラフから、ロードアベレージが大きく. を調査することが挙げられる。. 増えるときに応答時間が長くなる傾向があるこ示すようにロードアベレージの変化量と応答時. 参考文献： [1] Paul Albitz, Cricket Liu 著(高田、小島監訳、. 間との関係を散布図にしてグラフ化した。ロード. 小舘訳):DNS&BIND、オライリー・ジャパン、. アベレージが急激に変化すればするほど応答時. 2002. 間が長くなる傾向があることが良く分かる。. [2]DNS balance. CPU 使用率に関しては、実験ではほとんど 100%. http://www.netlab.is.tsukuba.ac.jp/~yokota/izumi/. の状態になっており、関連性を見出すことができ. dns_balance/. なかった。. [3]キーマンズネット：ロードバランサ基礎. とが分かった。この傾向を確認するために図６に. 図５のグラフから、ネットワークでの送信バイ. http://www.keyman.or.jp/search/30000363_1.html. ト数は 910 キロバイト/秒以下でネットワークが. [4] Netnice Project. 影響しているとは考えられにくい。受信に関して. http://www.netnice.org/pukiwiki.php. は、微々たる物であった。同様に、ディスクアク. [5]mod_access_limit. セスに関しては 280 ブロック/秒以下になってお. http://mm.apache.or.jp/pipermail/apache-users/. り HDD の性能を考慮すれば、これが影響してい. 2002-January/000879.html. るとは考えにくい。メモリ残量に関してはスワッ. [6]mod_conn. プが発生するほど逼迫していなかったので、これ. http://programmer.lib.sjtu.edu.cn/apache/. も関連性を見出せなかった。. modules.html. 以上のことから、今回の実験ではロードアベレ. [7]mod_bwshare. ージの変化だけがアクセスの応答時間に影響し. http://www.topology.org/src/bwshare/README.html. ていた。. [8]Ajax : A New Approach to Web Applications http://www.adaptivepath.com/publications/essays/a rchives/000385.php. ６．まとめ現在、システムの負荷状況に応じてアクセス制. [9] B.Laurie , P. Laurie 著(田辺監訳、大川訳):. 御を行う Web サーバを開発中である。本稿では. Apache ハンドブック、オライリー・ジャパン、. Web サーバに負荷をかけたときの応答時間およ. 2003. び応答時間とシステム情報との関連についての. [10]ASKA BBS. 調査結果を示した。その結果、Web サーバに負. http://www.kent-web.com/bbs/aska.html. 荷をかけると、突発的に応答時間の長くなるアク. [11] Web Application Stress Tool,. セスが現れるが、その時システムのロードアベレ. http://www.microsoft.com/japan/technet/archive/ itsolutions/intranet/downloads/webstres.mspx. ージが急激に変化する傾向があることが分かっ. [12] JM Project,. た。また、今回の結果では CPU 使用率がたとえ 100%だからといって必ず応答時間が長くなるわ. http://www.linux.or.jp/JM/html/LDP_man-pages/ man5/proc.5.html. [13] 小山浩之著： Web エンジニアのための. けではないことも分かった。今回の実験ではメモ. Apache モジュールプログラミングガイド、技術. リやディスク、ネットワーク帯域に関しては逼迫. 評論社、2003. させるほどの負荷がかけられなかった。. −46− 6.

(7)