1.
インタークラウドシステムの
実用化に向けて
棟朝 雅晴
北海道大学 情報基盤センター
副センター長・教授
munetomo@iic.hokudai.ac.jp
@(*

2.
[( %!*.9
7W1)'*%1 LXN*
2G
[@(*
89=)+Y=)H4:* $*(#([,P=)
ZCQ=* (#(B?
;D7S3RN
EIV[57JMO?A/
-Q0KUF @(*6T
アカデミックインタークラウド
シンポジウム２０１４＠北海道大学
２０１４年９月２日

3.
インタークラウド（Inter-Cloud）
• インターネット（Inter-net）がネットワークを相互接続することで世界規模の
インフラを構築したように、クラウドシステムが相互接続、連携することで
世界規模のインフラとしての”Cloud of Clouds”を実現 → インタークラウド
• 相互運用性（Inter-Operability）が重要な条件となる：サービスAPIの共通化、
認証連携などの要素技術に加えて、資源割当ポリシー、運用モデルの確立など、
運用システムとしての実現にあたっては課題も多い

4.
「要素技術」は整備されつつある
• IaaSマネージャ（クラウド管理ソフトウェア）
OpenStack, Apache CloudStack, Eucalyptus, etc.
• Identity Management
Shibboleth, MyProxy, etc.
• SDN controller
MANY!
• マルチクラウドコントローラ
RightScale, Scalr, PrimeCloud Controller, etc.

5.
インタークラウド基盤に必要となる連携技術
• Cloud Exchange (Marketplace, Broker, etc.) with user portal
→ 利用者から見たクラウドの「資源」を提供、管理する。
→ さらに「市場」として資源配分の最適化を実現する。
• Cloud Coordinator with IaaS (resource) manager
→ それぞれのクラウドを連携して管理する。
• AAA (Authentication, Authorization, Accounting) manager
→ 利用者の認証、認可、課金、ログ管理などを行う。
• SDN (Software Defined Network) (connection) manager
→ クラウド間の相互接続管理（一部IaaSに含まれる）

6.
どのレイヤーで「連携」すべきか
• SaaS Layer：Webサービス間の連携（通常のSOA）
• PaaS Layer：汎用PaaSや目的別PaaS間の連携フレー
ムワーク（現状，最も課題が多い）
• IaaS Layer：さまざまな計算資源（インフラ）を連携
させた運用管理：マルチクラウドコントローラ，ブロー
カ，スケジューラ，VPC管理, SDN, etc.
• HaaS Layer：ベアメタルクラウド間の接続・連携運用

7.
開発のターゲット（例）
• Cloud Exchange Marketplace, Broker, etc. User portal including SDN
management
• Cloud federation coordinator for heterogeneous cloud environment
• Scheduler resource optimizer from users’ point of view (not only from
the systems’ point of view)
• Distributed (Big) Data management processing framework
• Distributed PaaS and its management framework
• Security audit management frameworks and support systems
• Total service management and collaboration support systems

8.
関連研究プロジェクト＠北海道大学
• 分散クラウドにおける遠隔連携技術（JHPCN）
• インタークラウドのための認証連携技術
• インタークラウド上でのVPC（Virtual Private Cloud）構築技術
• インタークラウドにおける多目的資源割当最適化
• スパコンとインタークラウドの連携による設計探査フレームワークの構築
• 汎用PaaSによるインタラクティブ進化フレームワークの構築

9.
インタークラウド関連技術の開発（JHPCN）
'!!
$!
'!

10.
)(#'
$) '!%
Heterogeneous!
'! !
)('%
!
MapReduce/MPI
Contr
oller

11.
インタークラウドのための認証連携
• 異なるクラウドミドルウェアの管理下にある複数のクラウドのAPIキーを統一
的に管理するためのフレームワーク
• 大学間クラウド連携（北大・北見工大）での試験を実施
Shibboleth
SAML
SAML
PYTHON Bridge Package
PYTHON Driver Interface
SAML

12.
)% (
'$!#
WebAPI
PYTHON Driver PYTHON Driver PYTHON Driver
OpenNebula CloudStack OpenStack
情報処理学会論文誌Vol.53 No.10 1–7 (Oct. 2012)
学、北見工業大学から構成される認証基盤実験環境を構築
した。本節では、本環境上での実験結果について述べる。
4.1 動作試験
本実験環境では、図に示すように、北海道大学がイン
タークラウドポータル運用機関の役割を持ち、認証ポータ
ル、クラウド管理ポータル、代理証明書リポジトリを運用
する。また、北見工業大学は、インタークラウドアカウン
トIdP 運用機関および資源提供機関としての役割を持ち、
各自が各自が運用するユーザアカウント管理システム（ア
カウントDB）と連携したShibboleth IdP（IdP）、クラウ
ドシステムを運用する。表2 は、実証実験に用いたソフト
ウェアの一覧を示す。
!#$%'()*+,-.
!/01$%'()*+,-.
67+89:;++!
6=?@ABCD!
2345.
EF!
G-,9!
#$%!
H34I7JKL!
MN-OP.
%7+89:;++.
H34IQR
G-,9. '%=?@ABCD.
SRFTU!
VGOWV.
()$.
XY4+W!
*+.
FTU!
QR7JKL.
図5 実証実験環境
確認した。次に、北見工業大学にIdP を構築して北海道大
学のシステムとの連携試験を行った。クラウドシステムと
インタークラウドポータル運用機関に関する実験では、ま
ず北見工業大学のクラウドシステムを構築し、CloudStack
のWebUI からプロジェクト管理アカウントとプロジェク
トの作成を行った。次に、インタークラウドポータル上で
プロジェクトの登録を行った。
4.2 ユーザの利用例
ユーザの利用例として、シングルサインオンを行ってク
ラウドシステムの操作するまでの手順を示している。図
中、実線矢印はユーザの処理、点線矢印はシステムの処理
を意味する。
• ユーザはWeb ブラウザで認証ポータルにサインオン
する。この際、ユーザは自分のアカウントを管理する
インタークラウドアカウントIdP 運用機関を選択し、
インタークラウドアカウントとパスワードを入力する。
認証ポータルはユーザが指定したインタークラウドア
カウントIdP にユーザの認証処理を依頼する。その許
可をもとに、代理証明書リポジトリに対してインター
クラウドID を用いて代理証明書のダウンロードを行
い、クラウド管理ポータルに代理証明書を受け渡す。
• ユーザはクラウド管理ポータルから各クラウドシス
テム上の計算機資源の操作を行う。具体的には、認証
ポータルから受け取った代理証明書をもとに、プロ
ジェクトリストを用いて、ローカルアカウントとの対
応付けを行う。その後、ローカルアカウント（APIKey
とSecretKey）を用いて各クラウドシステムに対応し
たWebAPI でクラウドシステムの操作が行われる。そ
のため、ユーザがAPIKey、SecretKey を入力する必

13.
iii. Ability to satisfy quality of service levels using a scheduler, etc. based on user
needs.
In this paper, we outlined the requirements of the Fig. 3. Conceptual overview of the inter-cloud identity management component
インタークラウド上でのVPC構築の検討，検証
To implement the virtual overlay infrastructure depicted in
• バーチャルプライベートクラウド（仮想クラスタ等）を，イン
タークラウド上に実現するための検証実験を実施 → 北大，北
見工大，AWS(West Virginia/US)，Eucalyptus cloud を利用
Fig. 4, we deployed a VDE switch on the tap0 network
interface of each VM (and physical computer) and connected
the switches using SSH. We also constructed a tool for
automated cluster deployment on the infrastructure. The tool
deploys and configures master and slave nodes using prebuilt
CloudStack [13] templates made from Ubuntu 12.10 64-bit
servers, with MPICH2 [14] installed.
Fig. 4. Implemented virtual overlay infrastructure
C. Procedure for integration into Scalr
1. Create Scalarized template: Create a scalarized template installing the Scalarizer agent specific to the associated
cloud platform on the target template.
2. Create Role: Create a role in Scalr and associate it scalarized template to signify that it should template. (In Scalr, automation requires that images registered as roles, which are then added to Farms orchestrated one-step application deployment.)
3. Add custom scripts: Scalr uses shell scripts for automation.
These can be added to Roles, Farms, or individual for execution at launch, termination, or manually any part of an instance’s lifecycle.
4. Create Farm: Farms pair scripts with roles to facilitate application management. A farm is a collection roles that constitute a single deployment. Thus, a created simply by choosing the roles that make desired application, setting the parameters application, and pairing custom scripts with the roles.
5. Launch: At this point, all the various components parameters of the application are now in place. Thus, application is deployed by simply clicking “launch.”
VI. CONCLUSION
5. Billing and budget management
i. Ability to show the estimated billing charges both for a single cloud and for the
entire system.
ii. Budget management functions for groups and project.
6. Public, private, and jointly-owned
information disclosure, sharing, and
querying management
i. Ability to share and make public information about a wide variety of cloud
resources, billing systems, and service levels.
ii. Contact management functions such as a ticket system for processing queries from
users and sending feedback to the resource manager.
7. Administration, resource registration,
and provisioning management
i. System functions for monitoring and managing the entire inter-cloud system.
ii. Facility to enable administrators at each resource provider to see a listing of users
registered to use their resources, to see the resources being provided, to monitor
resource usage, and to manage the access rights of APIs, etc.
III. AN AUTONOMIC MODEL FOR SHINCLOM
In previous work [3], we introduced a conceptual
autonomic multi-cloud model for the system and focused on
the construction of a user-deployable overlay infrastructure.
We give a brief overview of the model below.
The proposed model guiding our development of the
system is depicted in Fig. 1. It comprises four layers: cloud
platforms specific layer (CPSL), virtual overlay infrastructure
layer (VOIL), application defined networking layer (ADNL)
[4], and cloud applications specific layer (CASL). The cloud
platforms specific layer (CPSL) forms the foundation of our
model as it translates the various calls from the upper layers
into calls that can be initiated on the various cloud platforms. It
also provides low-level autonomic functions such as
monitoring and repair of VMs. The virtual overlay
infrastructure layer (VOIL) provides (1) a seamless virtual
overlay infrastructure that abstracts away the differences
inherent in the various cloud platforms, (2) a homogeneous
context for VMs from disparate clouds, and (3) infrastructure
automation tools and services such as automated cluster and
VPC deployment services.
Fig. 1. Proposed layered autonomic multi-cloud model.
At the application defined networking layer (ADNL), the
focus is on optimization and orchestration of movement of
data throughout the VOIL for each application. In our proposed

14.
インタークラウドにおける資源最適配分
• Web3層システムをインタークラウド上に最適配置
するための多目的最適化フレームワーク
→ コスト，レスポンス，スループット，SLA
を同時に最適化する多目的最適化問題
→ NSGA-II等の多目的
進化計算を用いる
• トレードオフを考慮
したパレート最適解
から利用者がニーズ
に合わせて，実際の
資源配分を決定する
R
Cloud0
Cloud1
InterCloud
Cloud3
Cloud2
DB,
VM7
APP,
VM4
APP,
VM5,
WWW,
VM0
WWW,
VM1
WWW,
VM3
DB,
VM8
DB,
VM6
LB
ਤ 7.3: ࣮ݧ 2ʀେن໛γϛϡϨʔγϣϯ (ӈਤʀ௨ৗ࣌ ࠨਤʀࡂ֐࣌)
（川勝崇史「インタークラウド環境におけるWEBシステムの多目的資源割当最適化に関する研究」，2014）
7.2.3 ࣮ݧ̏
ɹVM ͷ਺ͱ SLA ͷؔ܎ʹ͍ͭͯߟ͑Δ. ࣮ݧ̍ͱ࣮ݧ̎Ͱ͸VM ͷ਺ΛҰఆʹ͠, ଟ໨త
࠷దԽΛߦͬͨ. ͔͠͠, ಉ͡਺ͷVMͰίετΛ཈͑Δʹ͸ݶք͕͋Δ. ैͬͯ, ٻΊΔγες

15.
Cloud Resource Deployment Optimization
(CReDO) in the Inter-Cloud Environment
• 利用者からのシステム構築要求を入力とし，その要求仕様を満たす（仮想）
システムを多目的最適化＋制約充足によるソルバーで生成 → 完全自動化では
なく，パレートフロント上にある複数の解を提示し，利用者が選択し，シス
テムをデプロイする。（乗り換え案内，価格コム的な利用イメージ）
CReDO
Solver /
Optimizer
DB
Response with
Deploy. info
Request with
Spec. info
Public Cloud A
Public Cloud B
Private Cloud
System info.,
Accounting, etc

16.
スパコン・インタークラウド連携による設計探査
• 全国規模の大規模分散設計探査
フレームワークの実現
• シミュレーション（スパコン）
と多目的最適化（クラウド）
を分散データベースで連携
Visualization
• パレート最適解の
Automated,
replication,
データベースを構築
for)DR)and,
（有望な設計パラメータ）
load)balancing
→ 可視化、最適設計Solutions)DB,
(distributed)
Simulation,
(Supercomputer)
Optimization),
DB)management,
(Cloud)system)
Distributed,
Database
(www.jaxa.jp)

17.
Grid Unified Framework for Optimization (Grid-UFO)
MHGRID (Asim, Wahib, Munetomo, 2008-2010)
• グリッドコンピューティング環境において，大規模なシミュレーションと連
携したパラメータサーベイ，最適化の連携フレームワークを提案
Solver(Developer(
(
User(Develops((Registers(an((
Op3miza3on(Problem(
Solvers(Database(
(
Obj(Func(Database(
GridUFO(Checks(compa3bility(of(sovler:obj(func(pair(
User(Develops((
Registers(a(Solver(
User(Selects(a(Solver((an(Objec3ve(Func3on(
GridUFO(Deploys(the(Job(over(Grid(
Solver(
Obj(Func(
Ninf:IDL(
MHAPI(
Distributed(Implementa3on(over(Grid(
MHML(
Obj(Func(Developer(
Submits(Op3miza3on(Job(
Ordinary(User(
MHML(

18.
全国規模での分散データベースの実現
• SINET4の北端～南端（北見工大～北大～琉球大）に渡って，分散データベー
クラスタ拡張についての検証
ス (Cassandra)基盤を構築
→ 応答性能，対故障性，災害対応などについて検証済み
データベースクラスタを構成するノードの数を増加させることによ
る性能上昇の効果を検証する。
データベースクラスタのノード数を変化させ、それぞれの限界リク
エスト処理量を計測する。
4000!
書き込み、読み込みの応答性につ3000!
いての検証
2000!
1000!
10000個のデータを書き込み、読み込みした際に計測したレイテン
シに対する度数分布
6000!
5000!
4000!
3000!
2000!
1000!
0!
0!
3! 6! 9! 12! 15!
1! 4! 7! 10!13!16!19!22!25!28!31!34!37!40!43!46!49!52!55!58!61!64!67!70!73!76!79!82!85!
5000!
4000!
3000!
2000!
1000!
0!
1! 4! 7! 10!13!16!19!22!25!28!31!34!37!40!43!46!49!52!55!58!61!64!67!70!73!76!79!82!85!
Number!of!requests Number!of!requests
write?latency
read?latency
各サイトに
１つずつ
複製なし
Throughput
(request/s)
Number of nodes
クラスタの拡張によって、限界リクエスト処理量が
増加することを検証できた。
read
write
（阿部友哉「インタークラウド環境下における広域分散データベースの構築に関する研究」，2014）

19.
大規模分散データベースによる設計探査
• 大規模な分散データベース＋オブジェクトストレージによる設計探査情報の一
元管理フレームワーク
• 進化計算などの
多目的最適化手法
による設計探査
を支援する
• 解情報を分散DBに，
付随する情報を
オブジェクト
ストレージに保存
DB
s,:?
Object)
Storage(s)
DB
DB
Simulator
s,:?
OptimizerSimulator
Optimizer
s,:f
s,:f
replication
pp
{:s,:f:}
s’
{:s,:f:}
s’
Visualizer
Controller:)
User:Interface
Distributed:DBs
{:p:}
{:s,:f:}
(feedback)
replication

20.
”Virtually infinite”-scale problem-solving on
distributed databased in the inter-cloud
• 最適化アルゴリズムにおける「解」を原理上無限に，インタークラウド上に
実現された分散データベース上に蓄積し，活用する
• 進化計算（遺伝的アルゴリズム）などの多点探索手法を実現
VM
VM
VM
VM
Fitness
Evaluations
(simulations, etc)
VM
VM
Optimization
Engines
(fetch s, f to
generate s’)
Garbage Collector (GC)
to discard unnecessary
solutions (deletions/selections)

21.
汎用PaaSによる世界規模でのインタラクティブ進化フ
レームワークの構築
• PaaS (CloudFoundry) を用いることで、数百万人～数億人規模のユーザが協調
して、進化計算による最適解の「進化」を実現するフレームワークを構築
iGA iGA iGA
・・・
instance
Ubuntu
VM
Redis
Ubuntu
CloudStack
Redis
Ubuntu
VM
Redis
Ubuntu
VM
VM
Database
・・・
Applycation resource
instance
Ubuntu
VM
instance
Ubuntu
VM
・・・
Load Balancer
CloudFoundry
Sever
Interactive Evolutionary
Computation using PaaS
Present
cadndates of
solutions from
the system
Users select
solutions according
to their preferences

22.
次期「北大インタークラウド」への発展
• インタークラウドシステムとしての展開
→ 現状のサービスポータルをインタークラウド対応に拡張
→ 北大クラウドの資源に加えて，パブリッククラウドなどのサービスについ
ても申請でき，一元的に管理できるようにする
→ 利用料金などの自動見積計算，最適化，選択肢の提示等
→ パブリッククラウドとの自動連携メカニズム（オフロード等）
• “(Big) Data” を中心に全てを考える
→ 大学の 「知的財産」としてデータを生成，蓄積，活用するシステム
→ ストレージと計算（スパコン）・処理・配信インフラを密結合
→ さらにインタークラウドとしてSINET等の超高速ネットワークで連携

23.
インタークラウド連携方式の検討
• SaaS Layer : Webサービス間の連携（通常のSOA）
• PaaS Layer : 汎用PaaSや目的別PaaS間の連携フレームワーク
• 本来有るべき姿ではあるが，現状，最も課題が多い
• IaaS Layerさまざまな計算資源を連携させた運用管理
• マルチクラウドコントローラ，ブローカ，スケジューラ，VPC，SDN等
• HaaS Layer：ベアメタルクラウド間の接続・連携運用
• 次期SINETとの密な連携が必須

24.
北大インタークラウドシステムの実現に向けて
• インタークラウドポータル：サービスレベルでの連携
→ Multi-Cloud Controller + Cloud Exchange (Market Place)
• インタークラウドネットワーク：インフラレベルでの連携
→ Inter-Cloud Connector + SDN/VPN solutions on SINET

25.
Inter-Cloud Portal
(multi-cloud controller)
Cloud
Exchange
@(*

26.
[( %!*.9
7W1)'*%1 LXN*
2G
[@(*
89=)+Y=)H4:* $*(#([,P=)
ZCQ=* (#(B?
;D7S3RN
EIV[57JMO?A/
-Q0KUF @(*6T
HPC
Private Cloud
with Supercompter
BigData Storage
Public Cloud A
Scheduler
VPN (SDN)
Public Cloud B
Inter-Cloud
Connector
Public/Comunity Clouds Community Cloud C

27.
クラウドインフラの広域分散化
• クラウドインフラネットワークの基本構成を広域分散環境へ拡
張し，バックボーン＋管理系をSDNで運用？
• バックボーン，管理系ネットワークはセンター管理下で直結
• ユーザ・プロジェクト毎のVPNをバックボーン上に動的構築

28.
@(*

29.
[( %!*.9
7W1)'*%1 LXN*
2G
[@(*
89=)+Y=)H4:* $*(#([,P=)
ZCQ=* (#(B?
;D7S3RN
EIV[57JMO?A/
-Q0KUF @(*6T
Public or community clouds
北大クラウド
Internet
FW FW

30.
VPN
SDN on SINET5

31.
今後に向けた展望
• インターネットと同様，クラウドは必然的に「インターク
ラウド」化していく（既にそうなりつつある）
• 基盤センターとして：スパコンを含めたすべての情報資源
を、インタークラウドのエコシステムとして統合
• （ビッグ）データの集約・処理・活用が本質的
• 「ネットワーク効果」による「予想外の組み合わせ」を促
し、イノベーション（アイディアの「再結合」）を加速