Vol.2018-IOT-42 No.1
2018/6/28

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

HTTP リクエスト単位でインスタンスの再配置が可能な
低コストで高速なスケジューリング手法
松本 亮介1,a)

中田 裕貴1

栗林 健太郎1

概要：スマートフォンや PC のモバイル化，SNS の爆発的普及に伴い，個人の Web サイトであってもコンテンツ次第でアクセスが集中する機会が増大してきている．我々は，サービス利用者に専門的な知識を要求せず，アクセス数や負荷に応じて反応的かつ高速にリソースをインスタンスに再割当てすることで，サービス利用者や事業者に手間を強いることなく突発的なアクセス集中に耐えうる FastContainer アーキ
テクチャを提案した．一方で，従来のホスティングサービスやクラウドサービスと同様に，インスタンスの収容サーバ障害時に，HTTP タイムアウトが生じない程度での可用性を担保しサービスを継続提供する
ためには，複数収容サーバに横断して，それぞれ複数インスタンスを立ち上げておく必要があった．そのため，利用者にとってはサービス利用コストの増加に繋がっていた．本研究では，HTTP リクエスト処理時において，単一のインスタンスであっても，収容サーバの状態に応じて自動的にインスタンスを別の収容サーバに再配置しサービスを継続させる，HTTP リクエスト単位での低コストで高速なインスタンスス
ケジューリング手法を提案する．高速にインスタンスを再配置するために，Web サーバソフトウェア自体を拡張することなく，Web サーバプロセス起動時に実行されるシステムコールを監視して，起動完了する
直前のシステムコール実行前の段階でプロセスイメージを作成しておくことにより，インスタンス再配置
時には高速に Web サーバプロセスをそのイメージから起動させる．

Low-cost and High Performance Scheduling Method that can Relocate
Instances each HTTP Request
Ryosuke Matsumoto1,a)Yuki Nakata1

1. はじめに

Kentaro Kuribayashi1

人用途であっても非常に重要になってきている．

Web コンテンツを継続的に配信するためには，オートス

インターネットを活用した企業や個人の働き方の多様化

ケーリングのような負荷対策と，冗長構成による可用性のに伴い，インターネット上で自らを表現する機会が増加し担保が重要である．一般的に，個人が Web コンテンツをている．特に個人にとっては，Twitter や Facebook を活配信するためには，Web ホスティングサービスやクラウ

用して，自身が作成したコンテンツを拡散させることによ

ドサービスなどが利用される [11]．特に，個人の利用を想り，効率よくコンテンツへの訪問数を増やすことができる

定した場合，単一の物理サーバに高集積にユーザ領域を収ようになった．その結果，コンテンツの内容の品質が高け容するような低価格 Web ホスティングサービスが利用されば，さらに拡散され，コンテンツに紐づく個人のブランれる．そのような低価格ホスティングサービスでは，利用ド化も可能になってきている．そのため，コンテンツ拡散

者の Web コンテンツが特定の Web サーバに紐づくため，時であっても継続的に配信可能な Web サイトの構築は，個

ユーザ領域単位で突発的なアクセス集中に対して負荷分散することが難しい．クラウドサービスの場合は，利用者が1a)

GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japanmatsumotory@pepabo.com

c 2018 Information Processing Society of Japan⃝

アクセス集中に耐えうるオートスケーリング [7] の仕組みを作る必要があったり，各サービス・プロバイダが提供し1Vol.2018-IOT-42 No.1
2018/6/28

情報処理学会研究報告
IPSJ SIG Technical Reportているオートスケーリングの機能 [2] を使う必要がある．

のインスタンスであっても，収容サーバの状態に応じて，

しかし，クラウドサービスに関する専門的な知識を有さな

自動的にインスタンスを別の収容サーバに再配置し，サーい個人が，費用を最低限に抑えつつ，突発的なアクセス集

ビスを継続させる，HTTP リクエスト単位でのインスタ中を予測的かつ安定的に対応することは依然として困難でンスのスケジューリング手法を提案する．提案手法では，ある．

FastContainer の状態変化の高速性に基づいて，インスタ可用性の面では，Web ホスティングサービスの方式もンスが頻繁に収容サーバを変更されてもサービスに影響がクラウドサービスも，仮想的に構築されたサーバ環境であないことを利用する．それによって，プロキシサーバからるインスタンスを複数のハードウェア上に起動させること収容サーバに 1 個の ICMP パケットで応答速度を計測し，により，特定のハードウェアに障害が置きてもサービスを少ないパケット数と短いタイムアウトで収容サーバの反応

停止せずに提供可能である [15]．しかし，複数台のインス

時間を計測できる．．そのことで，HTTP リクエスト単位

タンスが必要であることから，インスタンスの利用コスト

でのインスタンススケジューリングを実現する．さらに，が増加する．さらに，可用性のためのインスタンスをコス

高速にインスタンスを再配置するために，Web サーバソフ

トの兼ね合いから負荷分散用途に転用してしまうことによトウェア自体を拡張することなく Web サーバプロセス起り，収容サーバが停止した際に縮退状態のインスタンス数

動時に実行されるシステムコールを監視して，起動完了すでサービスを提供することになり，場合によってはリソー

る直前のシステムコール実行前の段階でプロセスイメージ

ス不足に陥る．

を作成しておくことにより，高速に Web サーバプロセス

我々はアクセス数や負荷に応じて反応的かつ高速にリをそのイメージから起動させる．

ソースをインスタンス*1 再割当てすることで，サービス利本論文の構成を述べる．2 章では，Web ホスティング

用者や事業者に手間を強いることなく突発的なアクセス集サービスやクラウドサービスにおける可用性の担保のため中に耐えうる FastContainer アーキテクチャ [16] を提案しの取り組みとその課題について述べる．3 章では，2 章でた．一方，可用性の面では，依然として単一のインスタン

述べたインスタンスの再配置の課題を解決するための提スの場合，そのインスタンスが収容されている物理サーバ

案手法のアーキテクチャおよび実装を述べる．4 章では，が正常に稼働していることが前提であり，収容サーバが停HTTP リクエスト単位でのインスタンススケジューリング

止すると，手動によるインスタンスの再配置が必要であっ手法の評価を行い，5 章でまとめとする．

た．そのため，障害時に HTTP タイムアウトを生じさせない程度の可用性を担保するには，従来手法と同様にイン2. Web サービス基盤の可用性

スタンスを複数の収容サーバに起動できるようにしておく

Web サイトが収容されている物理サーバに障害があった

必要があり，利用者にとっては利用コストの増加に繋がっ場合に，いかにサービスを継続するかといった可用性の観ていた．また，新たなインスタンスを新規で再配置する場

点でシステムを構築する必要がある．本章では，相互に関合は，インスタンス起動時の Web サーバプロセスの起動

連の深い負荷分散と可用性の観点から，Web ホスティング

時間がオーバーヘッドとなってレスポンスが一時的に遅くサービスやクラウドサービスにおける関連研究と課題につなり，ユーザ体験を損なう課題があった [13]．

いて整理する．

プロセスの起動時間を高速化するために，CRIU[4] と呼本論文における可用性とは，インスタンスの収容サーバ

ばれる Linux プロセスの Checkpoint/Restore 技術によっが停止しても，クライアントからインスタンスに対するリてプロセスをイメージ化することにより，高速にプロセス

クエストが HTTP タイムアウトせずに，オンラインでサーの状態を復帰させる手法がある．しかし，Web サーバが起

ビス継続を可能とする程度を前提とする．

動してからイメージ化すると，アドレスやポートの衝突，起動後のサーバプロセスの状態やコンテンツの状態等を保2.1 Web ホスティングサービス

持してしまうため，実用上扱いにくい．一方で，各種 Web

Web ホスティングサービスとは，複数のホストで物理サーバの起動処理時に，socket() システムコールを実行すサーバのリソースを共有し，それぞれの管理者のドメインにる直前でプロセスをイメージ化する場合，各種サーバソフ

対して HTTP サーバ機能を提供するサービスである．Web

トウェアの初期化処理にサーバソフトウェアに依存した拡

ホスティングサービス [11] において，ドメイン名 (FQDN)

張実装をそれぞれ追加する必要があり汎用性が低い．

によって識別され，対応するコンテンツを配信する機能を本研究では，HTTP リクエスト処理時において，単一ホストと呼ぶ．
一般的に，個人が Web コンテンツを配信するためには，*1

FastContainer におけるインスタンスとはリクエストを契機に一定期間起動するものであり，リクエストが送られてきていない場
合は停止している場合もありうる論理的なインスタンスである．
これを FastContainer では Mortal と名付ける．

c 2018 Information Processing Society of Japan⃝Web ホスティングサービスやクラウドサービスなどが利用される [11]．特に，個人の利用を想定した場合，仮想ホスト方式を利用して，単一の物理サーバに高集積にユーザ領

2

Vol.2018-IOT-42 No.1
2018/6/28

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

域を収容するような低価格 Web ホスティングサービスがハードウェアコストを限られた予算の中で活用するため利用される [14]．仮想ホスト方式では複数のホストを単一に，ホットスタンバイ状態のインスタンスを負荷分散に利*2のサーバプロセス群 で処理するため，リクエストは Web

用することもある．しかし，収容サーバが停止すると縮退

サーバプロセスを共有して処理される．そのため，ホスト状態のインスタンスでサービス提供することになり，場合単位で使用するリソースを適切に制御したり，その原因をによってはリソース不足に陥る．

迅速に調査することが困難である [18]．

高負荷状態に対して迅速に対応するために，事前にある

Web ホスティングサービスでは，サービス利用者の Web程度想定される量の仮想マシンを予測的に起動させておくコンテンツは特定の Web サーバに収容され，Web サーバ

ことによって対処する手法がある [19]．しかし，本手法はと Web コンテンツが紐づくため，負荷に応じたオートス

突発的なアクセスに対するスケーリングを対象としておらケーリング*3 は，データの整合性の面と前述したホスト単ず，予測の精度を保つための各種パラメータの選定に関す

位での適切な負荷計測・制御の面から困難である．

る課題もある．また，可用性を担保することは想定されてWeb ホスティングサービスにおける負荷分散と可用性をいない．

両立する手法として，ユーザデータ領域を共有ストレージ

上記のような問題を解決するために，クラウドサービスにまとめた上で，仮想ホスト方式を採用した複数台の Web

プロバイダの AWS は，プロバイダ指定の記法によってア

サーバで負荷分散と可用性を担保する手法 [15] がある．しプリケーションを実装すれば，自動的にコンピュータリ

かし，ホストの収容サーバを複数台配置して全ホストを複

ソースを決定し，可用性を担保しながらも高負荷時には自数の物理サーバに配置することが前提となる手法であるた

動的にプロバイダ側でオートスケーリングする機能 [2] をめ，ホスト単位でのスケーリングや可用性の担保は対応で提供している．しかし，前提としてプログラミングができ

きず，コストも高くなる．また，負荷に応じて，ホスト単るエンジニアを対象としており，一般的な OSS として公位での即時性の高いスケールアップ型の負荷対応もでき開されている Web アプリケーションを利用できないことない．

が多く，個人が Web コンテンツを配信する用途においては使用上の制限が大きい．

2.2 クラウドサービス
クラウドコンピューティング [9] とは，ネットワークや

2.3 FastContainer アーキテクチャ

サーバといったコンピュータリソースのプールから必要

我々は，個人が Web コンテンツを配信する用途においな時に必要な量だけオンデマンドに利用可能とするコンて，Web ホスティングサービスやクラウドサービスにおけピューティングモデルである．クラウドサービスはクラウ

る突発的にアクセス集中の対応やオートスケーリングの課

ドコンピューティングを各種サービスとして提供するサー

題を解決するために，FastContainer アーキテクチャを提ビスである．

案した [16]．FastContainer は，Web ホスティングサービ

クラウドサービスでは，Web コンテンツを配置するだけ

スを利用できる程度の知識を持った個人が，WordPress のでなく，Web サーバソフトウェアやデータベースをサービような一般的な CMS を利用した Web コンテンツを配信すス利用者が自ら構築する必要がある．そのため，負荷分散ることを前提にしている．そのような個人のサービス利用のためのシステム設計をホスト単位で個別に行うことがで者が負荷分散のシステム構築やライブラリの運用・管理をきる点において自由度は高いが，前提として専門的な知識極力必要とせず，HTTP リクエスト単位でインスタンスのが必要となる．

状態を決定し，迅速にユーザ領域を複数の物理サーバに展クラウドサービスで可用性を担保するためには，複数のインスタンスを複数の収容サーバにホットスタンバイ状態

開可能で，実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャである．

で起動させておき，特定の収容サーバに障害が発生した場

FastContainer アーキテクチャでは，インスタンスとし合には，ホットスタンバイ状態のインスタンスにリクエスて，仮想マシンではなく Linux コンテナ [6] を利用する．

トが送信されるように変更する．これによって，障害対応

Linux コンテナはカーネルを共有しながらプロセスレベル

時に，新規でインスタンスを立ち上げ直す処理を省略し，で仮想的に OS 環境を隔離する仮想化技術のひとつである．

継続的にサービスを提供し続けることが可能となる．しか

そのため，コンテナの起動処理は仮想マシンのようなカー

し，複数台のインスタンスが必要であることに起因して，ネルを含む起動処理と比べて，新しくプロセスを起動させ必要なハードウェアコストが増加する．また，そのようなる程度の処理で起動が可能であるため，起動時間が短時間で済むという特徴がある．

*2*3

ただし，ここでいう単一のサーバプロセス群とは，ホスト毎にサーバプロセスを起動させるのではなく，複数のホストでサーバプロセスを共有することを示す
自動的にハードウェアリソースを追加し負荷分散を実現する機能

c 2018 Information Processing Society of Japan⃝

FastContainer アーキテクチャでは，コンテナが仮想マ
シンと比較して速く起動できる点と，FastCGI[5] を参考に，
物理サーバへの収容効率を高めつつ性能を担保するアーキ

3Vol.2018-IOT-42 No.1
2018/6/28

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

テクチャを組み合わせる．さらに，HTTP リクエスト毎に負荷状態やアクセス数に応じて，Web アプリケーションコ
ンテナの起動処理，起動継続時間，コンテナの起動数およびリソース割り当てをリアクティブに決定する．一定時間起動することにより，一度コンテナが起動してしまえば，起動時間に影響なくレスポンスを送信できる．この特性によって，ホストをコンテナ単位で個別に起動しながらも，
リクエストの無いコンテナは自然に停止するため，高集積に収容できる．

FastContainer は，コンテナの起動が一般的に高速であること，リクエストを契機としたリアクティブな起動処理であることにより，突発的な負荷に対しても迅速にリクエ

図 1

コンテナスケジューリングフロー

Fig. 1 The Flow of Contaienr Scheduling.

スト単位でオートスケーリングが可能となる．スケール
アップについても，コンテナのリソース管理が cgroup にスを継続させる．FastContainer の状態変化の高速性に基

よってプロセス単位で制御されており，cgroup の特徴を利づいて，コンテナが誤検知によって再配置されてもサービ用して，プロセスが処理中であっても CPU 使用時間など

スが停止しないことを利用する．それによって，プロキシの割り当てを即時変更できる．

サーバから収容サーバに ICMP で接続を試みた上で，短い

しかし，このアーキテクチャはコンテナが収容される物

タイムアウトで収容サーバの反応時間を計測できる．その理サーバが適切に稼働していることが前提であり，収容ことで，HTTP リクエスト単位でのコンテナスケジューリ

サーバが停止すると，手動によるコンテナ再配置が必要でングを実現する．

あった．そのため，ホスティングサービスやクラウドサー

さらに，コンテナ再配置後の最初のリクエストに対するビスと同様に，収容サーバが停止した際にサービスを停止

起動時間を速くするために，予めインスタンスの起動処理させることなく継続的にレスポンスを返すためには，複数完了直後のプロセスをイメージ化 (Checkpoint) しておく．

の収容サーバにそれぞれ複数インスタンスを配置する必

起動時は，そのイメージから起動する (Restore) ことによ要があり，利用者にとってのサービス利用コストが増加す

り，通常起動よりも高速化を実現する．

る．また，単一のコンテナで起動している場合は，その収容サーバが停止すると，手動で再配置が行われるまでには同様にサービスも停止してしまう．

3. 提案手法

3.1 スケジューリングフロー
図 1 に，コンテナスケジューリングのフローを示す．

Host OS が障害を起こしていない正常時のフローについて述べる．図 1 における Client から Container に対して個人の利用者が WordPress のような一般的な Web コン

HTTP リクエストがあった場合，Client から Web Proxy

テンツを配信する仮想化基盤において，収容効率を高めつに一旦集約される．Web Proxy にリクエストが到達した

つ，アクセス集中による負荷やインスタンスの収容サーバ

段階で，Container の収容情報や構成管理情報を保持するの障害に対する可用性を担保可能な基盤にするためには，

CMDB API に情報を問い合せ，Container の収容サーバや以下の要件が必要である．

IP アドレス/ポート情報を得る．Web Proxy は収容サーバ( 1 ) インスタンスで WordPress のような一般的な Web アである Host OS 上に存在する Container にリクエストを転プリケーションが動作する( 2 ) 単一のインスタンスであっても収容サーバ障害時には別サーバへ自動的に再配置される( 3 ) インスタンスの再配置の実行時であっても数秒の遅延送する前に，その Host OS が稼働しているかを ICMP に
よって確認する．Web Proxy は ICMP の疎通を確認した
後に，いったん Host OS 上に稼働している Container Dis-

patcher にリクエストを転送する．Container Dispatcher

で HTTP タイムアウトすることなくオンラインでレはコンテナが稼働していればそのまま HTTP リクエスト

スポンスを返せるを転送し，稼働していなければ，再度 CMDB API 情報に本研究では，上述した 3 つの要件を満たすために Fast-

基いてコンテナを起動させてからリクエストを転送する．

Container を応用して，HTTP リクエスト単位でコンテナ

次に，コンテナが収容されている Host OS が突発的なを再配置する仮想化基盤の高速なスケジューリング手法を障害で停止した場合のフローについて述べる．Client から提案する．提案手法は，HTTP リクエスト処理時においCMDB API を介して Web Proxy に到達し，転送先の収容て，収容サーバ，および，その経路までの状態に応じて，サーバに ICMP のチェックを行う．その際に，収容サーバ

自動的にコンテナを収容する物理サーバを決定し，サービがダウンしている場合は，ICMP のチェックタイムアウト

c 2018 Information Processing Society of Japan⃝4

Vol.2018-IOT-42 No.1
2018/6/28

情報処理学会研究報告
IPSJ SIG Technical Reportを経て，Web Proxy が収容サーバのダウンを認識する．そ表 1 実験環境の後，Web Proxy は再度 CMDB API に接続を行い，コン

Table 1 Experimental Environment.

テナの収容情報を他に起動している Host OS の情報に基いて再生成する．その収容情報に基いて，再度起動中の Host項目

Client仕様

ベンチマークを実施するクライアントサーバ

OS に ICMP チェックを行い，起動していることを確認しCPUIntel Xeon E5-2650 2.20GHz 1core

た上で，Host OS 上で動作している Container Dispatcher

Memory2GBytesにリクエストを転送する．この場合，収容サーバにはコン

Computeテナが起動していないため，Container Dispatcher によって該当コンテナを起動し，HTTP リクエストを転送する．

UserProxy

提案手法では，要件 (1) について，本手法は FastContainer
アーキテクチャに基いており，複数の Host OS 間で共有
ストレージによりデータを共有しているため，コンテナ上

CoreAPIに WordPress のような Web アプリケーションが動作可能であり，かつ，別の Host OS 上でも同様に動作可能であCMDB

コンテナの収容サーバ

CPU

Intel Xeon E5-2650 2.20GHz 8core

Memory51GBytes

CMDB に基づきコンテナにリクエストを転送
CPUIntel Xeon E5-2650 2.20GHz 1core

Memory2GBytes

コンテナの構成管理情報を制御

CPUIntel Xeon E5-2650 2.20GHz 1core

Memory2GBytes

コンテナの構成管理情報を保存る．さらに，要件 (2) について，上記のスケジューリング

CPUIntel Xeon E5-2650 2.20GHz 1core

フローによって，収容サーバがダウンしてもクライアント

Memory16GBytesからの HTTP リクエスト処理の過程で再配置が行われる．

DataPool

コンテナのコンテンツを格納

要件 (3) を満たすためには，(1) で述べた通り，共有スト

Storage

NetApp FAS8200A

レージによってデータを Host OS 間で共有しているため，FlashPool

8.73 TB

データのコピーは発生しないことから，ICMP のタイムア
ウトの時間と，コンテナの収容サーバ変更後のコンテナ再にプロセスをイメージ化する研究がされている [20]．しか配置にかかる時間の合計値をできるたけ短くすれば良い．

し，任意のシステムコール実行前に自動で停止するといっ

ICMP のタイムアウト時間を短くするためには，Webたことができておらず，手動で感覚的に初期化完了時を予Proxy と Host OS 間の通常の ICMP に必要とする時間に想してイメージ化する方が速いといった実験結果になってタイムアウト値をなるべく近くすることが必要となる．同いる．

時に，一時的な遅延によって，障害と至らないにも関わらず

そこで，個々の Web サーバソフトウェアに機能拡張をタイムアウトした場合に再配置が発生したとしても，サー実装することなく，汎用的かつ自動でプロセスの Check-

ビス継続への影響を最小化できれば良い．FastContainer

point/Restore を実現するために，Linux の環境を前提としのプロトタイプ実装と実験環境では，単一のコンテナを複て，システムコールのフィルタリングが行える seccomp[12]数のコンテナにスケールアウトする場合に，レスポンスタと，システムコールの追跡が行える ptrace[10] を利用して，イムが短縮されるまでにかかる時間が実験から数秒程度と外部のプロセスから起動処理中のサーバプロセスを監視し，わかっている [16]．スケールアウト型のスケーリングは，イメージ化する．さらに，イメージ化のタイミングとして，コンテナを追加で起動させる処理であり，コンテナの再配

Web サーバソフトウェアは起動完了直前に必ず実行される

置の起動にかかる処理と同一の処理と言える．そのため，

システムコールである，socket()，setsockopt()，listen()，

再配置に必要となる時間が論文の環境では数秒程度で完了

bind()，などに着目し，seccomp でそれらのシステムコーすることが見込める．

ルが実行される直前の状態を検出し，ptrace によってその状態で処理を中断し，最後に CRIU によって Checkpoint

3.2 コンテナ環境の起動高速化を行うことでプロセスイメージを作成する．

再配置時のコンテナの起動時間をさらに短縮するため定期的にプロセスイメージの作成を行い，FastContainerに，コンテナ上で起動するサーバプロセスの起動時間を高アーキテクチャに従って，コンテナ停止時のリクエストや速化する．そのために，CRIU を使ってプロセスの起動処

コンテナの再配置が実行されるタイミングで，作成済みの理完了直前の状態でプロセスの Checkpoint を行い，プロ

プロセスイメージから Restore 処理によりプロセスの起動

セスをイメージ化する．その場合，複数の Web サーバソを行う．それによって，起動時間の高速化を実現する．

フトウェアに対して，個々に CIRU を組み込むことにより対応していくことは，多数のサーバソフトウェアの拡張が必要となり実装面で非効率である．

4. 実験
本手法の有効性を確認するために，図 2 に示す FastCon-

任意の GUI アプリケーションに対して，初期化時に実tainer を用いた実験環境を構築し，コンテナのスケジューリ

行されるシステムコールを監視しながら，初期化完了直前

ング処理を評価した．表 1 に実験環境と各種ロールの役割

c 2018 Information Processing Society of Japan⃝5

Vol.2018-IOT-42 No.1
2018/6/28

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

表 3 コンテナと Apache の起動時間合計

Table 3 Total Start Time of Container and Apache.
種類

応答時間

平均 (sec)

1.758

標準偏差 (sec)0.417

最大値 (sec)

4.817

最小値 (sec)

1.045

表 2 に，ICMP 応答時間の結果を示す．
実験環境では，ICMP 応答時間は平均 1msec 程度である
ことがわかった．また，最大値は 16msec 程度であることから，ICMP タイムアウトの値を 10msec 程度にすると，
図 2

FastContainer のシステム構成例

Fig. 2 Example of FastContainer System.
表 2

ICMP の応答時間

Table 2 ICMP Response Time.
種類

応答時間

平均 (ms)

1.007

Compute が停止していない状態でも誤検知を起こす場合があると考えられる．そこで，本実験では UserProxy からCompute へ HTTP リクエストを転送する際の ICMP タイ
ムアウトを，WordPress のような CPU を比較的多く利用するコンテナは 100msec で計測することにした．

4.1.2 Apache コンテナの起動時間に関する予備実験
続いて，実験環境において，Apache コンテナが最初に起

標準偏差 (ms)1.499

動するのに要する時間を計測した．計測する理由として，最大値 (ms)

16.214

Apache コンテナの起動時間を計測しておくことにより，実最小値 (ms)

0.0380

際に再配置が行われた場合のレスポンスタイムから，そのレスポンスタイムの妥当性を考察するためである．

を示す．実験環境の各ロールの NIC と OS は全て，NIC は

FastContainer アーキテクチャによるコンテナ停止状態

1Gbps，OS は Ubuntu16.04，カーネルは 4.4.0-59-genericに対して HTTP リクエストを送信し，リクエスト契機にを利用した．

コンテナが起動してレスポンスを返すまでの時間を計測すコンテナのデータは DataPool 上に保存し，Compute から DataPool に対して NFSv3 でマウントした．

る．pache と PHP が動作するコンテナを用いて，40 バイ
トの静的ファイルに対するレスポンスタイムを測定するこベンチマークには，WordPress4.9.5 のデフォルトページとで，全体のレスポンスタイムの内，コンテナと Apacheを表示できるように，PHP のバージョン 7.1.11 を Apacheの起動時間の合計が支配的になるようにした．また，40 バ

モジュールとして組み込んだ Apache2.4.10 をインストー

イトの静的ファイルに対するレスポンスタイムは，10msec

ルしたコンテナを用意した．Apache 起動時には 5 プロセ前後である．測定は 500 回行い，その平均と標準偏差，最ス起動し，アクセス集中時には 150 プロセスまでリクエス

大値，最小値を，小数点以下を有効数字 3 桁で計算した．

ト処理プロセスが追加で起動する設定を行った．

表 3 に，コンテナと Apache の起動時間合計を示す．コ

実験では，まず本実験のためのパラメータ設定と考察のンテナの起動時間については，平均的には 1.758 秒であっために，いくつかの予備実験を行った．その上で，本実験たが，最大値としては 4.817 秒，最小値としては 1.045 秒

では，表 1 のロールを構築し，Client から UserProxy を介となった．つまり，理想的には，本手法によって収容サー

して，Compute に収容されているコンテナに対してベンチバである Compute が停止した際には，ICMP タイムアウ

マークを行い，レスポンスタイムを計測した．

ト値が 1msec 程度で，かつ，コンテナの再配置による起動
時間が 1758msec であるため，それらの総和程度であるこ

4.1 予備実験
4.1.1 ICMP タイムアウトに関する予備実験とが見込める．
最大値が 4.817 秒かかっている原因の詳細は考察できて最初に，ICMP チェックのタイムアウト時間を決定すいないが，Apache の起動時に設定ファイルやモジュール

るために，UserProxy と Compute 間の ICMP の応答時間などがキャッシュに載っているかどうかによって変わる可を計測した．計測には mruby-fast-remote-check を利用し，能性があるため，引き続き考察を行う．

ICMP パケットを 1 パケット送信しその応答時間を測定した．測定は 1000 回行い，その平均と標準偏差，最大値，最小値を，小数点以下を有効数字 3 桁で計算した．

c 2018 Information Processing Society of Japan⃝

4.2 Checkpoint/Restore による起動時間
コンテナの起動時間を高速化するために，サーバプロ

6Vol.2018-IOT-42 No.1
2018/6/28

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

図 3 メモリサイズに応じた Checkpoint/Restore の時間

Fig. 3 Checkpoint/Restore Processing Time for Memory Usage.

図 4 ICMP タイムアウト 100msec の場合の WordPress のベンチ
マーク

Fig. 4 Benchmark of WordPress for ICMP Timeout 100 msec.

セスの起動完了直前の状態で CRIU による Checkpoint をマーク測定中に，一定時間経過後に Compute 上で ipatables

実施し，プロセスをイメージ化する．プロセスの Check-

コマンドにより UserProxy からのパケットを drop し，別point/Restore はメモリの状態もそのままイメージ化するの Compute にコンテナが再配置されるようにした．

技術であり，メモリの使用状態に起因して処理時間が変WordPress のコンテナは，PHP の処理に CPU 使用時間化することが想定されるため，mruby-simplehttpserver をを静的ファイルと比較して多く必要とするため，割り当て使って，初期化時に特定の変数に大量の文字列を格納する

メモリは 512MB であるが，CPU は 4 コア利用可能となことでメモリ使用量を変化させ，メモリ使用量に応じてるように割り当てた．WordPress のコンテナに対するベンCheckpoint/Restore の処理時間を計測する．

チマークでは，ab コマンドで，同時接続数 10，総接続数

実験は，図 1 の Compute 上で行った．seccomp と ptraceのライブラリである mruby-seccomp と CRIU のライブラ

5000 で計測を行い，ベンチマーク時間の中間時刻である
100 秒の時点でネットワークを切断した．

リである murby-criu を組み込んだ管理用 mruby を利用

ベンチマークでは，秒間のレスポンスタイムの平均値をし，mruby-simplehttpserver で実装した Web サーバプロ

計算し，時系列データとしてベンチマークが完了するまでセスが setsockopt() システムコールを実行する直前に，管のレスポンスタイムの変化を計測した．

理用 mruby プロセスから自動的に Web サーバプロセスの図 4 に，ICMP タイムアウトが 100msec の場合の Word-

Checkpoint を行う．Restore は，Checkpoint によって得ら

Press に対するベンチマーク結果を示す．WordPress は，れたイメージファイルに対して行う．

実験環境においては平均的に 400msec 前後のレスポンスタ

図 3 に ，プ ロ セ ス の メ モ リ サ イ ズ に 応 じ た Check-

イムであった．100 秒の時点で再配置の処理が動作した際

point/Restore の処理時間を示す．グラフが示すように，プには，2080msec の処理時間を要した．ICMP のタイムア

ロセスのメモリ使用量が増加するに従い，Checkpoint の処

ウト値が 100msec であることから，コンテナの再配置から理時間が比例して長くなっていることがわかる．Restore

Apache の起動とレスポンス生成までには概ね 1980msec で時間も同様に増加しているが，増加の割合は Checkpoint

実現できている．そのことから，コンテナの再配置とコンと比較して少ないことがわかった．また，WordPress が動テナ起動に要する時間は，WordPress のレスポンスタイム

作するような，PHP が組み込まれた Apache httpd のプロ

400msec を除くと，1580msec となる．．また，22 秒の時点

セスは，起動時に概ね 50MB 程度を確保しており，起動にから 70 秒の時点まで一時的にレスポンスタイムが 2 倍にも 4.1.2 説の予備実験から 2 秒程度かかることがわかって増加している期間があった．これは，実験では原因が特定いるため，あらかじめ Checkpoint でプロセスをイメージできなかったため，引き続き調査予定である．

化できていれば，図 3 から Restore によって 0.3 秒と高速に起動させられることが期待される．

以上の実験結果について，4.1.1 節と 4.1.2 節の数値からも，再配置に要する時間は妥当であることがわかった．

4.1.2 節の実験結果のコンテナの起動時間の平均や分散から
4.3 再配置時のレスポンスタイムの本実験

も，再配置後のコンテナからのレスポンスに要する時間は，予備実験の結果に基いて，WordPress に対するレスポンス

コンテナの起動時間が支配的であり，本手法における再配タイムを計測した．また，本実験には Checkpoint/Restore

置手法そのものの処理時間は影響がないことがわかった．

によるサーバプロセスの起動の高速化手法を組み込めな

UserProxy から Compute にリクエスト転送が送信されかったため，プロセスのイメージ化は行っていない．ベンチて，Compute 上のコンテナから UserProxy にレスポンス

c 2018 Information Processing Society of Japan⃝7

Vol.2018-IOT-42 No.1
2018/6/28

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

データが送信される前の状態で Compute が停止してしまった場合は，そのレスポンスを UserProxy が正しく受信できないため，レスポンスを一部取りこぼすこともありえる．
しかし，これは従来方式において複数のホスト OS にそれ
ぞれ分散してインスタンスを配置して可用性を担保する方式でも原理的に生じるため，本手法の特徴的な問題ではない．
本実験結果から，単一のコンテナインスタンスを単一の収容サーバに起動させておきながらも，その収容サーバの停止時には，迅速に再配置のスケジューリングが行えていることがわかった．また，実験環境程度のハードウェアス
ペックで，1.5 秒から 2 秒程度であれば，実用上は HTTP
タイムアウトすることなくレスポンスを返せると見込めるが，提供サービスレベルにも依存する問題でもあるため検討が必要である．FastContainer の課題 [13] のうち，予備実験で示したプロセスの Checkpoint/Restore 機能が導入できれば，再配置に占めるコンテナの起動時間を数百 msec
程度に短縮できるため，よりこの手法を活かすことができる．

5. まとめ本研究では，HTTP リクエスト処理時において，収容
サーバ，および，その経路までの状態に応じて，自動的にコンテナを収容する物理サーバを決定し，サービスを継続させる，HTTP リクエスト単位でのコンテナスケジューリ
ング手法を提案し，その有効性を評価した．
実験から，WordPress のような一般的な Web アプリケー
ションが起動しているインスタンスにおいて，複数のホス
ト OS に複数のインスタンスを配置して可用性を担保することなく，単一のインスタンスという少ないリソースで，1.5 秒から 2 秒程度の再配置処理により，HTTP エラーを発生させることなく可用性を担保することができた．このようなリソース使用量の削減により，サービス利用者は可用性の担保のために，複数の収容サーバに横断的に複数のインスタンスを配置する必要がなくなり，サービス利用料を削減できる．
今後の課題として，コンテナ起動時間の高速化手法をシステムに実装して評価を行うことや，負荷やレスポンス
タイムに応じた HTTP リクエスト単位でのコンテナスケ
ジューリング手法の実現が挙げられる．
参考文献
[1]
[2]
[3]
[4]

Amazon Web Services, https://aws.amazon.com/.
Amazon Web Services: Lambda, https://aws.amazon.
com/lambda/.
Amazon Web Services: Auto Scaling, https://aws.
amazon.com/autoscaling/.
CRIU – A project to implement checkpoint/restore functionality for Linux, https://criu.org/.

c 2018 Information Processing Society of Japan⃝[5]

Brown Mark R, FastCGI: A high-performance gateway
interface, Fifth International World Wide Web Conference. Vol. 6. 1996.
[6]
Felter W, Ferreira A, Rajamony R, Rubio J, An Updated Performance Comparison of Virtual Machines andLinux Containers, IEEE International Symposium Performance Analysis of Systems and Software (ISPASS),
pp. 171-172, March 2015.
[7]
Ferdman M, Adileh A, Kocberber O, Volos S, Alisafaee
M, Jevdjic D, Falsafi B, Clearing the clouds: a studyof emerging scale-out workloads on modern hardware,
ACM SIGPLAN Notices, Vol. 47, No. 4, pp. 37-48,
March 2012.
[8]
He S, Guo L, Guo Y, Wu C, Ghanem M, Han R, Elastic
application container: A lightweight approach for cloud
resource provisioning, Advanced information networking
and applications (AINA 2012) IEEE 26th international
conference, pp. 15-22, March 2012.
[9]P Mell, T Grance, The NIST Definition of Cloud
Computing”, US Nat’l Inst. of Science and Technology, 2011, http://csrc.nist.gov/publications/
nistpubs/800-145/SP800-145.pdf.
[10] Pradeep Padala, Playing with ptrace, Part I, Linux Journal, Vol.2002, Issue.103, p5, 2002.
[11] 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.
[12] SECure COMPuting with filters, https://www.kernel.
org/doc/Documentation/prctl/seccomp\_filter.
txt.
[13] 笠原 義晃, 松本 亮介, 近藤 宇智朗, 小田 知央, 嶋吉 隆
夫, 金子晃介, 岡村 耕二, 軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負荷
テスト環境の構築, 研究報告インターネットと運用技術（IOT）, Vol.2018-IOT-40(2), pp.1-8, 2018 年 3 月.
[14] 松本 亮介, Web サーバの高集積マルチテナントアーキ
テクチャに関する研究, 京都大学博士 (情報学) 学位論文,
2017.
[15] 松本亮介, 川原将司, 松岡輝夫, 大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086,
2013 年 3 月.
[16] 松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎,
FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用
技術シンポジウム 2017 論文集，2017，89-97（2017-11-30）,
2017 年 12 月.
[17] 松本亮介, 田平 康朗, 山下 和彦, 栗林 健太郎, 特徴量
抽出と変化点検出に基づく Web サーバの高集積マルチ
テナント方式におけるリソースの自律制御アーキテクチャ, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-36(26), 1-8, (2017-02-24).
[18] 松本亮介, 栗林 健太郎, 岡部寿男, リクエスト単位で仮想的にハードウェアリソースを分離する Web サーバのリ
ソース制御アーキテクチャ, 情報処理学会論文誌, Vol.59,
No.3, pp.1016-1025, 2018 年 3 月.
[19] 三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリ
ング, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-38, Vol.13, pp.1-8, 2017 年 6 月.
[20] 阿部 敏和, 中山 泰一, プロセスの保存と復元による GUI
アプリケーションの起動高速化, 情報処理学会全国大会
講演論文集, 第 72 回アーキテクチャ, pp95-96, 2010 年 3
月．

8