Vol.2018-IOT-40 No.2
2018/3/5

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

軽量コンテナに基づく柔軟なホスティング・クラウド基盤の研究開発と大規模・高負荷テスト環境の構築
笠原 義晃1,a)

松本 亮介2

近藤 宇智朗2

小田 知央2

嶋吉 隆夫1

金子 晃介3

岡村 耕二1

概要：インターネットを介して多種多様なサービスが提供されるようになり，そのサービス基盤となるホ
スティングやクラウドサービスには高効率化，耐障害性，負荷変動への耐性，柔軟性，セキュリティなど
さまざまな要件が求められている．本研究では，これらの問題を解決するため FastContainer と呼ぶ軽量コンテナに基づくシステムアーキテクチャの改良を進めており，特にオートスケーリングのために必要な状況検知やリソーススケジューリング機能の研究開発のため，パブリッククラウド上にテスト環境を構築している．本論文では FastContainer の概要とテスト環境の詳細，現状と今後の課題について述べる．

Flexible Hosting/Cloud Platform Based on Light-Weight Containers
and its Evaluation and Stress Test Environment
Yoshiaki Kasahara1,a) Ryosuke Matsumoto2 Uchio Kondo2 Tomohisa Oda2
Takao Shimayoshi1 Kosuke Kaneko3 Koji Okamura1

Abstract: As basic components of ever-expanding internet services, hosting services and cloud computing
platforms are expected to satisfy various requirements, such as eﬃciency, fault-tolerance, resiliency againsthigh load, flexibility, and security. We are trying to solve these problems with a light-weight container basedarchitecture (called FastContainer). To improve FastContainer (especially its auto-scaling function), we are
creating an environment for performance and stress tests on a public cloud platform. In this paper, we
describe the overview of FastContainer and details of the test environment, its current status, and futureplans.

1. はじめにサービスの構築と提供が可能となっている．大学や研究所などにおいても，研究成果を社会に還元するため積極的なウェブホスティングやクラウドサービス [1] の一般化・情報発信が求められているなど，教育研究のために情報発大衆化により，だれでも簡単にインターネット上にサーバ信する機会は多い．情報発信や情報サービス提供手段としを持つことができるようになった．また，オープンソースてはウェブサービスを利用する物が多く，その基盤としてソフトウェアの活発な開発と利用拡大，関連する技術情報のウェブホスティングやクラウドサービスには高効率化，や利用ノウハウの透明化と共有が進み，個人レベルでイン耐障害性，負荷変動への耐性，柔軟性，セキュリティなど

ターネットを介した情報発信や多様なアイデアによる新規

さまざまな要件が求められている．
ハードウェアやネットワークの高性能化と低価格化によ

1

2

3

a)

九州大学 情報基盤研究開発センター
Research Institute for Information Technology, Kyushu University
GMO ペパボ株式会社 ペパボ研究所
Pepabo Research and Development Institute, GMO Pepabo,Inc., Tenjin, Chuo ku, Fukuoka 810-0001 Japan
九州大学 サイバーセキュリティセンター
Cybersecurity Center, Kyushu University
kasahara@nc.kyushu-u.ac.jp

c 2018 Information Processing Society of Japan⃝り，個人や小規模な企業・組織による情報発信やサービス提供の場合，平常時には単一の物理サーバでは能力が余るようになり，複数のユーザ環境が単一のサーバに集約されるようになった．現在では，セキュリティの担保とリソー
ス管理のため，複数のユーザ環境をセキュアかつ安定的に単一のサーバ上に集約できるような，OS の仮想化技術が1

Vol.2018-IOT-40 No.2
2018/3/5

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

活用されている [2]．ウェブサービスのようなあまりハー

起動済み
コンテナ

ドウェアの構成に依存しない限定的な機能を集約させる場
合，ハードウェアを含む仮想化は必要ないため，プロセス単位でユーザ領域を隔離・制御するコンテナ型の仮想化技
ウェアを含む仮想化よりオーバーヘッドが少ないことからサービスの収容効率を高めることができ，また仮想環境のクライアントクライアント

リクエスト

プロキシ

術が活用されている [3]．コンテナ型の仮想化は，ハード

ホスト

ホスト

やがて
自動で終了

即座に
自動で起動

必要に応じてスケールアウトや収容サーバの変更

起動も高速である．

OS の仮想化技術による物理リソースの効率的利用は，サービスの低価格化と普及に寄与している．一方，個人レ収容サーバA
ホスト

ホスト

ホスト

収容サーバB

ホスト

ホスト

スケール
アップ

ベルでの情報発信などにおいても，テレビ番組で取り上げられたり，著名人のブログで紹介されるなどといった外部の要因により，突発的なアクセス集中が発生するような事

図 1 FastContainer のアーキテクチャ概念図

象が起こる．大企業による情報提供ではアクセスの変動に

Fig. 1 Concept Design of FastContainer Architecture

十分対応できるようなサービス基盤が設計され，突発的なアクセスにも耐えるような対策がなされるだろう．しかし課題についてまとめる．

個人レベルではコンテンツは作れても，それを提供する

本論文の構成を述べる．2 章では，FastContainer アーキ

サービス基盤についての知識はない事が多く，一般に提供

テクチャの概要について述べる．3 章では，現在構築してされているホスティングサービス等を利用するしかない．

いるテスト環境について述べる．4 章では，FastContainer

もちろん負荷変動に対する対策も難しい．低価格ゆえにホの研究開発における今後の課題について述べ，5 章でまとスト・ドメインの集積度が高いようなウェブホスティング

めとする．

サービスでは，ホスティングサービス提供側からの人手による個別の技術支援・運用支援も難しい．突発的な負荷変2. FastContainer アーキテクチャの概要

動に対応するにはサービス基盤側にリソース量の迅速な自本章では，本研究で改良を進めている FastContainer アー

動調整（オートスケール）の仕組みが必要と考えられる．

キテクチャの概要について述べる．なおより詳しい議論やまたその他の課題として，集積度が高いホスティング

実装の詳細については [4] を参照されたい．

サービスでは特に，影響を受けるユーザが多いためにメン

本研究では一般的なウェブホスティングサービスを利用

テナンス等での停止コストが高くなり，脆弱性対応やバーできる程度の知識を持った個人が意識せずとも使えるサージョンアップの頻度が低くなったり，サービスの安定性・

ビスの実装を目指している．そのためには，基本的なサー稼働率が低下する問題もある．

バ運用に加えて，突発的なアクセス集中への対応や脆弱性

このような課題を解決するサービス基盤として，筆者の松本らは FastContainer アーキテクチャを提案している．

対応やバージョンアップをサービス基盤で支援する必要がある．

これは軽量コンテナに基づくホスティング・クラウド基盤

特に，突発的なアクセス集中への対応については自動的

で，サービスを提供する単位であるコンテナの起動・複製・な負荷対策としてオートスケールの機能が必要だが，一般

終了・リソース割当の変更などの状態変化が高速で効率的的な仮想化基盤では以下の課題があると考えている．

という特徴を持つ．この特徴により，外部からのリクエス( 1 ) インスタンス追加処理が低速

ト単位でコンテナの構成を適応的に決定したり，逆に不要( 2 ) ハードウェアリソースの利用効率が低いになったコンテナは次にリクエストが来るまで停止してリ( 3 ) スケーリングすべき状況検知の即時性が低い

ソースの利用効率を上げるといったことが実現できる．

( 4 ) 空きリソース確認のためリソーススケジューリング処

この FastContainer アーキテクチャは商用ウェブホス

理の遅延

ティングサービスの基盤としても活用され始めているが、これを解決するために提案しているのが，コンテナ型

実運用や考察を通してさらなる課題が明らかになってき仮想化を活用したサービス提供基盤である FastContainerている．改良のための研究開発は実運用環境でも行なわれアーキテクチャである．各ユーザの環境は個別のコンテナているが，高負荷時の挙動確認など内容によっては実運用として隔離されており，そのユーザの情報発信のためのコ環境でのテストや評価が難しい場合が考えられる．そのたンテンツや，サービス提供のためのアプリケーションを提め，現在本研究において評価や改良のためのテスト環境を供するホストとして動作する．ただし，一般的なコンテナ

別途パブリッククラウド上に構築している．本論文では，

基盤やクラウド基盤と違い，ユーザコンテンツなどの永続

テスト環境の構築と，FastContainer で解決すべき今後の的な情報はコンテナからは完全に分離されていて，コンテ

c 2018 Information Processing Society of Japan⃝2

Vol.2018-IOT-40 No.2
2018/3/5

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

ナ外のデータベースや共有ストレージだけに保持されている．

ナへのリソース追加によるスケールアップが前提となる．

Heroku[7] の無料プランは，無料プラン利用によるサー外部から特定のホストに対するリクエストが到着する

ビスリソースの使用量を低減するために，リクエスト単位と，その時点で対応するコンテナが反応的に起動され，リで反応的にインスタンスを起動した後，インスタンスの稼クエストが処理される．起動したコンテナは一定期間はそ働時間制限やリクエストを処理できないスリープ時間を設のまま起動し続け，続くリクエストを通常通り処理するが，けている．Heroku のインスタンス上で状態を持つデータ，

その後自動で停止する．あるホストへのリクエストが増え

例えばブラウザからアップロードしたファイルやセッショて 1 つのコンテナでは対応できなくなると，コンテナに割

ン情報は，インスタンス再起動時に揮発し，永続化されなり当てられるリソースの上限を動的に上げたり（スケールい．Heroku の有料プランではスリープ時間がないことかアップ），コンテナの同時起動数を追加したり（スケール

らも，定期的な再起動を行いながら，基本的にはコンテナ

アウト）する．リクエストが減ればリソース割当の上限はを起動させ続けるアプローチによってリクエスト処理を安戻され，増えたコンテナは自動的に停止する．この動作の定的に処理するアーキテクチャと考えられる．

概念図を図 1 に示す．ウェブサービスではリクエストにド

一方で，FastContainer アーキテクチャはリソース効率

メイン名が含まれており，それに対応するコンテナの決定化に加えて，停止や起動，スケーリング処理などの状態のが容易であることから実装が比較的しやすい．IP アドレ

変化を高速化し，反応的に状態を変化させることによってスとポートの組み合わせを各ユーザで変えることにより常にインスタンスを循環させ，変化に強い恒常性を生み出

TCP/UDP に一般化する事も可能と考えている．

すことが主目的である．また，コンテナに置かれた状態をFastContainer アーキテクチャでは，コンテナ型仮想化技

持つデータは全て永続化され，スケールアウト時であって術を利用することでインスタンスの追加処理を高速化するも，複数のコンテナ間で共有される．さらに，サービスレ

とともに，オーバーヘッドが小さいというコンテナの特徴

ベルとアクセス数からコンテナのライフタイムを適応的にと，不要になるとコンテナが停止するという FastContainer

決める手法の検討や，コンテナの投機的起動により変化にの特徴により，(1) と (2) の課題を解決できると考えてい強い恒常性を目指している．

る．また (3) と (4) の課題については現在研究を進めている．関連する課題のいくつかは 4 章で述べる．

3. テスト環境

一般的なサービス基盤では，サービスの継続性から一度本章では，FastContainer アーキテクチャの改良のため現起動したサーバやサービスプロセスは基本的に止めない事

在構築しているテスト環境について述べる．これは「平成が要求される．一方 FastContainer では，コンテナ内のア

29 年度国立情報学研究所クラウド利活用実証実験」におい

プリケーションとデータを分離することで，コンテナを使て提供されたクラウド資源を利用している．FastContainer

い捨てにできるにもかかわらず外部からサービスは継続しアーキテクチャを利用したウェブホスティング環境を本クているように見せている．コンテナは自動で停止・再起動

ラウド資源上に構築し，実運用システムではサービスユー

を繰り返すため，ライブラリ等のバージョンアップは自然

ザへの影響などから難しいような高負荷試験などのテストにユーザ環境反映され，定期的な再起動によりシステムのを通して，FastContainer アーキテクチャを改良すること安定性も向上すると考えられる．コンテナが実行される物を目的としている．

理環境も自然に移動でき，メンテナンス性も向上する．

実体は Amazon Web Service (AWS) 上の IaaS インスタ

ここで，Serverless アーキテクチャ [5] と FastContainer

ンスで，FastContainer 基盤としては，コンテナ収容サー

アーキテクチャとの違いについて述べる．Serverless アーバとして r4.16xlarge 2〜3 台，NFS サービスによる共有ス

キテクチャは基本的にアプリケーションの運用を基盤側

トレージサーバとして r4.2xlarge 2〜3 台，その他アーキテで行わないのに対し，FastContainer アーキテクチャでは，

クチャ上必要な機能を搭載するサーバ群として c4.xlarge

WordPress 等の一般的な CMS を配置・オートスケール可

20 台前後で構成され，他に負荷試験等に利用する検証用ク

能とし，アプリケーションの運用まで一部基盤側で対応すライアントとして c4.xlarge 10 台程度を利用する．各イン

る．また，AWS lambda[6] に類する Serverless アーキテク

スタンスタイプの仕様は表 1 の通りである．

チャでは利用者による所定のコーディングが必要であるため，基本的にはエンジニアや研究者向けである．一方で，

表 1

FastContainer アーキテクチャは汎用的な Web アプリケー

Table 1 Specification of Instance Types

利用しているインスタンスタイプの仕様

ションを利用でき，アクセス集中時には基盤側でスケーリ

r4.16xlarge

Xeon E5-2686v4 2.3GHz × 64・メモリ 488GBングできるため，エンジニアの専門知識を持たない個人向

r4.2xlarge

Xeon E5-2686v4 2.3GHz × 8・メモリ 61GB
ストレージ各 2TB(予定)

けにも提供できる．ただし，FastContainer アーキテクチャ
におけるデータベースのスケーリングは，基本的にコンテ

c 2018 Information Processing Society of Japan⃝c4.xlarge

Xeon E5-2666v3 2.9GHz × 4・メモリ 7.5GB

3

Vol.2018-IOT-40 No.2
2018/3/5

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

もともと FastContainer アーキテクチャは高集積・高効ている．

率なホスティング環境を対象とするため，比較的大規模な計算機資源上でもオートスケールやリソース制御が適切に

4.2 サービスレベルの適切な導出方法

動作するか，また極端な高負荷下でも期待される性能が出

FastContainer アーキテクチャではインスタンス（コンせるかなどをテストする必要がある．このため，インスタテナ）の起動処理が高速である事を前提としているが，現ンスの数や規模については，実運用に供されている環境と状では利用するミドルウェアの種類によっては起動に時間同等の処理能力を持たせることを考慮してサイズ設計してがかかるため，最初のアクセスに対し応答が返るまでに待いる．

ち時間が生じる．

また，NII の実証実験で提供された資源は実験期間がは

例えば，Apache httpd をウェブサーバとした標準的な終了すると全資源が利用できなくなる予定となっている．

WordPress 環境では起動に 3 秒程度の時間が必要であっその後も構築情報の再利用により開発やテストを進められた．また初回起動に 10 秒かかるようなウェブアプリを用

るよう，仮想環境全体の構築は Terraform[8]，各インスタ

意した場合コンテナが起動してレスポンスを返すまでに 10ンスの環境構築は Chef[9] を利用するなどして自動化し，秒かかることになる．

汎用性を持たせている．この自動環境構築は，洗練させれ

このため，アクセス対象ドメインのコンテナが 1 つも起ば組織内で利用するためのプライベートな FastContainer

動していない状態で到着したリクエストは応答までに通常環境構築に利用できるかもしれない．

より長い待ち時間が生じ，そのタイミングに当たるとサー

なお，クラウドでの自動環境構築機能を提供するシステ
ムとしては AWS であれば CloudFormation[10] も利用でき

ビスレベル（そのリクエストによってサービスを受ける利用者のユーザ体験）が損なわれることになる．

るが，Terraform は特定のクラウド環境に依存しておらず，

一度コンテナが起動すると，そのコンテナの起動継続時

組織内で利用するにあたり利用環境等に柔軟に対応可能で間の間は通常の応答時間となるため，そのコンテナで提供ある点から採用した．また，インスタンスごとの環境構築

されるサービスを利用する側全体から見ると，応答時間がに Chef を利用した理由は、その他の構成管理ツールと比長いタイミングに当たる確率によってサービスレベルが変べ中央サーバまたはノードごとへのデプロイが必ずしも必わる事になる．このため，サービスレベルは起動時間，起要でないため小規模〜中規模の環境に向いていること、中動継続時間，アクセス頻度の関数になると考えられる．こ央サーバを利用した構成にも対応するため将来の大規模化のことから，例えばこれぐらいのアクセス数であれば，起にも耐えられること、オープンソースとして周辺のエコシ

動時間に数秒かかってもサービス全体から見た時にはほとステムが競合ツールより整っていることなどである．

んど無視できる，というようなサービスレベルの関係を定

4. FastContainer 研究開発における今後の課題
FastContainer アーキテクチャは商用ウェブホスティン

量的に導けるようにすべきである．この関係式が定義できれば，アクセス数に応じて適応的にコンテナ起動時間を設定することも可能だろう．また，サービス・プロバイダ側
は起動時間にかかる許容時間も設定できるだろう．

グサービスの基盤としても活用され始めているが、実運用や考察を通してさらなる課題が明らかになってきている．
本章では，FastContainer アーキテクチャ研究開発における今後の課題について述べる．

4.3 コンテナ起動時間の影響低減
4.2 節の議論に関連して，コンテナの起動時間はできるだ
け短い方がよいと考えられる．コンテナ内部で利用するミ
ドルウェア等のチューニングで改善できる場合もあるが，4.1 リソース効率化の実証実験

ユーザに高度な技術を要求しないという要件を満たすため

FastContainer アーキテクチャにより，ハードウェアリには，サービス基盤側により汎用的な対策が必要である．

ソースの利用効率改善が可能と考えているが，定量的な評

起動時間自体が短縮できないとした場合に，それでも起価ができていない．
今後，本論文で述べたテスト環境を用い，FastContainer

動時間の影響を減らす（アクセスに対する応答を早くする）
方法としてはによりインスタンスが不要な時に停止・循環させた場合( 1 ) 最低 1 つのコンテナを常に起動と，従来型の永続的なインスタンスの場合を比較して，ど( 2 ) コンテナプロセス実行状態のダンプ・リストア等によの程度リソースが効率化されるかを定量的に評価・検証しる起動状態の凍結と再開ていく．現在のテスト環境の構築状況では，利用している( 3 ) コンテナの事前起動からの切り換えによる循環

クラウド環境の利用期間の関係で実ユーザを付ける事は困( 4 ) 過去のアクセス履歴から将来のアクセス頻度を予測し難と考えているが，実際のウェブホスティングサービスのアクセスパターンを用いた実証的な負荷検証などを検討しc 2018 Information Processing Society of Japan⃝

投機的にコンテナを起動が考えられる．

4Vol.2018-IOT-40 No.2
2018/3/5

情報処理学会研究報告
IPSJ SIG Technical Report(1) は非常に単純な方法だがコンテナ循環による利点はシステムでは，誤検知を減らすことを正としてきたと考え失われ，リソース効率も下がるため，サービスとして提供られるが，FastContainer ではこのようなエラーを許容でする場合は時間単価を上げるような対応になるだろう．

きるシステムとして改善していく方針もあり得る．4.3 章(2) は CRIU(Checkpoint and Restore in Userspace)[11]で述べた投機的起動と関連して，過去のアクセス履歴に基等，実行中のプロセスの状態を凍結してストレージに保存

づき投機的に追加コンテナを起動したりリソース割当を追する技術を利用することで実現可能である．ただし，この加することも可能かもしれない．

手法ではプロセスのメモリ状態も含め保存されることからインスタンスの永続性が残ってしまい，FastContainer で

5. おわりにコンテナを循環することによる利点が失われる．コンテナ

本論文では，インターネットサービスの基盤としてのホ内のライブラリ等を更新するために別途完全なコンテナ再スティングやクラウドサービスに対するさまざまな要求

起動のタイミングが必要となるだろう．

を解決するアーキテクチャとして提案している FastCon-(3) では現在起動しているコンテナの起動継続時間が来tainer について，その概要と，これを改良する研究開発のた時に先に次のコンテナを起動し，リクエストの振り先をために構築しているテスト環境について紹介した．また，変更してから現在のコンテナを停止する．リソースの利用

FastContainer の今後の課題についてまとめた．

効率は下がるが，コンテナ視点では循環することからそれ本論文で述べたテスト環境は現在も構築中で，まだ実際による利点は継承できる．次に起動するコンテナを一旦起に FastContainer の評価や改良に利用できるには至ってい動してから凍結・停止しておくといった (2) と (3) を組みない．今後 4 章で述べたような課題について，本テスト環合わせた実装も可能かもしれない．

境を活用して開発を進め，より利用者目線で使いやすいホ(4) は，予測が的中すれば続くアクセスへの応答は高速化されるが，予測が外れれば起動したコンテナにはアクセスが来ず，無駄になってしまう．
いずれの対策もある程度のリソース効率の低下を伴なう

スティングサービスの構築基盤を目指す．
謝辞

本研究で使用したクラウド資源は，平成 29 年度

国立情報学研究所クラウド利活用実証実験において提供された．また，本研究は，以下の研究助成を受けている．

一方，サービスレベルの向上に寄与するため，ホスティン

松本亮介, 小田知央, 近藤宇智朗, 笠原義晃, 岡村耕二, 嶋

グサービスユーザの希望により追加の費用負担で利用する

吉隆夫, 金子晃介, mruby を利用した軽量コンテナクラウ

ような形になるだろう．

ド基盤の研究開発を介した mruby の大規模・高負荷テス
ト, 2017 年度 Ruby Association 開発助成, 2017 年 10 月.

4.4 要スケーリング状態の迅速な検知と誤検知の扱い
FastContainer の特徴を生かすためには，スケーリング
すべき状況検知のリアルタイム性が重要となる．いくらコ

参考文献
[1]

ンテナの増減・拡縮が高速でも，負荷の増減に対する反応が遅ければ効果が無くなってしまう．
現在運用中の実サービスでは，データ収集は 15 秒単位だが，集計は 3 分毎のためスケーリングのトリガ検知も 3[2]分の粒度となっていて，リアルタイム性が低い．しかし単純に集計時間を短くするだけでは，システムの負荷とは直接関係がない外部ネットワークの状況などによる外れ値の[3]

影響が増加することで誤検知が増加し，コンテナの起動や状態変化が無駄に発生する可能性がある．
これらをうまく適応的に解決するためには，トリガ検知のためのルールベースの設定，長期的な需要予測，短期的な変化点検出，そしてそれぞれのパラメータや閾値の適応[4]

的な設定変更のような観点について，サービス・製品の課
題や基盤の仕様に合わせて検討する必要がある．
一方で，FastContainer はもともとコンテナを高速で効[5]

率的に状態遷移できることに着目していることから，誤検知によりコンテナの状態遷移が短時間で頻発したとして[6]も，システム全体としては許容できるのではないかという観点もある．永続性が高く状態遷移のコストの高い旧来のc 2018 Information Processing Society of Japan⃝[7]

Prodan, R. and Ostermann, S.: A survey and taxonomy of infrastructure as a service and web hosting cloudproviders, 2009 10th IEEE/ACM International Conference on Grid Computing, IEEE, pp. 17–25 (online),
DOI: 10.1109/GRID.2009.5353074 (2009).
Che, J., Shi, C., Yu, Y. and Lin, W.: A Synthetical Performance Evaluation of OpenVZ, Xen and KVM,
2010 IEEE Asia-Pacific Services Computing Conference, IEEE, pp. 587–594 (online), DOI: 10.1109/APSCC.2010.83 (2010).
Soltesz, S., Pötzl, H., Fiuczynski, M. E., Bavier, A.
and 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 (online), DOI:
10.1145/1272998.1273025 (2007).
松本亮介，近藤宇智朗，三宅悠介，力武健次，栗林健太郎：FastContainer: 実行環境の変化に素早く適応できる
恒常性を持つシステムアーキテクチャ，インターネットと運用技術シンポジウム 2017 論文集，pp. 89–97 (2017).
Roberts, M.: Serverless Architectures, (online), available
from ⟨https://martinfowler.com/articles/serverless.html⟩ (accessed 2018-1-31).
Amazon Web Services: AWS Lambda, (online), available from ⟨https://aws.amazon.com/lambda/⟩ (accessed
2018-1-31).
Middleton, N. and Schneeman, R.: Heroku: Up and5

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

[8]
[9]

[10]

[11]

Vol.2018-IOT-40 No.2
2018/3/5

Running: Eﬀortless Application Deployment and Scaling, ” O’Reilly Media, Inc.” (2013).
HashiCorp: Terraform by HashiCorp, (online), available
from ⟨http://www.teraform.io/⟩ (accessed 2018-1-25).
Chef Software: Chef - Automate IT Infrastructure, (online), available from ⟨http://www.chef.io/chef/⟩ (accessed 2018-1-25).
Amazon Web Services: AWS CloudFormation, (online),available from ⟨https://aws.amazon.com/cloudformation/⟩ (accessed 2018-1-31).
CRIU: CRIU, (online), available from ⟨https://criu.org/Main Page⟩ (accessed 2018-1-25).

c 2018 Information Processing Society of Japan⃝

6