Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

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

HTTP リクエスト単位でコンテナを再配置する
仮想化基盤の高速なスケジューリング手法
松本 亮介1,a)

田中 諒介2

栗林 健太郎1

概要：クラウドサービスの普及に伴い，個人の Web サイトでもクラウドサービスに類する機能を利用して，突発的なアクセス集中に耐性があり，かつ，利用したリソース使用量に応じて課金するサービスの提供が求められている．我々はその要求に応じるために，Web サイトをコンテナ上に構築し，コンテナの起動や停止，複製やリソース割り当てといった状態の変更を素早く実行できるコンテナ管理アーキテクチャ
FastContainer を提案した．一方で，単一のコンテナが特定のサーバに収容されている状態で，サーバが過負荷に陥ったり停止したりするような状況においては，障害時にコンテナの収容サーバ情報の変更を手動で構成管理データベースに反映させる必要があった．本研究では，HTTP リクエスト処理時において，収容サーバ，および，その経路までの状態に応じて，自動的にコンテナを収容するサーバを決定し，サービスを継続させる，HTTP リクエスト単位でのコンテナスケジューリング手法を提案する．提案手法では，FastContainer の状態変化の高速性に基づいて，コンテナが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する．それによって，プロキシサーバから収容サーバに 1 個の ICMP パケットで応答速度を計測し，少ないパケット数と短いタイムアウトで収容サーバの反応時間を計測できる．そのこと
で，HTTP リクエスト単位でのコンテナスケジューリングを実現する．

Fast Scheduler for a Cloud Platform to Relocate Containers
at Each HTTP Request
Ryosuke Matsumoto1,a)Ryosuke Tanaka2

1. はじめに

Kentaro Kuribayashi1

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

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

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

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

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

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

た場合，単一のサーバに高集積にユーザ領域を収容するよようになった．その結果，コンテンツの内容の品質が高け

うな低価格 Web ホスティングサービスが利用される．それば，さらに拡散され，コンテンツに紐づく個人のブランのような低価格ホスティングサービスでは，利用者の Webド化も可能になってきている．そのため，コンテンツ拡散

コンテンツが特定の Web サーバに紐づくため，ユーザ領域時であっても継続的に配信可能な Web サイトの構築は，個単位で突発的なアクセス集中に対して負荷分散することがGMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan
GMO ペパボ株式会社 ホスティング事業部
Hosting Department, GMO Pepabo, Inc.
matsumotory@pepabo.com

難しい．クラウドサービスの場合は，利用者がアクセス集

1

2

a)

c 2018 Information Processing Society of Japan⃝

中に耐えうるオートスケーリング [9] の仕組みを作る必要があったり，各サービス・プロバイダが提供しているオー
トスケーリングの機能 [2] を使う必要がある．

1

Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

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

可用性の面では，Web ホスティングサービスの方式もク
ラウドサービスも，仮想的に構築されたサーバ環境である

2. Web サービス基盤の負荷分散と可用性

インスタンスを複数のハードウェア上に起動させることにより，特定のハードウェアに障害が置きてもサービスを停止せずに提供可能である [13]．しかし，複数台のインスタンスが必要であることに起因するコストの問題や，ハードウェアが停止すると縮退状態のインスタンスでサービスを提供することになり，場合によってはリソース不足に陥る．
我々は，従来の Web ホスティングサービスを利用できる程度の知識を持った個人が WordPress のような一般的な CMS を利用した Web コンテンツを配信することを前提に，サービス利用者が負荷分散のシステム構築やライブラ
リの運用・管理を極力必要とせず，迅速にユーザ領域を複数のサーバに展開可能な，実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャの FastContainerを提案した [14]．FastContainer は，インスタンスとしてコンテナのように起動の所要時間が小さい実行環境を採用
し，リクエスト単位でコンテナの状態を決定する．そのため，オートスケーリングの観点において，アクセス集中時にはコンテナの負荷やアクセス数に応じて，コンテナをリ
クエスト契機に自動的に複製，あるいはリソースの追加割り当てを行い，迅速に自動的な負荷分散ができる．一方，可用性の面では，単一のコンテナが収容されているサーバが稼働していることが前提であり，収容サーバが停止すると，手動によるコンテナ再配置が必要であった．そのため，可用性を担保するには，従来手法と同様にコンテナを複数の収容サーバに起動して配置しておく必要がある．
本研究では，HTTP リクエスト処理時において，単一のコンテナであっても，収容サーバの状態に応じて，自動的にコンテナを別の収容サーバに再配置し，サービスを継続させる，HTTP リクエスト単位でのコンテナスケジューリン
グ手法を提案する．提案手法では，FastContainer の状態
変化の高速性に基づいて，コンテナが頻繁に収容サーバを変更されてもサービスに影響がないことを利用する．それによって，プロキシサーバから収容サーバに 1 個の ICMP
パケットで応答速度を計測し，少ないパケット数と短いタ
イムアウトで収容サーバの反応時間を計測できる．．そのことで，HTTP リクエスト単位でのコンテナスケジューリングを実現する．
本論文の構成を述べる．2 章では，Web ホスティング
サービスやクラウドサービスにおけるオートスケーリング，

FastContainer 等の特徴とその課題について述べる．3 章
では，2 章で述べたインスタンスの再配置の課題を解決するための提案手法のアーキテクチャおよび実装を述べる．

最もアクセスが集中しており，かつ，Web コンテンツを幅広く閲覧される可能性が高い状況においては，サーバが高負荷状態となってアクセスが困難となり，貴重なコンテ
ンツ拡散の機会を逃すことも多い．また，ホストが収容されているハードウェアに障害があった場合に，いかにサービスを継続するかといった可用性の観点でシステムを構築する必要もある．本章では，相互に関連の深いスケーリン
グの特性と可用性の観点から，Web ホスティングサービス
やクラウドサービスにおける関連研究と課題について整理する．

2.1 Web ホスティングサービス
負荷対応のためのスケーリング手法は，大きく分けて，稼働している単一のインスタンスに割り当てるハードウェ
アリソースを増減させるスケールアップ型と，複数のインスタンスへと起動数を増減することによって負荷分散を行うスケールアウト型の 2 つに分類できる．
一般的に，個人が Web コンテンツを配信するためには，Web ホスティングサービスやクラウドサービスなどが利用される [8]．特に，個人の利用を想定した場合，仮想ホスト方式を利用して，単一のサーバに高集積にユーザ領域を収容するような低価格 Web ホスティングサービスが利用される [11]．仮想ホスト方式では複数のホストを単一のサーバプロセス*1 で処理するため，リクエストは Web サーバプ
ロセスを共有して処理される．そのため，ホスト単位で使用するリソースを適切に制御したり，その原因を迅速に調査することが困難である [16]．

Web ホスティングサービス [8] では，サービス利用者の Web コンテンツは特定の Web サーバに収容され，Web
サーバと Web コンテンツが紐づくため，負荷に応じたオー
トスケーリングは，データの整合性の面と前述したホスト
単位での適切な負荷計測・制御の面から困難である．このような場合に適用可能な手法として，ユーザデータ領域を共有ストレージにまとめた上で，仮想ホスト方式を採用した複数台の Web サーバで負荷分散と可用性を担保する手法 [13] がある．しかし，Web サーバを複数台配置して全ホストを同一の設定にすることが前提となる手法であるため，ホスト単位でのスケーリングや可用性の担保は対応で
きず，コストも高くなる．また，負荷に応じて，ホスト単位での即時性の高いスケールアップ型の負荷対応もできない．

4 章では，HTTP リクエスト単位でのコンテナスケジューリング手法の評価を行い，5 章でまとめとする．
*1

c 2018 Information Processing Society of Japan⃝ただし，ここでいう単一のサーバプロセスとは，ホスト毎にサーバプロセスを起動させるのではなく，複数のホストでサーバプロ
セスを共有することを示す

2

IPSJ SIG Technical Report

Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

2.2 クラウドサービス

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

情報処理学会研究報告

クラウドコンピューティング [7] とは，ネットワークやタンスが必要であることに起因するコストの問題や，ハーサーバといったコンピュータリソースのプールから必要

ドウェアが停止すると縮退状態のインスタンスでサービスな時に必要な量だけオンデマンドに利用可能とするコン

提供することになり，場合によってはリソース不足に陥る．

ピューティングモデルである．クラウドサービスはクラウ
ドコンピューティングを各種サービスとして提供するサービスである．

2.3 FastContainer アーキテクチャ
我々は，個人が Web コンテンツを配信する用途においクラウドサービスでは，Web コンテンツを配置するだけて，Web ホスティングサービスやクラウドサービスにおけでなく，Web サーバソフトウェアやデータベースをサービる突発的にアクセス集中の対応やオートスケーリングの課

ス利用者が自ら構築する必要がある．そのため，負荷分散

題を解決するために，FastContainer アーキテクチャを提のためのシステム設計をホスト単位で個別に行うことがで案した [14]．FastContainer は，Web ホスティングサービ

きる点において自由度は高いが，前提として専門的な知識スを利用できる程度の知識を持った個人が，WordPress のが必要となる．

ような一般的な CMS を利用した Web コンテンツを配信す

オートスケーリングについては，負荷に応じてインスタることを前提にしている．FastContainer は，そのようなンスを増減させる機能が提供されている [3]．しかし，そのサービス利用者が負荷分散のシステム構築やライブラリの負荷の監視間隔が分の単位であり，突発的なアクセスに対運用・管理を極力必要とせず，迅速にユーザ領域を複数のして検知するまでの時間が長くなる．負荷状況に応じて仮サーバに展開可能な，実行環境の変化に素早く適応できる想マシンを起動できたとしても，テレビ放映の影響のよう恒常性を持つシステムアーキテクチャである．その特性をな突発的な高負荷時に，オートスケーリングのための処理利用して，我々はメールシステムにも応用する手法を提案

自体が追いつかず，サービス停止に繋がることも多い．

した [12]．

仮想マシンの起動時間の問題を解決するためにコンテナ

FastContainer アーキテクチャでは，インスタンスとしを利用する手法 [6] や，外部サービス連携によってスケーて，仮想マシンではなく Linux コンテナ [5] を利用する．

リングを行う条件を詳細に定義できるサービス*2 もある．

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

しかし，スケーリング時の判定を行う際に，OS の負荷やで仮想的に OS 環境を隔離する仮想化技術のひとつである．

プロセスの状態等を監視する方式がとられており，監視のそのため，コンテナの起動処理は仮想マシンのようなカー

時間間隔や取得できる情報の粒度が荒く，突発的な負荷やネルを含む起動処理と比べて，新しくプロセスを起動させハードウェア障害に対する即時スケーリングと誤検知とのる程度の処理で起動が可能であるため，起動時間が短時間

両立が難しい．

で済むという特徴がある．

高負荷状態に対して迅速に対応するためには，事前にあFastContainer アーキテクチャでは，コンテナが仮想マる程度想定される量の仮想マシンを予測的に起動させておシンと比較して速く起動できる点と，FastCGI[4] を参考

くことによって対処する手法がある [17]．しかし，本手法に，サーバへの収容効率を高めつつ性能を担保するアーキ

は突発的なアクセスに対するスケーリングを対象としておテクチャを組み合わせる．さらに，HTTP リクエスト毎にらず，予測の精度を保つための各種パラメータの選定に関負荷状態やアクセス数に応じて，Web アプリケーションコ

する課題もある．

ンテナの起動処理，起動継続時間，コンテナの起動数およ

上記のような問題を解決するために，クラウドサービス

びリソース割り当てをリアクティブに決定する．一定時間

プロバイダの AWS は，プロバイダ指定の記法によってア起動することにより，一度コンテナが起動してしまえば，

プリケーションを実装すれば，自動的にコンピュータリ

起動時間に影響なくレスポンスを送信できる．この特性にソースを決定し，高負荷時には自動的にプロバイダ側でよって，ホストをコンテナ単位で個別に起動しながらも，

オートスケーリングする機能 [2] を提供している．しかし，リクエストの無い不要なコンテナは自然に停止するため，前提としてプログラミングができるエンジニアを対象とし高集積に収容できる．

ており，一般的な OSS として公開されている Web アプリ

FastContainer は，コンテナの起動が一般的に高速であケーションを利用できないことが多く，個人が Web コン

ること，リクエストを契機としたリアクティブな起動処理

テンツを配信する用途においては使用上の制限が大きい．

であることにより，突発的な負荷に対しても迅速にリクエ

可用性の面では，Web ホスティングサービスの方式と同スト単位でオートスケーリングが可能となる．スケール様に，インスタンスを複数のハードウェア上に起動させる

アップについても，コンテナのリソース管理が cgroup にことにより，特定のハードウェアに障害が置きてもサービ

よってプロセス単位で制御されており，cgroup の特徴を利用して，プロセスが処理中であっても CPU 使用時間など*2

http://www.rightscale.com/

c 2018 Information Processing Society of Japan⃝の割り当てを即時変更できる．

3Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

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

しかし，このアーキテクチャはコンテナが収容されるサーバが稼働していることが前提であり，収容サーバが停止すると，手動によるコンテナ再配置が必要であった．また，単一のコンテナで起動している場合は，その収容サーバが停止すると，手動で再配置が行われるまでには同様にサービスも停止してしまう．そのため，ハードウェア障害時の可用性については，Web ホスティングサービスやクラウドサービスと同様に，複数の収容サーバに横断的に複数のコンテナを立ち上げておく必要があった．

3. 提案手法
個人の利用者が WordPress のような一般的な Web コン

図 1

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

Fig. 1 The Flow of Contaienr Scheduling.

テンツを配信する仮想化基盤において，収容効率を高めつ
つ，アクセス集中による負荷やインスタンスの収容サーバ

patcher にリクエストを転送する．Container Dispatcherの障害に対する可用性を担保可能な基盤にするためには，はコンテナが稼働していればそのまま HTTP リクエスト

以下の要件が必要である．

を転送し，稼働していなければ，再度 CMDB API 情報に( 1 ) インスタンスで WordPress のような一般的な Web ア

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

プリケーションが動作する( 2 ) 単一のインスタンスであっても収容サーバ障害時には別サーバへ自動的に再配置される

次に，コンテナが収容されている Host OS が突発的な障害で停止した場合のフローについて述べる．Client から

CMDB API を介して Web Proxy に到達し，転送先の収容( 3 ) インスタンスの再配置の実行時であっても数秒の遅延サーバに ICMP のチェックを行う．その際に，収容サーバ

で HTTP タイムアウトすることなくオンラインでレがダウンしている場合は，ICMP のチェックタイムアウト

スポンスを返せるを経て，Web Proxy が収容サーバのダウンを認識する．そ

本研究では，上述した 3 つの要件を満たすために Fast-の後，Web Proxy は再度 CMDB API に接続を行い，コンContainer を応用して，HTTP リクエスト単位でコンテナテナの収容情報を他に起動している Host OS の情報に基いを再配置する仮想化基盤の高速なスケジューリング手法をて再生成する．その収容情報に基いて，再度起動中の Host

提案する．提案手法は，HTTP リクエスト処理時においOS に ICMP チェックを行い，起動していることを確認して，収容サーバ，および，その経路までの状態に応じて，た上で，Host OS 上で動作している Container Dispatcher

自動的にコンテナを収容するサーバを決定し，サービスをにリクエストを転送する．この場合，収容サーバにはコン

継続させる．FastContainer の状態変化の高速性に基づいテナが起動していないため，Container Dispatcher によって，コンテナが誤検知によって再配置されてもサービスがて該当コンテナを起動し，HTTP リクエストを転送する．

停止しないことを利用する．それによって，プロキシサー

提案手法では，要件 (1) について，本手法は FastContainer

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

アーキテクチャに基いており，複数の Host OS 間で共有

ムアウトで収容サーバの反応時間を計測できる．そのこと

ストレージによりデータを共有しているため，コンテナ上

で，HTTP リクエスト単位でのコンテナスケジューリング

に WordPress のような Web アプリケーションが動作可能を実現する．

であり，かつ，別の Host OS 上でも同様に動作可能であ図 1 に，コンテナスケジューリングのフローを示す．

る．さらに，要件 (2) について，上記のスケジューリング

Host OS が障害を起こしていない正常時のフローについフローによって，収容サーバがダウンしてもクライアントて述べる．図 1 における Client から Container に対してからの HTTP リクエスト処理の過程で再配置が行われる．

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

要件 (3) を満たすためには，(1) で述べた通り，共有ストに一旦集約される．Web Proxy にリクエストが到達した

レージによってデータを Host OS 間で共有しているため，段階で，Container の収容情報や構成管理情報を保持する

データのコピーは発生しないことから，ICMP のタイムア

CMDB API に情報を問い合せ，Container の収容サーバやウトの時間と，コンテナの収容サーバ変更後のコンテナ再IP アドレス/ポート情報を得る．Web Proxy は収容サーバ配置にかかる時間の合計値をできるたけ短くすれば良い．

である Host OS 上に存在する Container にリクエストを転ICMP のタイムアウト時間を短くするためには，Web送する前に，その Host OS が稼働しているかを ICMP に

Proxy と Host OS 間の通常の ICMP に必要とする時間によって確認する．Web Proxy は ICMP の疎通を確認した

タイムアウト値をなるべく近くすることが必要となる．同後に，いったん Host OS 上に稼働している Container Dis-

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

c 2018 Information Processing Society of Japan⃝4

Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

情報処理学会研究報告
IPSJ SIG Technical Report
表 1 実験環境

Table 1 Experimental Environment.
項目

ClientComputeUserProxy

CoreAPI

CMDB

DataPool仕様

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

CPUIntel Xeon E5-2650 2.20GHz 1core

Memory2GBytes

コンテナの収容サーバ

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

コンテナの構成管理情報を保存

CPUIntel Xeon E5-2650 2.20GHz 1core

Memory16GBytes

図 2

Fig. 2 Example of FastContainer System.
表 2

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

Storage

NetApp FAS8200A

FlashPool

8.73 TB

FastContainer のシステム構成例

ICMP の応答時間

Table 2 ICMP Response Time.
種類

応答時間

平均 (ms)1.007

標準偏差 (ms)1.499

タイムアウトした場合に再配置が発生したとしても，サー最大値 (ms)

16.214

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

最小値 (ms)

0.0380のプロトタイプ実装と実験環境では，単一のコンテナを複数のコンテナにスケールアウトする場合に，レスポンスタ
イムが短縮されるまでにかかる時間が実験から数秒程度とわかっている [14]．スケールアウト型のスケーリングは，を利用した．
コンテナのデータは DataPool 上に保存し，Compute から DataPool に対して NFSv3 でマウントした．

コンテナを追加で起動させる処理であり，コンテナの再配ベンチマーク対象のコンテナは，40 バイトの静的ファイ

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

ルを返すだけのコンテナと，WordPress4.9.5 をインストー

再配置に必要となる時間が論文の環境では数秒程度で完ルしてデフォルトページを表示するコンテナを用意した．

了することが見込める．また，コンテナの起動時間自体はそれぞれのコンテナには，Apache2.4.10 をインストール

FastContainer の課題である [10] ため，本手法のスコープ

し，PHP のバージョン 7.1.11 を Apache モジュールとしは，再配置に要する時間を FastContainer におけるコンテて組み込んで利用した．Apache 起動時には 5 プロセス起ナの起動時間にできるだけ近づけられることとする．

動し，アクセス集中時には 150 プロセスまで起動する設定

以上のことから，FastContainer の状態変化の高速性をを行った．

活用することにより，積極的に ICMP タイムアウトを短く実験では，まず本実験のためのパラメータ設定と考察することが可能である．また，Host OS が停止していないのために，予備実験を行った．その上で，本実験では，状況であっても，ICMP タイムアウトが生じた場合は何ら

表 1 のロールを構築し，Client から UserProxy を介して，かの負荷や異常が発生しているとも見なせる．それによっCompute に収容されているコンテナに対してベンチマーて，別の Host OS にコンテナが再配置されることは，サークを行い，レスポンスタイムを計測した．

ビスが停止しない限りは有効なスケジューリングと考えら
れる．

4. 実験

4.1 予備実験
4.1.1 ICMP タイムアウトに関する予備実験
最初に，ICMP チェックのタイムアウト時間を決定す

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

るために，UserProxy と Compute 間の ICMP の応答時間

tainer を用いた実験環境を構築し，コンテナのスケジューリを計測した．計測には mruby-fast-remote-check を利用し，ング処理を評価した．表 1 に実験環境と各種ロールの役割

ICMP パケットを 1 パケット送信しその応答時間を測定しを示す．実験環境の各ロールの NIC と OS は全て，NIC はた．測定は 1000 回行い，その平均と標準偏差，最大値，最1Gbps，OS は Ubuntu16.04，カーネルは 4.4.0-59-generic

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

c 2018 Information Processing Society of Japan⃝5

Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

情報処理学会研究報告
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 程度にすると，Compute が停止していない状態でも誤検知を起こす場合があると考えられる．

図 3 ICMP タイムアウト 10msec の場合の静的ファイルのベンチ
マーク

Fig. 3 Benchmark of Static Files for ICMP Timeout 10 msec.

そこで，本実験では UserProxy から Compute へ HTTP
リクエストを転送する際の ICMP タイムアウトを，静的ファイルのような負荷の小さなコンテナの場合は 10msec，

WordPress のような CPU を比較的多く利用するコンテナ
は 100msec で計測することにした．

4.1.2 Apache コンテナの起動時間に関する予備実験
続いて，実験環境において，Apache コンテナが最初に起動するのに要する時間を計測した．計測する理由として，

Apache コンテナの起動時間を計測しておくことにより，実際に再配置が行われた場合のレスポンスタイムから，そのレスポンスタイムの妥当性を考察するためである．コンテ
ナの起動時間自体は FastContainer の課題であるため，本実験のスコープは，再配置に要する時間を FastContainerにおけるコンテナの起動時間にできるだけ近づけられるこ

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

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

とである．

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

いないが，Apache の起動時に設定ファイルやモジュールに対して HTTP リクエストを送信し，リクエスト契機になどがキャッシュに載っているかどうかによって変わる可コンテナが起動してレスポンスを返すまでの時間を計測す能性があるため，引き続き考察を行う．

る．上述した，Apache と PHP が動作するコンテナを用いて，40 バイトの静的ファイルに対するレスポンスタイムを

4.2 再配置時のレスポンスタイムの本実験

測定することで，全体のレスポンスタイムの内，コンテナ

予備実験の結果に基いて，静的ファイルと WordPress にと Apache の起動時間の合計が支配的になるようにした．

対するレスポンスタイムを計測した．ベンチマーク測定中

また，40 バイトの静的ファイルに対するレスポンスタイムに，一定時間経過後に Compute 上で ipatables コマンドには，10msec 前後である．測定は 500 回行い，その平均とより UserProxy からのパケットを drop し，別の Compute

標準偏差，最大値，最小値を，小数点以下を有効数字 3 桁にコンテナが再配置されるようにした．

で計算した．

静的ファイルのコンテナの最大 CPU 使用量は，cgroup

表 3 に，コンテナと Apache の起動時間合計を示す．コの機能により 1 コアのみ利用できるように割り当て，メモ

ンテナの起動時間については，平均的には 1.758 秒であっ

リは 512MB を割り当てた．また，WordPress のコンテナ

たが，最大値としては 4.817 秒，最小値としては 1.045 秒

は，PHP の処理に CPU 使用時間を静的ファイルと比較しとなった．つまり，理想的には，本手法によって収容サーて多く必要とするため，割り当てメモリは 512MB である

バである Compute が停止した際には，ICMP タイムアウが，CPU は 4 コア利用可能となるように割り当てた．

ト値が 1msec 程度で，かつ，コンテナの再配置による起動

静的ファイルを返すコンテナに対するベンチマークでは，

時間が 1758msec であるため，それらの総和程度であるこ

ab コマンドで，同時接続数 10，総接続数 100000 で計測をとが見込める．

行い，50 秒の時点でネットワークを切断した．この 50 秒

最大値が 4.817 秒かかっている原因の詳細は考察できて

c 2018 Information Processing Society of Japan⃝は，静的ファイルに対する上述したパラメータによる総処

6

Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

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

理時間が 100 秒程度であるため，前後の変化が明らかとなを返す実装にしていたためである．この問題については，

るようにその半分程度の時間に設定した．

1 つを除いて再配置の要求リクエストを一時停止させ，再また，WordPress のコンテナに対するベンチマークでは，配置が完了した時点で残りのコンテナへの HTTP リクエ

ab コマンドで，同時接続数 10，総接続数 5000 で計測を行

ストを再配置後のコンテナに転送することで解決できる．

い，静的ファイルに対するコンテナと同様の理由から，100

UserProxy から Compute にリクエスト転送が送信され秒の時点でネットワークを切断した．

て，Compute 上のコンテナから UserProxy にレスポンス

ベンチマークでは，秒間のレスポンスタイムの平均値をデータが送信される前の状態で Compute が停止してしまっ

計算し，時系列データとしてベンチマークが完了するまでた場合は，そのレスポンスを UserProxy が正しく受信できのレスポンスタイムの変化を計測した．

ないため，レスポンスを一部取りこぼすこともありえる．

図 3 に，ICMP タイムアウトが 10msec の場合の静的

しかし，これは従来方式において複数のホスト OS にそれ

ファイルに対するベンチマーク結果を示す．実験環境にぞれ分散してインスタンスを配置して可用性を担保する

おいては，静的ファイルのベンチマークでは 1 リクエス

方式でも原理的に生じるため，本手法の特徴的な問題ではトにつき 10msec 前後でレスポンスを返せている．50 秒

ない．

の時点で Compute が停止し，UserProxy が ICMP タイム

本実験結果から，単一のコンテナインスタンスを単一のアウト 10msec 経過後に，CoreAPI から再配置の情報を取収容サーバに起動させておきながらも，その収容サーバの得し，もう一台の正常に動作している Compute に再配置

停止時には，迅速に再配置のスケジューリングが行えていを行う．その際，ICMP タイムアウトに 10msec，再配置

ることがわかった．また，実験環境程度のハードウェアス

後，コンテナを起動させてレスポンスを返すまでに秒間平ペックで，1.5 秒から 2 秒程度であれば，実用上は HTTP

均 1400msec 程度時間を要している．その後 52 秒の段階でタイムアウトすることなくレスポンスを返せると見込めるは，既に 10msec 前後のレスポンスタイムとなっているたが，提供サービスレベルにも依存する問題でもあるため検め，再配置に要する時間は 1.5 秒程度であった．

討が必要である．一方，FastContainer の課題のうち，コン

図 4 に，ICMP タイムアウトが 100msec の場合の Word-

テナのイメージ化によって起動時間を高速化する研究 [10]Press に対するベンチマ¿ーク結果を示す WordPress では，が改善されれば，再配置に占めるコンテナの起動時間も短

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

縮できるため，よりこの手法を活かすことができる．

イムであった．100 秒の時点で再配置の処理が動作した際には，2080msec の処理時間を要した．ICMP のタイムア

5. まとめ

ウト値が 100msec であることから，コンテナの再配置から本研究では，HTTP リクエスト処理時において，収容Apache の起動とレスポンス生成までには概ね 1980msec でサーバ，および，その経路までの状態に応じて，自動的に実現できている．そのことから，コンテナの再配置とコンコンテナを収容するサーバを決定し，サービスを継続させテナ起動に要する時間は，WordPress のレスポンスタイム

る，HTTP リクエスト単位でのコンテナスケジューリング

400msec を除くと，1580msec となる．．また，22 秒の時点手法を提案し，その有効性を評価した．

から 70 秒の時点まで一時的にレスポンスタイムが 2 倍に

本研究により，WordPress のような一般的な Web アプ

増加している期間があった．これは，実験では原因が特定リケーションが起動しているインスタンスにおいて，複数できなかったため，引き続き調査予定である．

のホスト OS に複数のインスタンスを配置して可用性を担以上の実験結果について，4.1.1 節と 4.1.2 節の数値か保することなく，単一のインスタンスという少ないリソー

らも，再配置に要する時間は妥当であることがわかった．

スで，1.5 秒から 2 秒程度の再配置処理により，HTTP エ

4.1.2 節の実験結果のコンテナの起動時間の平均や分散かラーを発生させることなく可用性を担保することができらも，再配置後のコンテナからのレスポンスに要する時間

た．このようなリソース使用量の低減により，本手法は個

は，静的コンテンツも WordPress もコンテナの起動時間が人用途のホスティングサービスのような低価格が求められ支配的であり，本手法における再配置手法そのものの処理るサービスの設計に適している．

時間は影響がないことがわかった．また，誤検知による再今後の課題として，従来からの課題である FastContainer

配置は生じなかったが，1msec までタイムアウトを短くすアーキテクチャのコンテナ起動時間を更に短縮することや，

ると，実験環境においては大量に再配置が発生することが負荷やレスポンスタイムに応じた HTTP リクエスト単位

わかっている．

でのコンテナスケジューリング手法の実現が挙げられる．

一方で，再配置時に 9 リクエストだけ，500 系のエラーを返していたことが分かった．これは，(同時接続数-1) の参考文献

値であり，システム実装上の問題で，CoreAPI に対して同

[1]
[2]

時に再配置の依頼が要求された際に，1 つを除いてエラー

c 2018 Information Processing Society of Japan⃝

Amazon Web Services, https://aws.amazon.com/.
Amazon Web Services: Lambda, https://aws.amazon.

7

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

Vol.2018-CSEC-81 No.13
Vol.2018-IOT-41 No.13
2018/5/18

com/lambda/.
Amazon Web Services: Auto Scaling, https://aws.
amazon.com/autoscaling/.
[4]
Brown Mark R, FastCGI: A high-performance gateway
interface, Fifth International World Wide Web Conference. Vol. 6. 1996.
[5]
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.
[6]
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.
[7]
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.
[8]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.
[9]
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.
[10] 笠原 義晃, 松本 亮介, 近藤 宇智朗, 小田 知央, 嶋吉 隆
夫, 金子晃介, 岡村 耕二, 軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負荷
テスト環境の構築, 研究報告インターネットと運用技術（IOT）, Vol.2018-IOT-40(2), pp.1-8, 2018 年 3 月.
[11] 松本 亮介, Web サーバの高集積マルチテナントアーキ
テクチャに関する研究, 京都大学博士 (情報学) 学位論文,
2017.
[12] 松本 亮介, 小田 知央, 笠原 義晃, 嶋吉 隆夫, 金子晃介,
栗林 健太郎, 岡村 耕二, 精緻に解析可能な恒常性のあるメール基盤の設計, 研究報告インターネットと運用技術（IOT）, Vol.2018-IOT-40(17), pp.1-8, 2018 年 3 月.
[13] 松本亮介, 川原将司, 松岡輝夫, 大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086,
2013 年 3 月.
[14] 松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎,
FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用
技術シンポジウム 2017 論文集，2017，89-97（2017-11-30）,
2017 年 12 月.
[15] 松本亮介, 田平 康朗, 山下 和彦, 栗林 健太郎, 特徴量
抽出と変化点検出に基づく Web サーバの高集積マルチ
テナント方式におけるリソースの自律制御アーキテクチャ, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-36(26), 1-8, (2017-02-24).
[16] 松本亮介, 栗林 健太郎, 岡部寿男, リクエスト単位で仮想的にハードウェアリソースを分離する Web サーバのリ
ソース制御アーキテクチャ, 情報処理学会論文誌, Vol.59,
No.3, pp.1016-1025, 2018 年 3 月.
[17] 三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリ
ング, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-38, Vol.13, pp.1-8, 2017 年 6 月.
[3]

c 2018 Information Processing Society of Japan⃝

8