[PrimeCloud Controller / OSS MeetUp] CloudConductorのご紹介
?Download as PPTX, PDF?
1 like?874 views
2015/01/23(金) に行われました、PrimeCloud Controller / OSS MeetUpで講演した資料です。
![[PrimeCloud Controller / OSS MeetUp] CloudConductorのご紹介](https://image.slidesharecdn.com/20150123pccmeetupcloudconductor-150129170843-conversion-gate02/85/PrimeCloud-Controller-OSS-MeetUp-CloudConductor-24-320.jpg)
[PrimeCloud Controller / OSS MeetUp] CloudConductorのご紹介
- 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
- 18. 本日の内容 1. クラウド時代のシステムインテグレーション 2. デザイン指向クラウドオーケストレータ CloudConductor 3. CloudConductorを活用した災害対策実証実験 18
- 19. 災害対策実証実験の概要 ? 宮城県登米市?慶應大学?TISで災害対策の実証実験を実施 ? CloudConductorを用いたシステムのクラウド間フェイルオーバー （2014/11/07） 19
- 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 システム復旧