日本ソフトウェア科学会第 35 回大会 (2018 年度) 講演論文集

VM 内コンテナを用いたサービス単位のオートスケール機構
植木 康平

光来 健一

IaaS 型クラウドでは仮想マシン (VM) 内で動作するサービスの負荷に対応するために，オートスケールと呼ばれる機能が提供されている．オートスケールにより，VM の負荷が高まった時には自動的に VM の数を増やすスケール
アウト処理が行われる．しかし，1 つの VM で複数のサービスを動作させている場合，その中の 1 つのサービスに負荷が集中したとしても VM 全体がスケールアウトされる．その結果，新しく起動される VM においてスケールア
ウトが不要なサービスも動作するため，必要以上に大きな VM を用意しなければならず，スケールアウトを完了させるのにも時間がかかる．本稿では，VM 内の各サービスをコンテナを用いて動作させることにより，サービス単位
でのきめ細かいオートスケールを実現するシステム Ciel を提案する．Ciel では，VM 内コンテナに対して VM イ
ントロスペクションと呼ばれる技術を用いることで，各サービスのリソース使用量を VM の外部から正確に監視す
る．負荷の高いコンテナが見つかれば，そのコンテナが動作するのに必要十分な大きさの VM を新たに作成し，その VM ではスケールアウトする必要のあるコンテナだけを起動する．これにより，VM のコストとスケールアウトにかかる時間を最小限に抑えることができる．我々は Ciel を Xen と Docker を用いて実装し，有用性を確認する実験を行った．

に，新たに VM を起動することで負荷を分散させて1 はじめに

各 VM の負荷上昇を抑える手法である．多くのクラ

近年，Amazon AWS や Microsoft Azure をはじめ

ウドでは，VM の負荷に応じて自動的にスケールアとするクラウドサービスの利用が広まってきている．

ウトを行う機能を提供しており，この機能はオートス

その利用形態の一つである IaaS 型クラウドでは利用

ケールと呼ばれる．オートスケール機能は VM の負者に仮想マシン（VM）の提供を行う．VM には利用荷を監視し，負荷の上昇を検知した際にスケールアウ

者の用途に応じて搭載する OS やアプリケーションなトを行う．

どを自由にインストールすることが可能である．VM

しかし，1 つの VM 内で複数のサービスが動作しのメモリ量や仮想 CPU 数，ディスク容量などはあらている場合，その中の 1 つのサービスの負荷が高まっ

かじめ用意されたテンプレートの中から選択するこたとしても VM 全体がスケールアウトされる．そのとが多いが，リソースごとにきめ細かく設定できる

結果，必要以上に大きな VM を起動することになり，クラウドも存在する．利用料金は VM 単位で課金さコストが上昇する．また，不要なサービスの起動にもれ，大きな VM ほど単位時間あたりのコストがかか

リソースが消費されるため，スケールアウトの完了

る．一般的に，仮想 CPU の性能や個数，メモリ量，にも時間がかかる．本来，高負荷なサービスのみをス

ディスク容量に比例した料金体系となっている．

ケールアウトするべきであるが，複雑に絡み合ったクラウドでは VM 内で動作するサービスの負荷上

個々のプロセスやファイルがどのサービスで使用され昇に対応するために，スケールアウトと呼ばれる処理ているかをクラウド側から正確に把握するのは容易を行う．スケールアウトは VM の負荷が高まった際ではない．そのため，VM 外部から各サービスのリ

Kohei Ueki，Kenichi Kourai, 九州工業大学, Kyushu
Institute of Technology.

ソース使用量を監視するのも困難であり，VM 全体のリソース使用量やサービスへのリクエストを基に推スケールを実現するシステム Ciel を提案する．コンテナの中でサービスを実行することにより，各サー

処理能⼒↑
負荷↓
負荷

本稿では，VM 内の各サービスをコンテナを用いて実行することにより，サービス単位の柔軟なオート

このままだと閾値を超える可能性
負荷測するしかない．

時間

VM 1

スケールアウト

時間

VM 1

VM 2

ビスが使用しているリソースを容易に特定することができる．Ciel では VM イントロスペクション [6] を

図1

VM のオートスケール

用いて VM の外から VM 内コンテナを監視することで，各サービスのリソースの使用量を監視する．負荷40%程度に低下させることができる．一方，スケールの高いコンテナがあれば，そのコンテナが動作するのインはスケールアウトによって増加した VM の負荷に必要十分な VM を起動し，新たに起動した VM でが低くなった際に，コストを削減するためにいくつかはスケールアウトする必要のあるコンテナだけを起の VM を停止する手法である．例えば，2 つの VM

動する．

の CPU 使用率がそれぞれ 20%であれば，一方の VM

我々は Ciel を Xen 4.6.0 [3] と Docker 17.05.0-ceを停止させても VM の負荷は 40%程度に抑えられる．

[14] に実装した．VM 外部から VM のメモリ上にあ多くのクラウドでは，VM の負荷に応じてスケー

る Linux の cgroup の階層構造を解析し，コンテナのルアウトとスケールインを自動的に行うことが多く，

リソース使用量を取得できるようにした．このリソー

この機能はオートスケールと呼ばれる．オートスケー

ス監視機能は OS の仮想アドレスを VM の物理メモ

ル機能は VM の負荷を監視し，負荷の上昇を検知しリアドレスに変換する必要があるため，LLVM を用た際にはスケールアウトを行う．逆に，スケールア

いてプログラム変換を行う LLView [25] を使用した．

ウトによって増やした VM の負荷が低いことを検知

Ciel を用いてスケールアウトにかかる時間やスケーした際にはスケールインを行う．負荷上昇の検知は

ルアウト時のリソース消費量を測定し，従来システム

VM 全体のリソース使用量に基づいて行われ，VM のと比べて大幅に改善できることを確認した．
以下，2 章で従来のオートスケール手法とその問題点について述べる．3 章で VM 内コンテナを用いてCPU 使用率やメモリアクセス量，ディスクアクセス
量，接続クライアント数などの推移によるトレンド分
析が主流となっている．

オートスケールを行う Ciel を提案し，4 章でその実クラウドでは，1 つのサービスに対して 1 つの VM

装について述べる．5 章で Ciel の有用性を調べた実を割り当てることも多いが，複数のサービスを 1 つ験について述べる．6 章で関連研究に触れ，7 章でまの VM に集約することでリソースをより有効に活用とめと今後の課題について述べる．

し，コストを削減することができる．しかし，VM 内の特定のサービスに負荷が集中することによって VM

2 従来のオートスケールの負荷が高まった場合でも，VM 全体をスケールア

クラウドでは VM 内で動作するサービスの負荷にウトすることになる．そのため，必要以上に大きな対して柔軟に対応するために，スケールアウトおよ

VM を新たに作成して起動しなければならず，その分びスケールインと呼ばれる処理を行う．スケールアウ

だけ VM にかかるコストが上昇する．また，新しく

トは VM の負荷が高まった際に，図 1 のように新た起動した VM ではスケールアウトの必要がないサーに VM を起動することで負荷を分散させて VM の負

ビスも起動されるため，スケールアウトの完了にも荷の上昇を抑える手法である．例えば，Web サーバ

時間がかかる．これは VM 内の複数サービス間でリが動作している VM の CPU 使用率が 80%を超えた

ソース競合が引き起こされ，サービスの起動が遅くな時には，新しい VM を起動してリクエストを分散さるためである．

せることにより，それぞれの VM の CPU 使用率を

本来，VM の中で高負荷の原因となったサービスのリソース

VMイントロスペクション

時間

VM 1

VM

VM、コンテナの起動監視コンテナ A

コンテナ A

コンテナ Bサービス

オートスケーラ
コンテナ Bサービス

図2

オートスケーラ

コンテナ Aに負荷

コンテナ A

コンテナ C

コンテナ Cサービス

VM 2

ロードバランサ
サービス利⽤者

Ciel のシステム構成

みをスケールアウトすることが望ましい．しかし，複図3

Ciel におけるオートスケール

雑に絡み合ったプロセスやファイルなどがどのサービスによって使われているかを VM の外部から特定す

その際に，取得する OS データの仮想アドレスを VMるのは困難である．その上，サービスごとのリソースの物理メモリアドレスに変換して，VM のメモリに使用量の監視についても，VM 外部のクラウド側かアクセスする．また，VM の仮想ディスク上のファイ

らでは各サービスに送られたリクエストを基に推測

ルシステムを解析することで，VM 内で使われていするしかなく，正確な監視，計測は困難である．VM

るファイルにアクセスすることもできる．

内部で監視を行う手法も考えられるが，監視ソフト

図 3 に Ciel におけるオートスケールの様子を示す．

ウェアをクラウドの利用者にインストールさせる負担

Ciel では，VM 内コンテナを用いてきめ細かいオーが大きく，監視データを外部に送信する必要もある．

トスケールを行うオートスケーラが動作する．Ciel のオートスケーラは VM 外部から VM イントロスペク

3 Ciel

ションを用いて VM 内の各コンテナのリソース使用

本稿では，VM 内コンテナを用いて各サービスを実量を監視する．負荷の高いコンテナが見つかれば，そ行することにより，サービス単位でのより柔軟なオーのコンテナが動作するのに必要十分な大きさの VM

トスケールを行うシステム Ciel を提案する．図 2 にを新たに起動する．新しい VM ではスケールアウト

Ciel のシステム構成を示す．コンテナは計算機全体をを行う必要のあるコンテナだけを起動し，元の VM仮想化する VM とは異なり，OS が提供する仮想実行で動作していたそれ以外のコンテナは起動しない．ス

環境である．Ciel では VM 内のサービスごとにコンケールアウト後は，ロードバランサが各 VM 内のコ

テナを起動し，コンテナ内で 1 つのサービスだけをンテナにリクエストを分散させる．

動作させる．これにより各サービスが使用するプロセ

このようにサービス単位でのスケールアウトを行う

スやファイルなどが分離されるため，サービスごとのことにより，Ciel では新たに起動する VM への課金

リソース使用量を正確に計測することが容易になる．

を最小限に抑えることができる．VM には動作させる

VM 内コンテナのリソース使用量を VM 外部からコンテナが使用するリソースだけを割り当てればよ監視するために，Ciel は VM イントロスペクション

く，VM への課金は基本的に割り当てられたリソース[6] と呼ばれる技術を用いる．VM イントロスペクショ

量に比例して決まるためである．また，スケールアウ

ンは VM の外部から VM 内部の情報を取得する手法

トする必要のないサービスを起動しないため，スケーである．例えば，VM のメモリを解析することで OS

ルアウトにかかる時間を必要最小限に抑えることがでが管理している CPU 使用時間，メモリ使用量，ディ

きる．迅速に起動する必要のあるサービスの起動処理

スクアクセス量などの情報を取得することができる．

が不要なサービスの起動処理と競合することもない．

サービスの負荷の監視はまず VM 全体で行い，VMの負荷が高い場合に VM 内で動作している各コンテ

Dom 0

VM
コンテナ

ナに対して行う．一つの理由は，VM のリソース監サービス

視に比べて VM 内コンテナのリソース監視のほうが，VM イントロスペクションを必要とすることからオーバヘッドが大きいためである．もう一つの理由は，各コンテナの負荷が高くない場合でも VM 全体の負荷

コンテナ

オートスケーラ

Docker Engine

Linux OSは高い場合があるためである．例えば，VM 内でコンサービス

Linux OSXen Hypervisor

テナが 3 つ動作している場合，それぞれの CPU 使用

Hardware

率が 30%だとしても VM 全体の CPU 使用率は 90%となる．Ciel のオートスケーラは VM の負荷上昇を

図4

各ホストのシステム構成

検知すると，各コンテナのリソース使用量から負荷の原因となっているコンテナを特定してスケールアウト

4. 1 リソース使用量の監視を行う．上の例のように，どのコンテナの負荷もあまDocker では Linux の cgroup を用いてリソース制

り高くない場合には，リソース使用量の変化などから御を行っているため，Ciel は VM イントロスペクショ

スケールアウトさせるのが最も効果的だと考えられンを用いて VM 内の cgroup の階層構造を解析するるコンテナを選択する．

ことにより情報を取得する．まず，監視するリソー

最近は VM の代わりにコンテナを提供するクラウスに対応する cgroup のサブシステムを探す．例えドも増えており，VM を用いずにコンテナのみを用い

ば，CPU アカウンティングサブシステム，メモリサてサービスを提供する方法も考えられる．各コンテ

ブシステム，ブロック I/O サブシステムなどがある．

ナで 1 つのサービスのみを動作させれば，クラウド

次に，各 Docker コンテナの情報が格納されている側から各サービスのリソース使用量を容易に取得すdocker グループを探す．コンテナはコンテナ ID で識ることができ，サービス単位のスケールアウトを行別する．VM の仮想ディスクの中に格納されているコ

うことができる．しかし，VM をコンテナと併用しンテナのコンフィグを解析することで，コンテナ ID

たほうがよい理由が少なくとも 3 つ存在する．第一とコンテナ名を対応づけることもできる．そして，コに，VM のほうがセキュリティがより強固である．第ンテナごとに cgroup のサブシステム情報を取得する．

二に，VM 間ではリソース分離がより厳密に行える．

CPU アカウンティング（cpuacct）サブシステムの第三に，現状ではコンテナのマイグレーションを安場合，サブシステム情報の中の CPU アカウンティン

定して行うことができない．これらの理由から，Ciel

グ情報を用いて CPU ごとの使用時間の合計をナノ秒では従来の VM を用いるクラウドを想定し，VM 内単位で取得する．この情報は VM 内コンテナの中ででコンテナを活用する．

は，cgroup ファイルシステムの cpuacct.usage 疑似
ファイルから取得することができる．定期的にコンテ

4 実装

ナの CPU 使用時間を取得してその増分を計算するこ

図 4 に Ciel における各ホストのシステム構成を示とにより，CPU 使用率を算出する．

す．現在の実装では，Xen [3] を用いて VM を動作さ

メモリ（memory）サブシステムの場合，サブシス

せ，VM の中で Docker [14] を用いてコンテナを動作

テム情報の中のメモリ cgroup の情報を用いて CPUさせる．オートスケーラはドメイン 0 と呼ばれる特権

ごとのメモリ統計情報を取得する．取得できる情報

VM で動作させる．仮想化ソフトウェアとして KVM

は，RSS と呼ばれる匿名メモリとスワップキャッシュ[10] などを用いたり，コンテナソフトウェアとしての合計のバイト数と，ページキャッシュのバイト数でLXD [5] などを用いたりすることも可能である．

ある．匿名メモリはコンテナ内のプロセスが使用しているメモリであり，スワップキャッシュはスワップア

レスをマッピング先のメモリアドレスに変換するようウトされた後，まだメモリ上に保持されているメモリにした．

である．ページキャッシュはプロセスがファイルを読み書きする際に OS 内に確保されるメモリである．こ

例えば，リソース監視機能をコンパイルして次のよ
うな中間表現が得られたとする．

れらの情報は VM 内コンテナの中では，cgroup ファ
イルシステムの memory.stat 疑似ファイルから取得%1 = load i64, i64* %jiffies

することができる．

%2 = udiv i64 %1, 250

ブロック I/O（blkio）サブシステムの場合，サブシステム情報の中のブロック cgroup の情報を用いてこの中間表現は Linux カーネル内の 64 ビットのグ

CPU ごとのディスクアクセス量をバイト単位で取得

ローバル変数 jiﬃes の値をローカル変数%1 に読み込する．この情報は VM 内コンテナの中では，cgroup

み，250 で割って%2 に格納している．LLView を用

ファイルシステムの blkio.throttle.io service bytes 疑いるとこの中間表現は次のように変換される．

似ファイルから取得することができる．定期的にコンテナのディスクアクセス量を取得してその増分を計算%1 = bitcast i64* %jiffies

することにより，消費ディスク帯域を算出する．

%2 = call i8* @g_map(i8* %1)

一方，VM のリソース使用量は libvirt API を用い%3 = bitcast

to i8*

i8* %2 to i64*て取得する．定期的に VM の CPU 使用時間をナノ秒%4 = load i64, i64* %3

単位で取得してその増分を計算することにより，VM%5 = udiv i64 %4, 250の CPU 使用率を算出する．
この中間表現では jiﬃes のアドレスを 8 ビット整数の4. 2 リソース監視機能の開発

ポインタにキャストして%1 に格納し，それを引数とオートスケーラの中でコンテナのリソース使用量をして g map 関数を呼び出してメモリマッピングおよ

監視する機能は，VM 内で動作している Linux カー

びアドレス変換を実行する．g map 関数から返されネルのソースコードをできるだけ利用して作成した．

たアドレスを元の 64 ビット整数のポインタにキャス

ヘッダファイルはそのまま利用し，cgroup の情報をトし，そのアドレスにあるデータを%4 にロードする．

取得するコードは必要な部分だけを一部修正して利LLView はアセンブリ言語で書かれたプログラムの用した．しかし，そのままでは VM 内の情報を取得

変換に対応していないため，等価な C プログラムにすることができないため，VM のメモリにアクセス置き換える必要があった．例えば，ビットマップの指して情報を取得するように変更する必要がある．この定したビットの値を調べる test bit 関数などである．

ような変更を利用したソースコード全体について行
うのは非常に大変な作業になる．

4. 3 VM のスケールアウト

そこで，Ciel では LLView [25] を用いてコンパイル

Ciel で VM のスケールアウトを行う際には，テン時にプログラム変換を行うことにより，VM イントロ

プレートから新たに VM を作成する．ただし，事前

スペクションを行えるようにした．LLView はソースに VM を作成しておいたり，スケールインを行った

コードを LLVM コンパイラでコンパイルし，中間表

りしてシステムに VM がプールされている場合には現の中の load 命令を変換する．LLView は GPU プ

その VM を再利用することもできる．テンプレート

ログラム用に開発されていたが，それを VM 用に修には Docker を動作させるための最小限のシステム正した．具体的には，リソース監視機能が VM のメだけをインストールしておく．そのために，Barge [1]

モリにアクセスする際に，VM のメモリの必要な部のような Docker ホスト用軽量 OS を使うことができ分をマッピングしてから，Linux カーネルの仮想アド

る．コンテナイメージについては，VM 作成後に必要なものだけをインストールする．

5. 1 VM 内コンテナの性能

テンプレートは VM の構成情報が書かれたコンフィ

VM 内でコンテナを使用することによるオーバヘッ

グとディスクイメージからなる．Ciel で用いた libvirt

ドを調べるために，VM 内コンテナの中で UnixBench[19] では VM のコンフィグは XML 形式となってい[13] を実行して性能測定を行った．ストレージドラ

るため，libxml2 [21] を用いて構文解析を行う．そしイバには AUFS [18]，OverlayFS，ZFS [12]，Deviceて，同一物理ホスト上で重複が許されない UUID や

Mapper の 4 種類を用いた．比較として，VM 上でコ

MAC アドレス，VM 名，イメージファイル名を変更

ンテナを用いない場合の性能も測定した．UnixBench

する．また，スケールアウトするサービスに必要十は 10 回実行し，平均を算出した．

分なサイズの VM となるように，仮想 CPU 数やメ測定結果を図 5 に示す．このグラフではコンテナ

モリ容量を変更する．作成した VM のコンフィグはを用いない場合の性能を 1 として正規化している．整

libvirt API を用いてシステムに登録する．

数演算，プログラム実行，プロセス生成，シェルスク

VM のディスクイメージはテンプレートのイメー

リプト実行については VM 内コンテナのオーバヘッ

ジファイルを複製することによって作成する．ディスドは小さいことがわかった．一方，システムコール，

クサイズが大きくなると複製に時間がかかるため，テ浮動小数点演算，パイプ，コンテキストスイッチにつンプレートのイメージファイルはスパースファイルをいてはオーバヘッドが大きかった．これはコンテナに用いて作成しておく．スパースファイルはデータが書よる仮想化の影響のためだと考えられる．

き込まれたブロックだけ実体を持つ特殊なファイル

ファイルコピーではストレージドライバによって性である．スパースファイルを使用することで，実デー能差が大きく，AUFS と ZFS でオーバヘッドが大きタを持つブロックのみが複製されるため，ディスクイ

かった．特に ZFS に関しては約 75 ％の性能低下を引メージの複製時間を短縮することができる．

き起こした．これは ZFS がデータブロックを読み出

スケールアウトにより VM の台数が増えると，Ciel

す際にブロックポインタをたどる回数が多く，同一のは Linux Virtual Server (LVS) [23] と呼ばれるロー

処理に対してより多くの I/O が必要になるためだとドバランサを用いて VM 内コンテナにリクエストを考えられる．また，シェルスクリプト実行では AUFS

分散させる．LVS に設定した仮想 IP アドレスへのパだけが 15〜20 ％の性能低下を引き起こした．

ケットが追加した VM 内のコンテナにも転送される

実験結果より，ストレージドライバに OverlayFS

ように，コンテナの IP アドレスを LVS に登録する．

または Device Mapper を使用した場合の性能低下は転送方式には Direct Server Return (DSR) と呼ばれ

平均 10%程度であり，許容できるオーバベッドであるる方式を用い，リクエストが転送されたコンテナはクことが分かった．そこで，以下の実験では OverlayFS

ライアントに直接，レスポンスを返すことで高速化を

を用いた．

図る．

5. 2 VM 内コンテナのリソース監視5 実験

VM 内コンテナのリソース使用量を監視するため

Ciel の有用性を確かめるための実験を行った．実験に，VM 内で 3 つのコンテナを用いて Apache ウェブには Intel Xeon E3-1225 v5 の CPU，12GB のメモ

サーバ [2]，nginx ウェブサーバ [17]，WildFly アプリ

リ，1TB のディスクを搭載したマシンで Xen 4.6.0 動

ケーションサーバ [20] を動作させた．Apache 上では作させ，1 個の仮想 CPU，1GB のメモリ，50GB の仮

Bottle フレームワーク [8] を用いて作成したウェブア

想ディスクを持つ VM を用いた．VM 内では Ubuntu

プリケーションを動作させた．このウェブアプリケー

16.04 と Docker 17.05.0-ce を動作させた．

ションは指定された画像にモザイク処理を行う．この
ウェブアプリケーションに負荷をかけた時に，VM イ
ントロスペクションを用いて各コンテナの CPU 使用

1.2
1

性能

0.8
0.6
0.4
0.2

100
80
60
40
20
0
60

80

Index Score

Shell1

80

4
3
2
1
0

100

0

20

WildFly

ApacheVM 内コンテナの CPU 使用率

率，メモリ使用量，消費ディスク帯域を測定した．
図 6，図 7，図 8 にそれぞれの測定結果を示す．

Apache の CPU 使用率だけが 100%に増加していることが分かる．また，メモリ使用量についてもApache だけが多かった．消費ディスク帯域の結果か
らは，Apache が最初だけディスクアクセスを行ったことが分かる．その後はページキャッシュにアクセス

図7

100

nginx

WildFly

VM 内コンテナのメモリ使用量

100
90
80
70
60
50
40
30
20
10
0
0

20

40

60

80

100

計測時間(s)したと考えられる．

5. 3 スケールアウトにかかる時間

40

計測時間(s)

消費ディスク帯域(KB/s)

図6

nginx

60

5

計測時間(s)ApacheSystem Call

6

120

40

Shell87140

20Device Mapper

VM 内コンテナの性能

160

0

Process
CreationContext
Switching

ZFS

メモリ使⽤量(MB)CPU使⽤(%)

図5

Pipe

File Copy 256
OverlayFS

File Copy 4096

AUFS

File Copy 1024

Execl

Dhrystone

Whetstone0

Apache図8

nginx

WildFly

VM 内コンテナの消費ディスク帯域

5.2 節の実験において，Apache の CPU 使用率が80%を超えた時にスケールアウトを行い，スケール

ジはあらかじめインストールしておいた．比較のためアウトにかかる時間を測定した．スケールアウト時に，VM 単位でスケールアウトを行う従来システムにはテンプレートから VM を作成してコンテナを起についてもスケールアウトにかかる時間を測定した．

動し，そのコンテナ内で Apache を起動した．この実

従来システムでは元々の VM と同様に，3 つのコン

験では，テンプレートのディスクイメージに Ubuntu

テナイメージをインストールしたディスクイメージを

16.04 をインストールし，Apache のコンテナイメー

用意した．

300

120

250

100

CPU使⽤率[%]

200
150
100
50

80
60
40
20

0

Ciel

従来
複製時間

図9

0

Ciel

起動時間

スケールアウト完了時間

図 10

スケールアウトにかかった時間を図 9 に示す．Ciel

た．これはスケールアウトする必要のないサービスを起動しなかったためであり，特に WildFly の有無の影響が大きかった．VM を作成せずにプールされたVM を使う場合には，スケールアウトにかかる時間

500

メモリ使⽤量[MB]減されており，Ciel では 7 秒しかかかっていなかっスケールアウト中の CPU 使用率

600

では従来システムの 33%の時間でスケールアウトが完了した．内訳を見ると VM の起動時間が大幅に削

400
300
200
100
0

Ciel

は起動時間のみとなり，Ciel では従来システムの 4%の時間で完了することになる．ディスクイメージの複

従来

図 11

従来

スケールアウト中のメモリ使用量

製時間については，インストールされているサービスが少ない Ciel のほうが若干高速になった．これは5. 5 スケールアウト後のリソース使用量

スパースファイルを用いたため，複製するディスクブ

5.3 節の Apache のスケールアウトが終了した後，ロック数が少なかったことによる．巨大なデータベー

LVS を用いて 2 台の VM 内のコンテナにリクエスト

スを使うサーバがある場合にはこの差がより顕著にを分散させた時の CPU 使用率の変化を測定した．負なると考えられる．

荷分散方式にはラウンドロビンを用いた．ベンチマー
クには httperf [16] を用い，ウェブアプリケーション

5. 4 スケールアウト時のリソース使用量に 1 秒間に 5 個のリクエストを送信した．図 12 に

5.3 節の Apache のスケールアウトの際に，新しい測定結果を示す．170 秒付近でスケールアウトが完了

VM を起動してからサービスの起動が完了するまでし，新しい VM のコンテナの中で Apache が動作しの VM 全体での CPU 使用率とメモリ使用量を測定始めた．その後は，各 VM 内のコンテナにリクエスした．図 10 と図 11 に測定結果を示す．スケールア

ト処理が分散し，それぞれの CPU 使用率は 60%とウトする必要のない nginx や WildFly も起動されて30%程度となった．CPU 使用率が同程度にならない

しまう従来システムと比べて，Ciel では VM の CPU

原因は現在調査中である．

使用時間が 3 分から 7 秒に減少した．CPU 使用率も低く抑えられた．また，Ciel ではメモリ使用量も6 関連研究

41%に抑えられた．これらは主に WildFly の起動に

Picocenter [22] は，長期間実行されるがほとんど使CPU とメモリが必要とされるためである．

われないサービスをクラウドで効率よく動作させる
ために，VM 内コンテナを用いて実行を行う．サービ

を動作させ，ライブラリ OS を用いることで軽量化し160

CPU使⽤率(%)

140ている．しかし，VM 内で VM を動作させるオーバ

120
100

ヘッドが依然として大きい．Ciel では VM 内でコン80

テナを動作させることでオーバヘッドを抑えることが

60

できる．

40

V-Met [15] は，監視対象 VM が動作している仮想

20
0
0

50

100

150

200

250

時間(s)
VM1

図 12

VM2

スケールアウト後の CPU 使用率化システム全体を VM 内で動作させることにより，信頼できない仮想化システムの外側で侵入検知システム(IDS) を安全に動作させる．V-Met では，VM イント
ロスペクションを用いて VM の外部からまず仮想化システムを解析し，さらにその中の監視対象 VM のスが使用されず，コンテナが非アクティブになった場

OS データを解析する．Ciel では VM 内の OS データ

合は，コンテナごとストレージにスワップアウトし，を解析するだけで VM 内コンテナを監視することが再びサービスへの要求が来た時にコンテナをスワップできる．また，セキュリティに必要な情報ではなく，インする．VM 内コンテナを用いてサービスを実行す

リソース使用量に関する情報を収集する点も異なる．

る点で Ciel に似ているが，本研究では各サービスのDocker コンテナの中で Docker コンテナを動作さ

リソース使用量を VM の外部から正確に計測し，負せる Docker in Docker と呼ばれる手法も利用され荷の高いサービスだけをスケールアウトできるようている．dind [9] は Docker コンテナの中で Dockerにするためにコンテナを使用している．

Engine を動作させることにより，ユーザが独自の

VCRecovery [24] は，障害対策として VM 内コンテ

コンテナを用いることができる．ホストの Docker

ナを用いて待機系のサービスを動作させる．ウォーム

Engine を共有することにより，コンテナ内でコンテ

スタンバイの場合には，運用系の VM と待機系のコナを起動する手法もある．これらの手法は主に開発用ンテナを一対一に対応させて動作させる．コールドス

途で用いられている．

タンバイの場合には，障害発生時に待機系の VM 内

cAdvisor [7] は Docker コンテナのモニタリング

でコンテナを起動する．これにより待機系の VM に

ツールであり，cAdvisor 自体もコンテナで動作する．

かかるコストを最小限に抑えつつ，迅速な障害復旧

cAdvisor はコンテナの CPU 使用率やメモリ使用量を実現している．VCRecovery では従来の VM 内のを取得することができる．Ciel において VM イント

サービス全体をそのままコンテナ内で動作させるのにロスペクションを用いて取得した VM 内コンテナの対して，Ciel ではサービスごとに異なるコンテナを情報を標準インタフェースで提供できるようにするこ用いる．VCRecovery では VM 内コンテナの負荷がとで，VM 外部で cAdvisor を動作させることも可能高まった時にコンテナマイグレーションを行うため，になると考えられる．

Ciel と相補的に用いることができる．
FlexCapsule [11] は，VM 内で軽量な VM を用いて7 まとめサービスを実行する．クラウドにおいて VM 構成の

本稿では，VM 内コンテナを用いることで，サービ

きめ細かい最適化を動的に行うことにより，コスト

ス単位でのより柔軟なオートスケールを行うシステを削減することが可能である．例えば，VM マイグ

ム Ciel を提案した．Ciel では VM 内で動作しているレーションにより負荷の低いサービスを少数の VM

各サービスをコンテナを用いて実行することにより，に集約したり，負荷の高いサービスを新たに起動した

各サービスのリソース使用量を正確に計測すること

VM に移動させたりすることができる．FlexCapsuleができる．VM 内コンテナのリソース使用量は VM

では，ネストした仮想化 [4] を用いて VM の中で VM

イントロスペクションを用いて VM 内の OS データ

を取得することで計測する，負荷の原因となっている
サービスのみをスケールアウトすることで，新たに起動する VM のコストを削減し，スケールアウトにかかる時間を短縮することができる．
今後の課題は，様々なリソースの使用量を考慮してオートスケールのポリシーを作成することである．
また，負荷の高いサービスを動作させるのに必要なリソース量を見積もることができるようにし，必要十分な大きさの VM を起動してスケールアウトが行えるようにする必要がある．さらに，サービスの負荷が低くなった時に VM の数を減らし，複数の VM で動作しているコンテナを集約するスケールインにも対応
していくことを計画している．

参 考 文 献[ 1 ] A.I.: Barge: Yet Another Lightweight Linux
Distribution for Docker Containers, https://github.com/bargees/barge-os.
[ 2 ] Apache Software Foundation: Apache HTTP
Server Project, https://httpd.apache.org/.
[ 3 ] Barham, P., Dragovic, B., Fraser, K., Hand, S.,
Harris, T., Ho, A., Neugebauer, R., Pratt, I., andWarfield, A.: Xen and the Art of Virtualization,
Proc. Symp. Operating Systems Principles, 2003,
pp. 164–177.
[ 4 ] Ben-Yehuda, M., Day, M. D., Dubitzky, Z.,
Factor, M., Har’El, N., Gordon, A., Liguori, A.,
Wasserman, O., and Yassour, B.-A.: The Turtles
Project: Design and Implementation of Nested Virtualization, Proc. Symp. Operating Systems Design
and Implementation, 2010.
[ 5 ] Canonical Ltd.: Linux Containers, https://linuxcontainers.org/.
[ 6 ] Garfinkel, T., Rosenblum, M., et al.: A Virtual
Machine Introspection Based Architecture for Intrusion Detection., Proc. Network and Distributed
Systems Security Symp., 2003, pp. 191–206.
[ 7 ] Google, Inc.: cAdvisor: Analyzes Resource Usage and Performance Characteristics of Running
Containers, https://github.com/google/cadvisor.
[ 8 ] Hellkamp, M.: Bottle: Python Web Framework,https://bottlepy.org/.

[ 9 ] J. Petazzoni, d.: Docker in Docker, https://github.com/jpetazzo/dind.
[10] Kivity, A., Kamay, Y., Laor, D., Lublin, U., andLiguori, A.: kvm: the Linux Virtual Machine Monitor, Proc. Ottawa Linux Symp., 2007, pp. 225–230.
[11] Kourai, K. and Sannomiya, K.: Seamless andSecure Application Consolidation for Optimizing
Instance Deployment in Clouds, Proc. Int. Conf.
Cloud Computing Technology and Science, 2016,
pp. 318–325.
[12] Lawrence Livermore National Laboratory: ZFS
on Linux, https://zfsonlinux.org/.
[13] Lucas, K.: Byte-UnixBench, https://github.com/
kdlucas/byte-unixbench.
[14] Merkel, D.: Docker: Lightweight Linux Containers for Consistent Development and Deployment,
Linux J., Vol. 2014, No. 239(2014).
[15] Miyama, S. and Kourai, K.: Secure IDS Oﬄoading with Nested Virtualization and Deep VM Introspection, Proc. European Symp. Research in Computer Security, 2017, pp. 305–323.
[16] Mosberger, D. and Jin, T.: httperf―A Tool
for Measuring Web Server Performance, ACM
SIGMETRICS Performance Evaluation Review,Vol. 26, No. 3(1998), pp. 31–37.
[17] NGINX, Inc.: NGINX: High Performance Load
Balancer, Web Server, &Reverse Proxy, https://www.nginx.com/.
[18] Okajima, J. R.: Aufs4 – Advanced Multi Layered Unification Filesystem Version 4.x, https://aufs.sourceforge.net/.
[19] Red Hat, Inc.: libvirt: The virtualization API,
https://libvirt.org/.
[20] Red Hat, Inc.: WildFly, https://www.wildfly.org/.
[21] Veillard, D.: Libxml2: The XML C parser andtoolkit of Gnome, https://xmlsoft.org/.
[22] Zhang, L., Litton, J., Cangialosi, F., Benson, T.,
Levin, D., and Mislove, A.: Picocenter: Supporting
Long-lived, Mostly-idle Applications in Cloud Environments, Proc. European Conf. Computer Systems, 2016.
[23] Zhang, W.: Linux Virtual Server for Scalable
Network Services, Proc. Ottawa Linux Symp., 2000.
[24] 森川智紀, 光来健一: クラウドにおける VM 内コン
テナを用いた低コストで迅速な自動障害復旧, 第 142 回
OS 研究会, 2018.
[25] 尾崎雄一, 山本裕明, 光来健一: GPU を用いた OSレベルでの障害検知, 第 142 回 OS 研究会, 2018.