情報処理学会研究報告
IPSJ SIG Technical Report

特徴量抽出と変化点検出に基づく
Web サーバの高集積マルチテナント方式におけるリソースの自律制御アーキテクチャ
松本 亮介1,a)

田平 康朗2,b)

山下 和彦2,c)

栗林 健太郎1,d)

概要：Web ホスティングサービスにて管理者がテナントごとのコンテンツを制御できないような高集積マ
ルチテナント Web サーバ環境では，ホスト間のリソース競合を減らすことが安定運用にとって不可欠である．しかしホスト数が増えるにつれ，サーバ内の原因となるホストの監視や制御のコストも増加するため運用は難しくなる．本論文ではリソースの各指標の時系列データの変化点検出，ならびにサーバ内ホスト
やプログラムの各指標の重みづけによって，システムリソース逼迫状況下で多量のリソースを消費するリクエストを同定し隔離する自律的アーキテクチャを提案する．

Autonomous Resource Control Architecture
for a Multi-Tenant Web Server by Detecting Change Points
in Time Series Data of the Feature Quantities
Ryosuke Matsumoto1,a)Yasuaki Tahira2,b)Kazuhiko Yamashita2,c)

Kentaro Kuribayashi1,d)Abstract: In a highly integrated multi-tenant Web server enviroment such as a Web hosting service where
the server administrator has no control of the contents in each tenant, reducing resource competition between
the server hosts is essential for the stable operation. As the number of the hosts increases, however, the operation becomes diﬃcult due to the increasing cost of monitoring and control to manage the responsible hosts
in the server. We propose an autonomous architecture of identifying and isolating the requests causing highsystem resource consumption under the resource exhaustion condition, by detecting the change points of theresource metrics as time series data, and by weighting the metrics of the hosts and programs in the server.

1. はじめに

ビス基盤の運用を効率化するために，Web サービスの基盤
技術とシステム運用技術 [7] が注目されている．Web サー

Web サービスの低価格化とスマートフォンの普及に伴

バの高集積マルチテナント方式は，単一の Web サーバに複い，Web サービス利用者の数が増大している．そのような数の利用者環境であるホストを高集積に収容することで，状況で，Web サービスを安定稼働させ，同時に Web サー

ハードウェアや運用のコストを低減するために利用され

1

2

a)
b)
c)
d)

GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka, 810-0001, Japan
GMO ペパボ株式会社 ホスティング事業部
Hosting Department, GMO Pepabo, Inc., Tenjin, Chuo ku,
Fukuoka, 810-0001, Japanmatsumotory@pepabo.com
tahira@pepabo.com
pyama@pepabo.com
antipop@pepabo.com

c 2012 Information Processing Society of Japan⃝る．しかし，高集積マルチテナント方式の一つである Web
ホスティングサービスは，ホストに配置される Web コン
テンツの動作を管理者が詳細に把握できないため，ホスト間でのリソース競合をあらかじめ予測することは困難である．また，原因となるホストの調査についても，高集積にホストが収容されている場合，数多くのホストが原因対象となる事が多く，かつ，その対象が時間の経過と共に変化

1

情報処理学会研究報告
IPSJ SIG Technical Report

していくため，適切な調査と対策に要するコストが著しくめの提案手法について，原因の自動的な検出と自動制御に高くなる [6]．

よって実現するリソースの自律制御アーキテクチャとその従来の Web サーバの高集積マルチテナント方式におけるリソース制御は，ホスト名やファイル名，接続元 IP アド
レス等の同時接続数を計測し，設定された閾値を超えたらリクエストを拒否あるいは中断するような方式 [2] であっ実装ついて述べる．4 章では提案手法の有効性を検証する
ための予備実験を行い，5 章でまとめとする．

2. リソース制御の既存手法と課題

た．その場合，同時接続数を超えると全く接続できなくな

高集積マルチテナント方式の代表的なサービスである

るため，利用者にとってはサービス停止と変わらず，サーWeb ホスティングとは，複数のホストでサーバのリソー

ビス品質を低下させることになる．その問題を解決するたスを共有し，それぞれの管理者のドメインに対して HTTP

めに，我々は，リクエスト毎に CPU 等のコンピュータリ

サーバ機能を提供するサービス [7] である．Web ホスティ

ソースの使用量を限定可能な隔離環境で，リソースは制限

ングサービスにおいて，ドメイン名 (FQDN) によって識別しサーバの負荷を低減させながらも継続的にレスポンス生

され，対応するコンテンツを配信する機能をホストと呼ぶ．

成処理を行うリソース制御手法を提案した [11]．一方で，高集積マルチテナント方式によって構築された Web ホ

どのような状況においてどれぐらいのリソース使用量を割スティングサービスでは，ホストの Web コンテンツはサー

り当てるのが適切なのかということや，負荷原因の状況に

ビス利用者によって自由に配置されるため，サーバ管理者

応じて同時接続数制限との組み合わせをどう判定するかにはコンテンツを管理することはできない．そのため，サーついて，刻々と変化しログの量も肥大化していく状況下でバ高負荷時は，Web サーバソフトウェアや OS のプロセス

人力による調査に頼って判断することは依然高コストであ管理の技術を使って制限する必要がある [1], [5]．

る．適切な制限項目や一定のルールに従った制限値を，い高集積マルチテナント方式の Web ホスティングサービ

かにシステム管理者の運用コストをかけずに調査し制限すスに求められる要件は，低価格化を実現するためにいかにるかという，ホスト単位で精細なリソース制御を行う際の単一のサーバにホストを数多く収容 [12] し，品質を向上す

課題が残っている．

るためにいかに安定稼働させるかである．安定稼働のため

従来の手法による問題を解決するためには，時間とともの重要な対策のひとつとして，一部のホスト間でのサーバに変化する各ホストのリソースの変化を都度把握し，原因のコンピュータリソース使用量の競合による大多数のホスとなるホストを自動的に検出した上で，その変化の特性にトの性能劣化を未然に防ぐ必要がある．

よって制限の組み合わせを決定し，自動で制限することが効果的である．本研究では，Web サーバのコンピュータリ

2.1 同時接続数制限の課題

ソースの特徴量を時系列データとして抽出してリクエスト

Web サーバ高負荷時のリソース制御手法は，これまで，毎に変化点検出を行い，原因となるホストやプログラムのホスト単位でのホスト名やファイル名，あるいは，接続元

変化らしさの重み付けを行った上で，サーバ全体のリソーの IP アドレスを利用してサーバに対する同時接続数を計

ス逼迫時には，重み付けリストの結果に基いて自律的に原測し，運用管理者が設定した同時接続数の閾値を超過して因となるリクエストを同定し分離するアーキテクチャを提いた場合リクエストを拒否するような方式 [2] であった．

案する．時系列データには，ホストおよびプログラム単位

これらの方式は，閾値超過時に接続を拒否するため，サーでのレスポンスタイムのデータとその時点の同時接続数を

バ自体の高負荷状態を防止するには効果的であるが，サー使用する．この時系列データに対して，変化点検出アルゴ

バへリクエストを送信しているクライアントからすると，

リズム ChangeFinder[4] により変化点スコアを計算し，リ

サービス停止と変わらず，サーバを高負荷状態から防ぐ事

クエスト時のホスト名とプログラム名にもとづいて，計測のみに特化した手法であった．すなわち，処理を継続しなしたスコアからリソースの傾向変化に寄与したホストおよ

がらも，リクエスト単位でリソースを制御することのできびプログラムの重み付けリストを更新していく．そして，ない粗い制限手法であり，制限によってサーバを安定さ

サーバ全体が高負荷状態になった場合に，重み付けリストせたとしても，ユーザ体験の質は大きく低下する．また，に従って原因の可能性が高いリクエストのみを，リソース

CPU を 100%消費するようなプログラムへのリクエスト

使用量が限定された隔離環境内で処理するようにする．こは，同時接続数を制限したとしても，たったひとつのリク

れらを，Web サーバのレスポンス生成処理の過程に組み込エストで CPU を占有するため，同時接続数制限では対処

むことにより，Web サーバはサーバ管理者の代わりに自律が難しい．

的に原因を解析し，必要な時にその原因に対処できる．
本論文の構成を述べる．2 章では Web サーバの高集積マ

2.2 リクエスト単位のリソース制御の課題

ルチテナント環境におけるリソース制御の既存手法と課題

リクエスト単位のリソース制御に関する既存手法は，について述べる．3 章では，既存手法の課題を解決するた

CPU 等のコンピュータリソースが閾値を超えた場合に，リc 2012 Information Processing Society of Japan⃝2

情報処理学会研究報告
IPSJ SIG Technical Report

するような仕組みになっており，その閾値を低くすると，サーバのより詳細なリソース負荷をサーバ管理者が認識できる代わりにアラート通知の届く頻度が増加し運用コストが増大する．閾値以下であっても，サーバの負荷原因となる要因は既に存在していることが多く，そのような情報を大量のログなどから収集し，アラート時に迅速に対応する
図 1

同時接続数と CPU 使用率の関係

Fig. 1 Trade-oﬀ between the number of simultaneous connections and CPU usage.

ことは難しい．
別のやり方として大量のログを解析することによって問題を分析し予測するような方法も考えられるが，低価格でサービスを提供することや，サーバ管理者やハードウェア

クエストを拒否あるいは中断する方式 [8] であった．このの限られたコストを考慮すると新規導入は容易ではない．

方式も 2.1 節と同様の理由によりユーザ体験の質を低下さ検知のリアルタイム性とコンピュータリソースのバランスせる手法であった．これを改善するため，筆者らは，リクをどう取るかといった問題もある．本手法では計算量をいエスト毎に最大 CPU 使用率といったコンピュータリソー

かに少なくし，提供サービスの構成を大きく変更すること

ス使用量を限定可能な隔離環境で，リソースは制限しつつなく Web サーバの拡張機能ソフトウェアとして導入できも継続的にレスポンス生成処理を行うリソース制御手法をる方向性を検討する．

提案した [11]．この手法によって，サーバの負荷状態を防ホスティングサービスとしてコンテンツを快適に配信し止するだけでなく，リソースの限定環境下では通常のレス続けることと，サーバを安定させるために問題となるホス

ポンス処理よりも低速ではあるが，クライアントにコンテトを制限することを両立させるためには，単一の制限手法

ンツを取得可能にすることができた．

だけではなく，状況に合わせてホストやプログラムに対す

図 1 に，同時接続数制限と CPU 使用率の関係，リソー

る同時接続数や各リクエストのリソース使用量の上限設

ス制限と CPU 使用率の関係を示す．CPU コアを 3 つを搭

定などを組み合わせて制限する必要がある．例えば，制限載していた Web サーバ上で，CPU を 100%使用するプロ

対象をホスト単位よりも，より粒度の細かいファイル単位

グラムに対してリクエストが送られてきた場合，同時接続にし，リクエスト単位の最大 CPU 使用量制限値と同時接数を 3 以上許可してしまうと容易に高負荷な状態になる．

続数制限値を適切に組み合わせることが必要である．しかしかし，最大同時接続数を 3 に設定すると，他のリクエ

し，高負荷状態が発生している中，迅速に原因対象の調査

ストは拒否する動作になるため，ユーザ体験の質は低い．

を行いながら，負荷をかけている原因の特徴を捉え，最適

一方で，リクエスト単位でリソースを制御する手法では，な組み合わせで制限設定を行うことは困難である．

CPU を 100%消費しようとするプログラムに対して，CPU

以上を整理すると，高集積マルチテナント環境の Web ホ

利用率を最大 30%に制限することにより，同一の環境でもスティング環境において，CPU の使用量といったリソー

最大 9 並列でリクエストを処理できるようになる．このよスが逼迫している状況で，サーバ管理者が負荷原因を特定

うな制限を課すことで，モバイル環境のような低速なネッする基本的な作業フローは以下のようになる．

トワークからのリクエストが増加していることを考慮した( 1 ) サーバの高負荷状態やレスポンス遅延をアラートで場合，ユーザ体験の質が向上することが見込める．
リクエスト単位でのリソース制御によって解決できない
課題としては，リクエストに割り当てる CPU 使用率の最検知( 2 ) 現時点のプロセスの CPU 使用量の状態から原因となるホストやプログラムの候補を検出

大値を設定することにより処理が低速化されたリクエスト( 3 ) レスポンスタイムやアクセス数のログの傾向から時間が停滞するため，Web サーバ全体の同時接続数の最大値をのかかっているホストやプログラムの候補を検出

超えた場合はサービス停止につながるという問題がある．

( 4 ) 候補の中からレスポンスタイムの傾向が大きく変化し2.3 原因調査と制限設定種別の取捨選択の課題( 5 ) 原因事象に対して，その特徴にあった制限設定を選択ている対象を原因と判定
高集積マルチテナント方式の Web ホスティングサービ

し実施スにおいては，サーバのリソースやサーバに対する HTTP

上記のようなフローで原因を特定する場合，サーバ管理

アクセス，実行されるコンテンツが刻々と変化する状況下者がアラートを受けて SSH でサーバにログインしてからで，人力による負荷原因の調査に頼って判断することは高作業を行う．高集積マルチテナント環境では，ホストの収コストであるという課題が挙げられる．また，既存のサー容数が著しく多いため，各フロー項目の作業量のコストがバ監視手法では通常，サーバのリソース値があらかじめ設

高い．また，調査するログの量も多いため検出にも時間が定した閾値を超過したらサーバ管理者にアラートを通知かかる場合が多い．また，その後の原因の特徴を考慮した

c 2012 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Report

制限の設定も困難である．
ここまで述べたことから，既存手法の課題として，以下の 2 点を挙げることができる．

( 1 ) 高集積マルチテナント環境下での過去のログを活用した負荷原因の調査コストが高く即時性が低い( 2 ) 負荷原因に対する制限設定や設定の組み合わせが人の判断に依存しており対応コストが高い
高集積マルチテナント方式による Web ホスティングサー

図 2

ビスにおいて，これらの課題を解決できる手法は未だ確立

リクエスト単位での自律制御フロー

Fig. 2 Flow of autonomous control per request.

していない．

3. 提案手法

{

成する必要がある．

( 1 ) 過去のリソース使用量の傾向と特徴を逐次学習しなが

st_score: 83,# 同時接続数スコア

rc_score: 32,# レスポンスタイムスコア

files: {path_to_progmra1: {ら高速に負荷原因を自動検出する

rc_score: 20,

高い自動制限を行う},
path_to_progmra2: {上記の 2 つの要件を満たすためには，サーバのリソース

st_score: 53,が逼迫していない状況でも，サーバのリソース変化に大きrc_score: 12,

く寄与した原因となるホストやファイルの特徴を解析する},必要がある．また，定常的にリソースを使用しているようして多かったとしても，高負荷時の調査コストの観点から
事前にリソース使用量が予測しやすく，経験的に突発的な高負荷の原因となることはまれであるため，それほど問題# プログラムファイルパス

st_score: 30,( 2 ) 検出結果に基づいて負荷の特徴にもとづいた即時性のなホストは，サーバのリソース使用量が他のホストと比較# ホスト名

host1: {2 章で述べた課題を解決するためには，以下の 2 つを達

},
},
}




図 3

重み付けリストのデータ構造

Fig. 3 Data structure of the weighted lists.

にならない．一方で，高集積マルチテナント方式における突発的な高負荷の原因とその調査コストの観点では，サース使用量，特に CPU の使用時間と強く相関していると考バのリソース使用量の変化が大きいホストやプログラムほえられる．プログラムによっては sleep を実行している場

ど，問題になることが多いと考えられる．

合もあるため，厳密にはプロセスの CPU 使用時間などを本論文では，このサーバのリソース使用量の変化に注目した処理を行うアーキテクチャを提案する．提案手法で採用すべきであるが，本研究ではレスポンスタイムで十分にリソース使用量の用途に足りうると判断した．

は，まず Web サーバで管理している各ホストおよびプログ

変化点スコアの計算には SDAR モデルに基づく変化点

ラムのレスポンスタイムや同時接続数のようなリソースの検出エンジン ChangeFinder[4] を使う．SDAR モデルは，使用量を表す特徴量を時系列データとして抽出し，時系列

オンラインでの解析のために計算量を少なくし，過去の統データの変化らしさを数値化するために変化点検出による計情報の影響を次第に少なくしていく統計モデルである．

変化点スコアを算出する．次にリソースの特徴量の変化点

ChangeFinder は外れ値と変化点を統一的に扱うために，

スコアからホストとプログラムの重み付けリストを作成す

SDAR アルゴリズムによる二段階の学習と平滑化を組み合る．サーバ全体のリソース逼迫時やレスポンスが遅くなっ

わせて設計された非定常の時系列データにも対応しやすい

た時は，重み付けリストの重み付けスコアにもとづいて自アーキテクチャである．本手法では，Web サーバがリクエ

律的に原因となるリクエストをリソースの限定環境下で処ストの処理と並行して非定常な時系列データの変化点検出

理する．

を行うため，計算量の少ないアルゴリズムを採用すること
で，リクエスト処理に極力影響を与えないようにしている．

3.1 負荷原因の自動検出の実装

ホストとプログラムの重み付けスコアの作成には，リク

処理のフローを図 2 に示す．変化点検出を行う時系列

エストを処理する際に得られたホスト名とプログラム名を

データには，リクエストされたプログラムのレスポンスタ

図 3 に示すようなデータ構造で表現し，該当ホストとファ

イムとその時点での同一プログラムに対する同時接続数をイル名（図 3 中の host1 と files）が示す重み付けスコアに使う．レスポンスタイムは実行されたプログラムのリソー

変化点スコアを加算していく．重み付けスコアは，ホスト

c 2012 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report







> cf = ChangeFinder.new 5, 0.01, 10, 0.01, 7# /etc/httpd/conf.d/mod_mruby.conf=> #<ChangeFinder:0x7fad5c80be50 @ts_data_buffer=[],

LoadModule mruby_module modules/mod_mruby.so@change_point_analyze=#<ChangeFinder::SDAR:0x7fad5c80bb80>, @smooth_term=5, @outlier_analyze=#<ChangeFinder:# ChangeFinder の初期化処理をフック:SDAR:0x7fad5c80be20>>

mrubyPostConfigMiddle cf_init.rb cache> cf.learn [1,2,1,2,3,2,1,2,1]# 変化点スコアの計算処理をフック=> [6.2017912433901, 1.3973555597559, 2.4211198000217,

mrubyLogTransactionMiddle cf_score.rb cache

2.3979400886673, 1.7835503570548, 1.4166612339939, 1.4

837836144657, 1.2835583707215, 1.1556254255408]

図 5 mod mruby の設定例

Fig. 5 Configuration examples of mod mruby.

> cf.score 1=> 1.1044914205061



図 4 mruby-changefinder の実行例

Fig. 4 Execution examples of mruby-changefinder.

およびプログラムに対して 2 種類用意しておき，st score# ChangeFinder インスタンス生成
cf = ChangeFinder.new(5, 0.1, 10, 0.1, 3)# 仮学習データによる事前学習
cf.learn [1,1,1,1,1,1,1,1,1,1]には同時接続数の変化点スコアを，rc score にはレスポン
スタイムの変化点スコアを加算する．ホストのそれぞれの# 各フェーズでデータを取り出せるようにユーザデータに保存

スコアは，プログラムの各スコアの合計スコアを示す．こUserdata.new.cf_list = {}の処理をリクエスト単位で繰り返し行っていくことによ

Userdata.new.cf = cf

り，Web サーバのリソースの傾向変化に寄与したであろう

図 6 ChangeFinder の初期化処理スクリプト

ホストとプログラムの重み付けリストを作成できる．

Fig. 6 ChangeFinder initializing script.

提 案 手 法 の 実 装 に は Apache[3] と 筆 者 ら が 開 発 し た

mod mruby[10] *1 を採用した．mod mruby は Apache の機能拡張を mruby[9] で実装でき，高速かつ少ないメモリ

r = Apache::Request.new
cf = Userdata.new.cf

消費量で動作するため，本手法のようにリクエスト処理

cf_list = Userdata.new.cf_list hostname = r.hostnameの中で複数の処理を実現する必要がある場合に有用であ

res_time = r.response_time

る．また，ChangeFinder は mruby のモジュール mruby-changefinder*2 として実装し，mod mruby から直接実行で# vhost の ChangeFinder インスタンスが存在しなければ複製
unless cf_list.has_key?(hostname)

きるようにした．mruby-changefinder の実行例を図 4 にusercf[hostname] = cf.clone示す．この例では ChangeFinder.new に，変化点検出のた

end

めのパラメータであるモデルの係数の数と過去の学習結果# リクエストタイムから変化点スコアを計算しログに出力の影響を少なくする忘却係数をそれぞれ 2 種類ずつ渡してApache.log Apache::APLOG_ERR,

いる．これは，SDAR アルゴリズムの中で二段階の学習を

requesttime: #{r.response_time.to_s}

行っているためである．図 4 では，第 1 引数と第 2 引数に第 1 段階の係数の数と忘却係数，第 3 引数と第 4 引数に
第 2 段階の係数の数と忘却係数を渡している．第 5 引数には各学習段階で得られたスコアの時系列データに対して，

score: #{cf_list[hostname].score(res_time)}
hostname: #{hostname}




図 7

変化点スコア計算スクリプト

Fig. 7 Change point score analysis script.

データの平滑化を行う時間の枠を示す値を設定する*3 ．

ChangeFinder ではモデルの係数を増やせばより細かくの引数に時系列データの配列を渡すことによって，時系列

時系列データの特徴を抽出できるがその分計算量が増加

データの初期状態の学習を行い，その後に score メソッド

し，忘却係数を大きくすれば過去の学習データの影響を少の引数に次の時点でのデータを渡すことにより変化点スコなくできる．また，平滑化の時間の枠を大きくすると，突アを算出している．

発的な時系列データの変化の影響を少なくできるが，傾向変化点スコアの計算後は，図 3 のデータ構造に基づき，変化のスコアの算出が遅延する．図 4 では learn メソッド

スコアに紐づくホスト名とプログラム名に該当する score

*1
*2
*3

https://github.com/matsumotory/mod_mruby
https://github.com/matsumotory/mruby-changefinder
例えば，1 分毎に蓄積された時系列データに対して，10 を設定す
ると，10 分の枠の中でデータの平均値を計算し，時系列データを更新する．

c 2012 Information Processing Society of Japan
⃝にデータを加算する．図 5 に，Apache が mod mruby に
よってレスポンスタイムから変化点スコアを計算し，スコ
アをエラーログに出力する場合の mod mruby の設定例を示す．mod mruby の設定からは 2 つのスクリプトがフッ

5情報処理学会研究報告
IPSJ SIG Technical Report

クされており，Apache が起動時に実行するフックには，

表 1alba の実験環境

Table 1 Experimental Environment for alba.

図 6 に示す Ruby コードを登録しておく．また，Apache
がレスポンスを返した後に，ログ出力時に実行するフッ仕様

クには図 7 に示す Ruby コードを登録する．図 6 の Ruby

CPUIntel Xeon E5-2620 v3 2.40GHz

コードにより，ChangeFinder の初期化，事前学習，ホス

Memory32GBytes

ト単位のインスタンスを保存するハッシュを用意する．レServer

NEC Express5800/R120f-2E

OS

CentOS6 Linux Kernel 4.8.14

アカウント数

約 1300

ト毎に保存している ChangeFinder インスタンスから変化

ホスト数

約 10000

点スコアを計算し，エラーログに出力する．また，同様に

1 日の平均アクセス数

約 950 万スポンス処理後は，図 7 の Ruby コードによって，ホス

mod mruby で実装したファイル単位の同時接続数解析と制限ソフトウェアである http-access-limiter*4 によって，リクエスト処理の時点での同時接続数を取得できるため，その値から変化点スコアが計算できる．

負荷時には自動で適切な制限を行える．

4. 実験と考察

以上の手順により，Web サーバがリソース使用量の傾提案手法の有効性を検証するにあたり，まずは，2.3 節で向変化に大きく寄与したホストとプログラムの重み付けリ明らかにした運用フローを自動化するために，提案手法のストを自動的に作成する．この手順に従うことで，人間にプロトタイプ実装として筆者らが開発した自動監視・制限

とっては簡単な作業である変化点の認識を，より細かく長

ツール alba をプロダクション環境に導入して評価を行っ期間に渡ってスコアとして自動的に保存し指標化することた．続いて，重み付けリストの生成とリストの特徴にもとができる．

づいて適切な制限を行う処理については，プロダクションで動作させるまでには至っていないため，2.3 節で述べた

3.2 検出結果に基づく自動制限の実装
提案手法では，Web サーバが自律的に作成した CPU 使
用量や同時接続数の変化らしさの重み付けリストを使い，運用フローによる調査結果と，提案手法にもとづいてサーバのログを解析して作った重み付けリストの結果を比較して考察を行った．

Web サーバが高負荷の場合あるいはレスポンスタイムが増加した時に，重み付けリストの中で特にスコアが高いプロ

4.1 alba の評価と考察

グラムに対して自動的に制限を設定する．具体的には 3.1

表 1 に alba の動作検証環境を示す．本論文ではプロダ節で作成した重み付けリストに基づいて，スコアが高いホ

クション環境で動作している複数のサーバから，alba によストおよびファイルへのリクエストのみに対し，CPU 使用

る影響を考察しやすくするために，ホスト数やアカウント量が限定された隔離環境内でレスポンスを処理する．実装

数，一日の平均アクセス数が半年間で大きく変化していなには，筆者らが開発した mod mruby と mruby-cgroup*5 をいサーバを対象とした．

使用し CPU の最大使用率を，また http-access-limitter をalba は，Web サーバとは別のプロセスで 3 分毎に実行使ってプログラム単位での同時接続数およびホスト単位でされる．alba の監視・制限のフローは以下の通りである．

のプログラムに対する同時接続数を制限する．

ただし，ここでのアカウントとは複数のホストを契約して判断の基準は以下の通りである．サーバの高負荷時あるいるアカウントのことを意味し，アカウントに紐づく複数

いはレスポンスタイムが一定の閾値を超えた場合，リクエ

ホストの集合である．

ストのあったプログラムの st score が特定の閾値を超えて( 1 ) レスポンス監視用のコンテンツへの HTTP リクエス

いた場合には，http-access-limiter によってそのプログラ

トのレスポンス時間が 10 秒かロードアベレージが 60

ムに対する同時接続数を制限し，rc score も閾値を超えてを超えるいた場合は，mruby-cgroup により，リクエストを処理す( 2 ) 過去 3 分間のログから以下のいずれかの計測条件からるプロセスの CPU の最大使用率が限定した状態でプログ得られたアカウントに一致しているか，またはホスト

ラムを実行する．制限設定後にサーバの負荷が安定し，レがサーバ全体の 10%以上の計測値を示せば (3) へスポンスタイムの閾値を下回った場合は，その後一定の時( a ) アカウント単位で集計した処理時間の合計が最も間を設けた後に制限下で処理していたプログラムの制限を解除する．これらの基準を Web サーバのレスポンス生成
処理の過程で Web サーバの拡張処理として組み込むことにより，Web サーバは自律的に原因を解析し，サーバの高*4*5

https://github.com/matsumotory/http-access-limiter
https://github.com/matsumotory/mruby-cgroupc 2012 Information Processing Society of Japan⃝

多いアカウント( b ) アカウント単位で集計したアクセス数の合計が最も多いアカウント( c ) ホスト単位で集計したレスポンスタイムの合計が最も多いホスト( d ) ホスト単位で集計したアクセス数の合計が最も多

6

情報処理学会研究報告
IPSJ SIG Technical Report

図 8 alba 導入前後のロードアベレージの遷移

Fig. 8 Transition of load average with alba.
図 9alba 導入前後の CPU 使用率の遷移

Fig. 9 Transition of CPU usage with alba.

いホスト( 3 ) 全体の 10%以上の処理時間またはアクセス数を占有している場合は最大同時接続数 10，全体の 25%以上のリソースを利用している場合最大同時接続数 2 に制限する（アカウントが一致した場合はアカウントが管理する全てのホストに対して制限を設定する）( 4 ) 制限 30 分経過後にレスポンス時間が 10 秒以下かつ
ロードアベレージが 60 以下の場合，自動で制限解除
各パラメータは，導入した環境で，制限によって全体のアクセス数が大きく低下しないこと，Web サーバが高負荷状態にならないことを前提に予備実験を行い決定した．レスポンスタイム 10 秒としたのは，通常監視用コンテンツのレスポンスタイムは 1 秒程度であり，本来 10 秒となる

図 10

alba 導入前後の 1 秒間のアクセス数の遷移

Fig. 10 Transition of the number of access/second with alba.

とユーザ体験が大きく低下することになりかねないが，制限設定時に Apache のリロードに必要となる時間を考えるとその状況下では 3 秒の閾値では繰り返し検出してしまう
ため 10 秒と決定した．また，ロードアベレージについて
は，監視のアラートに繋がる値は導入環境において 100 程度であり，60 を超えた場合には 100 に到達してアラートとなることが経験的に確実であることから 60 と決定した．
最大同時接続数の制限値については，予備実験を繰り返した結果，上記で述べた前提のもとに値を決定した．
比較のために alba の導入例を示す．2016 年 9 月 15 日にホストの新規収容を停止し，その後ホスト数が大きく変わ図 11 alba 導入前後の一日のアラート数の遷移

Fig. 11 Transition of the number of alert/second with alba.

らない状態で alba を 2016 年 11 月 15 日に導入し，約 2 ヶ月間ロードアベレージとのモニタリングを行った結果につ負荷やアクセス数の直接的な改善は見られなかった．

いて，ロードアベレージのグラフを図 8，CPU のグラフを

alba 導入前後のサーバ管理者への 1 日毎のアラート数お

図 9，Apache に対する 1 秒間のアクセス数を図 10 に示

よびアラートの総数の遷移を図示したものを図 11 と図 12

す．各図の横軸は時間を示しており，縦軸は各時点での値に示す．alba 導入後にアラート数の削減に対する有効性を示している．CPU グラフの図 9 はシステム CPU 使用を示すデータは得られなかった．この理由としては，実運

率 (緑)，ユーザ CPU 使用率 (青)，idle 率 (黄) の重ね合わ用上はアラート通知を受けてサーバを調査した際は既にせを示している．この例では図 10 が示すように，全体とalba によって対応済みであり，設定反映のための Apache

して 1 秒間のアクセス数は概ね一定であり，図 8 や図 9 をのリロードによってアラート通知が行われる場合が多かっ

見ると，アクセス数と負荷の変化は相関がある．alba 導入たことが挙げられる．現在の alba は，制限を行うために前後で傾向に大きな変化はなく，alba 導入によるサーバのApache のリロードが必要であることから、リロードによっc 2012 Information Processing Society of Japan⃝7

情報処理学会研究報告
IPSJ SIG Technical Report

ルによって自動化されており対応が不必要であった場合や，アラートの受信から対応完了までの時間を評価の指標に加える必要がある．これらの評価を行うことで，サーバのリ
ソースが逼迫していない状況でも，サーバのリソース変化に大きく寄与した原因となるホストやファイルの特徴を解析する必要性を示すことができる．また，これらの評価によって、3 章で述べた本論文のアイディアの核である「負荷原因の調査コストが大きくなる原因としてはサーバのリソース使用量の大小よりも，ソース使用量の変化の大小が
図 12

alba 導入前後のアラート合計数の遷移

Fig. 12 Transition of total number of alert/second with alba.

高集積マルチテナント方式における突発的な高負荷の原因とその調査コストの観点から問題になることが多い」という主張の有効性を示すことができる．

て発生したアラートが検知されたものと推測できる．
参考文献

4.2 重み付けリストの考察[1]

次に，alba と同一の作業フローによって，高負荷状態を検知した時刻の調査結果とその日のレスポンスタイムが記録されているログを調査した結果を，3.1 節で示したような重み付けリストを生成するためのサンプル実装によって解析し，ホスト単位の変化点スコアから重み付けリストを

[2]
[3]

作成した結果との比較を行った．
その結果，日々の高負荷対応のフローでは，直近数十分[4]のアクセス数や転送量，レスポンスタイムから原因ホストを見つけ出すことができなかったが，1 リクエスト単位のレスポンスタイムの平均値を比較したところ，問題となる[5]

ホストの候補を検出でき，そのホストのみに着目すると高負荷時に大きく傾向が変化していることが分かり，負荷原
因であることがわかった．一方，重み付けリストからは，[6]

該当ホストのアクセス数は少ないにもかかわらず，重み付
けリスト上位に 10 位以内に位置し，問題となるホストとして検出できていた．この結果から，重み付けスコアにア
クセス数の数を考慮した計算方法を考慮することでより精[7]

度が高くなると考えることができる．

5. まとめ[8]

本論文では，高集積 Web ホスティングサービスのようにサービス事業者がホストに配置する Web コンテンツの動作をあらかじめ予測できない状況において，サーバ高負[9]荷時の調査や対応を Web サーバが自律的に行う手法を提[10]案した．そして，提案手法の有効性を示すために，まずは，

2.3 節で述べた運用フローを実装した alba の評価を行い，その有効性を考察した．

[11]

今後の課題としては，提案手法の重み付けリスト機能や特徴を考慮した自動制限機能を定期実行の alba をベースに mod mruby でリクエスト契機の処理に実装しなおした
上で，プロダクション環境で動いている alba と置き換えを行い，有効性がどの程度あるかを評価する必要がある．ま[12]

Che J, Shi C, Yu Y, Lin W, A Synthetical Performance
Evaluation of Openvz, Xen and KVM, IEEE Asia Pacific
Services Computing Conference (APSCC), pp. 587-594,
December 2010.
David J, mod limitipconn, http://dominia.org/djao/
limitipconn.html.
Fielding R T, Kaiser G, The Apache HTTP Server
Project, IEEE Internet Computing, Vol. 1, No. 4, pp.
88-90, 1997.
J Takeuchi, K Yamanishi, A Unifying Framework for
Detecting Outliers and Change Points from Time Series, IEEE transactions on Knowledge and Data Engineering, pp.482-492, 2006.
Kovri A, Dukan P, KVM & OpenVZ virtualization
Based IaaS Open Source Cloud Virtualization Platforms:
OpenNode, Proxmox VE, IEEE 10th Jubilee International Symposium on Intelligent Systems and Informatics, pp. 335-339, September 2012.
Mietzner R, Metzger A, Leymann F, Pohl K, Variability
Modeling to Support Customization and Deployment ofMulti-tenant-aware Software as a Service Applications,the 2009 ICSE Workshop on Principles of Engineering
Service Oriented Systems, pp. 18-25, May 2009.
Prodan R, Ostermann S, A Survey and Taxonomy ofInfrastructure as a Service and Web Hosting Cloud
Providers,10th IEEE/ACM International Conference on
Grid Computing, pp. 17-25, October 2009.
The Apache Software Foundation, Server
Wide
Configuration Limiting Resource Usage,
http://httpd.apache.org/docs/2.2/en/server-wide.
html#resource.
NPO 法人軽量 Ruby フォーラム, http://forum.mruby.
org/.
松本亮介, 岡部寿男, mod mruby：スクリプト言語で高速かつ省メモリに拡張可能な Web サーバの機能拡張支援機構 , 情報処理学会論文誌, Vol.55, No.11, pp.2451-2460,
2014 年 11 月
松本亮介, 岡部寿男, リクエスト単位で仮想的にコンピュー
タリソースを分離する Web サーバのリソース制御アーキ
テクチャ, 情報処理学会研究報告 Vol.2013-IOT-23, No.4,
2013 年 9 月.
松本亮介, 川原将司, 松岡輝夫, 大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086,
2013 年 3 月.

た，アラートが通知されたとしても，その後の対応がツー

c 2012 Information Processing Society of Japan⃝

8