インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

FastContainer: 実行環境の変化に素早く適応できる
恒常性を持つシステムアーキテクチャ
松本 亮介1,a)

近藤 宇智朗2

三宅 悠介1

力武 健次1,3

栗林 健太郎1

概要：クラウドサービスや Web ホスティングサービスの低価格化と性能の向上に伴い，コンテナ型の仮想化技術を活用することにより，複数のユーザ環境の収容効率を高めると同時に，セキュリティの担保とリソース管理を適切に行うことが求められている．一方で，障害時の可用性やアクセス集中時の負荷分散については依然として各システムに依存している．本研究では， HTTP リクエスト毎に，コンテナの起動，起動時間，起動数およびリソース割り当てをリアクティブに決定する，実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャを提案する．提案手法により，アクセス集中時にはコンテナ
が HTTP リクエストを契機に，アクセス状況に応じて複製・破棄されることで，迅速に自動的な負荷分散が可能となる．さらに，コンテナが一定期間で破棄されることにより，収容効率を高め，ライブラリが更新された場合には常に新しい状態へと更新される頻度が高くなる．

FastContainer: A Homeostatic System Architecture Rapidly Adapting
Execution Environment Changes
Ryosuke Matsumoto1,a)Uchio Kondo2 Yusuke Miyake1
Kentaro Kuribayashi1

Kenji Rikitake1,3

Abstract: Price reduction and performance improvement of cloud computing and Web hosting services leadto more demand on eﬃciency of highly utilized multi-tenant user environment while maintaining the security
and appropriate resource management, by making use of container virtualization technology. On the other
hand, maintaining the availability and load balancing on access congestion are still dependent on each system configuration. In this paper, we propose a homeostatic system architecture rapidly adapting execution
environment changes which reactively decides invocation, running periods, simultaneous running numbers
and assigned resources of the containers in connection with the incoming HTTP requests. Our proposedarchitecture enables automatic and rapid load balancing by generating and discarding the containers following the access frequency in case of access congestion. The proposed method improves eﬃciency of resource
utilization by automatically discarding the containers in a fixed period, which also contributes to increase
the chance of reflecting the library updates.

1. はじめに
1

2

3

a)

GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan
GMO ペパボ株式会社 技術部 技術基盤チーム
Developer Productivity Team, Engineering Department,
GMO Pepabo, Inc.
力武健次技術士事務所
Kenji Rikitake Professional Engineer’s Oﬃce, Toyonaka
City, Osaka 560-0043 Japanmatsumotory@pepabo.com

c 2017 Information Processing Society of Japan⃝

インターネットを活用した企業や個人の働き方の多様化に伴い，インターネット上で自らを表現する機会が増加している．特に個人にとっては，Twitter や Facebook を活用して，自身が作成したコンテンツを拡散させることによ
り，効率よくコンテンツへの訪問数を増やすことができるようになった．その結果，コンテンツの内容の品質が高け
れば，さらに拡散され，コンテンツに紐づく個人のブラン

89インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

ド化も可能になってきている．一般的に個人が Web コンやレスポンス性能の劣化を，リクエスト単位またはコンテ

テンツを配信するためには，Web ホスティングサービス，

ナ自身の監視プロセス経由で検知することで，コンテナ自クラウドサービスなどが利用される [16]．

身を自動的に複製し，迅速に自動的な負荷分散ができる．

Web ホスティングサービスやクラウドサービスの低価格

また，コンテナが一定期間で破棄され，プロセスの起動時化と性能の向上に伴い，Web アプリケーションの複数の実間を短縮することによって，マルチテナント方式 [14] のリ

行環境を単一の Web サーバ上で安定かつセキュアに提供

ソース効率を高め，同時に，ライブラリが更新された場合するために OS の仮想化技術 [3] が活用されている．OS のには新しい状態へと更新される頻度が高くなる．

仮想化技術の中でも，プロセス単位でユーザ領域を隔離し本論文の構成を述べる．2 章では，Web ホスティングてリソース管理ができるコンテナ型の仮想化技術 [19] を活サービスやクラウドサービスにおけるオートスケールとそ用することにより，仮想マシンと比べて，複数の実行環境の課題について述べる．3 章では，2 章の課題を解決するの収容効率を高めることができ，プロセス単位でのセキュための提案手法のアーキテクチャおよび実装を述べる．4

リティも担保できる．また，仮想マシンと比較して，高速

章では，2 章におけるオートスケールによる負荷分散の評に仮想環境を起動することができる．

価を行い，5 章でまとめとする．

一般的に，単一のサーバに複数のユーザ領域を収容するような Web ホスティングサービスでは，利用者の Web コ

2. 負荷分散と運用技術

ンテンツが特定の Web サーバに紐づくため，負荷分散す

最もアクセスが集中しており，かつ，コンテンツを幅広ることが難しい．また，クラウドサービスの場合は，利用く閲覧される可能性が高い状況においては，サーバが高負者がアクセス集中に耐えうるオートスケール [18] の仕組み

荷状態となってアクセスが困難となり，貴重なコンテンツを作る必要があったり，各サービス・プロバイダが提供し拡散の機会を逃すことも多い．本章では，Web ホスティンているオートスケールの機能を使う必要がある．AWS[1]グサービスやクラウドサービスにおける，負荷分散のためなどのサービス・プロバイダが提供しているオートスケーのオートスケールや関連する運用技術について整理する．

ル機能では，サービス・プロバイダ自身が提供する監視項

負荷対応のためのスケール手法は，大きく分けて，稼働目に基づき内部で自力構築した仮想マシンを起動するかましている単一のインスタンス*1 に割り当てるハードウェア

たは外部のサービスを利用して仮想マシンを自動で起動さリソースを増減させるスケールアップ型と，複数のインスせる必要があるため，突発的なアクセス集中に対して，スタンスへと起動数を増減することによって負荷分散を行う

ケール処理に時間がかかり負荷分散が間に合わない場合がスケールアウト型の 2 つに分類できる．

多い [6]．また，迅速に負荷分散の仕組みを構築するのは，個人の利用者には困難である．

2.1 Web ホスティングサービス

本研究では，従来の Web ホスティングサービスを利用で

Web ホスティングサービス [16] では，サービス利用者きる程度の知識を持った個人が Web コンテンツを配信すの Web コンテンツは特定の Web サーバに収容され，Webることを前提に，サービス利用者が負荷分散のシステム構

サーバと Web コンテンツが紐づくため，負荷に応じたオー

築やライブラリの運用・管理を必要とせず，迅速にユーザ

トスケールはデータの整合性の面で困難である．このよう領域を複数のサーバに展開可能にするために，コンテナのな場合に適用可能な手法として，ユーザデータ領域を共有

起動を HTTP リクエスト単位でリアクティブに決定する，

ストレージにまとめた上で，仮想ホスト方式を採用した複実行環境の変化に素早く適応できる恒常性を持つシステム

数台の Web サーバで負荷分散を行う手法 [22] があるが，アーキテクチャを提案する．ここで述べる「リアクティブ

この手法には以下の課題がある．

な決定」とは，HTTP リクエスト単位で外的要因に基づく

仮想ホスト方式では複数のホストを単一のサーバプロセ

負荷の状態やレスポンス性能を検出し，状況に応じたコン

ス*2 で処理するため，リクエストは Web サーバプロセスをテナの構成を迅速に決定することを意味する．具体的な手共有して処理される．そのため，ホスト単位で使用するリ法としては，Web アプリケーションの実行におけるユーザ

ソースを適切に制御したり，その原因を迅速に調査するこ

データとアプリケーションの処理を明確に分離した上で，とが困難 [24] であり，スケール時のコスト計算や必要な時迅速に負荷分散処理を実現するために，HTTP リクエストに必要なだけリソースを追加するような方式が利用できなを契機に，コンテナの起動処理，起動継続時間，リソース

い．また，負荷の応じた即時性の高いスケールアップ型の割り当ておよびコンテナ起動数を決定する．

負荷対応も困難である．

本研究で提案するアーキテクチャを実現することで，コンテナのように起動の所要時間が小さい実行環境を採用す
ることにより，リクエストを受け付けない時間が短くできる．アクセス集中時には，既に起動済みのコンテナの負荷

c 2017 Information Processing Society of Japan
⃝

*1
*2

仮想的に構築されたサーバ環境
ただし，ここでいう単一のサーバプロセスとは，ホスト毎にサーバプロセスを起動させるのではなく，複数のホストでサーバプロ
セスを共有することを示す

90

インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

運用技術の観点からは，ライブラリの更新の際に，沢ソースを決定し，高負荷時には自動的にプロバイダ側で山のホストを単一のサーバプロセスで処理している特性

オートスケールする機能*4 を提供している．しかし，前提上，サーバプロセスの再起動時の影響が大きくなる．まとしてプログラミングができるエンジニアを対象としておた，サーバ高負荷時には，リソースを適切に限定すること

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

が困難であるため，高負荷原因の調査と制御にコストがかションを利用できないことが多く，処理の実行時間が限定

かり [23]，サービス品質への影響も大きい．

的であるといった使用上の制限が大きい．このようなサー

また，サービス利用者の観点では，利用できる Web サー
バソフトウェアをはじめとしたミドルウェア及び機能が全ビスを使う場合に，専門的な知識なく Web コンテンツを公開した上でオートスケールすることは困難である．

ホスト共通となり，システム構築の面で自由度が低い．

2.3 Web サーバ機能のプロアクティブ性とリアクティ
2.2 クラウドサービス

ブ性

クラウドコンピューティング [15] とは，ネットワークや突発的なアクセス集中のような変化に耐えうるシステム

サーバといったコンピュータリソースのプールから必要を構築するためには，負荷の状態に基いて適切なインスタな時に必要な量だけオンデマンドに利用可能とするコンンスの数を決定し，必要以上にコンピュータリソースを使

ピューティングモデルである．クラウドサービスはクラウ

用しないように設計することも重要である．単一のサーバ

ドコンピューティングを各種サービスとして提供するサーに高集積にホストが収容可能であり，ホスト単位でのリビスである．

ソース管理を適切に行いながら，セキュリティと性能およ

クラウドサービスでは，Web コンテンツだけでなく，び負荷に強い Web ホスティング環境を構築することを目Web サーバソフトウェアやデータベースをサービス利用的とした場合，Web サーバ機能をプロアクティブ性とリア者が自ら構築する必要がある．そのため，負荷分散のため

クティブ性に基いて分類できる．以下に，Web サーバ機能のシステム設計を個別に行うことができる点において自由のプロアクティブ性とリアクティブ性を定義する．

度は高いが，専門的な知識が必要となる．オートスケール

プロアクティブ性とは，Web サーバ機能を持つ仮想マシについても，負荷に応じて増減させる機能が提供されていン，コンテナおよび Web サーバプロセスが予め起動してる [2] が，その負荷の監視間隔が分の単位であり，突発的なおり，リクエストに応じて仮想マシンやコンテナの状態をアクセスに対して検知するまでの時間が長くなる．負荷状

即時変更できないが，常に起動状態であるため，高速にリ

況に応じて仮想マシンを起動させたとしても，テレビ放映

クエストを処理できる性質とする．また，常時 Web サーの影響のような突発的な高負荷時に，オートスケールのたバ機能を稼働させておく必要があるため，リソース効率がめの処理自体が追いつかず，サービス停止に繋がることも悪い．プロアクティブ性をもったオートスケールは，例え多い．また，仮想マシンの起動時間の問題を解決するため

ば 2.2 で述べたように，事前にアクセス頻度から予測を行にコンテナを利用する手法 [6] や，外部サービス連携によっい，予測に基づいた数だけインスタンスを起動させておく*3てスケールを行う条件を詳細に定義できるサービス もあようなアプローチである．

るが，スケール時の判定を行う際に，外部サーバなどからリアクティブ性とは，CGI や FastCGI[4] のように，アプ

OS の負荷やプロセスの状態等を監視する方式がとられてリケーションが実用上現実的な速度で起動可能であること

おり，監視の時間間隔や取得できる情報の粒度が荒く，突を前提に，リクエストに応じてアプリケーションを起動す

発的な負荷に対して即時性が低くなる問題もある．高負荷る性質とする．リアクティブ性を持つ Web サーバ機能は，状態に対して迅速に対応する即時性を持たせるためには，

起動と停止のコストは生じるため，性能面はプロアクティ

事前にある程度想定される量の仮想マシンを起動させておブ性を持つ Web サーバ機能より劣るが，リクエストを受信くことによって対処する必要があるが，定量的な見積もりしない限りはプロセスが起動しないため，リソース効率がや事前のメンテナンスが必要であったり，限られたコスト

良い．また，リクエストに応じて複数起動させるといったの兼ね合いから適切な見積もりをすることは困難である．

変更に強い処理が実装し易い．一例として，FastCGI はリ

そのため，負荷の状態に基いて適切なインスタンスの数をソース効率と性能を両立するために，一定期間起動して連決定することは難しく，必要以上にコンピュータリソース

続するリクエストを高速に処理可能とするアーキテクチャを使用していることが多い．

をとっている．

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

しかしながら，CGI のようなリアクティブ性に基づく従プロバイダの AWS は，プロバイダ指定の記法によってア来の処理手法は性能面の問題などから利用されなくなって

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

きており，オートスケールについても，リクエスト単位で*3*4

http://www.rightscale.com/

c 2017 Information Processing Society of Japan⃝

https://aws.amazon.com/lambda/

91インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

仮想マシンやコンテナを都度起動させるコストを考慮する

起動させる程度の処理で起動が可能であるため，起動時間と，実用的な性能を満たすことは困難である．

が短時間で済むという特徴がある．また，コンテナ環境単3. 提案手法

位であるため広く使われている Web アプリケーションを隔離して利用できる．

現状の各種サービスの特徴を考慮した場合，限られたリ

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

ソースの範囲内で負荷に応じて即時インスタンスを制御す

シンと比較して速く起動できる点と，2.3 で述べた FastCGI

るためには，リアクティブ性を持つ Web サーバ機能を前のようにリソース効率を高めつつ，性能も担保するアーキ

提に，インスタンスを柔軟に管理し，実用上問題にならな

テクチャを組み合わせた上で，コンテナ上で起動する Web

い程度の性能を担保するアーキテクチャが必要となる．以

アプリケーションの実行処理におけるデータとアプリケー

下に要件をまとめる．

ションの処理を明確に分離する．さらに，HTTP リクエ( 1 ) HTTP リクエスト単位の粒度で迅速にインスタンスの

スト毎に負荷状態やレスポンス性能に応じて，Web アプ

スケールアウトとスケールアップできる( 2 ) HTTP リクエスト単位の粒度でインスタンスの監視を行い即時スケール処理の命令を出せる

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

( 3 ) リソース効率化のため必要の無いインスタンスは停止提案手法では，最低一つのコンテナが常に起動している可能であり，必要な時に HTTP リクエスト単位で起ことを前提に，コンテナが一つ以上起動していれば即時レ動できる

スポンスを送信し，コンテナが停止していた場合は，リク

また，このアーキテクチャによって実現される Web ホ

エストを契機にコンテナを一定期間起動させて複数のリク

スティングサービスとしては以下の要件が必要となる．

エスト処理を行う．これによって，仮にコンテナが全て停( 1 ) OS やライブラリの更新作業のようなサーバ運用はサー止していたとしても，コンテナがリクエスト単位で起動すビス提供側が行う( 2 ) 広く使われる一般的な Web アプリケーション（WordPress など）を利用できる( 3 ) アクセスが集中した際に専門的な知識がなくてもオー
トスケールによる負荷分散が行われる( 4 ) Web アプリケーション実行時間程度の粒度での課金が可能である( 5 ) ホストの収容効率を高めることによってハードウェア
コストを低減する( 6 ) 高頻度でセキュリテイを担保するための OS やライブ
ラリの更新が行われるるため可用性が高くなる．例えば，メモリリークが生じる
ような不完全なソフトウェアが動作していたとしても，定期的に循環が行われることにより，メモリが解放される．
この特徴により，システム全体がメモリ不足にならないた
め，そういったソフトウェアを許容できる．ただし，シス
テムとしては許容できても，ソフトウェアとして不完全であることを検知する必要がある．また，一定時間起動することにより，一度コンテナが起動してしまえば，起動時間に影響なくレスポンスを送信できる．
アクセス集中時には，既に起動済みのコンテナがコンテナ
自身の CPU 使用時間の割り当ての失敗を示す cgroup[17]

そこで，本研究では，Web コンテンツを配信するための throttled の値を監視し，80%以上失敗していたらスケーに，サービス利用者が負荷分散のシステム構築やライブラ

ルアウトさせ，5 分間の失敗の平均値が 10%以下であれば，

リの運用・管理を必要とせず，迅速にユーザ領域を複数のコンテナの起動継続時間に基いてスケールアウトしたコン

サーバに展開可能とするために，Web アプリケーション

テナを停止させる．スケールアウト時には，自動的に新しコンテナの起動，起動継続時間，起動数およびスケール処

いコンテナの構成情報をコンテナの収容情報を構成管理

理の判定といった状態の変更を HTTP リクエスト毎にリデータベース（CMDB）に対して管理マネージャ経由で登アクティブに決定する，実行環境の変化に素早く適応でき録する．その後，コンテナの前段に配置されている Web

る恒常性を持つシステムアーキテクチャを提案する．このプロキシが構成管理データベースに基づいて，新しいコンアーキテクチャを FastContainer と名付ける．

テナへとリクエストを転送する．この転送作業では，コンテナが収容されているサーバ上で動作している Web ディ

3.1 FastContainer アーキテクチャ及び関連技術

スパッチャが，プロキシ先のコンテナが起動していればそ

FastContainer アーキテクチャでは，インスタンスとしのままリクエストを転送し，起動していなければ，CMDBて，仮想マシンではなく Linux コンテナを利用する．Linuxからコンテナの構成情報を取得して，コンテナを先に起動

におけるコンテナ [5] はカーネルを共有しながらプロセス

しリクエストを転送する．ただし，コンテナが起動中の場

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

合は既に起動済みのコンテナにリクエストを転送し，起動である．そのため，コンテナの起動処理は仮想マシンのよが完了してからリクエストが振り分けられるようにする．

うなカーネルを含む起動処理と比べて，新しくプロセスを

Web アプリケーションに関するデータは共有ストレージ

c 2017 Information Processing Society of Japan⃝92

インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

上に配置し，コンテナを収容するサーバ群は同一領域をマウントすれば，どのサーバにコンテナが起動していても，

CMDB 上にコンテナの構成情報に基づいて適切に動作可能となる．

IOTS2017
2017/12/8



Haconiwa.define do |config|
config.name = "haconiwa-auto-droptest"# Ruby loop daemon:
config.init_command = ["/usr/bin/ruby",

提案手法では，コンテナの起動が一般的に高速であること，リクエストを契機としたリアクティブな起動処理であ"-e","loop { sleep 1 }"]config.daemonize!

ること，および，オートスケールの監視手法がリクエスト
単位での粒度で行われることにより，突発的な負荷に対し

root = Pathname.new("/var/lib/haconiwa/#{config.name}")ても迅速にオートスケールが可能となる．スケールアップ

config.chroot_to rootについても，コンテナのリソース管理が cgroup によってconfig.bootstrap do |b|

プロセス単位で制御されており，cgroup の特徴を利用し

b.strategy = "git"b.git_url = "https://example.jp/haconiwa.image"て，プロセスが処理中であっても CPU 使用時間などの割り当てを即時変更できる．また，コンテナが一定期間で破棄されることにより，不必要なプロセスの起動数を低減しend
config.provision do |p|p.run_shell <<-SHELLてコンテナの収容効率を高め，ライブラリが更新された場
合には常に新しい状態へと更新されることが保証される．

apk add --update bash
apk add --update rubySHELL

3.2 Haconiwa: コンテナ管理ツール
FastContainer アーキテクチャをシステムとして実現す

end
config.add_async_hook(msec: 30 * 1000) do |base|

るためには，コンテナの複雑な制御が必要である．Ha-

Haconiwa::Logger.info("Process killed: #{base.pid}")coniwa*5 は筆者の一人である近藤らによって開発されており，コンテナのリソース割り当てやプロセス隔離の構成情報の設定だけでなく，コンテナ起動・停止時やコンテナのセットアップ時の各種フェーズで Ruby DSL*6 を実行する::Process.kill :TERM, base.pid
end
config.mount_independent "procfs"
config.namespace.unshare "pid"ことにより，コンテナの振る舞いをプラガブルに定義でき

end

るソフトウェアである．Haconiwa はコンテナを固定的な

仮想環境としてのみ利用するだけでなく，プログラムで制

図 1 Haconiwa の設定記述例

御が可能なネットワーク上で動作するスレッドとみなせる

Fig. 1 Haconiwa configuration example.

ような方針で開発されている．また，FastContainer アー
キテクチャのように，リクエスト単位でリアクティブにコびツールは，多数のコンテナで構成されたシステムを自動

ンテナを起動させることができ，かつ，一定時間起動したで管理するためのコンテナオーケストレーションソフト

後に停止する処理や，Haconiwa で起動されたコンテナをウェアであり，Haconiwa は単一のコンテナを管理するツー

管理するプロセスがコンテナのリソース使用状態を監視

ルと定義できる．

して，状態によって HTTP ベースの API にアクセスする

3.2.1 既存のコンテナ管理ツールとの比較といったような動的な処理を DSL で平易に記述できる．

コンテナの構成を管理するソフトウェアとしては，LXC[7]Haconiwa によって構築されたコンテナのリソース割り当や Docker[9]，rkt[8] がある．Docker はコンテナによる仮ては cgroup を活用しており，コンテナのプロセスを停止

想環境の独立性を重視しているため，コンテナを構成するさせることなく，処理中であっても割り当てを即時変更すプロセスの隔離技術やリソース割り当て技術が機能としることができる．図 1 のように書かれた Haconiwa の設定て密結合になっている．一方で Haconiwa は，必要なコンを実行すると，bootstrap API により，git でコンテナのイ

ポーネントを組み合わせて，chroot() システムコールによメージを取得後，provision API によりコンテナに Ruby のる最低限のファイルシステム隔離に加え，CPU やメモリ環境を作り，コンテナ起動と同時にコンテナ内部で Rubyのリソース割り当てのみを適用した環境を DSL によってプログラムが sleep するだけの処理を実行する．その後，平易に記述することができる．そのため，構築したい仮想

Haconiwa の add async hook API の定義に従い，30 秒後

環境に応じて，仮想環境の独立性と運用性のバランスを検にコンテナを停止する．

討しやすい設計になっている．

FastContainer アーキテクチャを適用したシステムおよ*5*6

https://github.com/haconiwa/haconiwa
Domain-specific language

c 2017 Information Processing Society of Japan⃝

LXC は Haconiwa と同様に比較的プラガブルな作りになっているものの，コンテナの振る舞いを定義するためのフックフェーズが，コンテナ起動や停止時のみといったよ93インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

うに限定的である．一方 Haconiwa は，シグナルハンドラ
や起動後の非同期遅延処理，さらには定期実行のタイマー処理を定義して実行することも可能となっており，コンテ
ナを活用した様々なシステムに適用しやすくなっている．

rkt は多くの設定をサポートしているものの，Ruby DSLのようにプログラマブルに記述することはできず，コマン
ドラインのオプション設定で実行する必要がある．

3.2.2 コンテナのオーケストレーションソフトウェアとの比較
代表的なコンテナのオーケストレーションソフトウェアとして Kubernetes[20] がある．Haconiwa は，通常のDocker や LXC による単一あるいは複数の平易なコンテナ
管理に加え，Ruby DSL を各コンテナの処理フェーズで記述可能で，任意の処理を実行可能であることから，独自で実装する場合に複雑になりがちなオーケストレーション層との連携を想定した作りとなっており，Haconiwa 自体が図 2

コンテナを利用した Web サービス基盤モデル

Fig. 2 Web service infrastructure model using container.

オーケストレーションソフトウェアとしても遜色ない使い方が可能である．Haconiwa と Kubernetes の機能を比較した場合，Kubernetes は設定を単一の yaml ファイルで記述する必要があり，独自のオーケストレーション層を実装する場合において自由度が低い．今後コンテナを活用した複
雑なコンテナ設定，あるいは，オーケストレーション層との連携が求められることを想定すると，Haconiwa のようにコンテナの設定層およびオーケストレーション層との接続を DSL で統一的に記述でき，かつ，Ruby のような一般的に広く使われるプログラミング言語を利用できることにより，独自に定義された記述言語よりも自由度が高く，学習もしやすいと考えられる．

3.3 コンテナを利用した Web サービス基盤モデル
図 2 に，FastContainer アーキテクチャやその実装の立

図 3

Haconiwa による FastContainer のシステム構成例

Fig. 3 Example of FastContainer System using Haconiwa.

ち位置を明確化するために，コンテナを利用した Web サー
ビス基盤モデルを示す．

レーション層の上のストラテジー層は，コンテナのオーケ

図 2 の各層について説明する．サービス層は実際の Web

ストレーションツール基盤の上に，さらにそれぞれの Web

アプリや Web サービスのコンテンツを含む層である．ス

サービスの特性に合わせた戦略の層として位置するのでトラテジー層は，Web サービスの特性に合わせてコンテナはないかと考える．例えば，本論文におけるホスティング

基盤をより特徴的に制御する層であり，FastContainer はサービスのスケーリングや運用効率化に基づいた戦略としここに属する．オーケストレーション層は，3.2.2 節で言及て FastContainer アーキテクチャを提案し，その上の層にした Kubernetes を代表として，コンテナ群や収容ホスト位置する Web アプリケーションのホスティング環境を改善

群のモニタリングやリソース管理等によって CRI[11] と呼していくことが目的である．そういう意味では，ホスティ

ばれるコンテナ管理ツール（コンテナランタイム）のイン

ングサービスにより特化した基盤として FastContainer はタフェース仕様を介してコンテナを制御する層である．コ

ストラテジー層に位置し，オーケストレーション層に位置

ンテナランタイム層は，コンテナそのものの制御層であり，する各種ツールで実装可能であり，Kubernetes や Mesos

3.2 節で言及した Haconiwa や Docker，LXC 等を含む．イMarathon[12] によって実現することも可能である．本研

ンフラストラクチャ層はハードウェアや VM，ベアメタル

究では，FastContainer アーキテクチャをより最適にオー等のコンテナのリソースプールを実現する層である．

バーヘッドなく実現するために，3.1 節で述べた Haconiwa

コンテナを利用した Web サービス基盤モデルにおける層は，大きく上記のように分類できる．特に，オーケスト

c 2017 Information Processing Society of Japan
⃝と各種連携ツールによって構成されるシステムの実装を

NHHM Stack[21] と命名した．
94

インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

表 1 実験環境

01#23%&21)&"/'4"&,561/7#'8%/'.,19":;<2+3%&,,</"&,='>??@'(%219'!"A<"#2#'>?????-'#!!!"

Table 1 Experimental Environment.

+!!"

UserProxy

CoreAPI

CMDB

DataPool

コンテナが動作するサーバ

CPUIntel Xeon E5-2650 2.20GHz 12core

Memory39GBytes

CMDB に基づきコンテナにリクエストを転送

*!!"
)!!"
(!!"
'!!"
&!!"
%!!"

CPU

Intel Xeon E5620 2.40GHz 4core$!!"

Memory4GBytes#!!"

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

CPUIntel Xeon E5620 2.40GHz 8core

Memory8GBytes!"!"

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

CPUIntel Xeon E5620 2.40GHz 4core

Memory16GBytes
Intel Xeon E5620 2.40GHz 2core

Memory4GBytes

4. 実験
FastContainer アーキテクチャの有効性を確認するために，図 3 に示す FastContainer を用いたプロトタイプ環境を構築し，コンテナのスケール処理を評価した．表 1 に実

#$!"

#*!"

$&!"

%!!"
%(!"
()*"'."/)"#+#",-!

&$!"

&*!"

'&!"

(!!"

#/-$",-./01.23"43-5"'!!!!326"

図 4 FastContainer のオートスケールアウト

Fig. 4 FastContainer Auto-Scale-Out.

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

CPU

(!"

#",-./01.23"

01#23%&21)&"/'4"&,561/7#'8%/'.,19":;$+3%&,,</"&,='>??@'(%219'!"A<"#2#'>?????-'
#!!!"
+!!"
*!!"
!"#$%&#"'()*"+*#",-!

Compute仕様!"#$%&#"'()*"+*#",-!

項目

)!!"
(!!"
'!!"
&!!"
%!!"
$!!"
#!!"
!"
!"

験環境と各種ロールの役割を示す．実験環境の各ロールの

(!"

#$!"

#*!"

$&!"

#",-./01.23"456%!7"

NIC と OS は全て，NIC は 1Gbps，OS は Ubuntu 14.04

%!!"
%(!"
()*"'."/)"#+#",-!

&$!"

&*!"

'&!"

(!!"

#",-./01.23"456%!7/-(!7"83-9"'!!!!32:"

図 5 FastContainer のオートスケールアップ

Kernel4.4.0 を利用した．実験では，表 1 のロールのみを構

Fig. 5 FastContainer Auto-Scale-Up.

築し，UserProxy から Compute で起動しているコンテナに対してベンチマークを行う．コンテナのデータは DataPool

図 4 の 1 container で示されるグラフは 1 コンテナに対上に保存し，Compute から DataPool に対して NFS マウ

するベンチマークの結果を示している．ベンチマークの間ントする．コンテナ上には，Apache2.4.10 を 1 プロセスでは，制限された最大 CPU 使用率 30%を常に使い切ってい起動させた上で PHP5.6.30 をインストールし，PHP の環る状態となっており，その状態で概ねグラフの通りレスポ

境情報を取得する phpinfo() 関数を実行するだけのコンテ

ンスタイムは 700msec 前後程度になっている．また，これンツを動作させる．また，コンテナの最大 CPU 使用量は，以上同時接続数を増やすと，リクエストの処理に失敗する

cgroup の機能により 1 コアの 30%に制限し，その設定のも数が増えるため，この値が 1 コンテナがリクエストの処理と予備実験から CPU を 30%使い切ることのできるベンチに失敗することなく処理できる最大のレスポンスタイムでマークの設定を同時接続数 100，総リクエスト数を 10 万にある．

決定した．ベンチマークには ab コマンドを利用した．本

次に，横軸 340 秒あたりから下降する 1to2 container で実験では，コンテナの負荷に応じてコンテナ追加を，起動示されるグラフは，5 万リクエストに到達した横軸で 335

済みのコンテナが自身で CoreAPI を介してスケール処理秒の時点でオートスケールアウトを行った場合の結果であを実施する処理は未実装であるため，コンテナ追加のためる．グラフからも，コンテナが数秒で立ち上がることの高の CoreAPI へのリクエストは手動で実施した．

速性と，オートスケールアウトの処理がリクエストに対しベンチマークでは，1 秒間のレスポンスタイムの平均値てリアクティブに起動することにより，迅速にスケールア

を時系列データとして作成しグラフ化した．続いて，同様

ウトし，リクエストを取りこぼすことなくレスポンスタイのベンチマークを実施し，処理リクエスト数が 5 万を超え

ムが半分程度に短くなり，高速に処理できていることがわた段階で，スケールアウト型とスケールアップ型それぞれ

かる．具体的な数値としては，335 秒時点でオートスケーの負荷対応を実施し，即時スケール処理が実施され，レスルアウトを発生させ，そこから 339 秒まではスケーリング

ポンスタイムが短くなるかどうかを確認した．図 4 にス処理が行われているため 700msec のレスポンスタイムのケールアウト型，図 5 にスケールアップ型の実験結果をままであり，340 秒にはスケーリングが完了して，同時に示す．

秒間のレスポンスタイムは 300msec 前後程度となった．まc 2017 Information Processing Society of Japan⃝95

インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

た，レスポンスタイムが短くなったことにより，1 コンテ

あるし，Kubernetes の CRI API に Haconiwa を対応させナの場合は 10 万リクエストを処理するのに 720 秒程度かる必要もある．FastContainer アーキテクチャや Haconiwa

かっていたが，グラフのように 470 秒程度で 10 万リクエのような新しいソフトウェアを自社や個人で開発していく

ストの処理が完了していることがわかる．

中で，コンテナ関連ソフトウェアの立ち位置と比較対象を

図 5 の 1 container は，図 4 の 1 container と同様に，ス明確化し，各層の連携をより汎用化していくためにも，そケール処理を何もしない場合のグラフであり，横軸 300 秒の他のツールとの連携や技術的背景を考慮しつつ，ツールあたりから下降し始めている 1 container CPU30%to60%

開発者と議論しながら研究開発を続けていく予定である．

のグラフは，5 万リクエストに到達した横軸 301 秒の時点
で，Haconiwa によって即時 CPU の最大使用率を 60%ま

参考文献

でに引き上げた場合のレスポンスタイムの遷移を示して

[1]
[2]

いる．このグラフからも，リクエスト処理が 5 万リクエス
トまで到達した横軸 301 秒の時点から，大きなレスポン[3]

スタイムの遅延やレスポンス処理の失敗などなく，即時ス
ケールアップ処理が行えていることが分かる．具体的な数
値としては，301 秒時点でオートスケールアップを発生さ[4]せ，302 秒からレスポンスタイムが 700msec から 574msecと下降が始まり，304 秒の時点で 358msec となり，以降は350msec 前後に安定した．オートスケールアウトよりも，[5]

オートスケールアップが即時レスポンスタイムへの影響があった理由としては，新たなコンテナを起動させてリクエ
ストの振り分けに追加するスケールアウトに対して，直接[6]稼働中のコンテナのリソースを増強できるからだと考えられる．

5. おわりに本研究では，Web ホスティングサービスにおいて，サービス利用者に専門的な知識を要求することなく，アクセス
集中時には，HTTP リクエスト単位で迅速にコンテナで構成されたユーザ環境がオートスケールできる，コンテナ管
理アーキテクチャの FastContainer を提案した．FastCon-

[7]
[8]
[9]
[10]
[11]

tainer アーキテクチャでは，HTTP リクエスト毎に，コンテナ上の Web アプリケーションの起動，起動継続時間，起動数およびリソース割り当てをリアクティブに決定する．
これによって，Web アプリケーションの負荷や性能劣化[12]をリクエスト単位で検知し，オートスケールまでの処理を大幅に短縮して，迅速にオートスケールが可能となる．ま[13]

た，コンテナが一定期間で破棄されることによりリソース[14]

効率を高め，ライブラリが更新された場合には新しい状態へ更新される頻度も高くなる．
今後の展望としては，さらに FastContainer アーキテク
チャのシステム設計と実装を進めていき，実サービス展[15]

開した場合の実用的な環境における評価を継続的に行っていく．また，現在注目されているサーバレスアーキテクチャ [13] との関係性も考慮していく必要がある．その際，[16]コンテナ時代の Web サービス基盤をモデル化した時に，

Haconiwa の実装においても，世界中で活発に開発されているコンテナ技術と協調するために，前述した CRI や Open

[17]

Amazon Web Services, https://aws.amazon.com/.
Amazon Web Services: Auto Scaling, https://aws.
amazon.com/autoscaling/.
Che J, Shi C, Yu Y, Lin W, A Synthetical Performance
Evaluation of Openvz, Xen and KVM, IEEE Asia Pacific
Services Computing Conference (APSCC), pp. 587-594,
December 2010.
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.
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.
LXC, https://linuxcontainers.org/.
rkt: A security-minded, standards-based container engine, https://coreos.com/rkt/.
Docker, Inc., Docker: Build, Ship, and Run Any App,Anywhere, https://www.docker.com/.
Open Container Project, The Open Container Initiative,
https://www.opencontainers.org/.
The
Kubernetes
Authors,
Introducing
Container
RuntimeInterface(CRI)
in
Kubernetes,
http://blog.kubernetes.io/2016/12/
container-runtime-interface-cri-in-kubernetes.
html.
Mesosphere, Inc., Marathon: A container orchestration
platform for Mesos and DC/OS, https://mesosphere.
github.io/marathon/.
M Roberts,
Serverless Architectures,https://martinfowler.com/articles/serverless.html.
Mietzner R, Metzger A, Leymann F, Pohl K, Variability
Modeling to Support Customization and Deployment ofMulti-tenant-aware Software as a Service Applications,the 2009 ICSE Workshop on Principles of Engineering
Service Oriented Systems, pp. 18-25, May 2009.
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 ofInfrastructure as a Service and Web Hosting Cloud
Providers,10th IEEE/ACM International Conference on
Grid Computing, pp. 17-25, October 2009.
Rosen R, Resource Management: Linux Kernel Namespaces and cgroups, Haifux, May 2013.

Container Initiative(OCI)[10] に準拠した仕様にすべきで

c 2017 Information Processing Society of Japan⃝96

インターネットと運用技術シンポジウム 2017
Internet and Operation Technology Symposium 2017

IOTS2017
2017/12/8

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.
[19] Soltesz S, Ptzl H, Fiuczynski M E, Bavier A, Peterson
L, Container-based Operating System Virtualization: A
Scalable, High-performance Alternative to Hypervisors,
ACM SIGOPS Operating Systems Review, Vol. 41, No.
3, pp. 275-287, March 2007.
[20] The Kubernetes Authors, kubernetes: ProductionGrade Container Orchestration, https://kubernetes.
io/.
[21] 近藤宇智朗, 変拍子パワーポップ系コンテナ、Haconiwa/the-alternative-container, https://speakerdeck.com/
udzura/the-alternative-container.
[22] 松本亮介, 川原将司, 松岡輝夫, 大規模共有型 Web バー
チャルホスティング基盤のセキュリティと運用技術の改善, 情報処理学会論文誌, Vol.54, No.3, pp.1077-1086,
2013 年 3 月.
[23] 松本亮介, 田平 康朗, 山下 和彦, 栗林 健太郎, 特徴量
抽出と変化点検出に基づく Web サーバの高集積マルチ
テナント方式におけるリソースの自律制御アーキテクチャ, 情報処理学会研究報告インターネットと運用技術（IOT）,2017-IOT-36(26), 1-8, (2017-02-24).
[24] 松本亮介，岡部寿男, リクエスト単位で仮想的にコンピュー
タリソースを分離する Web サーバのリソース制御アーキ
テクチャ, 情報処理学会研究報告 Vol.2013-IOT-23, No.4,
2013 年 9 月.

[18]

c 2017 Information Processing Society of Japan⃝

97