Vol.2019-IOT-44 No.27
2019/3/8

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

CRIU を利用した HTTP リクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法
松本 亮介1,a)

近藤 宇智朗2

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

Low-cost and High Performance Scheduling Method
for Reactive Relocation of Containers Each HTTP Request Using CRIU
Ryosuke Matsumoto1,a)1. はじめにインターネットを活用した企業や個人の働き方の多様化

Uchio Kondo2ド化も可能になってきている．そのため，コンテンツ拡散時であっても継続的に配信可能な Web サイトの構築は，個人用途であっても非常に重要になってきている．

に伴い，インターネット上で自らを表現する機会が増加し

Web コンテンツを継続的に配信するためには，オートスている．特に個人にとっては，Twitter や Facebook を活ケーリングのような負荷対策と，冗長構成による可用性の用して，自身が作成したコンテンツを拡散させることによ担保が重要である．一般的に，個人が Web コンテンツをり，効率よくコンテンツへの訪問数を増やすことができる

配信するためには，Web ホスティングサービスやクラウようになった．その結果，コンテンツの内容の品質が高け

ドサービスなどが利用される [8]．特に，個人の利用を想れば，さらに拡散され，コンテンツに紐づく個人のブラン定した場合，単一の物理サーバに高集積にユーザ領域を収容するような低価格 Web ホスティングサービスが利用さ

1

2

a)

さくらインターネット株式会社 さくらインターネット研究所
SAKURA Research Center, SAKURA Internet Inc.,
Akasaka, Chuo-ku, Fukuoka 810-0042 Japan
GMO ペパボ株式会社
GMO Pepabo, Inc., Tenjin, Chuo ku, Fukuoka 810-0001
Japan
r-matsumoto@sakura.ad.jpⓒ 2019 Information Processing Society of Japanれる．そのような低価格ホスティングサービスでは，利用者の Web コンテンツが特定の Web サーバに紐づくため，
ユーザ領域単位で突発的なアクセス集中に対して負荷分散することが難しい．クラウドサービスの場合は，利用者が1Vol.2019-IOT-44 No.27
2019/3/8

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

アクセス集中に耐えうるオートスケーリング [5] の仕組み

ビスを継続させる，HTTP リクエスト単位でのインスタを作る必要があったり，各サービス・プロバイダが提供しンスのスケジューリング手法を提案する．提案手法では，ているオートスケーリングの機能 [1] を使う必要がある．

FastContainer の状態変化の高速性に基づいて，インスタ

しかし，クラウドサービスに関する専門的な知識を有さなンスが頻繁に収容サーバを変更されてもサービスに影響がい個人が，費用を最低限に抑えつつ，突発的なアクセス集

ないことを利用する．それによって，プロキシサーバから中を予測的かつ安定的に対応することは依然として困難で収容サーバに 1 個の ICMP あるいは TCP パケットで応答ある．

速度を計測し，少ないパケット数と短いタイムアウトで収可用性の面では，Web ホスティングサービスの方式も

容サーバの反応時間を計測できる．．そのことで，HTTP

クラウドサービスも，仮想的に構築されたサーバ環境であリクエスト単位でのインスタンススケジューリングを実るインスタンスを複数のハードウェア上に起動させること現する．さらに，高速にインスタンスを再配置するためにより，特定のハードウェアに障害が置きてもサービスをに，Web サーバソフトウェア自体を拡張することなく Web

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

サーバプロセス起動完了直後にフックする処理を入れるこタンスが必要であることから，インスタンスの利用コストとでプロセスイメージを作成しておくことにより，高速にが増加する．さらに，可用性のためのインスタンスをコスWeb サーバプロセスをそのイメージから起動させる．

トの兼ね合いから負荷分散用途に転用してしまうことによ

本論文の構成を述べる．2 章では，Web ホスティング

り，収容サーバが停止した際に縮退状態のインスタンス数

サービスやクラウドサービスにおける可用性の担保のためでサービスを提供することになり，場合によってはリソーの取り組みとその課題について述べる．3 章では，2 章でス不足に陥る．

述べたインスタンスの再配置の課題を解決するための提我々はアクセス数や負荷に応じて反応的かつ高速にリ

案手法のアーキテクチャおよび実装を述べる．4 章では，

ソースをインスタンス*1 再割当てすることで，サービス利HTTP リクエスト単位でのインスタンススケジューリング

用者や事業者に手間を強いることなく突発的なアクセス集

手法の評価を行い，5 章でまとめとする．

中に耐えうる FastContainer アーキテクチャ [13] を提案した．一方，可用性の面では，依然として単一のインスタン

2. Web サービス基盤の可用性

スの場合，そのインスタンスが収容されている物理サーバ

Web サイトが収容されている物理サーバに障害があったが正常に稼働していることが前提であり，収容サーバが停場合に，いかにサービスを継続するかといった可用性の観止すると，手動によるインスタンスの再配置が必要であっ点でシステムを構築する必要がある．本章では，相互に関た．そのため，障害時に HTTP タイムアウトを生じさせ連の深い負荷分散と可用性の観点から，Web ホスティング

ない程度の可用性を担保するには，従来手法と同様にインサービスやクラウドサービスにおける関連研究と課題につスタンスを複数の収容サーバに起動できるようにしておく

いて整理する．

必要があり，利用者にとっては利用コストの増加に繋がっ

本論文における可用性とは，インスタンスの収容サーバていた．また，新たなインスタンスを新規で再配置する場が停止しても，クライアントからインスタンスに対するリ合は，インスタンス起動時の Web サーバプロセスの起動

クエストが HTTP タイムアウトせずに，オンラインでサー

時間がオーバーヘッドとなってレスポンスが一時的に遅く

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

なり，ユーザ体験を損なう課題があった [10]．
プロセスの起動時間を高速化するために，CRIU[2] と呼2.1 Web ホスティングサービス

ばれる Linux プロセスの Checkpoint/Restore 技術によっ

Web ホスティングサービスとは，複数のホストで物理てプロセスをイメージ化することにより，高速にプロセス

サーバのリソースを共有し，それぞれの管理者のドメインにの状態を復帰させる手法がある．しかし，Web サーバが起

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

動してからリクエストを処理している状態のプロセスをイ

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

メージ化すると，起動後のサーバプロセスの状態やコンテによって識別され，対応するコンテンツを配信する機能をンツの状態等を保持してしまうため，実用上扱いにくい．

ホストと呼ぶ．

本研究では，HTTP リクエスト処理時において，単一

一般的に，個人が Web コンテンツを配信するためには，のインスタンスであっても，収容サーバの状態に応じて，Web ホスティングサービスやクラウドサービスなどが利用

自動的にインスタンスを別の収容サーバに再配置し，サーされる [8]．特に，個人の利用を想定した場合，仮想ホスト方式を利用して，単一の物理サーバに高集積にユーザ領域*1

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

ⓒ 2019 Information Processing Society of Japanを収容するような低価格 Web ホスティングサービスが利用される [11]．仮想ホスト方式では複数のホストを Apache

httpd のような単一のサーバプロセス群で処理するため，

2Vol.2019-IOT-44 No.27
2019/3/8

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

リクエストは Web サーバプロセスを共有して処理される．

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

そのため，ホスト単位で使用するリソースを適切に制御し程度想定される量の仮想マシンを予測的に起動させておくたり，その原因を迅速に調査することが困難である [14]．

ことによって対処する手法がある [15]．しかし，本手法はWeb ホスティングサービスでは，サービス利用者の Web

突発的なアクセスに対するスケーリングを対象としておらコンテンツは特定の Web サーバに収容され，Web サーバ

ず，予測の精度を保つための各種パラメータの選定に関すと Web コンテンツが紐づくため，負荷に応じたオートス

る課題もある．また，可用性を担保することは想定されてケーリング*2 は，データの整合性の面と前述したホスト単

いない．

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

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

Web ホスティングサービスにおける負荷分散と可用性をプロバイダの AWS は，プロバイダ指定の記法によってア

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

プリケーションを実装すれば，自動的にコンピュータリにまとめた上で，仮想ホスト方式を採用した複数台の Web

ソースを決定し，可用性を担保しながらも高負荷時には自サーバで負荷分散と可用性を担保する手法 [12] がある．し動的にプロバイダ側でオートスケーリングする機能 [1] をかし，ホストの収容サーバを複数台配置して全ホストを複提供している．しかし，前提としてプログラミングができ数の物理サーバに配置することが前提となる手法であるたるエンジニアを対象としており，一般的な OSS として公め，ホスト単位でのスケーリングや可用性の担保は対応で開されている Web アプリケーションを利用できないこと

きず，コストも高くなる．また，負荷に応じて，ホスト単が多く，個人が Web コンテンツを配信する用途において

位での即時性の高いスケールアップ型の負荷対応もできは使用上の制限が大きい．

ない．

2.3 FastContainer アーキテクチャ
2.2 クラウドサービス

松本らは，個人が Web コンテンツを配信する用途においクラウドコンピューティング [7] とは，ネットワークやて，Web ホスティングサービスやクラウドサービスにおけ

サーバといったコンピュータリソースのプールから必要る突発的にアクセス集中の対応やオートスケーリングの課な時に必要な量だけオンデマンドに利用可能とするコン

題を解決するために，FastContainer アーキテクチャを提案

ピューティングモデルである．クラウドサービスはクラウしている [13]．FastContainer は，Web ホスティングサー

ドコンピューティングを各種サービスとして提供するサービスを利用できる程度の知識を持った個人が，WordPress

ビスである．

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

クラウドサービスでは，Web コンテンツを配置するだけすることを前提にしている．そのような個人のサービス利

でなく，Web サーバソフトウェアやデータベースをサービ用者が負荷分散のシステム構築やライブラリの運用・管理

ス利用者が自ら構築する必要がある．そのため，負荷分散を極力必要とせず，HTTP リクエスト単位でインスタンスのためのシステム設計をホスト単位で個別に行うことがでの状態を決定し，迅速にユーザ領域を複数の物理サーバにきる点において自由度は高いが，前提として専門的な知識展開可能で，実行環境の変化に素早く適応できる恒常性をが必要となる．

持つシステムアーキテクチャである．

クラウドサービスで可用性を担保するためには，複数のFastContainer アーキテクチャでは，インスタンスとしインスタンスを複数の収容サーバにホットスタンバイ状態て，仮想マシンではなく Linux コンテナ [4] を利用する．

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

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

合には，ホットスタンバイ状態のインスタンスにリクエス

で仮想的に OS 環境を隔離する仮想化技術のひとつである．

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

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

時に，新規でインスタンスを立ち上げ直す処理を省略し，ネルを含む起動処理と比べて，新しくプロセスを起動させ継続的にサービスを提供し続けることが可能となる．しかる程度の処理で起動が可能であるため，起動時間が短時間し，複数台のインスタンスが必要であることに起因して，で済むという特徴がある．

必要なハードウェアコストが増加する．また，そのような

FastContainer アーキテクチャでは，コンテナが仮想マ

ハードウェアコストを限られた予算の中で活用するため

シンと比較して速く起動できる点と，FastCGI[3] を参考に，に，ホットスタンバイ状態のインスタンスを負荷分散に利物理サーバへの収容効率を高めつつ性能を担保するアーキ

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

テクチャを組み合わせる．さらに，HTTP リクエスト毎に状態のインスタンスでサービス提供することになり，場合

負荷状態やアクセス数に応じて，Web アプリケーションコ

によってはリソース不足に陥る．

ンテナの起動処理，起動継続時間，コンテナの起動数およびリソース割り当てをリアクティブに決定する．一定時間*2

自動的にハードウェアリソースを追加し負荷分散を実現する機能ⓒ 2019 Information Processing Society of Japan

起動することにより，一度コンテナが起動してしまえば，

3Vol.2019-IOT-44 No.27
2019/3/8

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

起動時間に影響なくレスポンスを送信できる．この特性によって，ホストをコンテナ単位で個別に起動しながらも，
リクエストの無いコンテナは自然に停止するため，高集積に収容できる．

FastContainer は，コンテナの起動が一般的に高速であること，リクエストを契機としたリアクティブな起動処理であることにより，突発的な負荷に対しても迅速にリクエ
スト単位でオートスケーリングが可能となる．スケール
アップについても，コンテナのリソース管理が cgroup に
よってプロセス単位で制御されており，cgroup の特徴を利
図 1用して，プロセスが処理中であっても CPU 使用時間など

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

Fig. 1 The Flow of Contaienr Scheduling.

の割り当てを即時変更できる．
しかし，このアーキテクチャはコンテナが収容される物
理サーバが適切に稼働していることが前提であり，収容ムアウトで収容サーバの反応時間を計測できる．実装にサーバが停止すると，手動によるコンテナ再配置が必要では，mruby-fast-remote-check[9] を採用した．そのことで，あった．そのため，ホスティングサービスやクラウドサー

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

ビスと同様に，収容サーバが停止した際にサービスを停止現する．

させることなく継続的にレスポンスを返すためには，複数

さらに，コンテナ再配置後の最初のリクエストに対するの収容サーバにそれぞれ複数インスタンスを配置する必

起動時間を速くするために，予めインスタンスの起動処理要があり，利用者にとってのサービス利用コストが増加す

完了直後のプロセスをイメージ化 (Checkpoint) しておく．

る．また，単一のコンテナで起動している場合は，その収起動時は，そのイメージから起動する (Restore) ことによ

容サーバが停止すると，手動で再配置が行われるまでにはり，通常起動よりも高速化を実現する．

同様にサービスも停止してしまう．

3. 提案手法

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

個人の利用者が WordPress のような一般的な Web コンのフローでは簡単のため，ホストの監視に ICMP を使う．

テンツを配信する仮想化基盤において，収容効率を高めつ

Host OS が障害を起こしていない正常時のフローについつ，アクセス集中による負荷やインスタンスの収容サーバて述べる．図 1 における Client から Container に対しての障害に対する可用性を担保可能な基盤にするためには，

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

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

に一旦集約される．Web Proxy にリクエストが到達した( 1 ) インスタンスで WordPress のような一般的な Web ア

段階で，Container の収容情報や構成管理情報を保持す

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

る CMDB API に情報を問い合せ，Container の収容サーバや IP アドレス/ポート情報を得る．Web Proxy は収容サーバである Host OS 上に存在する Container にリクエ

( 3 ) インスタンスの再配置の実行時であっても数秒の遅延

ストを転送する前に，その Host OS が稼働しているかを

で HTTP タイムアウトすることなくオンラインでレICMP パケットによって確認する．Web Proxy は ICMP のスポンスを返せる

疎通を確認した後に，いったん Host OS 上に稼働している

本研究では，上述した 3 つの要件を満たすために Fast-

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

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

Dispatcher はコンテナが稼働していればそのまま HTTPを再配置する仮想化基盤の高速なスケジューリング手法をリクエストを転送し，稼働していなければ，再度 CMDB

提案する．提案手法は，HTTP リクエスト処理時においAPI 情報に基いてコンテナを起動させてからリクエストをて，収容サーバ，および，その経路までの状態に応じて，転送する．

自動的にコンテナを収容する物理サーバを決定し，サービ

次に，コンテナが収容されている Host OS が突発的なスを継続させる．FastContainer の状態変化の高速性に基障害で停止した場合のフローについて述べる．Client からづいて，コンテナが誤検知によって再配置されてもサーCMDB API を介して Web Proxy に到達し，転送先の収容ビスが停止しないことを利用する．それによって，プロキ

サーバに ICMP のチェックを行う．その際に，収容サーバ

シサーバから収容サーバに ICMP あるいは SO LINGER

がダウンしている場合は，ICMP のチェックタイムアウト

オプションを用いた TCP で接続を試みた上で，短いタイを経て，Web Proxy が収容サーバのダウンを認識する．そⓒ 2019 Information Processing Society of Japan4

Vol.2019-IOT-44 No.27
2019/3/8

情報処理学会研究報告
IPSJ SIG Technical Reportの後，Web Proxy は再度 CMDB API に接続を行い，コン

表 1 実験環境

テナの収容情報を他に起動している Host OS の情報に基いTable 1 Experimental Environment.

て再生成する．その収容情報に基いて，再度起動中の Host

OS に ICMP チェックを行い，起動していることを確認し項目

Client仕様

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

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

CPUIntel Xeon E5-2650 2.20GHz 1coreにリクエストを転送する．この場合，収容サーバにはコン

Memory2GBytes

テナが起動していないため，Container Dispatcher によっComputeて該当コンテナを起動し，HTTP リクエストを転送する．
提案手法では，要件 (1) について，本手法は FastCon-

UserDB

コンテナの収容サーバ

CPU

Intel Xeon E5-2650 2.20GHz 8core

Memory51GBytes

コンテナのアプリケーションが利用する DB

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

CPUIntel Xeon E5-2650 2.20GHz 8core

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

Memory51GBytes

ナ上に WordPress のような Web アプリケーションが動作

UserProxy

可能であり，かつ，別の Host OS 上でも同様に動作可能である．さらに，要件 (2) について，上記のスケジューリン

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

Memory2GBytes

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

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

CPUIntel Xeon E5-2650 2.20GHz 1core

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

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

CMDB

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

トレージによってデータを Host OS 間で共有しているたCPUIntel Xeon E5-2650 2.20GHz 1core

め，データのコピーは発生しないことから，ICMP や TCP

Memory16GBytesのタイムアウトの時間と，コンテナの収容サーバ変更後のDataPool

コンテナ再配置にかかる時間の合計値をできるたけ短くす

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

Storage

NetApp FAS8200A

FlashPool

8.73 TB

れば良い．

ICMP や TCP のタイムアウト時間を短くするためには，にプロセスをイメージ化する研究がされている [16]．しかWeb Proxy と Host OS 間の通常の ICMP や TCP に必要し，任意のシステムコール実行前に自動で停止するといっとする時間にタイムアウト値をなるべく近くすることが必たことができておらず，手動で感覚的に初期化完了時を予要となる．同時に，一時的な遅延によって，障害と至らな想してイメージ化する方が速いといった実験結果になっていにも関わらずタイムアウトした場合に再配置が発生した

いる．

としても，サービス継続への影響を最小化できれば良い．

そこで，個々の Web サーバソフトウェアに機能拡張を

FastContainer のプロトタイプ実装と実験環境では，単一実装することなく，汎用的かつ自動でプロセスの Check-のコンテナを複数のコンテナにスケールアウトする場合

point/Restore を実現するために，Haconiwa[6] を利用すに，レスポンスタイムが短縮されるまでにかかる時間が実

る．Haconiwa は近藤らが開発しているコンテナランタイ

験から数秒程度とわかっている [13]．スケールアウト型のムであり，コンテナ上で起動するプロセスの完了直後をスケーリングは，コンテナを追加で起動させる処理であり，フックして任意の処理を実行することができる．その機能コンテナの再配置の起動にかかる処理と同一の処理と言えを利用して，Haconiwa でコンテナ上にプロセスを起動さる．そのため，再配置に必要となる時間が論文の環境ではせ，起動完了直後に Haconiwa プロセスから起動処理中の数秒程度で完了することが見込める．

サーバプロセスをイメージ化する．

3.2 コンテナ環境の起動高速化

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

理完了直前の状態でプロセスの Checkpoint を行い，プロセスをイメージ化する．その場合，複数の Web サーバソ

4. 実験

フトウェアに対して，個々に CIRU を組み込むことにより本手法の有効性を確認するために，図 2 に示す FastCon-

対応していくことは，多数のサーバソフトウェアの拡張がtainer を用いた実験環境を構築し，コンテナのスケジューリ必要となり実装面で非効率である．

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

任意の GUI アプリケーションに対して，初期化時に実を示す．実験環境の各ロールの NIC と OS は全て，NIC は行されるシステムコールを監視しながら，初期化完了直前

1Gbps，OS は Ubuntu16.04，カーネルは 4.4.0-59-genericⓒ 2019 Information Processing Society of Japan5

Vol.2019-IOT-44 No.27
2019/3/8

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

図 2

FastContainer のシステム構成例

図 4 Ruby on Rails のベンチマーク

Fig. 2 Example of FastContainer System.

Fig. 4 Benchmark of Ruby on Rails.

図 5 Django のベンチマーク

図 3 WordPress のベンチマーク

Fig. 5 Benchmark of Django.

Fig. 3 Benchmark of WordPress.

を利用したものを採用した*3 ．Ruby on Rails は，gem をを利用した．本実験では，Comupte ノードを 2 台利用し事前コンパイルしておくことにより起動を高速化させるて，ノードの障害をエミュレートした．コンテナのデータ

bootsnap という機能があるため，CRIU を使わない場合

は DataPool 上に保存し，Compute から DataPool に対しは，bootsnap を使った場合と使わない場合も計測した．まて NFSv3 でマウントした．

た，CRIU によるイメージ化時の Rails のプロセス数は 2，

本実験では，Checkpoint/Restore によるサーバプロセスの起動の高速化手法を組み込んだ場合と組み込まない場合

スレッド数は 14，単一のプロセスのメモリサイズ (RSS) は

89MBytes であった．

とで，Wordpress，Ruby on Rails，Django それぞれのレ

Django は，Python 3.7.1，Django 2.1.4，gunicorn 19.9.0

スポンスタイムを計測した．Wordpress は，Web サーバにを利用し，Rails と同様に，現実的な規模で DB を利用しは Apache 2.4.18，PHP 7.3.0，Wordpress 5.0.3 を利用した Web アプリケーションを採用した*4 ．また，CRIU によた．PHP は Opcache 機能を有効にした．また，CRIU にるイメージ化時の Django のプロセス数は 2，スレッド数

よるイメージ化時の Apache のプロセス数は 3，スレッド

は 2，単一のプロセスのメモリサイズ (RSS) は 33MBytes

数 3，単一のプロセスのメモリサイズ (RSS) は 35MBytes

であった．

であった．

Ruby on Rails は，Ruby 2.5.1，Rails 5.2.1，Puma 3.12.0
を利用し，起動するアプリケーションは現実的な規模（個人/グループ内での利用のアプリケーション程度）で DBⓒ 2019 Information Processing Society of Japan

全ての Web アプリケーションは Haconiwa 0.10.0 で作成したコンテナ上で起動した．データベースは UserDB*3*4

https://github.com/everyleaf/el-training
https://mclolipop.zendesk.com/hc/ja/articles/360011824713

6Vol.2019-IOT-44 No.27
2019/3/8

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

上の MySQL 5.7.24 を利用した．コンテナの割り当てメ

図 4 に，Ruby on Rails に対するベンチマーク結果を示

モリは 1024MB であり，CPU は 1 コアを割り当てた．コ

す．Ruby on Rails は，実験環境においては平均的に 20ms

ンテナに対するベンチマークでは，ab コマンドで，同時前後のレスポンスタイムであった．CRIU も bootsnap も

接続数 1，総接続数 3000 で計測を行い，数十秒たった時

使わない場合は，38 秒の時点で再配置の処理が発生した際

点で手動でネットワークを切断し，収容ホストの再配置に，8575ms のレスポンスタイムを要した．TCP のタイムを発生させた．コンテナの収容サーバに対する TCP 監視

アウト値が 100ms であることから，コンテナの再配置かには mruby-fast-remote-check を利用して SO LINGER オ

ら Rails の起動とレスポンス生成までには概ね 8475ms でプション付きの TCP パケットを送信し，タイムアウトは実現できている．そのことから，コンテナの再配置とコン

100ms とした．

テナ起動に要する時間は，Rails のレスポンスタイム 70ms

ベンチマーク測定中に，一定時間経過後に Compute 上を除くと，8455ms となる．

で ipatables コマンドにより UserProxy からのパケットを一方，CRIU のイメージ化を使った場合は，35 秒の時点

drop し，別の Compute にコンテナが再配置されるようにしで再配置の処理が動作した際には，1544ms の処理時間でた．今回採用したコンテナランタイムの Haconiwa 0.10.0

あった．TCP のタイムアウト値が 100ms であることから，の Checkpoint/Restore 機能*5 を利用して，各 Web アプリ

コンテナの再配置から Rails の起動とレスポンス生成まで

ケーションをイメージ化しておく．各 Web アプリケーショには概ね 1444ms で実現できている．そのことから，コンンの起動が完了し、コンテナ内部のポートをリッスンしテナの再配置とコンテナ起動に要する時間は，レスポンス

た状態でイメージ化している。したがって、通常起動時は

タイム 20ms を除くと，1424ms となる．これらの結果か

ワーカーが全て起動し切っていなくともレスポンスを返す

ら，CRIU を使ったイメージ化を組み合わせることにより，ため、CRIU からの起動では若干の条件の違いがある。

7011ms 高速に起動できた．同様に，bootsnap と比較した

ベンチマークでは，秒間のレスポンスタイムの平均値を計算し，時系列データとしてベンチマークが完了するまでのレスポンスタイムの変化を計測した．

場合は，同様の計算式から，2734ms 高速に起動できた．
図 5 に，Django に対するベンチマーク結果を示す．

Django は，実験環境においては平均的に 15ms 前後のレス

図 3 に，WordPress に対するベンチマーク結果を示す．

ポンスタイムであった．42 秒の時点で再配置の処理が動作

WordPress は，実験環境においては平均的に 70ms 前後のした際に，6030ms のレスポンスタイムを要した．Word-

レスポンスタイムであった．45 秒の時点で再配置の処理

press や Rails のレスポンスタイムと同様の計算式から，コが動作した際には，3037ms のレスポンスタイムを要した．

ンテナの再配置とコンテナ，および，Web アプリケーショ

TCP のタイムアウト値が 100ms であることから，コンテン起動に要する時間は，5915ms となる．同様に，CRIU

ナの再配置から Apache の起動とレスポンス生成までにはを使った場合は，コンテナの再配置実行時に 2249ms のレ

概ね 2937ms で実現できている．そのことから，コンテナ

スポンスタイムになっている．つまり，CRIU を使ったイの再配置とコンテナ起動に要する時間は，WordPress のレメージ化を組み合わせることにより，3781ms 高速に再配

スポンスタイム 70ms を除くと，2867ms となる．

置とレスポンス送信が可能になる．

一方，CRIU のイメージ化を使った場合の Wordpress にUserProxy から Compute にリクエスト転送が送信され対するベンチマークは，ベンチマークが 55 秒経過したときて，Compute 上のコンテナから UserProxy にレスポンスに，手動でネットワークを切断した．WordPress は，CRIU

データが送信される前の状態で Compute が停止してしまっを使わない場合の実験と同様に，平均的に 70ms 前後のレた場合は，そのレスポンスを UserProxy が正しく受信できスポンスタイムであった．55 秒の時点で再配置の処理が動ないため，レスポンスを一部取りこぼすこともありえる．

作した際には，2163ms の処理時間を要した．TCP のタイ

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

ムアウト値が 100ms であることから，コンテナの再配置かぞれ分散してインスタンスを配置して可用性を担保する

ら Apache の起動とレスポンス生成までには概ね 2063ms

方式でも原理的に生じるため，本手法の特徴的な問題ではで実現できている．そのことから，コンテナの再配置とない．

コンテナ起動に要する時間は，WordPress のレスポンス

本実験結果から，単一のコンテナインスタンスを単一のタイム 70ms を除くと，1993ms となる．これらの結果か収容サーバに起動させておきながらも，その収容サーバのら，CRIU を使ったイメージ化を組み合わせることにより，停止時には，プロセスのイメージ化を組み合わせることに874ms 高速に起動できた．高速に起動できることから，収より，迅速に再配置のスケジューリングが行えていること

容サーバ障害時にも，874ms 速くレスポンスを返すことががわかった．また，実験環境程度のハードウェアスペック

できる．

で，2 秒程度であれば，実用上は HTTP タイムアウトする
ことなくレスポンスを返せると見込める．Ruby on Rails*5

https://github.com/haconiwa/haconiwa/pull/188ⓒ 2019 Information Processing Society of Japanや Django のように，起動してしまえばレスポンスは速い

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

が，起動に時間がかかるような Web アプリケーションに対して，大きな効果が見込めることもわかった．一方で，コンテナの再配置が頻発する場合には，提供サービスレベ
ルにも依存する問題でもあるため，再配置の頻度について
はサービスに合わせた検討が必要である．

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

Vol.2019-IOT-44 No.27
2019/3/8

Infrastructure as a Service and Web Hosting Cloud
Providers,10th IEEE/ACM International Conference on
Grid Computing, pp. 17-25, October 2009.
[9]
RyosukeMatsumoto,mruby-fast-remote-check,
https://github.com/matsumotory/mruby-fastremote-check.
[10] 笠原 義晃, 松本 亮介, 近藤 宇智朗, 小田 知央, 嶋吉 隆
夫, 金子晃介, 岡村 耕二, 軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負荷
テスト環境の構築, 研究報告インターネットと運用技術（IOT）, Vol.2018-IOT-40(2), pp.1-8, 2018 年 3 月.
[11] 松本 亮介, Web サーバの高集積マルチテナントアーキ
テクチャに関する研究, 京都大学博士 (情報学) 学位論文,
2017.
[12] 松本亮介, 川原将司, 松岡輝夫, 大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086,
2013 年 3 月.
[13] 松本亮介, 近藤宇智朗, 三宅悠介, 力武健次, 栗林健太郎,
FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用
技術シンポジウム 2017 論文集，2017，89-97（2017-11-30）,
2017 年 12 月.
[14] 松本亮介, 栗林 健太郎, 岡部寿男, リクエスト単位で仮想的にハードウェアリソースを分離する Web サーバのリ
ソース制御アーキテクチャ, 情報処理学会論文誌, Vol.59,
No.3, pp.1016-1025, 2018 年 3 月.
[15] 三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリ
ング, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-38, Vol.13, pp.1-8, 2017 年 6 月.
[16] 阿部 敏和, 中山 泰一, プロセスの保存と復元による GUI
アプリケーションの起動高速化, 情報処理学会全国大会
講演論文集, 第 72 回アーキテクチャ, pp95-96, 2010 年 3月．

タイムに応じた HTTP リクエスト単位でのより適応的なコンテナスケジューリング手法の実現が挙げられる．
参考文献
[1]
[2]
[3]

[4]

[5]

[6]
[7]

[8]

Amazon Web Services: Lambda, https://aws.amazon.
com/lambda/.
CRIU – A project to implement checkpoint/restore functionality for Linux, https://criu.org/.
Brown Mark R, FastCGI: A high-performance gateway
interface, Fifth International World Wide Web Conference. Vol. 6. 1996.
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.
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.
Haconiwa - the mruby on container, https://haconiwa.
mruby.org/.
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.
Prodan R, Ostermann S, A Survey and Taxonomy ofⓒ 2019 Information Processing Society of Japan

8