マルチクラウド基盤上のアプリケーション構築自動化アーキテクチャの提案と評価
M2013SE010 岡田 幸大
指導教員 青山 幹雄

1. はじめに

4. アプローチ

近年，複数のクラウド基盤を連携して運用するマルチクラウドが注目されている．そのため，複数のクラウド基盤を管理できるマルチクラウド管理ツールが必要となっている．また，クラウドの環境構築を自動化する構成管理ツールが提供されている．しかし，クラウド基盤ごとにクラウドを構成する要素が異なり，クラウドイメージの管理方法が異なるため複数のクラウド基盤上に同一方法で構成を定義してアプリケーションを配置することは困難である．
本稿ではマルチクラウド管理ツールである Scalr に基づき，同一方法で複数のクラウド基盤へクラウドの構成定義を可能にする．これにより，マルチクラウド上へのクラウドの構築とアプリケーションの配置を自動化する方法を提案する．

クラウド基盤ごとに異なる構成要素とアプリケーションを配置する振る舞いを抽象化することで，同一のインタフェース上から各クラウド基盤に対応した構成を定義する．クラウドの構成は抽象 API を定義する．アプリケーション配置の振る舞いは，クラウド構築者によって選択されたアプリケーションに対応するイメージファイル(イメージ ID)と Recipe を抽出する．これにより，同一方法でマルチクラウドの構成定義と，アプリケーションの自動配置を可能にする(図 1)．

2. 研究課題

VMの構築とアプリケーション
イメージファイル展開
個別配置統一
インタフェース

3. 関連研究3.1. Scalr[3]Scalr は複数のクラウド基盤を管理するマルチクラウド管理ツールである．クラウドの構成をDBに定義することで，クラウドの構築を自動化できる．クラウドサービス全体の定義は Farm，クラウドの構成は Farm Role に定義する．アプリ
ケーションの役割は Role に，対応するクラウドイメージはRole Images にそれぞれ定義する[4]．Farm を実行すると，定義された構成を抽出してクラウドを自動構築する．
3.2. Chef[5]Chef はクラウドの環境構築を自動で行う構成管理ツールである．クラウドの環境を Recipe と呼ばれる Ruby ファイルで記述しておき，Recipe を実行することで，適用したサーバの環境を自動構築する．

構成定義
クラウド構成の抽象化

AppOSVM

VM

VMM(Xen)VMM(KVM)

Amazon EC2OpenStack

振る舞い抽象API2.1. クラウド基盤ごとの構成要素の差異
クラウド基盤ごとに，クラウドを構成するために用いるAPIとその引数が異なる．マルチクラウド上にクラウドを構築するためには，各クラウド基盤の構成の定義に用いる構成を確認し，適切な値を適用して構成を定義する必要がある．
2.2. クラウドイメージの管理方法の差異
クラウド基盤ごとにクラウドを構築するためのイメージファイルの管理方法が異なる．そのためクラウド基盤ごとにアプリケーション配置の振る舞いが異なる．従って，任意のクラウド基盤上へのアプリケーションの自動配置が困難である．

AppOS

アプリケーション配置
App配置の

図 1 アプローチ

5. 構成の抽象化
5.1. クラウド構成の抽象化
クラウド基盤ごとに異なる構成要素を抽象化して定義する(図 2)．Scalr でクラウドを自動構築するためには，FarmRole にクラウドの構成を定義する必要がある．Farm Roleには構築する対象のクラウド基盤やアプリケーションの役割を示す RoleID などを定義する．詳細な構成は Farm RoleSettings に定義する．クラウドの構成を定義するためのAPI 名は name に記述し，引数名は value に記述する．
Abst_Name
abst_nameplatform
name

API_Signature

Abst_Value
abst_value
platform
value

Farm_Role_Settings
farm_roleid
name
value

Farm_Roles
Id＊
1 farmid
alias<<USE>> role_id
platformcloudlocation

図 2 クラウド構成抽象化
5.1.1. API 名の抽象化
Farm Role Settings で定義される API 名は，各クラウド基盤で共通に用いられる API 名と，クラウド基盤ごとに異なる API 名に分類される．共通な API 名は全てのクラウド基盤の定義に利用できる．異なる API名は抽象化して定義することで，各クラウド基盤に対応した API 名を抽出する．
5.1.2. API の引数の抽象化
クラウド基盤ごとに API 名が異なると，適用する引数や抽象度が異なる．クラウド基盤ごとに異なる引数名を抽象化し，各クラウド基盤に同一の構成になる抽象 API を定義する．
インスタンスタイプを例にして抽象 API を示す(図 3)．

アプリケーション自動配置基盤

AmazonEC2
aws.instance_Type

OpenStackopenstack.flavor-id

クラウド
構成定義

Farm生成Farm Role
登録

クラウド構築者<<include>>

アプリケー
ション指定

クラウド構築Instance Type

抽象API

クラウド基盤

アプリケー
ション構築

Scalr

Chef

図 5 アーキテクチャのユースケース
Disk

NumCpus

Memory図 3 インスタンスタイプの抽象化
5.2. アプリケーション配置の振る舞いの抽象化
アプリケーション配置の振る舞いを抽象化し，同一方法で異なるクラウド基盤へアプリケーションを自動配置する．
Amazon EC2[1]ではイメージファイルとして，あらかじめ様々なアプリケーションが配置されているので，Scalr のRole で定義されている OS とアプリケーションの役割から，対応するイメージ ID を取得できる．OpenStack[2]では多数のイメージファイルを管理することが困難なので，あらかじめベースとなる OS のイメージファイルのみを配置する．
OS のイメージ ID とアプリケーションを配置する Recipe 名を抽出して Farm Role に定義することで，クラウドの構築とアプリケーションの配置の自動化を可能にする(図 4)．

6.2. アーキテクチャの構造
提案アーキテクチャの構造を示す(図 6)．Scalr はクラウ
ド構築者からの指示に従ってクラウドを構築する．クラウドの構成を管理するための情報はデータベース上に保存され，新しいクラウドの構成を定義することで，クラウドの自動構築を可能にする．データベース上には，抽象 API とアプリケーションの役割に対応した Recipe 名を定義して作成する．
Chef には環境構築をする Recipe を作成する．そして，クラウド構築者から選択された構成をもとに，各クラウド基盤に対応した構成を抽出して Farm Role に定義する Farm 生
成プログラムを Scalr 上に作成する．Farm を実行すると，Farm Role に定義された構成を抽出する．抽出した構成を用いてクラウドを構築し，イメージIDとRecipeによってアプリケーションを自動配置する．
Scalr

配置振る舞い定義
統一
ア プリケーション選択 イ ンタフェース

クラウド構築指示
クラウド構築とア プリケーション配置

構成定義
Farm Role

AmazonEC2
イメージファイルの参照

VM
VM
クラウド基盤

クラウド
構築

Role
RoleID抽出
Recipe名抽出 Role Images
ImageID抽出
Recipe名

クラウド
構築者

構成抽出

クラウド基盤指定

OpenStackChef
RecipeVM
VM
クラウド基盤

Recipe抽出

ア プリケーション
自動配置

Farm実行 Cloud
WebUI
自動構築
API
構成指定
Farm生成Recipeプログラム
Recipe
抽出Chef

クラウド基盤Image FileAmazonEC2
Image File
OpenStack

イメージID取得
構成定義

Farm抽出

低水準API

Recipe名
抽出

高水準API

Chef に保存された Recipe を取得する．Recipe を適用する
ことにより，自動的にアプリケーションを配置する．

AbstNameAbstValue

Recipe名

抽象API

Recipe一覧

Farm

Farm Role
Settings

Roleimages

FarmRole

Role

ImagesSCALRDB

図 6 アーキテクチャの構造
図 4 アプリケーション構成の抽象化

6. アプリケーション構築自動化アーキテクチャ
6.1. アーキテクチャのユースケース
提案する構築アーキテクチャのユースケースを示す(図5)．アクタはクラウド構築者，Scalr，クラウド基盤，Chef である．クラウド構築者は Scalr を用いて新しい Farm の生成とFarm Role を登録する．Farm Role を登録するためには，クラウドの構成の定義や，配置するアプリケーションの指定をする必要がある．Scalr を用いて Farm を実行すると，Farm Role に定義された構成をもとに，クラウド基盤に対してクラウドの構築を指示する．また抽出した Recipe 名から，6.3. アーキテクチャの振る舞い
提案アーキテクチャの振る舞いを示す(図 7)．クラウドの構築者は，Farm生成プログラムをWeb UI から利用する．
クラウドサービス全体を定義する Farm を生成後，クラウドの構成を定義する Farm Role を登録する．クラウドの構成と構築する対象となるクラウド基盤，配置するアプリケーションを指定する．各クラウド基盤に対応したAPI名とその引数を抽出する．また，Amazon EC2 であれば，選択した OSとアプリケーションの組み合わせとなるイメージ ID を抽出する．OpenStack であれば，ベースとなる OS のイメージ
ID と，配置するアプリケーションを自動構築する Recipe 名を抽出する．抽出した構成を Farm Role に定義し，Farmに登録する．複数のクラウドを構築するには Farm Role の登録を複数回実行する．Farm を実行すると，登録されたFarm Role から構成要素を抽出し，また Open Stack であれば Recipe も抽出し，クラウドを自動構築する．
Role FarmFarm生成抽象 Recipe
WebUIAPIプログラム
名 Role Images Role
httpFarm
アクセス
生成指示
Farm生成クラウド構築者

FarmChef

クラウド基盤

Loop[1,インスタンス数]
クラウド基盤構成指定

詳細API
取得
RoleID抽出
ImageID抽出

opt[クラウド基盤=OpenStack]
Recipe名抽出
構成定義

Farm実行指示

Farm Role
登録

Farm実行構成抽出
opt

Recipe抽出
インスタンス起動

図 7 アーキテクチャの振る舞い

7. プロトタイプの開発
提案アーキテクチャのプロトタイプを開発した． プロトタ
イプ実行の前提作業として，Amazon EC2 のイメージファ
イル一覧が記録された Role を取得することと，Open Stack
上に Ubuntu12.04 のイメージファイルを配置し，Scalr のデータベースにイメージ ID を登録する．
7.1. プロトタイプの実行環境
プライベートクラウドはOpenStack上に構築する．パブリッククラウドは Amazon EC2 上に構築する．クラウド管理ツールは Scalr を構築して利用する．構成管理ツールはChef を構築して利用する．
7.2. プロトタイプの実装
7.2.1. データベースの各要素の定義(1) API 名の定義
クラウド基盤ごとに異なる API 名を抽象化して定義する．
インスタンスタイプとセキュリティグループを抽象化して定義した．抽象 API 名とクラウド基盤を指定することで，各クラウド基盤に応じた API 名を抽出する．
(2) インスタンスタイプの定義
クラウド基盤ごとにインスタンスタイプの引数名が異なるため抽象化して定義する．各クラウド基盤によって異なるリソース量を定義することで，同一のリソース量を持つようにクラウドの構成を定義する．なお OpenStack はリソース量を詳細に定義可能なため，Amazon EC2 で提供されるリソース量と統一する．
(3) Recipe の定義
アプリケーションを自動配置する Recipe を作成する．ク
ラウド構築者によって指定されたアプリケーションの役割に対応する Recipe を抽出できるように定義する．Recipe を適用することでアプリケーションを自動配置する．
7.2.2. Web アプリケーションの作成
定義したデータベースを利用して，マルチクラウド上へクラウドの構成を定義してアプリケーションを自動配置する
WebアプリケーションをPHPで作成した．アプリケーションの規模は 527(LOC)である．
(1) Farm の生成生成する Farm 名を入力し，REST API を用いて新しいFarm を生成する．
(2) Farm Role の構成定義
クラウドを構築するための構成を選択することで，FarmRole に定義する要素を抽出する．構築する対象のクラウド基盤，OS のバージョンや配置するアプリケーション，インスタンスタイプなどを選択する．
(3) Farm Role の登録抽出した値を用いて，Farm に対して Farm Role を登録する．REST API を用いて登録する．
7.3. プロトタイプの構造プロトタイプの構造を示す(図 8)．ScalrはOpenStackとAmazon EC2から提供されるID，パスワードを用いて認証し，Scalr から VM を管理可能な状態にする．また Chef と認証することで，Recipe を抽出可能な状態にする．Open
Stack 上では VM を構築するために必要な仮想ネットワークを構築する．クラウドの構築者は，Scalr を用いて Farmの生成やFarmRoleを登録する．生成したFarmを実行することで，定義された Farm Role の構成とイメージ ID，Chef の Recipe を抽出してクラウドの構築とアプリケーションを配置する．構築したクラウドにアクセスし，アプリケーションが利用可能になる．
アクセス
認証，自動構築
Farm生成，実行

ブラウザ
Windows

VM
ApacheUbuntu12.04
Amazon EC2

VPC

外部ネットワーク

認証，
Scalr
自動構築
Ubuntu12.04
Recipe適用
アクセス

Recipe抽出
OpenStackCentOS

VM
ApacheUbuntu12.04

LAN

Chef
Ubuntu12.04
仮想ネットワーク

図 8 プロトタイプの構造

8.

プロトタイプの適用

8.1. 例題の概要
プロトタイプを用いて Farm を生成し，各クラウド基盤にApache を配置する Farm Role を登録する．これにより，OpenStack と Amazon EC2 上に，Ubuntu12.04 とApache がインストールされたクラウドを自動構築する．

Farm Role Settings

Farm Role

8.2. クラウド構成の定義作成したプロトタイプを用いて定義された Farm Role とFarm Role Settings の詳細を示す（表 1）．Amazon EC2では選択したOSとアプリケーションを示すイメージ ID を抽出した．OpenStackでは選択したOSからベースとなるOSのイメージ ID を抽出し，アプリケーションの役割からRecipe 名を抽出した．
表 1 定義された構成
クラウド基盤
Farm Role ID
Alias
Role ID
Platform
Cloud Location
Image ID

Amazon EC277App-ec2
38355
ec2
ap-northeast-1
ami-7876c679

OpenStack78
App-os38240
openstack
RegionOne
bafc5451-895d-413696b3-5873dcba8e3f
1
1
1
2
9600
9600
1
_default
auto["recipe[app::default]"]2

scaling.enabled1
scaling.max_instances 1
scaling.min_instances 1
scaling.polling_interval 2
system.timeouts.launch 9600
system.timeouts.reboot 9600
chef.bootstrap
chef.environment
chef.log_level
chef.runlist
chef.server_id
aws.instance_type
t1.microaws.security_groups.list ["default","scalr.i7x
e1381ccd.ip-pool"]openstack.flavor-id
6
openstack.ip-pool
83c9e17c-445f-45f6-a9
f5-35a89dbe7d44
openstack.networks["dd566ff8-45a3-498389fa-ab8795e1f816"]["default","scalr.i7xe13
openstack.security_groups.list
81ccd.ip-pool"]ウド基盤に構築する際の作業プロセスを削減した．同一構成でクラウドを構築する場合は，Farm Role の定義回数は1 回のみで，マルチクラウド上へ自動配置が可能になる．

10. 考察10.1. 同一構成による設定の誤りの削減
提案アーキテクチャでは，同一方法でマルチクラウド基盤上にアプリケーションを配置することを可能にした．そのため，マルチクラウド基盤に同一の構成で定義する際に，構成定義の設定の誤りの削減につながる．
10.2. アプリケーション数の増加の対応
マルチクラウド上に配置するアプリケーション数が多くなる場合や，アプリケーションの配置に必要な設定項目が増加する場合，アプリケーション配置時間が手作業に比べてさらに短縮できると考える．

11. 今後の課題
11.1. クラウド構成の変更管理
提案アーキテクチャはマルチクラウド上に同一方法で構成定義ができるが，構成の変更管理はできない．クラウド構
築者によって，変更管理を可能にする必要がある．
11.2. 定義可能な構成の追加
プロトタイプではネットワーク構成や外部ストレージの利用の定義が行えない．そのため抽象 API を拡張することにより，妥当性を確認する必要がある．
11.3. 柔軟なクラウドの構成定義
マルチクラウド上のアプリケーション配置は，同一の構成に限定される．クラウドの構成と配置するアプリケーションの制約がない柔軟な定義を可能にする必要がある．

9. 評価

12. まとめ9.1. アプリケーションの自動配置
Amazon EC2 上と OpenStack 上に配置したアプリケーションにアクセスできることを確認した．これにより，定義した抽象 API の妥当性を確認した．
9.2. アプリケーション配置の時間削減
アプリケーション配置の振る舞いを抽象化し，マルチクラウド上へのアプリケーションの配置を自動化した．これにより，アプリケーションが利用できるようになるまでの時間を短縮できた．手作業は 3 分10 秒から 1 分に短縮し，削減率は68%になった（表 2）．
表 2 手動作業の削減率

本稿では，クラウド基盤ごとに異なる構成やアプリケーション配置の振る舞いを抽象化して定義した．これにより，同一方法でクラウドの構成を定義し，マルチクラウド基盤上へアプリケーションの配置を可能とするアーキテクチャを提案した．提案アーキテクチャのプロトタイプを構築し，同一方法でAmazon EC2とOpenStackに対応した構成を抽出して定義した．定義した構成を用いて，マルチクラウド基盤上にクラウド構築とアプリケーション配置を自動化した．

作業内容
Farm 生成Farm Role 登録アプリケーション構築
合計

従来方法 提案方法 削減時間 削減率33%
1 分 30 秒
15 秒
-30 秒
45 秒
1 分 40 秒
0 秒 -1 分 40 秒 100%
3 分 10 秒
1 分 -2 分 10 秒 68%

9.3. Farm Role 生成のプロセスの削減
抽象 API を用いることで，同一方法でマルチクラウドに対応した構成定義が可能になった．そのため，複数のクラ参考文献[1] Amazon, Amazon EC2 (Amazon Elastic Compute
Cloud), http://aws.amazon.com/jp/ec2.
[2] K. Jackson, OpenStack Cloud Computing
Cookbook, Packet Publishing, 2012.
[3] Scalr Enterprise Cloud Management Platform,
http://www.scalr.com.
[4] Scalr Wiki, https://scalr-wiki.atlassian.net/wiki/
display/docs/Home.
[5] 吉羽 龍太郎ほか，Chef 実践入門，技術評論社，2014．