デザイン指向クラウドオーケストレータCloudConductorのご紹介

2015年1月23日

TIS株式会社 松井 暢之

PrimeCloud Controller / OSS MeetUP

松井暢之（まつい のぶゆき）

TIS株式会社コーポレート本部戦略技術センター

～2003

2003～2008

2009

2010～2012

2013～

現場PJでアーキテクト兼モデラー兼プログラマ兼…を歴任

基盤技術センター（現戦略技術センター）で不芳PJの火消しに奔走

全社生産性向上の企画策定に従事

オープンでエッジな技術を活用した事業企画に従事

Cloud Orchestrator “CloudConductor” の企画開発とOSS化開始

http://cloudconductor.org

nbyk.matsui

nmatsui

nbyk.matsui

@n_matsui

本日の内容

1. クラウド時代のシステムインテグレーション

2. デザイン指向クラウドオーケストレータ CloudConductor

3. CloudConductorを活用した災害対策実証実験

3

本日の内容

1. クラウド時代のシステムインテグレーション

2. デザイン指向クラウドオーケストレータ CloudConductor

3. CloudConductorを活用した災害対策実証実験

4

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

† 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/

仮想化＝クラウド化ではない

参考）弊社調査事例

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人日）

みずほ情報総研プライベートクラウド基盤構想コンサルティング

サービスメニュー

公開時に削除

参考）みずほクラウドの事例

みずほクラウドの取り組み†,‡

標準化、そして自動化へと段階的に改善を進め、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

従来のシステムインテグレーションの課題

仮想化によって解決できるシステムインテグレーションの課題はごく一部に限定される

「必要なリソースを必要に応じてAPIを通じて取得できる」というクラウドの特性を活用し、

システムインテグレーションのプロセス自体を

クラウドロックインされない形で

クラウドに適合させて初めてクラウド化の効果が得られる

9

リソース利用効率の向上

リソース調達納期の短縮 システムバックアップの容易化

etc…

クラウド時代のシステムインテグレーションの姿

システムの設計を標準化・資産化する

システムの設計ノウハウを抽象化して標準化し、再利用可能にする

10

アジャイル開発プロセス アジャイル運用プロセス

設計

開発

検証

設計

自働構築

自律運用

リリース

運用標準(QMS/ITIL、SLAレベル、業務継続計画(BCP)、クラウドポートフォリオ)

インフラ方式標準(冗長化方式、負荷分散方式、DR／バックアップ方式、ネットワーク設計、統合ログ管理方式、統合監視方式等)

標準運用を含むインフラパターン(Build/Bootstrap/Test Scripts, Configuration Parameters, ...)

パターン化された設計、自「働」化された構築、標準化された運用(Orchestrator、Chef/Puppet、Docker等)

ミドルウェア標準(Web/APサーバ、RDBMS、冗長化ソフトウェア、認証認可システム、統合ログ管理システム、統合監視システム等)

クラウド時代のシステムインテグレーションの姿

システムの構築を自”働”化する

インフラ運用を機械的に構築するスクリプトを記述

構築されたインフラを機械的に検証するスクリプトを記述

スクリプトを元にクラウドのAPIを通じてシステムを自”働”構築

11

インフラ運用の設計書

人が手作業でシステムを構築し検証を行う クラウドが機械的・自働的にシステムを構築し検証を行う

インフラ運用の構築スクリプト

インフラ運用のテストスクリプト

インフラ運用のテスト手順書

インフラ運用のノウハウをプログラムとして資産化

従来のインフラ運用構築 クラウド時代のインフラ運用構築

本日の内容

1. クラウド時代のシステムインテグレーション

2. デザイン指向クラウドオーケストレータ CloudConductor

3. CloudConductorを活用した災害対策実証実験

12

CloudConductorとは

デザイン指向クラウドオーケストレータ CloudConductor

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

13

CloudConductorの特徴①

Infrastructure Design Patterns as Code

インフラ・運用のノウハウを依存関係を整理してパターン化

パターンを機械可読な形式で集積し、集合知化

14

CloudFormation TemplateChef CookbookServerSpec TestCode…

CloudConductorの特徴②

Everyone, EveryTime & EveryCloud

必要なパターンを組み合わせて誰でも最適なインフラ設計を獲得

クラウドを跨りデータを遍在化させ、どのクラウドでもシステムを再現（現在はAWSとOpenStack Juno）

15

CloudConductorの特徴③

OnDemand Service Level

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

16

CloudConductorの情報公開

17

公式サイト http://cloudconductor.org

ソーシャルhttps://twitter.com/ccndctr

https://www.facebook.com/cloudconductorhttps://github.com/cloudconductorhttp://www.slideshare.net/cloudconductor

本日の内容

1. クラウド時代のシステムインテグレーション

2. デザイン指向クラウドオーケストレータ CloudConductor

3. CloudConductorを活用した災害対策実証実験

18

災害対策実証実験の概要

宮城県登米市・慶應大学・TISで災害対策の実証実験を実施

CloudConductorを用いたシステムのクラウド間フェイルオーバー（2014/11/07）

19

災害対策実証実験の概要

実証実験の様子

20

災害対策実証実験の概要

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

重要文書システム

重要文書システム

システムのスペック

通常系：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 システム復旧

災害対策実証実験の結果

詳細な結果レポートをCloudConductorの公式サイトで公開

23