情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

リクエスト単位で仮想的にハードウェアリソースを分離する
Web サーバのリソース制御アーキテクチャ
松本 亮介1,a)

栗林 健太郎1

岡部 寿男2

受付日 2017年6月26日, 採録日 2017年12月8日

概要：大規模 Web サービスの普及にともない，Web アプリケーションはますます高度化してきている．さらに，スマートフォンの普及によって，Web サーバへのアクセス数は日々増加してきおり，Web サーバの運用・管理が非常に重要になってきている．Web サーバソフトウェアにおいて，CPU リソースを多く消費するリクエストがあった場合，その処理を柔軟に制御する必要がある．しかし，既存の Web サーバのリ
ソース制御は，リクエストの同時接続数や単位時間あたりのリクエスト数が指定の閾値を超えた場合や，管理者があらかじめ設定した CPU 使用時間やメモリ使用量の閾値を超えた場合にリクエストを強制的に切断，あるいは，拒否するようなアーキテクチャになっている．そのため，処理を継続しながらもリソースを制御することができない．そのような状況を解決するためには，リクエスト処理を一時的に限られたリソースの範囲内に分離すれば，複数のリクエスト処理の間でリソース占有の影響を互いに受けることが原理的に生じない．そこで，本論文では，同一のサーバプロセス上で，リクエスト単位で任意のリソース分離が可能なリソース制御アーキテクチャを提案する．このアーキテクチャによって，各リクエスト処理
は一時的に仮想的なリソースを割り当てられ，そのリソースの範囲内で処理が行われる．そのため，特定のリクエスト処理のリソース使用超過による影響を受けにくくなる．さらに，大量にリソースを消費する
ようなリクエストであっても，リクエストを拒否・切断することなく，割り当てたリソースの範囲内で処理を継続させることが可能となる．
キーワード：Web サーバ，運用技術，リソース制御，Apache，cgroup

Resource Control Architecture for a Web Server Separating Computer
Resources Virtually at Each HTTP Request
Ryosuke Matsumoto1,a)Kentaro Kuribayashi1

Yasuo Okabe2

Received: June 26, 2017, Accepted: December 8, 2017

Abstract: As the increase of large-scale Web services, Web applications are increasingly sophisticated. The
increase of smartphones makes traﬃc to Web servers increase each day. Management of Web servers isincreasingly important. When a Web server receives resource-hungry requests, administrators of the web
server must control the resources ﬂexibly. However, existing resource control methods process mandatorilysuch as denial, disconnect or the like of the request when the number of simultaneous connections, request
per unit time, CPU used time or memory utilization exceed a certain threshold value. These methods can’t
control resources processing request. In this situation, if one request has the potential to occupy a majority
of computer resources, the server process can process other request in principle by separating resources of theserver process temporarily without using up the saving of computer resources. In this paper, we propose aresources control architecture separating computer resources virtually by a HTTP request for a Web server.
Each HTTP request processing is allocated virtual computer resources temporarily and the request is process
within the limit of the allocated computer resources in our architecture. Therefore, each request processing
has a very small eﬀect if clients access to contents heavily or a particular content occupy a majority of computer resources. If a request has the potential to occupy a majority of computer resources, our architecture
can process the request continually within the limit of the allocated computer resources without denying or
disconnecting requests mandatorily.
Keywords: Web Server, Operation Technology, Resource Management, Apache, cgroup

1

2

GMO ペパボ株式会社ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Fukuoka 810–0001, Japan
京都大学学術情報メディアセンター

c 2018 Information Processing Society of Japana)Academic Center for Computing and Media Studies, Kyoto
Univesity, Kyoto 606–8501, Japanmatsumotory@pepabo.com

1016情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

1. はじめに
大規模 Web サービスの普及や Web ホスティングサービ
ス [13] の低価格化にともない，企業だけでなく個人の日

さらに，特定のリクエストに対する制限が他のリクエストには適用されないように，あらかじめプロセスに制限を課するのではなく，HTTP リクエスト単位でリソース制御する必要がある．

記や作品をインターネット上で平易に公開することが可

既存の Web サーバの一般的なリソース制御 [3], [17], [23]

能となり，個人が Web サイトや Web サービスを持つ時代

は，リクエストの同時接続数や単位時間あたりのリクエスになってきている．さらには，スマートフォンの普及によト数が指定の閾値を超えた場合や，管理者があらかじめ指り，インターネットはより身近なものになってきている．

定した CPU 使用時間やメモリ使用量の閾値を超えた場合

その結果，Web サーバへのアクセス数は日々増加してきに，リクエストを切断，あるいは，拒否するような手法でており，多くの Web サイトを管理する Web ホスティング

ある．これは，サーバの負荷低減を重視しすぎるあまりに，サービス事業者は，いかに安定してアクセスを処理できる

サイトに何度アクセスしてもレスポンスが受信できないとか，また，個人でも利用できるようにいかに安価にサービ

いったようなユーザ体験を損なうアーキテクチャになってスを提供できるかが課題となっている．Web ホスティング

いる点が課題である．また，1 つの Web サーバに高集積サービス事業者は，そのような課題を解決するための 1 つにテナントを収容している場合，特定のテナントに配置さのアプローチとして，限られたハードウェアリソースで高れれているループ処理が多数実行されるような CPU 使用

集積にホストを収容可能なマルチテナント環境を構築する

率を占有する動的 Web コンテンツに対して，たった 1 つことが求められてきている．多数のユーザに同一サーバ上のリクエスト処理がサーバの CPU リソースを占有してしのハードウェアリソースを共有させることの効率性と，共まった場合にも，他のテナントにリソースを分配するため有することによるセキュリティ上の課題を解決しつつ，リには，強制的に処理を中断するような対応しかとれないとソースを柔軟に制御し，かつ，できるかぎり高集積にホスいう課題がある．数万ホストを単一のサーバに収容するよ

トを収容できれば，安定したユーザ単位のリソース配分がうな高集積マルチテナント方式のホスティングサービスに可能となり，ユーザにとっては快適でセキュリティが担保おいて，昨今の Web サーバ用途に使われるようなサーバのされた環境をより安価に提供可能となる．

CPU コア数が数十コアであることを想定する [20]．そのWeb ホスティングサービスにおいて，ドメイン名（FQDN）

場合，サーバに複数収容されているホストにできるだけ平によって識別され，対応するコンテンツを配信する機能を等にハードウェアリソースを分配すべき状況で，特定のホホストと呼ぶ．ホスティングサービスの個人利用においてストに対するたった 1 つのリクエストが 1 つの CPU コア

は，サービスの提供価格を数百円程度に下げるために，筆の使用率を 100%占有し続けると，数万ホストで数十コア者が所属する GMO ペパボ株式会社では 1 つのサーバに数の CPU を共有して使うことを想定している状況では CPU

万から最大 10 万ホスト程度収容するような，大規模高集使用過多であり，そのような他のホストにリクエスト処理

積 Web ホスティング基盤の構築が要求される．Web サーのためのリソースが十分に分配されなくなる状況は回避す

バに収容効率良く高集積に複数のホストを収容するためべきである．

には，プロセス数がホスト数に依存しないように，単一の1 つの HTTP リクエストがハードウェアリソースを大サーバプロセス*1 で複数のホストを処理する必要がある．

きく占有しようとしても，その他のリクエスト処理が影響

また，ホスティングサービスのようにサービス利用者が自を受けず，さらには各リクエストが継続的に処理を行うた

由に Web コンテンツを配置可能なサービスでは，サービ

めには，リクエストを処理中のプロセスを，一時的に限ら

ス提供側が Web コンテンツの実装まで管理することがでれたリソースの範囲内に分離し，その制限下でリクエストきないため，OS やミドルウェアの領域でセキュリティやを継続的に処理すればよい．また，管理者がそのようなリリソースを管理する必要がある．そのような環境で，Web

ソース制御ルールをプログラマブルに記述できれば，柔軟

サーバプロセスは高速にリクエストを処理するために複数なリソース制御が可能になる．そこで，本研究では，同一のリクエストを同一のサーバプロセスを使いまわして順番のサーバプロセス上で，HTTP リクエスト単位の粒度でに処理する特性上，大量のリクエストを安定して処理する

ハードウェアリソースを仮想的に分離できる Web サーバ

ためには，CPU といったハードウェアリソースを多く消費のリソース制御アーキテクチャを提案する．このアーキテ

する CGI プログラムのような動的コンテンツへのリクエ

クチャによって，継続的にリクエストを処理しつつも，各ストがあった場合，その特定のリクエストのみを他のリク

リクエスト処理は一時的に仮想的なリソースを割り当てら

エスト処理に影響を与えないように制限する必要がある．

れ，そのリソースの範囲内で処理が行われる．そのため，*1

特定のリクエスト処理が CPU を占有する処理であったと
ただし，ここでいう単一のサーバプロセスとは，ホストごとにサーバプロセスを起動させるのではなく，複数のホストでサーバプロセスを共有することを指す．

c 2018 Information Processing Society of Japan

しても，制限したリソース使用量以上には利用できないた
め，その他のリクエストは制限値以上の影響を受けない．

1017

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

さらに，大量にリソースを消費するようなリクエストでおける Web サーバのハードウェアリソースを仮想的に分離あっても，リクエストを拒否・切断することなく，割り当する手法は，主に以下の 3 種類が提案されている [2], [11]．

てたリソースの範囲内で処理を継続させることが可能とな以降では，Web サーバにおける既存のリソース制御技術

る．従来手法では高集積にホストを収容すればするほど，の問題点を整理する．

互いにリソースの影響を受け合うためにサーバが不安定に( 1 ) KVM [8], [10] や VMware 等の仮想マシンで複数の OSなりがちであり，それを解決するためにはリクエストを拒否，あるいは，切断という制限手法をとる必要があったが，提案手法によって高集積にホストを収容しても，高負荷時にクライアントにエラーを返すことなく，リクエスト単位
でリソースの最大使用量を制限できるため，制限されていてもリクエスト処理が継続されることによるユーザ体験のでリソースを分離する手法( 2 ) OpenVZ [1] や LXC のようにカーネルを共有しながらプロセス権限で OS リソースを分離する方式( 3 ) 仮想ホスト方式のように単一のサーバプロセスで複数のホストを扱う手法
ハードウェアリソースが潤沢にあり，サーバの運用面や向上と，より詳細にリソース制御できることによるサーバ

セキュリティおよび可用性を重視した場合は，手法 ( 1 ) の，の安定性を高いレベルで両立できる．

ホストそれぞれに対して，個別の仮想マシン [5], [6], [7] を実装に関して，Linux（Linux Kernel 3.10）上で動作する割り当てる構成がとられてきた．しかし，これらはハード

Apache HTTP Server 2.4.6 [16] に mod mruby [22] を組み

ウェアリソースの面で非常にコストが高く，オーバヘッド

込み，mod mruby 上で動作するモジュールとして，Linuxも大きいため，限られたリソースで高集積に数万ホストをの仮想化技術である cgroup [19] を用いたリソース制御モ

収容するにはホストごとに数十から数百 MBytes の仮想マ

ジュールを実装した．制御ルールは，Ruby で記述できる

シンが必要となるため不向きである．

ようにした．

( 2 ) の方式では，ホスト単位で chroot() システムコール

本論文の構成は以下のとおりである．2 章ではリソースによるファイルシステムの隔離やプロセスリソース管理技

制御技術について述べる．3 章では提案するリソース制

術を組み合わせたコンテナ環境 [4], [14], [18] を構築し，そ御アーキテクチャについて説明する．4 章でリソース制御の環境ごとにサーバプロセスを起動させる必要があるた

アーキテクチャの評価を行い，5 章でまとめとする．

め，プロセス数がホスト数に依存する．プロセス数がホス

2. リソース制御アーキテクチャ

ト数に依存すると，収容数が搭載メモリ容量により制約されるため，高集積に数万ホスト収容する場合，Web サーバ

限られたハードウェアリソースで複数のホストをできるプロセスが一般的に数十から数百プロセス必要になること

だけ高集積に収容したうえで管理・運用するためには，リを考えると，そのプロセス群が数万ホスト分必要となるたソースの分離と各ホストが安全にコンテンツを配置できる

め高集積にホストを収容するには向いていない．通常 Web

ような権限分離の管理が重要である．我々は，大規模共有

サーバプロセスは性能を担保するために，想定される同時型 Web バーチャルホスティング基盤のセキュリティと運用

接続数にあたる数のプロセスを起動させる．たとえば 5 万技術の改善 [23] を行った．その改善において，リソースのホスト収容する場合に，ホストごとに同時接続数 20 を想分離のために，ファイルやホスト単位で同時接続数を制御定した場合，20 個のサーバプロセスを起動させたとする

したり [3]，OS の負荷によってリクエストを中断あるいはと，100 万プロセス起動させる必要がある．一方で，サー拒否したりする [17]．しかし，CPU や Disk I/O 等のハービスを安価に提供するためには広く使われている一般的

ドウェアリソースは共有のため，多くのリソースを消費すなサーバを利用する必要がある．そのため，筆者が所属する CGI のような動的コンテンツへのたった 1 つのリクエ

る GMO ペパボ株式会社では，32 GB のメモリを搭載した

ストによってサーバのリソースを占有し，他のホストに影サーバを Web ホスティングサービスにおいて採用してい響を与えるという問題があった．特にホスティングサービ

る．その場合を考えると，1 プロセス最大 32 KB 程度しかスにおいては，利用者が配置する動的コンテンツをサービ割り当てることができず，Apache の 1 プロセスが通常数

ス提供側が変更することができないため，そのような高負十 MB 程度消費されることを想定すると，安定稼働は到底荷状態を引き起こすコンテンツを適切に OS や Web サー

不可能である．

バの機能によって制限する必要がある．

( 2 ) の方式のメリットは，ホストごとにサーバプロセスを起動させる方式であるため，( 3 ) の仮想ホスト方式では

2.1 権限分離を考慮した Web サーバのリソース分離

設定できないような，サーバプロセス全体の設定や，プロ

単一のサーバで複数のホストを管理する場合，セキュリ

セス単位でのリソース制御や隔離機能を利用することがでティを担保するための権限分離を考慮しながら，複数のホきる．また，プロセスとしては完全に他のホストのプロセ

ストでサーバのハードウェアリソースを共有する構成が一スと分離しているため，特定ホストのリクエスト処理に時般的である．これまで，マルチテナントアーキテクチャに間がかかっていたとしても，プロセスレベルで他のホスト

c 2018 Information Processing Society of Japan

1018

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

は影響を受けない．しかし，サーバプロセス数がホスト数の統一されたインタフェースを持っている．cgroup は，以に依存するため，高集積は困難である．

下のような機能を提供している．

Apache の VirtualHost 機能*2 で採用されている ( 3 ) の( 1 ) リソース制限

仮想ホスト方式のように，単一のサーバプロセスで複数の( 2 ) 優先順位

ホストを管理するアーキテクチャの場合，数万ホストに対( 3 ) 説明するリクエスト処理は数百から数千個のサーバプロセスで( 4 ) 隔離

共有して処理するため，ホスト数に依存せず高集積が可能( 5 ) コントロール

である．たとえば，Apache の VirtualHost 機能を利用する( 1 ) はプロセスグループのメモリ使用量やファイルシス

と，2 万ホスト収容した場合でもプロセス数がホスト数に依テムキャッシュを制限する機能を提供する．この機能に存せず，プロセスのメモリ使用量は 2 GB 程度となり [24]，より，プロセス単位でメモリ消費量の上限を制限するこ

5 万ホストであっても十分に，( 2 ) の方式で言及したメモとが可能となる．制限値を超えた場合は，プロセス停止処

リ 32 GB のサーバでも動作可能となる．しかし，( 3 ) の方理が動作する．( 2 ) は CPU やトラフィック，I/O を制御式では，単一のサーバプロセスで複数のホストを処理してする機能を提供する．この機能により，プロセスグループいるため，特定のホストやリクエスト処理がリソースを占で利用可能な CPU 使用率の割合を 10%程度にしたり，ト有した場合に，他のホストやリクエスト処理が影響を受け

ラフィックの流量を 10 Mbps にしたり，デバイス I/O をやすいという問題がある．

10 MByte/sec や 100 IOPS に制御したりできる．( 3 ) はプ

以上より，ホスト単位で適切にリソースを分離するため

ロセスグループのリソース消費の統計値を計測する機能をには ( 1 )，( 2 ) が適切であるが，収容効率は悪い．( 2 ) は提供する．たとえば，各プロセスグループのリソース消費

プロセスごとにリソース分離できるが，高集積マルチテナ量を可視化したり，従量課金の基準を定義したりすること

ントアーキテクチャのリソース制御においては，少なくとが容易になる．( 4 ) は異なる名前空間，たとえば，プロセ

も個々のプロセスに適切なリソース制約を与えて，ホスト

ス ID やオーナ，ファイルシステム等が別空間には原理的単位のリソース分離を図る必要がある．( 3 ) は高集積なマに干渉しないような領域にプロセスグループを分離し隔

ルチテナント環境を構築する際には適切であるが，単一の離する機能を提供する．( 5 ) はプロセスグループをサスペサーバプロセスで複数ホストに対するリクエストを処理すンドしたりリストアしたりする機能を提供する．この機能るため，最もリソース分離に向いていない．

を利用することで，再起動なしでのカーネルの置き換え，( 3 ) におけるリソース分離の課題に対して，既存の Webコンテナやプロセスレベルでのサスペンド・レジューム機

サーバの一般的なリソース制御 [3], [17], [23] は，リクエス

能，コンテナやプロセスのライブマイグレーションが可能

トの同時接続数や単位時間あたりのリクエスト数が指定のとなる．

閾値を超えた場合や，管理者があらかじめ指定した CPU

cgroup の機能を利用することで，システム開発者はシス使用時間やメモリ使用量の閾値を超えた場合に，リクエス

テムリソースの割当て，優先順位付け，モニタリング等，

トを切断，あるいは，拒否するような手法であり，CPU 使

粒度の細かいコントロールが容易に可能となる．

用率の占有によるサーバの負荷の低減を重視しすぎるあま3. 提案するリソース制御アーキテクチャ

りに，サイトに何度アクセスしてもレスポンスが受信できないといったユーザ体験を損なうようなアーキテクチャに

2.1 節に基づいて，高集積にホストを収容するためのマなっている．また，CPU を占有する CGI プログラムのよルチテナントアーキテクチャのリソース制御の要件をまとうな動的コンテンツに対して，たった 1 つのリクエスト処

める．2.1 節の ( 3 ) のような高集積に収容可能な仮想ホス

理がサーバの CPU リソースを占有してしまった場合にも，ト方式を採用したうえで，ハードウェアリソースを占有す

強制的に処理を中断するような対応しかとれない．

るような動的コンテンツに対するリクエストがあったとしても，同時に処理しているその他のリクエスト処理に対す

2.2 Linux のプロセスリソース管理技術

る影響を最小化する必要がある．さらには，各リクエスト

Linux には，cgroup [19] と呼ばれるプロセスのリソースが継続的に処理を行うためには，リクエストを処理中のプ管理技術がある．cgroup は，2006 年 9 月から開発が開始

ロセスを，一時的に限られたリソースの範囲内に分離してされ，2008 年 1 月に Linux Kernel 2.6.24 に取り込まれた．

から，その制限されたリソース範囲内でリクエストを処理

cgroup は，プロセスの優先度を変更する nice のような機すればよい．また，管理者がそのようなリソース制御ルー

能から，コンテナである LXC や OpenVZ のような OS レ

ルをプログラマブルに記述できれば，柔軟なリソース制御

ベルの仮想化までの，様々な仮想化の用途に対応するためが可能になる．

*2

http://httpd.apache.org/docs/current/en/vhosts/

c 2018 Information Processing Society of Japan

1019

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

3.1 アーキテクチャの詳細実装する．これによって，Web サーバソフトウェアの違い

単一のサーバプロセスで複数のホストを高集積に管理すを気にすることなく，リソースコントローラ自体の拡張・るアーキテクチャにおいて，動的コンテンツによるリソー

修正が容易となる．このようなアーキテクチャをとること

ス占有の問題を解決するためには，HTTP リクエスト単位

により，リクエストに含まれる情報，たとえば，ホスト名という細かい粒度で，CPU のようなハードウェアリソー

や HTTP メソッド，ユーザ情報等を条件に，管理者が柔スの最大使用率を制御し，仮想的に分離できればよい．そ軟にリソース制御を行える．

れによって，CPU を大量に消費するような動的コンテンツに対するクエスト処理が，サーバに収容されているホス

3.2 アーキテクチャの実装

ト間で共有しているリソースを占有しようとしても，分離提案するアーキテクチャを Linux（Linux Kernel 3.10）

されたリソースの範囲内で動作するため，他のリクエスト上で動作する Apache（Apache HTTP Server 2.4.6）に実処理に影響を与えない．また，管理者がリソース制御ルー

装する．高集積マルチテナント方式の Web サーバでは，収ルをプログラマブルに記述できれば，柔軟なリソース制御

容ホストに対するリクエストを，収容ホストよりも少ないが可能になる．それによって，サービス利用者が配置する数のプロセスで同時に処理するため，プロセス間でリソー

Web コンテンツを管理できないサービスのサーバ管理者

ス競合が起き，適切にホスト単位でリソースの分配を管理

が，サーバを安定稼働させる際に，リソース制限によってすることは困難である．提案するアーキテクチャは，多数

リクエストの拒否を頻繁に生じさせることで，サーバへアのリクエストやリソースを専有するリクエストを同時並行クセスする利用者にとってのユーザ体験の低下を引き起こで処理する状況で，各リクエストを制限された仮想リソー

すことなく，多種多様な動的コンテンツのリソース消費量

ス領域に隔離することにより，同時に処理しているようなを制御できるようになる．さらに，単一のサーバプロセス

リクエスト間で，特定のリクエストがリソースを占有せず，で高集積にホストを管理していることを考慮すると，可能他のリクエストに十分にリソースを分配できる状態，つまな限りサーバプロセスを再起動することなく，リソース制

りリソース専有の干渉度合いが低い競合状態を実現でき

御の変更をできるようにするべきである．

る．その結果，高集積のマルチテナント環境であっても，本論文では，HTTP リクエスト処理時に，管理者が記ホスト間において，たとえば特定のホストに配置された

述した内容に従って仮想的に分離されたリソース領域を作CPU 使用率を占有する CGI プログラムに対してリクエス

成し，サーバプロセスをそのリソース領域内で動作させ，トが生じても，他のホストへのリクエストに必要な CPU

レスポンスを送信後はそのリソース領域内の制限を解除す

リソースを分配可能となり，ホスト間のリソース競合も緩ることで，高集積マルチテナント環境においても，リクエ和できる．

スト単位で任意のリソース制御が可能な Web サーバのリ

仮想リソース領域の作成には cgroup を利用した．2.2 節

ソース制御アーキテクチャを提案する．クライアントからで言及した ( 2 ) 優先順位の機能を使い，CPU や I/O をリ

サーバプロセスに対してリクエスト処理があると，そのリクエスト単位で制御し，任意の設定パラメータによってリクエストが制御対象であった場合，サーバプロセス上で動ソース分離を実現する．cgroup は，本来同じ基準で集めら作しているリソースコントローラが，リソース制御ルール

れたプロセスの集合に対してまとめて制御を行うものであからリソースに関する設定値を取得する．そして，そのリるが，その方式に加えて，提案手法では高集積マルチテナ

ソース設定値をもとに確保された仮想リソース領域がなけント方式における特定のテナント，あるいは特定のリクエ

れば，新規で領域を作成する．たとえば，任意のリクエス

ストを処理しているプロセスのみの CPU 使用率を一時的トに対し，CPU 使用率は最大 10%，ディスクへの書き込に制限する必要があるため，リクエスト単位で cgroup にみは最大 5 MBytes/sec に制限したいとする．その場合は，よる仮想リソース領域を割り当てるようにした．また，一制御ルールを設定ファイルに記述する．記述後，新しいリ

般的な Web サーバの実装上，サーバプロセスは異なるテクエストを受けた際に，リソースコントローラは制御ルー

ナントに対するリクエストを同一のプロセスで順番に処理

ルを解釈し，ルールどおりにリソース領域を生成する．そするため，サーバプロセスをあらかじめ仮想リソース領域

して，サーバプロセスを，作成したリソース領域に割り当に割り当てておくことはできないという問題もあったためてた後，リクエストをそのリソース範囲内で処理する．処である．この方式による性能上のオーバヘッドも実運用上

理後は，レスポンスをクライアントに返し，リソース領域

問題ない程度であった．オーバヘッドについては 4 章で言への割当てを解除してから，リソース領域を削除し，次の及する．

リクエスト処理に備える．また，リソースコントローラは，

このようなアーキテクチャと実装によって，たとえばテ

複数の Web サーバソフトウェア上でも同様に扱えるよう

ナント単位でリソース制御をしたい場合は，従来手法の同に，複数の Web サーバソフトウェアに汎用的な機能拡張イ

時接続数制限と組み合わせて，リクエストに含まれるホス

ンタフェースを用意したうえで，そのインタフェース上にト情報により，テナントに割り当てる最大 CPU 使用量を

c 2018 Information Processing Society of Japan

1020

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

図 1 Apache と mod mruby と cgroup の関係

Fig. 1 Relationship between Apache, mod mruby and cgroup.

図 2

Linux への実装例

Fig. 2 Implementation example on Linux.

制限することもできる．その場合，1 つのリクエスト，たとえば CGI プログラムを実行するプロセスのみに対する最大 CPU 使用率の割当てを 20%として，最大同時接続数
を 5 とし，テナント全体でのプロセス集合に対して最大CPU 使用率の割当てを 50%とすることもできる．これは，cgroup のプロセスの集合に対してまとめて制御する方式と，プロセス単位でリソース割当て領域を作成する方式を組み合わせることにより実現できる．このように提案手法
は，OS のスケジューラのできるだけ平等にプロセスにリソースを配分する戦略を尊重しながら，cgroup の機能を使ってテナントあるいは CGI プログラムに対するリクエ
ストを処理するプロセスの集合，あるいはリクエスト単位

図 3

リソース制御ルール記述例

Fig. 3 Example of resource control rule descriptions.

操作したりすることが可能になる．

に対応する個々のプロセスについて，管理者がその意図す

図 2 に，図 1 のアーキテクチャ図を Linux 上で動作するところによりリソースの制御を補助的に行えるようにす

る Apache に実装する場合のアーキテクチャの構成を示るものである．

す．リソースコントローラは mruby と mruby-cgroup が担

汎用的な Web サーバの機能拡張 I/F には，組み込みス

い，その制御を Web サーバ上で可能にする機能拡張機構

クリプト言語を Web サーバに組み込むことで，スクリプトを mod mruby が担う．制御ルールは Ruby の構文で記述

言語にかかわらず Web サーバを高速かつ省メモリに機能し，ファイル，ディレクトリ，ホスト単位等，様々な条件拡張できる mod mruby [22] を利用した．mod mruby は，からリソース制御対象の記述が可能となっている．また，代表的な Web サーバソフトウェアの Apache と nginx [12]cgroup によるリソース領域は複数設定することが可能で，の Web サーバ機能拡張を，Ruby によって容易に拡張がリクエスト時にすでに存在する場合はその領域を利用し，可能であり，高速かつ省メモリに動作する．また，提案す存在しない場合は新規で領域を確保する．

るアーキテクチャでは，リクエストごとに Ruby で記述さRuby で記述された各種リソース制御ルールに従って，れた設定を読み込むため，mod mruby のように Ruby でクライアントからのリクエスト処理のリソースを制御す

Web サーバの機能を記述可能で，リクエスト単位で高速にる．図 3 に，cpu.cgi にリクエストがあった場合に，その動作する Web サーバ機能拡張は，本アーキテクチャの実

リクエスト処理を最大 CPU 使用率 10%のリソース領域に装に適している．

分離する場合のリソース制御ルール記述例を示す．

図 1 に Apache と mod mruby と cgroup の関係を示す．

図 3 のように，Ruby で記述可能な機能拡張インタフェー

Ruby スクリプトから Apache の内部 API を操作できるよスによって，Ruby の言語仕様をもとに，リソース制御ルー

うに，Apache に mod mruby を組み込む．同様に，Ruby

ルを柔軟に記述することが可能となる．また，条件としてスクリプトから cgroup を操作するために，cgroup を操作す利用するホスト名やファイル名等は条件分岐として記述するためのシステムライブラリである libcgroup を Ruby でるだけでなく，数万単位のホストを扱う場合には，ホストと制御できるように mruby-cgroup *3 という拡張モジュール

関連する設定データを Key-Value Store（KVS）のようなを実装する．これによって，Ruby スクリプトから Apache

データベースに保存しておいて，リクエスト時にホスト名

内部の情報を取得したり，その情報をもとに libcgroup ををキーに設定を取得するような記述も Ruby で実装可能で*3

https://github.com/matsumotory/mruby-cgroupc 2018 Information Processing Society of Japan

あるため，制御ルール行数がホスト数に依存して長大にな

1021

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)を制限することにより，プログラムの動作に依存することなく CPU 使用率を制限でき，かつ継続的に処理を行える
ため，ホスティングサービスのように多種多様なプログラ
ムが動作する環境においても，特定のテナントのみを制限
して，他のテナントにリソースを分配することができるた
め有用である．CPU 使用率を制限されたリクエストは，リクエスト処理にかかる時間が増加する．そのため，テナン
ト単位での同時接続数を制限する従来手法と組み合わせ，並行処理されるリクエストの数を一定以下に抑えるような運用を行うことが必要である．また，制限対象となったテ
ナントについては，同時接続数による制限だけではなく，CPU 使用率との組合せによって制限が可能となるため，これまでは CPU100%使用するレスポンスに対して同時接続
数 1 としか制限できなかった状況で，CPU33%かつ同時接
続数 3 というような，CPU リソースは制限しながらも同時接続数をできるだけ増やしたいといった要求にも応えられるようになる．
従来手法では，閾値を超過した場合にリクエストを拒否，
あるいは，中断していたが，本手法では閾値を超えた場合には，あらかじめプログラマブルに記述されたルールに従って，使用可能なリソース使用量を限定しつつも継続的にリクエストを処理することが可能となる．さらに，Web
サーバソフトウェア内部の情報や OS の負荷状況を考慮した記述や，仮想ホスト，ファイル，ディレクトリ単位の制
御も，Ruby の制御構造によって柔軟に記述でき，汎用性が高い．また，Ruby スクリプトを変更することで，サーバプロセスを再読み込みすることなくリアルタイムで条件
図 4

ホスト単位でリソースを分離

Fig. 4 Separating resources for each host.

記述を変更できる機能も実装しているため，運用においても負担が少ない．一方で，スクリプトの変更を必要としない場合は，事前に中間コードにコンパイルしておいて，リらない．また，制御ルールをフックしておくためのフェー

クエスト時に中間コードを実行することでより高速に動作

ズは，サーバのレスポンスを生成するまでのリクエスト解させることも可能である．なお，mod mruby は高速にか析，アクセスチェック，レスポンス生成直前，レスポンス

つ省メモリで動作することも，本手法のプログラマブルに生成後等である．

ルールを記述する機能に適しており，オーバヘッドは少な

図 4 にリソース制御ルールの応用例を示す．図 4 では，あらかじめ高負荷ユーザが所属するホストを対象に，リクエストが対象のホストであれば高負荷ユーザと判定

いことが分かっている [22]．

4. リソース制御アーキテクチャの実装の評価

し，全体の CPU の 25%，DISK I/O の最大読み書き帯域提案するリソース制御アーキテクチャの評価を行うためを 30 MByte/sec 使えるようにリソースを分離する．対象に，CPU 制御機能を組み込むことによるオーバヘッドやリ外のホストに対しては CPU を 75%，DISK I/O の読み書

ソース制御の精度評価を行った．リクエスト単位で CPU

きの帯域を最大 100 MByte/sec 使用できるように設定したのリソース制御精度が十分であれば，HTTP リクエスト単例である．cgroup により，プロセスが利用できる最大メ位でリクエスト処理の最大 CPU 使用率が制限できる．そモリ使用量を制限することは可能であるが，本研究ではリれにより，高負荷時においても，高負荷の原因となるリク

クエストを継続的に処理しながら制限も行うことを目的と

エスト以外の他のリクエスト処理に CPU リソースを残す

しているため，今回は対象としない．また，本研究では，ことができ，かつ，制限した最大 CPU 使用率の範囲内で高集積マルチテナント方式により高集積にテナントを収容

制限対象のリクエスト処理を継続的に行うことができる．

しているようなシステムで，特定のテナント上で CPU を

HTTP リクエスト単位でリソース制御が達成できれば，高100%消費するような CGI プログラムに対して最大使用率

集積ホスティング環境のように，プロセスを共有しながらc 2018 Information Processing Society of Japan

1022

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

表 1 実験環境

Table 1 Experimental environment.

ClientServer

項目

仕様

CPU

Intel Core2Duo E6600 3.06 GHz

Memory8 GBytes

NIC

Realtek RTL8111/8168B 1 Gbps

OS

Fedora 18

CPUIntel Core i7-4770K 3.5 GHz

Memory32 GBytes

NICIntel I217V 1 Gbps

Middle-Ware

Apache/2.4.6

OS

Fedora 19

複数のホストに対するリクエストを処理するような場合であっても，各リクエストのリソース使用量を限定できるため，ホスト間のリソース競合も低減することが可能となる．

図 5

リクエスト処理時間の違いによるリソース制御精度

Fig. 5 Resource control accuracy regarding the diﬀerence between request processing time.

性能評価として，本アーキテクチャの導入前後でリソース制御対象でないリクエストの性能にどの程度違いがある

ラムが単なるループ処理であるため，CGI プログラムに対か，リクエスト処理時間の違いによってリソース制御の精するリクエスト処理時間のほとんどは，Web サーバ上で度に差がどれほど生じるのかを評価した．表 1 にテスト

CGI プログラムのレスポンスを返す Web サーバプロセス

環境のマシンスペックを示す．また，Apache の仮想ホスの CPU 使用時間とおおむね同じであると考えられる．そトの数は 10 万ホストとした．Apache の起動プロセス数はの CGI プログラムに対して，リソース制御アーキテクチャ

Apache のバージョン 2.4.6 のデフォルト設定の 250 プロセ

により CPU 使用率を 50%に制限し，表 1 のテスト環境のスとした．

リソースを十分に使用できるように予備実験から決定した

まず，本アーキテクチャを導入することで，リソース制

同時接続数 10，総接続数 1000 で，CGI プログラムにリク御対象でないリクエストの性能にどの程度差異があるかをエストを送信した．CGI プログラムのリクエスト処理時間評価した．評価方法として，リソース制御アーキテクチャを変化させながら，1 リクエストの処理にかかった時間が，の処理の影響を最大にするため，リクエスト対象のファイ

リソース制御をしていない場合にかかった処理時間と比較

ルは hello world を出力するだけの静的な HTML ファイル

して，性能がどれだけ低下しているかを測定した．その値とした．そのファイルに対し，表 1 のテスト環境のリソーを性能制御率と呼ぶことにする．50%にリソース制御してスを十分に使用できるように，予備実験から同時接続数いる場合，性能制御率が 50%に近ければ近いほど，正確に100，総接続数 10 万のリクエストパターンを決定し，評価

リソース制御できていることになる．

を行った．ベンチマークソフトウェアには ab コマンド [15]

図 5 に 1 リクエストの処理時間を変化させた場合の，リを利用した．その結果，リソース制御アーキテクチャを導ソース制御アーキテクチャの性能制御率を示す．図 5 の入していない場合は，1 秒間に 32915.46 リクエスト処理

ように，1 リクエストの処理時間が 0 msec から 6 msec 程

できており，リソース制御アーキテクチャを導入している

度の場合は，表 1 のテスト環境において，本来制御したい

場合は，32322.07 リクエスト処理できていた．この結果か50%よりも，より低く性能が制御されていることが分かる．

ら，リソース制御アーキテクチャを導入することによるボ

これは，CGI プログラムが CPU を 50%以上消費できていトルネックはほとんどないと考えられる．また，CGI プロ

ないことによって生じており，CPU を 50%以上消費する

グラムのような動的コンテンツの場合には，静的コンテンプログラムであれば，正確に 50%に制御できることが分かツの処理よりも多くの CPU 使用時間を使用することが多る．実験環境においては，6 msec 以上リクエスト処理に時いため，静的コンテンツで無視できる程度の処理であれば，間がかかるような処理は，正確に性能を 50%に制御できて

動的コンテンツの場合も無視できる．

いることが分かる．

次に，リクエストの処理時間の違いによって，リソース

以上より，リクエスト単位でリソースの最大使用率を制制御の精度にどれほど差異が生じるのかを評価した．評価限する場合において，本手法が有効に機能すると考えられ方法として，シェルスクリプトで単純に while でループをる．制度評価により，リソースを占有するようなプログラ

行い，ループ終了後に hello world を出力するだけの CGIムに対してリクエストがあったとしても，管理者が設定しプログラムを作成し，そのループ回数を変化させることた CPU 使用率を超えることはない．すなわち，高負荷時で，リクエスト処理時間を変化させた．また，CGI プログ

でも他のリクエストへ与える影響は，リクエスト処理時間

c 2018 Information Processing Society of Japan


1023

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)の大小にかかわらず限定できる．2.1 節で述べたように，高集積マルチテナント方式における従来の制限手法は処理を継続しながらリクエスト単位でリソースを制御することが[6]

できない粗い制限手法であり，制限によってサーバを安定させたとしても，ユーザ体験の質は大きく低下するという課題があったが，リクエストを拒否，あるいは，切断する

[7]
[8]

ことなく継続的な処理とリソースの制限が同時に実現できるため，処理は低速になるもののレスポンスを送信可能と[9]なり，本研究の目的を達成できる．

5. むすび本研究では，限られたハードウェアリソースで高集積に

[10]

[11]

ホストを収容する際に，単一のサーバプロセスで複数のホストを管理する場合に生じるリソース制御の問題を解決するために，リクエスト単位で仮想的にリソースを分離する

Web サーバのリソース制御機構を提案した．本手法によ

[12]
[13]

り，1 つのリクエストがハードウェアリソースを大きく専有しようとしても，同時にリクエストを処理しているプロセス間で，リソース専有の競合の少ない状態を実現するこ[14]とができるため，他のリクエストが処理できなくなるようなことが生じない．また，リクエスト処理を切断・拒否す
ることなく継続的にリソースを制御できる．さらに，シス
テム管理者が Ruby で柔軟にリソース制御ルールを記述可[15]

能であるため，多種多様なリソース制御に関する問題に対し，対応できると考えている．

[16]

今後，より複雑なリソース管理の問題を解決するための方法論について検討していく予定である．実装面では，こ[17]のアーキテクチャを，マルチスレッド型や非同期 I/O 型のWeb サーバアーキテクチャにも対応させ，汎用的なインタ
フェースとして実装することで，複数の Web サーバソフ[18]

トウェアでも同様にリソースを制御できるようになると考
えている．
参考文献
[1]

[2]

[3]
[4]

[5]

Ben-Yehuda, M., Mason, J., Xenidis, J., Krieger, O.,
Van Doorn, L., Nakajima, J. and Wahlig, E.: Utilizing
IOMMUs for Virtualization in Linux and Xen, The 2006
Ottawa Linux Symposium (OLS’06 ), pp.71–86 (July
2006).
Che, J., Shi, C., Yu, Y. and Lin, W.: A Synthetical Performance Evaluation of Openvz, Xen and KVM,
IEEE Asia Pacific Services Computing Conference(APSCC ), pp.587–594 (Dec. 2010).
David, J.: mod limitipconn.c, available fromhttp://dominia.org/djao/limitipconn.html.
Felter, W., Ferreira, A., Rajamony, R. and Rubio, J.:
An Updated Performance Comparison of Virtual Machines and Linux Containers, IEEE International Symposium Performance Analysis of Systems and Software(ISPASS ), pp.171–172 (Mar. 2015).
Garﬁnkel, T., Pfaﬀ, B., Chow, J., Rosenblum, M. andBoneh, D.: Terra: A Virtual Machine-based Platform

c 2018 Information Processing Society of Japan


[19]

[20]

[21]

[22]

[23]

[24]

for Trusted Computing, ACM SIGOPS Operating Systems Review, Vol.37, No.5, pp.193–206 (Oct. 2003).
Garﬁnkel, T. and Rosenblum, M.: A Virtual Machine Introspection Based Architecture for Intrusion Detection,
NDSS, Vol.3, pp.191–206 (Feb. 2003).
Goldberg, R.P.: Survey of Virtual Machine Research,
Computer, Vol.7, No.6, pp.34–45 (1974).
Habib, I.: Virtualization with KVM, Linux Journal,
No.166, p.8 (2008).
Poul-Henning, K. and Watson, R.N.M.: Jails: Conﬁning the omnipotent root, Proc. 2nd International SANE
Conference, Vol.43 (2000).
Kivity, A., Kamay, Y., Laor, D., Lublin, U. and Liguori,
A.: KVM: The Linux Virtual Machine Monitor, The
Linux Symposium, Vol.1, pp.225–230 (July 2007).
Kovári, A. and 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 (Sep. 2012).
nginx: nginx, available from http://nginx.org/ja/.
Prodan, R. and Pstemann, S.: A survey and taxonomy of infrastructure as a service and web hosting cloudproviders, Grid Computing, 2009 10th IEEE/ACM International Conference, pp.17–25 (October 2009).
Soltesz, S., Pötzl, H., Fiuczynski, M.E., Bavier, A. andPeterson, L.: Container-based Operating System Virtualization: A Scalable, High-performance Alternative toHypervisors, ACM SIGOPS Operating Systems Review,
Vol.41, No.3, pp.275–287 (Mar. 2007).
The Apache Software Foundation: ab–Apache HTTP
server benchmarking tool, available from http://httpd.
apache.org/docs/2.2/programs/ab.html.
The Apache Software Foundation: Apache HTTP Server
Project, available from http://httpd.apache.org/.
The Apache Software Foundation: Server – Wide
Conﬁguration Limiting Resource Usage, available fromhttp://httpd.apache.org/docs/2.2/en/server-wide.
html#resource.
Xavier, M.G., Neves, M.V., Rossi, F.D., Ferreto, T.C.,
Lange, T. and De Rose, C.A.: Performance Evaluation of Container-based Virtualization for High Performance Computing Environments, 21st Euromicro International Conference on Parallel, Distributed, andNetwork-Based Processing, pp.233–240 (Feb. 2013).
富樫荘太，片山吉章，桐村昌行，瀧本栄二，毛利公一：Linuxの Cgroups における CPU throttling の性能評価，2013
年電子情報通信学会総合大会 情報・システム講演論文集，No.1, p.58 (2013).
松本亮介：博士学位論文 Web サーバの高集積マルチテナ
ントアーキテクチャに関する研究，入手先
https://repository.kulib.kyoto-u.ac.jp/dspace/handle/
2433/225954, 京都大学 (May 2017).
松本亮介，岡部寿男：スレッド単位で権限分離を行う Web
サーバのアクセス制御アーキテクチャ，電子情報通信学会論文誌，Vol.J96-B, No.10 (Oct. 2013).
松本亮介，岡部寿男：mod mruby：スクリプト言語で高速かつ省メモリに拡張可能な Web サーバの機能拡張支援機構，情報処理学会第 6 回インターネットと運用技術シンポジウム IOTS2013, pp.79–86 (Dec. 2013).
松本亮介，川原将司，松岡輝夫：大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善，情報処理学会論文誌，Vol.54, No.3, pp.1077–1086(2013).
松本亮介，三宅悠介，力武健次，栗林健太郎：高集積1024

情報処理学会論文誌

Vol.59 No.3 1016–1025 (Mar. 2018)

マルチテナント Web サーバの大規模証明書管理，情報処理学会研究報告インターネットと運用技術（IOT），
Vol.2017-IOT-37, No.1, pp.1–8 (May 2017).

松本 亮介 （正会員）
2015 年京都大学大学院情報学研究科博士課程単位取得認定退学．同年 GMO
ペパボ株式会社入社．2016 年よりペパボ研究所主席研究員．京都大学博士（情報学）．OS やサーバソフトウェア，
インターネットの運用技術やセキュリ
ティ等に興味を持つ．電子情報通信学会会員．

栗林 健太郎 （正会員）
1999 年東京都立大学法学部政治学科卒業．2002 年奄美市役所入所，2008
年株式会社はてな入社を経て，2012
年株式会社 paperboy&co.（現，GMO
ペパボ株式会社）入社．2016 年より
ペパボ研究所所長，2017 年より GMO
ペパボ株式会社取締役 CTO．インターネットサービスの開発，技術経営等に興味を持つ．人工知能学会会員．

岡部 寿男 （正会員）
1988 年京都大学大学院工学研究科修士課程修了．同年京都大学工学部助手．同大学大型計算機センター助教
授等を経て，2002 年より同大学学術
情報メディアセンター教授．博士（工学）．2005 年より国立情報学研究所客員教授．インターネットアーキテクチャ，ネットワーク・
セキュリティ等に興味を持つ．システム制御情報学会，日本ソフトウェア科学会，IEEE，ACM 各会員．

c 2018 Information Processing Society of Japan

1025