2015/01/23(金) に行われました、PrimeCloud Controller / OSS MeetUpで講演した資料です。

1. デザイン指向クラウドオーケストレータ
CloudConductorのご紹介
2015年1月23日
TIS株式会社 松井 暢之
PrimeCloud Controller / OSS MeetUP

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

3. 本日の内容
1. クラウド時代のシステムインテグレーション
2. デザイン指向クラウドオーケストレータ CloudConductor
3. CloudConductorを活用した災害対策実証実験
3

4. 本日の内容
1. クラウド時代のシステムインテグレーション
2. デザイン指向クラウドオーケストレータ CloudConductor
3. CloudConductorを活用した災害対策実証実験
4

5. Gartner 2014 Hype Cycle
公開時に削除
クラウドは「幻滅期」へ
 クラウドは「過度の期待」から「幻滅の窪地」へ†
 「クラウドを導入すればビジネスが改善する」という考えは幻想
だということが理解され始めている
5
† Gartner, “Gartner's 2014 Hype Cycle for Emerging Technologies Maps the Journey to Digital Business“
2014-08, http://www.gartner.com/newsroom/id/2819918
Gartner says, “There are many signs of fatigue,
rampant cloudwashing and disillusionment
(for example, highly visible failures)”.

6. 仮想化とクラウド化の誤解
 プライベートクラウドの成熟モデル†
 インフラの標準化と集約からはじまり、仮想化を経て、自動化・
オーケストレーションを満たして初めて「クラウド化」に至る
6
† 451Resarch, “Internal Cloud Roadblocks Threaten to Disrupt the Pace of Public Cloud Adoption“, 2012-11,
http://theinfopro.blogs.451research.com/index.php/2012/11/internal-cloud-roadblocks-threaten-to-disrupt-the-pace-of-public-cloud-adoption/
仮想化＝クラウド化ではない

7. 参考）弊社調査事例
 A社プライベートクラウドにおける仮想マシン構築リードタイム†
7
プライベートクラウド
運用担当
基盤担当
システム管理担当
保守担当
統合運用監視システム
担当 作業フロー
業務システム
開発者
クラウド基盤
保守
キ
ッ
ク
オ
フ
ヒアリング
シート記入
ヒアリング
シート確認
マシン作成
報告書作成
マシン作成
報告書確認
マシン作成
マ
シ
ン
確
認
1~2週間（3~5人日）
1~2週間（3~5人日）
1週間（2~3人日）
1週間（2~3人日）
0.5~1週間（1~3人日）構築準備 4.5~7週間（11~19人日）
0.2~0.5週間（1~2人日）
1週間（1~3人日）
† TIS, “運用側面からのCloudConductor調査“
2014-03, http://download.cloudconductor.org/ whitepaper/運用側面からのCloudConductor評価.pdf
構築作業 0.2~0.5週間（1~2人日）
構築確認 1週間（1~3人日）

8. みずほ情報総研
プライベートクラウド基盤構想コンサルティング
サービスメニュー
公開時に削除
参考）みずほクラウドの事例
 みずほクラウドの取り組み†,‡
 標準化、そして自動化へと段階的に改善を進め、ITインフラ構築の
迅速化（最短3日）とコストの6割削減を実現
 「仮想化技術が脚光を浴びているがそれ単独の効果は限られている。
設計の標準化こそが早くて安いITインフラ提供に欠かせない」
（みずほ銀行 IT・システム統括第一部長 加藤昌彦氏）
8
‡ みずほ情報総研, “プライベートクラウド基盤構想コンサルティング サービスメニュー“
http://www.mizuho-ir.co.jp/solution/improvement/it/network/privatecloud/02.html
† Itmediaエンタープライズ, “IBM Infrastructure Matters 2014 Report：みずほクラウドの挑戦─知恵と工夫で経営に貢献“
2014-05, http://www.itmedia.co.jp/enterprise/articles/1405/29/news053.html

9. 従来のシステムインテグレーションの課題
 仮想化によって解決できるシステムインテグレーションの課題は
ごく一部に限定される
 「必要なリソースを必要に応じてAPIを通じて取得できる」という
クラウドの特性を活用し、
システムインテグレーションのプロセス自体を
クラウドロックインされない形で
クラウドに適合させて初めてクラウド化の効果が得られる
9
リソース利用効率の向上
リソース調達納期の短縮 システムバックアップの容易化
etc…

10. クラウド時代のシステムインテグレーションの姿
 システムの設計を標準化・資産化する
 システムの設計ノウハウを抽象化して標準化し、再利用可能にする
10
アジャイル開発プロセス アジャイル運用プロセス
設計
開発
検証
設計
自働構築
自律運用
リリース
運用標準
(QMS/ITIL、SLAレベル、業務継続計画(BCP)、クラウドポートフォリオ)
インフラ方式標準
(冗長化方式、負荷分散方式、DR／バックアップ方式、ネットワーク設計、統合ログ管理方式、統合監視方式等)
標準運用を含むインフラパターン
(Build/Bootstrap/Test Scripts, Configuration Parameters, ...)
パターン化された設計、自「働」化された構築、標準化された運用
(Orchestrator、Chef/Puppet、Docker等)
ミドルウェア標準
(Web/APサーバ、RDBMS、冗長化ソフトウェア、認証認可システム、統合ログ管理システム、統合監視システム等)

11. クラウド時代のシステムインテグレーションの姿
 システムの構築を自”働”化する
 インフラ運用を機械的に構築するスクリプトを記述
 構築されたインフラを機械的に検証するスクリプトを記述
 スクリプトを元にクラウドのAPIを通じてシステムを自”働”構築
11
インフラ運用の設計書
人が手作業でシステムを構築し検証を行う クラウドが機械的・自働的にシステムを構築し検証を行う
インフラ運用の
構築スクリプト
インフラ運用の
テストスクリプト
インフラ運用のテスト手順書
インフラ運用のノウハウを
プログラムとして資産化
従来のインフラ運用構築 クラウド時代のインフラ運用構築

12. 本日の内容
1. クラウド時代のシステムインテグレーション
2. デザイン指向クラウドオーケストレータ CloudConductor
3. CloudConductorを活用した災害対策実証実験
12

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

14. CloudConductorの特徴①
 Infrastructure Design Patterns as Code
 インフラ・運用のノウハウを依存関係を整理してパターン化
 パターンを機械可読な形式で集積し、集合知化
14
CloudFormation Template
Chef Cookbook
ServerSpec TestCode
…

15. CloudConductorの特徴②
 Everyone, EveryTime & EveryCloud
 必要なパターンを組み合わせて誰でも最適なインフラ設計を獲得
 クラウドを跨りデータを遍在化させ、どのクラウドでもシステムを
再現（現在はAWSとOpenStack Juno）
15

16. CloudConductorの特徴③
 OnDemand Service Level
 「負荷分散」「災害対策」「ログ分析」等の非機能要件は最初か
ら作りこまず、必要になった段階で適用したシステムへ乗り換え
16

17. CloudConductorの情報公開
17
公式サイト http://cloudconductor.org
ソーシャル
https://twitter.com/ccndctr
https://www.facebook.com/cloudconductor
https://github.com/cloudconductor
http://www.slideshare.net/cloudconductor

18. 本日の内容
1. クラウド時代のシステムインテグレーション
2. デザイン指向クラウドオーケストレータ CloudConductor
3. CloudConductorを活用した災害対策実証実験
18

19. 災害対策実証実験の概要
 宮城県登米市・慶應大学・TISで災害対策の実証実験を実施
 CloudConductorを用いたシステムのクラウド間フェイルオーバー
（2014/11/07）
19

20. 災害対策実証実験の概要
 実証実験の様子
20

21. 災害対策実証実験の概要
21
通常時 Backup
利用者
Virtual
Router
通常系
業務システム用のサーバ等は
構築されていない
TIS DC
Virtual
Router
監視系
監視
TIS DC
Internet
Amazon S3
Amazon Route53
(DNS)
災害時
利用者
Virtual
Router
通常系
TIS DC
Virtual
Router
監視系
TIS DC
Internet
①障害の検知
災対系
Amazon S3
Amazon Route53
(DNS)
Virtual
Router
災対系
②パターンを用いて
システムを自動再構築
DNS設定変更
③接続先を自動的に切り替える
データバックアップ
④データの自動リストア
障害発生！
Restore
重要文書システム
重要文書システム

22.  システムのスペック
 通常系：OpenStack Icehouse上のVM（シングルノード）
 災対系：Amazon EC2 東京リージョン上のVM（シングルノード）
 システムの再構築に要した時間 = 6分53秒
災害対策実証実験の結果
CPU 2コア
RAM 4GB
Storage 20GB
22
CPU 4コア
RAM 7.5GB
Storage 2×40GB
時刻 経過時間 イベント
7:05:50 00:00 災害発生（人為的にNICをダウン）
7:06:05 00:15 CloudConductorによる障害検知
7:06:21 00:31 CloudConductorによるシステム再構築開始
7:12:43 06:53 システム復旧

23. 災害対策実証実験の結果
 詳細な結果レポートをCloudConductorの公式サイトで公開
23