2014/07/17に開催されたOSSユーザーのための勉強会#7で発表した資料です

1. CloudConductorの特長と最新動向
2014年7月17日
TIS株式会社
OSSユーザーのための勉強会 <OSS X Users Meeting> #7
CloudConductor と PrimeCloud Controller

2. 2
松井 暢之（まつい のぶゆき）
TIS株式会社
コーポレート本部 戦略技術センター
～2003
2003～2008
2009
2010～2012
現場PJでアーキテクト兼モデラー兼プログラマ兼…を歴任
基盤技術センター（現 戦略技術センター）にて不芳PJの火消しに奔走
全社生産性向上の企画策定に従事
オープンでエッジな技術を活用した事業企画に従事
の企画開発を開始2013～
@n_matsui nbyk.matsui nmatsui

3. Agenda
1. 加速するクラウド化
2. クラウド時代のシステムインテグレーション
3. デザイン指向クラウドオーケストレータ CloudConductor
4. CloudConductorのロードマップ
5. CloudConductorの活用例 ～災害対策のデモ～
3

4. Agenda
1. 加速するクラウド化
2. クラウド時代のシステムインテグレーション
3. デザイン指向クラウドオーケストレータ CloudConductor
4. CloudConductorのロードマップ
5. CloudConductorの活用例 ～災害対策のデモ～
4

5. 情報システム担当者の悩み
5
そろそろウチのシステムも
クラウド化すべきだよな…
新しいこともやりたいし、
ビジネスのアジリティや
コスト削減を考えると
でもクラウドの専門家は
なかなか居ないし
今の資産を全部クラウドへ
持っていけないだろうし
そもそもクラウド化して
データは大丈夫なのか…？

6. IT投資額のトレンド予測
 クラウドとオンプレミスのIT投資額予想（Mary Allen (2014)†1より転載）
 2012年にはオンプレミス1ドルに対してクラウドへの投資額は
わずか0.04ドルであったが、オンプレミスへの投資性向は年々低下し、
2020年には両社がほぼ同じ投資額となる
6
†1 Allen (2014). InsightaaS and TechConnex talk cloud tactics and tools.
http://www.insightaas.com/insightaas-and-techconnex-talk-cloud-tactics-and-tools/
2012年のオンプレミス投資額
2012年のクラウド投資額
2020年のオンプレミス投資額 2020年のクラウド投資額

7. デプロイ先インフラのトレンド予測
 Saugatuck Technologyによる米国、欧州、アジアの大企業CIOに
対する調査（Louis Naugès (2012)†2より転載）
 Business softwareを今後どのようなインフラにデプロイするか？
 2012年には50%だったOn-premiseが2016年にはわずか13%へ激減
 Cloudも伸びるが中期的には半数がhybrid cloud
7
†2 Naugès (2012). Cloud Computing or the IT Industrial Revolution (ITIR): Economic impacts on supply and demand
in IT. http://www.cloud-migration.eu/en/webedition/business-webedition/louis-nauges.html

8. クラウドサービス利用状況
 クラウドサービス利用状況（総務省 情報通信白書 (2013)†3より転載）
 国内企業のクラウド活用は進んでおらず、その傾向は中小企業でより顕著
8
クラウドサービスの
利用実績の日米比較
国内における
クラウドサービスの利用状況
†3 総務省 (2013).平成25年版情報通信白書 http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h25/pdf/

9. Agenda
1. 加速するクラウド化
2. クラウド時代のシステムインテグレーション
3. デザイン指向クラウドオーケストレータ CloudConductor
4. CloudConductorのロードマップ
5. CloudConductorの活用例 ～災害対策のデモ～
9

10. 仮想化・自動化の次はOrchestration
 プライベートクラウドの成熟モデル（Sean Hackett(2012)†5より転載）
 プライベートクラウドはインフラの統合と標準化からはじまり、
仮想化・自動化を経てOrchestrationで終わる
10
†5 Hackett (2012). Internal Cloud Roadblocks Threaten to Disrupt the Pace of Public Cloud Adoption
http://theinfopro.blogs.451research.com/index.php/2012/11/internal-cloud-roadblocks-threaten-to-disrupt-the-pace-of-public-cloud-adoption/

11. Infrastructure as Code と Orchestration
 Infrastructure as Code と Orchestrationの価値
 システム基盤の設計と構築に関する専門家の暗黙的ノウハウをコードに
よってパターン化・標準化し、クラウドへ自動構築できる
11
 手作業による手間の削減とミスの回避
 設計と実装の乖離の防止
 インフラ構成のバージョン管理
 インフラ構成の容易な再現
 自動的なインフラヘルスチェック
 保守しやすく回復性の高い標準化された運用
 etc…
Software-Defined Infrastructure
Storage Network
Compute
オープンなAPI
Configuration
Orchestrator
システムのテンプレート

12. Immutable & Disposable Infrastructure
 ImmutableでDisposableなインフラの価値
 クラウド＋Orchestrationにより、一度構築した環境は二度と更新せず、
システムのリリース毎に環境一式を新たに構築して切り替えれば良くなる
12
 リリースのダウンタイム削減
 容易なフォールバック
 システムのブラックボックス化抑制
 etc…
システム
Release1
システム
Release2
システム
Release3
更新 更新
従来のリリース
システム更新は停止を伴うか、ローリングリリース等の工夫が必要
前リリースは失われるため、フォールバックは容易ではない
更新を重ねるため、同じシステムを再現することは容易ではない
ImmutableでDisposableなリリース
システム
Release1
システム
Release2
新規構築 システム
Release3
新規構築
Х
不要になった
システムは破棄
新システムを構築して切り替えることがリリースにあたる
フォールバックする場合、前リリースに切り替えなおすだけ
パターンからのOne-wayのため、システムはいつでもクリーン

13. Immutable & Disposable Infrastructure
 ImmutableでDisposableなインフラを実現するためには、
システム全体のアーキテクチャと運用プロセスの考慮が必要
 特定サーバにしか存在しないデータが無いシステムアーキテクチャ
 公開APIのみでサブシステムと結合した疎結合なシステムアーキテクチャ
 本番障害発生時でも、構築された本番環境に手を入れずパターンを
修正してシステムを再リリースする運用プロセス
 もしくは、手を入れざるを得なかった環境をパターンへ確実にリバース
できる運用プロセス
13

14. クラウド時代のシステムインテグレーション
 これからのシステムインテグレーションは、
高信頼で安全で柔軟なシステムを、ビジネスのアジリティを
満足するスピードで、安価に
提供しなければならない
 そのためには、
クラウドを前提としImmutableでDisposableなシステムの
アーキテクチャをパターン化し、システムの構築と運用を
自動化・自律化・標準化する
ことが最も重要となる
14

15. Agenda
1. 加速するクラウド化
2. クラウド時代のシステムインテグレーション
3. デザイン指向クラウドオーケストレータ CloudConductor
4. CloudConductorのロードマップ
5. CloudConductorの活用例 ～災害対策のデモ～
15

16. デザイン指向クラウドオーケストレータ CloudConductor
 CloudConductorとは
 インフラ・運用のノウハウを込めたパターンを中心に
 いつでも誰でもどのクラウドにでも
 その時点で最適な非機能要件を持ったシステムを
簡単に構築する、クラウドオーケストレータである
16

17. 特徴①：Infrastructure Design Patterns as Code
 インフラ・運用の設計に関するノウハウを、個別の要件へ分解して
依存関係を整理してパターン化
 形式知化されたパターンを集積し集合知を形成
17
Build
Scripts
Bootstrap
Scripts
Pattern Repository
Configuration
Parameters
Build
Scripts
Other
Resources
Bootstrap
Scripts
Optional
Patterns
アプリケーションやデータに
必要な要件を満たす
インフラ構成の基本パターン
インフラ・運用のノウハウを
個別の要件へ分解してパターン化
Platform
Pattern
非機能要件の
パターン
ここには気を使いたい
・可用性
・性能・拡張性
・運用・保守性
・移行性
・セキュリティ
追加の非機能要件を
実現するパターン
Test
Codes
Configuration
Parameters
Test
Codes
こういうアプリを動かしたい
こういうデータを保管したい
基本構成の
パターン

18. 特徴②：Everyone, EveryTime & EveryCloud
 必要なパターンを組み合わせ、誰でも最適なインフラ設計を獲得
 組み合わせたパターンから各クラウドに適合したテンプレートを生成し
システムを自動構築
 クラウドを跨ってデータを遍在化させ、いつでもどのクラウドでも
システムを再現
18

19. 特徴③：OnDemand Service Level
 必要に応じてRASIS（信頼性、可用性、保守性、完全性、機密性）に
関するパターンを個別適用
 「負荷分散」「可用性」「業務継続」等、必要なパターンを適用した
システムを新規に作って乗り換える
19

20. CloudConductorの全体像
20
Pattern Repositoryパターン製作者
（インフラ専門家）
システム構築
担当者
システムの運用
CloudConductorにより
クラウドOS上へ
構築されたシステム
パターン作成 パターン選択
登録 取得
構築指示
デプロイ
監視・運用
システム運用
担当者
・CLI
・(グラフィカルエディタ)
UI (Pattern Register)
・(設計書からのスケルトン抽出)
・(リバースツール)
Support Tools
・テンプレートを元に指定した
クラウドへプロビジョニング
Provisioner
・パラメータの実体化
・テンプレート生成
Pattern Converter
・リストからパターンを選択
・(パターンのリコメンド)
UI (Provisioning)
・(メタデータ分析)
・(質問応答)
Recommend Engine
システムの構築システムの設計
・Service Design
・Service Transition
・Service Operation
ITSM
・システムの稼働監視
Monitor
・バックアップリストア
・(分散ファイルシステム)
Ubiquitous Data
・Action実行
Operator
・Eventに対するActionを
定義
WorkFlow
・アプリケーションデプロイ
・システム稼働状況と切り替え指示
UI (Operation)

21. 経済産業省の補助金事業
 CloudConductorの開発と公開は経済産業省の補助金事業に採択
21
平成25年度
産業技術実用化開発事業費補助金（ソフトウェア制御型クラウドシステム技術開発プロジェクト）
平成26年度
中小企業等のクラウド利用による革新的省エネ化実証支援事業クラウド基盤ソフトウェア導入実証

22. Agenda
1. 加速するクラウド化
2. クラウド時代のシステムインテグレーション
3. デザイン指向クラウドオーケストレータ CloudConductor
4. CloudConductorのロードマップ
5. CloudConductorの活用例 ～災害対策のデモ～
22

23. CloudConductorの公開
 CloudConductorはApache License 2.0で公開中
 公式サイト
http://cloudconductor.org
 Github
cloudconductor
 Twitter
@ccndctr
 Facebook
CloudConductor
23

24. ロードマップ
2014/03/24
version 0.2.0 Release
version 0.2.1 version 0.2.2
2014/10/末
version 0.3.0 Release
2015/03/末
version 1.0.0 Release
2014/06/30
version 0.3.0 Feature List
2014/11/末
version 1.0.0 Feature List
Architecture
 システム構築のアーキテクチャを再設計
 AWS CloudFormation, OpenStack Heatを活用したプロビジョニングへ移行
 パターン仕様の再設計
 Platform PatternとOptional Pattern
System Management
 外部DNSサービスとの連携
 システムの再構築に伴うIPアドレスの変動に追従（Amazon Route53, Dynamic DNS）
 外部監視システムとの連携
 構築したシステムの基本的な監視項目を登録（Zabbixに対応）
 SSHコンソール
 CloudConductorを通して構築した各インスタンスのSSHコンソールを管理可能に
Patterns
 以下のPlatform Patternを提供
 Java Application with PostgreSQL (Apache, Tomcat, PostgreSQL)
 Rails Application with MySQL (Nginx, Unicorn/Rails, MySQL)
 Platform Patternと組み合わせて利用可能な以下のOptional Patternを提供
 Monitoring (Zabbix)
コアとなるシステム構築機能の
整備を中心に活動予定
24

25. Version0.3でのCloudConductorの機能とサンプルパターン（予定）
25
CloudConductor
GUI
Core
アプリケーションデプロイ
順序制約に従った
システムの停止・再起動
システム構築
運用機能
パターン管理
自身の冗長化
課題管理連携
認証機能
外形監視
(Zabbix)
Platform Pattern
Tomcat HA
(ELB/LBaaS, Apache*n, Tomcat*n,
PostgreSQL+Pacemaker+DRBD*2)
Ruby on Rails HA
(ELB/LBaaS, Apache*n, Unicorn/Rails*n,
PostgreSQL+Pacemaker+DRBD*2)
Optional Pattern
統合監視 (内部監視)
(Zabbix)
ログ収集
(Fluentd)
ジョブ管理
(JobScheduler? Job Arranger for Zabbix?)
Patterns
統合認証
(OpenAM)
Tomcat
(Apache*1, Tomcat*1, PostgreSQL*1)
Ruby on Rails
(Apache*1, Unicorn/Rails*1, PostgreSQL*1)
DNS連携
(Route53, bind9)
ミドルウェア
バージョンアップ
リソースの追加・削減
システム構成の変更・再構築
障害時別クラウド上で復旧
バックアップ管理・
リストア
システム内の
コンソール取得
(GateOne)
VPN Gateway
(?)
Tomcat Cluster
(ELB/LBaaS, Apache*n, Tomcat*n,
PostgreSQL+pgpool-II*n)
Ruby on Rails Cluster
(ELB/LBaaS, Apache*n, Unicorn/Rails*n,
PostgreSQL+pgpool-II*2)

26. Agenda
1. 加速するクラウド化
2. クラウド時代のシステムインテグレーション
3. デザイン指向クラウドオーケストレータ CloudConductor
4. CloudConductorのロードマップ
5. CloudConductorの活用例 ～災害対策のデモ～
26

27. 災害対策デモの想定要件
 想定要件
 災害時にシステムがダウンしても、現実的な目標復旧時点（RPO）/
目標復旧時間（RTO）でサービスを復旧（バックアップ・リストア）する。
1. サービス監視やバックアップ・リストア手順も含め、システム全体を
パターン化
2. パターンより通常系システムを構築
3. 災害発生時には、被災していないクラウドへパターンを用いて
自動的に災対システムを立ち上げ、データも自動的にリストア
4. DNSを自動的に切り替え、通常系と同じURLでサービスを継続
 サービス継続に要する金額的・電力的・人的コストを最小限にする。
 災害対策用のシステムをホットスタンバイさせず、災害発生時に
自動構築することで、無駄なリソース消費・電力消費・費用を抑制
 通常系も災対系も同じパターンから自動構築することで、災対系の
維持運用に手間が取られることが無い
 災対系のURLを覚えておくなど、利用者に負担を書けることが無い
27

28. 28
災害対策デモの全体像
DBWeb/AP Monitoring CoreFileServer
Virtual
Router
DNS
通常時
災害時
Backup
User
User
Virtual
Router
業務システム
障害発生！
④接続先が自動的に切り替わる
Monitoring CoreFileServer
Virtual
Router
DNS DBWeb/AP
Virtual
Router
業務システム
Restore
②パターンを用いて
システムを自動再構築
DBWeb/AP
業務システム
①障害の検知
①監視
②データのバックアップ
通知
設定
変更
Virtual
Router
通常系
通常系 待機系
待機系
③データの自動リストア
業務システム用のサーバ等は
構築されていない

29. デモ実施
 デモ動画はYouTubeにも公開しています
 https://www.youtube.com/user/ccndctr
 https://www.youtube.com/watch?v=Im81YXeUhC8
29
1. 障害検知
4. 別クラウド上で復旧
2. クラウドの状態を確認
Cloud B
Cloud A
Cloud B
DB Web/AP
障害通知
3. 再構築 & データリストア
パターン定義に
従って自動構築
Cloud B
DB Web/AP
Cloud A
Monitoring Server
404
Not Found!
DNS Monitoring
前回構築時
の情報
障害発生時の動作