【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築

Copyright © 2015 TIS Inc. All rights reserved.
クラウドオーケストレーションが描く
明日からのシステム構築
2015年9月14日
TIS株式会社戦略技術センターエキスパート松井暢之
クラウドオーケストレーションと構築・運用の「アジャイル化」
～クラウド時代におけるシステム運用の課題と対策勉強会～

Agenda
1. クラウド時代におけるシステム構築の課題
1. クラウドロックイン
2. インフラ運用の手法
3. インフラ運用のプロセス
2. インフラ運用の自”働”化とクラウドオーケストレーション
3. クラウドオーケストレーションの活用案
4. まとめ
2

クラウド市場の拡大
 2013年度の国内クラウド市場は6,257億円であり、2018年度には
2.9倍の1兆8,000億円まで拡大する。
 うちプライベートクラウドの比率は2013年度で70.1%を占めるが、
2018年度には73.0%と緩やかにシェアを高める。
3
出展：MM総研, "国内クラウドサービス需要動向(2014年版)“, 2014-11
http://www.m2ri.jp/newsreleases/main.php?id=010120141104500
公開時に図表削除

クラウドファーストの浸透
 新規システム構築時にクラウドの活用を検討する法人ユーザーは、
2013年調査時の69.1%から78.1%へ9ポイント増加している。
 原則的にプライベートクラウドやパブリッククラウドを利用する
割合は40.5%（2013年調査時35.0%）
 クラウドを検討に入れる割合は37.6%（同34.1%）。
4
出展：MM総研, "国内クラウドサービス需要動向(2014年版)“, 2014-11
http://www.m2ri.jp/newsreleases/main.php?id=010120141104500

クラウドの真の力を引き出せているか？
 米国国立標準技術研究所（NIST）によれば、クラウドは次のように
定義される。
 共用の
 （APIを通じて）構成可能な
コンピューティングリソースの集積に、
 どこからでも、簡便に、必要に応じて、
 ネットワーク経由でアクセスすることで、
 最小限の利用手続きで速やかに
 リソースが割当てられ提供されるもの
5
出展：NIST, “The NIST Definition of Cloud Computing“, 2011-09
The Awakening‘s giant hand by WorldIslandInfo.com, on Flickr
あなたのインフラ運用はクラウドの能力を十全に活用しているだろうか？

クラウド時代のシステム運用の課題
 クラウド時代のシステム運用の課題として、複数のクラウドを管理
運用するプロセスの課題や、属人化した現状から抜け出せず機械化・
自動化が進んでいない課題などが挙げられている。
 また「クラウドを利用する」ためには、まず「クラウドを選択する」
必要があるが、クラウドの選択にもリスクがある。
6
プライベート・クラウド・コンピューティングの課題に関する調査
出展：ガートナー, “INF-13-157 Research Note “, 2014-10
http://www.gartner.co.jp/b3i/research/141014_inf/index.html
運用管理の課題（複数回答）
出展：Tech Target Japan, “システム運用管理に関する読者調査“, 2014-01
http://techtarget.itmedia.co.jp/tt/news/1401/09/news03.html
公開時に図表削除公開時に図表削除

Agenda
4. まとめ
7

パブリッククラウドの市場推移
 AWSの一人勝ちが続くが、Microsoftが急速に追い上げてきている。
 一方で厳しい戦いを強いられるクラウドも多く、二極化が進んでいる。
8
LEADERS:
CHALLENGERS:
市場ニーズに対応する成熟した製品をリリース
しており、市場が進化した場合でもリーダーの
座を維持できるビジョンを明示している
実行能力に優れているが、新たな顧客に最新
かつ強力な価値を提案する戦略を欠く
VISIONARIES:
NICHE PLAYERS:
市場の進化に関するビジョンを持っているが、
ビジョンを実現する能力が実証されていない
特定の市場セグメントで成功を収めているか、
またはイノベーションを実現する能力や競合
他社を上回るために必要な能力が限られている
出展：Gartner “Magic Quadrant for Cloud Infrastructure as a Service“ 2012年度～2015年度を加工

プライベートクラウドの市場推移
 実際に利用しているプライベートクラウドはVMWare製品が多いが、
検証中・計画中も合わせるとOpenStackも比肩する。
 エンジニアが注目するOSSクラウド基盤ツールはOpenStackが支配的
で、CloudStackやEucalyptusの将来は厳しいと言わざるを得ない。
9
Private Cloud 利用状況（2014年） Private Cloud 利用状況（2015年）
出展：RightScale “Cloud Computing Trends“ 2014年版と2015年版を加工
月間のGit commit数開発者数の累積
出展：婉兮清扬 “CY15-Q1 Community Analysis“, 2015-04
http://www.qyjohn.net/?p=3801

クラウドサービスの継続性への期待
 企業がクラウドサービスを導入する際には、サービスの継続性が
重視されている。
10
出展：NRI Secure Technologies, “企業における情報セキュリティ実態調査2011”を加工, 2011-12

クラウドサービスは終了するという現実
 クラウドサービスは永遠に継続されるわけではなく、クラウド事業者
の戦略変更のためにサービスが利用できなくなる場合もある。
 クラウドストレージサービスを展開していたNirvanix社が倒産し、
2013年9月に月末でサービスを終了することを告知
 OpenStack創始者の1人であるChris Kemp氏が2011年に設立した
プライベートクラウド構築アプライアンスを販売するNebula社は、
2015年4月、会社を廃業
 LINEは2013年6月、オンラインストレージサービスやオンライン
アルバムサービス等を終了し、収益性の高いサービス開発に集中
 Googleは2013年7月、当時100万人の利用者が居たRSSリーダー
のGoogle Readerを終了
11
Clouds, storms and sunsets by MattysFlicks, on Flickr

クラウドロックインの回避
 クラウドは永遠ではない。しかし、もはや後戻りはできない。
12
Effraction by Sébastien Launay, on Flickr

Agenda
4. まとめ
13

インフラ運用の現実
 かつての（今も？）のインフラ運用は、手順書とパラメータシートを
元に、エンジニアが手作業で一行一行コマンドを入力していた。
 人為的ミスを防止するために、コマンドを実行する毎に複数人で再鑑
するチェック体制が必要だった。
14
Marc and Lancelot in Redwood City by Sean Ellis, on Flickr

インフラ運用の現実
 Shell Script等を用いてある程度はインフラ運用作業を自動化してい
るとしても、まだまだ不十分と言わざるを得ない。
15
出展：REBELLABS, “IT OPS & DEVOPS PRODUCTIVITY REPORT 2013 “, 2013-04,
http://zeroturnaround.com/rebellabs/rebel-labs-release-it-ops-devops-productivity-report-2013/4/

手作業の運用による弊害
 手作業の運用には、様々な弊害がある。
 作業の実施に非常に手間と時間がかかる
 コマンドのコピペミスによる障害発生
 コマンドの実行順序を間違えたり、
重複実行してしまうことによる障害発生
 環境の前提条件が異なっていることに
気づかずにshell scriptを流してしまう
ことによる障害発生
 苦労する割に障害が無くてあたりまえ、
という心的外圧
16
76/365 - Tired by Shane Robinson, on Flickr

手作業の運用が引き起こす障害
 システム停止に至る障害のうち、２～３割は作業ミスが原因と言われ
ている。
17
出展：IT media エンタープライズ, “日常でも、いざという時にも役立つバックアップとは？”, 2013-03
http://www.itmedia.co.jp/enterprise/articles/1303/28/news003.html
出展：キーマンズネット, “運用現場の課題と解決第二回”, 2012-12
http://www.keyman.or.jp/kc/30005390/

手作業の運用からの脱却
 労働集約的な手作業の運用は、もはや時代遅れと言わざるを得ない。
18
Tesla Autobots by Steve Jurvetson, on Flickr

Agenda
4. まとめ
19

クラウドの力を活用できていないインフラ運用プロセスの例
 従来のインフラ運用プロセスを踏襲したまま、単なる仮想化基盤として
クラウドを用いるだけでは、クラウドの恩恵を得ることはできない。
20
プライベートクラウド
運用担当
基盤担当
システム管理担当
保守担当
統合運用監視システム
担当作業フロー
業務システム
開発者
クラウド基盤
保守
キ
ッ
ク
オ
フ
ヒアリング
シート記入
ヒアリング
シート確認
マシン作成
報告書作成
マシン作成
報告書確認
マシン作成
マ
シ
ン
確
認
1~2週間（3~5人日）
1~2週間（3~5人日）
1週間（2~3人日）
0.5~1週間（1~3人日）構築準備 4.5~7週間（11~19人日）
0.2~0.5週間（1~2人日）
出展：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・システム統括第一部長加藤昌彦氏）
21
出展：Itmediaエンタープライズ, “IBM Infrastructure Matters 2014 Report：みずほクラウドの挑戦─知恵と工夫で経営に貢献“, 2014-05
http://www.itmedia.co.jp/enterprise/articles/1405/29/news053.html
みずほ情報総研, “プライベートクラウド基盤構想コンサルティングサービスメニュー“
http://www.mizuho-ir.co.jp/solution/improvement/it/network/privatecloud/02.html

クラウドの真の力を引き出すためには
 仮想化によって解決できるシステムインテグレーションの課題は、
ごく一部に限定される。
 リソース調達の短縮、リソース利用効率の向上、・・・
 クラウドを十全に活用するためには、クラウドが備えるAPIを活用し、
「労力を減らして品質を向上させる」ことがカギとなる。
 クラウドを活用するためのステップ
1. 標準化
2. 集約
3. 仮想化
4. 自動化
5. オーケストレーション
22
出展：451Resarch, “Internal Cloud Roadblocks Threaten to Disrupt the Pace of Public Cloud Adoption“, 2012-11

今までのインフラ運用プロセスからの変革
 インフラ運用の設計ノウハウを標準化・コード化し、APIを用いて
システム全体を自動的に構築（オーケストレート）する。
 運用して得られたノウハウをコードに反映し次のサイクルで活用する。
23
アジャイル開発プロセスアジャイル運用プロセス
設計
開発
検証
設計
自働構築
自律運用
リリース
運用標準
(QMS/ITIL、SLAレベル、業務継続計画(BCP)、クラウドポートフォリオ)
インフラ方式標準
(冗長化方式、負荷分散方式、DR／バックアップ方式、ネットワーク設計、統合ログ管理方式、統合監視方式等)
標準運用を含むインフラパターン
(Build/Bootstrap/Test Scripts, Configuration Parameters, ...)
パターン化された設計、自「働」化された構築、標準化された運用
(Orchestrator等)
ミドルウェア標準
(Web/APサーバ、RDBMS、冗長化ソフトウェア、認証認可システム、統合ログ管理システム、統合監視システム等)
Infrastructure
as Code
システム全体の
オーケストレート

アジャイルなインフラ運用プロセス
 従来の常識を引きずったままでは、クラウド時代に取り残される。
24
Family by Keoni Cabral, on Flickr

Agenda
4. まとめ
25

インフラ運用の自”働”化
 コードを活用し、手作業から自”働”化されたインフラ運用へ転換する。
 インフラ運用をいつでも正しく機械的に構築するコード
 インフラ運用の確からしさを機械的に検証するコード
 スクリプトを用いてインフラの構築や運用を自”働”的に実施
26
インフラ運用の設計書
人が手作業で
インフラ運用を
構築し検証する
機械が自”働”的に
インフラ運用を
構築し検証する
インフラ運用の
構築コード
インフラ運用の
テストコード
インフラ運用のテスト手順書
インフラ運用のノウハウを
コードとして資産化
これまでのインフラ運用今からのインフラ運用
ニンベンの付く「自働化」
トヨタ生産方式で使われる言葉。作られたものが良品であれ不良品であれ、ただ単に機械的に動き続けることを意味する
「自動化」とは異なり、「不都合を検知して停止」する行為をも自律的に行えることを意味する。「自働化」により、
少なくとも「検知可能な不都合が起きていないこと」が保証される。

Infrastructure as Codeとは
 インフラ運用の維持管理を、手順書やパラメータシートを用いた手作
業で行うのではなく、インフラ運用のあるべき姿をプログラム（コー
ド）として書き下し、コードを元にインフラ運用を自働的に構成する
仕組みのこと。
 Infrastructure as Codeにより、次のようなメリットが得られる。
1. 手作業によるミスや手間の削減
 コードによる自働処理のため、人為的ミスが入り込まない。
 人的リソースの限界に囚われず、大量のインフラを並列に構成するこ
ともできる。
2. 設計と実装の乖離の防止
 インフラ運用を構成しテストするコード自身がインフラ運用の設計書
となるため、設計と現実の乖離が起きない。
(次ページに続く）
27

Infrastructure as Codeとは
(前ページからの続き）
3. インフラ運用のバージョン管理
 アジャイルなアプリケーション開発と同様、インフラ運用もバージョン
管理ができるようになる
 インフラ運用の更新差分の把握
 コードレビューによるリリース判定
 ブランチングによる実験用インフラの管理
 等
4. インフラ運用の継続的テスト
 インフラ運用のあるべき姿をテストコードとして表現し、自動的・継続
的にインフラ運用構成をテストし続けることで、インフラ運用の更改時
に品質を維持することができる。
28

自働的なインフラ運用を強制する仕組み
 ただし自働的にインフラを運用するためには、環境を直接手で触らず、
コードからのインフラ運用構成を強制する仕組みが必要。
29
出展：DRECOM, “ドリコムのInfrastructure as Code“, 2014-05
http://www.slideshare.net/y05_net/infrastructure-as-code-35373108

 インフラ運用の自働化に関連する代表的なツールやサービス
（便宜的な分類であり、複数のレイヤの機能を持つツールも多い）
構築テスト
インフラ運用の自働化に関連するツールやサービス
30
Bootstrapping
OSの起動を自動化するツール
LXC
OpenStack Amazon Web Services
Software Defined Infrastructure
APIを通じて操作できるインフラ
Orchestration
アプリのデプロイや運用等を含め、
システム全体として協調動作させる
ツール
AWS OpsWorks
Configuration
OSの設定やミドルウェアの
インストール・設定を自動化
するツール PuppetChef Ansible

 Chefとは
 Chef社（旧Opscode社）が開発しているインフラ構成管理ツール。
 コア機能（Essentials）はOSS公開されており、Chef自体の高可用性
や管理機能のオプション、サポート等が有償販売されている。
 インフラの「あるべき姿」をコードとして記述しておけば、その
あるべき姿へ自動的にインフラが構成される。
 Chefの仕組みを用いてサーバのあるべき姿を定義すると、その定義文
は一度だけ実行された場合でも複数回実行された場合でも、必ず同じ
結果に収束する（これを冪等性という）。
 そのためChefを用いれば、今のインフラの状態を調査し、どのコマン
ドをどの順序で実行すれば良いか、if文で分岐処理させる必要が無い。
 Shell Scriptを冪等に書くのは非常に面倒だが、Chefのルールに
従ってインフラをコード化すれば、冪等性を容易に実現できる。
Chef
31

 cookbook
 インフラのあるべき姿を宣言したコードをまとめたもの。
（例えば「apache2のcookbook」のような単位）
 cookbookは以下のような要素で構成される。
 recipe : インフラのあるべき姿を記述する
（apache2が入っていて、port 80が開いていて…）
 template : 設定ファイル等を動的に生成するための雛形
（httpd.confはコレから生成して、…）
 attribute : cookbook内で利用する変数のデフォルト値を定義する
（必要であれば実行時に上書きすることもできる）
等
Chef
32

 Serverspecとは
 想定している「あるべき姿」通りにサーバが構成されているかを
サーバの内部からテストするためのインフラツール。
 apache2が入っているか、port 80が開いていているか、
httpd.confのServerNameは正しく設定されているか、…
 インフラ運用のテストを機械化することで、インフラ運用のコード
に不具合が混入していないことを継続的にチェックし続けることが
できる。
（アプリケーション開発の「継続的インテグレーション」と同様）
Serverspec
33

CloudConductor
 デザイン指向クラウドオーケストレータ CloudConductor
 システム構築のノウハウを込めたパターンを組み合わせ、クラウド
へシステム全体を「自”働”構成」するOSSツール。
34

CloudConductor
 CloudConductorの全体像
 パターン開発者が作成したパターンを元に、AWSやOpenStackと
いったクラウドへシステム全体を自動構築し、適切に構築された
ことを自動でテストする。
35
パターン
パターン開発者
システム構築者
CI
実績のある様々なOSSを組み合わせることで
クラウドオーケストレーションを実現

CloudConductor
 CloudConductorとライフサイクルイベント
 システムのライフサイクルイベントごとに、各サーバが実行すべき
処理をコードで記述しておけば、ライフサイクルイベントの発生時
に各サーバが自律的に自らを望まれた状態へ構成する。
36
Setup
Configure
Deploy
BackupRestore
サーバ単体の構築
サーバを組み合わせ
システム全体を構築アプリケーションの
デプロイ
バックアップ取得時DR, システム切替時

CloudConductor
37
公式サイト http://cloudconductor.org
ソーシャル
https://twitter.com/ccndctr
https://www.facebook.com/cloudconductor
https://github.com/cloudconductor
http://www.slideshare.net/cloudconductor
 平成25年度～平成27年度の経済産業省補助金事業に採択され活動中
 開発成果は全てオープンソース（Apache License 2.0）として公開

CloudConductorのサンプルパターン～ tomcat cluster ～
 CloudConductorのInfrastructure as Codeの書き方（の一部）を、
公開しているサンプルパターンを例にとって解説する。
 LoadBalancer – Apache+Tocmat – PostgreSQLクラスタを
AWS/OpenStackへ構成するサンプルパターン
 https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/
38
Load Balancer（active）
(HAProxy)
Load Balancer（active）
(HAProxy) …
Web/APサーバ（active）
(Apache + Tomcat)
Web/APサーバ（active）
(Apache + Tomcat) …
RDBサーバ（master）
(PostgreSQL)
RDBサーバ（slave）
(PostgreSQL)
n台
m台
2台

 インフラのあるべき姿を記述するrecipeの書き方
 サーバが果たすべき役割（ロール）とライフサイクルイベントごと
にrecipeを分割することで、見通し良くコード化することができる。
39
tomcat_cluster_pattern
├ site-cookbooks
│ ├ apache_part
│ │ └ recipes
│ │ ├ default.rb
│ │ ├ setup.rb
│ │ ├ configure.rb
│ │ └ deploy.rb
│ ├ tomcat_part
│ │ └ recipes
│ │ ├ default.rb
│ │ ├ setup.rb
│ │ ├ configure.rb
│ │ └ deploy.rb
│ ├ pgpool-II_part
│ ├ postgresql_part
│ ├ haproxy_part
│ └ cloudconductor
例）apacheの役割を期待されているサーバが、
configureイベントが発生した際に実行するrecipe

 例）apache + setup
 https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/
master/site-cookbooks/apache_part/recipes/setup.rb
40

 例）apache + configure
master/site-cookbooks/apache_part/recipes/configure.rb
41

 例）apache + deploy
master/site-cookbooks/apache_part/recipes/deploy.rb
42

 インフラが正しく構成されたかを確認するテストの書き方
 サーバ内部で完結する構成は、ロールの単体テストとして記述する。
 configureやdeployといった複数のロール・サーバが組み合わさる
ことで意味を成す構成は、サーバの結合テストとして記述する。
43
tomcat_cluster_pattern
├ site-cookbooks
│ ├ apache_part
│ │ └ spec
│ │ └ recipes
│ │ ├ default_spec.rb
│ │ ├ setup_spec.rb
│ │ ├ configure_spec.rb
│ │ └ deploy_spec.rb
│
├ serverspec
│ └ spec
│ ├ ap
│ │ ├ ap_configure_spec.rb
│ │ └ ap_deploy_spec.rb
│ ├ db
例）apacheロールに関するconfigureイベントの単体テスト
例）APサーバに関するconfigureイベントの結合テスト

 例）apache + configureのテスト
master/site-cookbooks/apache_part/spec/recipes/configure_spec.rb
44

 例）APサーバ + configureのテスト
master/serverspec/spec/ap/ap_configure_spec.rb
45

 例）APサーバ + deployのテスト
master/serverspec/spec/ap/ap_deploy_spec.rb
46

Agenda
1. 今までのシステム構築の課題
4. まとめ
47

 システムテンプレートによるサービス構築プラットフォーム。
 サーバやネットワーク、各種ミドルウェア、アプリケーションの
フレームワークやライブラリ、データベース定義や初期データ、
及び運用スクリプトまで全てをパッケージングしてパターン化する。
 「開発したアプリをデプロイするだけ」という視点はPaaSに似て
いるが、構築されたシステムは従来通りのノウハウで運用できる。
FW
Apache2
HTML
WEB JS
JVM
Tomcat
Spring FW
pgpool-II
lib
Java ClassAPP
JVM
Tomcat
Spring FW
pgpool-II
lib
Java ClassAPP
PostgreSQL
Schema
DB
(SBY)PostgreSQL
Schema
DB
(ACT)
Apache2
HTML
WEB JS
Zabbix
Template
Monitor
Cloud B
VDC
IaaSとPaaSの良いとこ取りなシステム
48
Monitor
Zabbix
DB
(master)
WEB
Apache2
APP
Tomcat etc
PostgreSQL
DB
(slave)
WEB
Apache2
APP
Tomcat etc
PostgreSQL
パターン
アプリケーション
FW
Apache2
HTML
WEB JS
JVM
Tomcat
Spring FW
pgpool-II
lib
Java ClassAPP
JVM
Tomcat
Spring FW
pgpool-II
lib
Java ClassAPP
PostgreSQL
Schema
DB
(slave)PostgreSQL
Schema
DB
(master)
Apache2
HTML
WEB JS
Zabbix
Template
Monitor
Cloud A

甚大災害時でも自律的に復元するシステム
 甚大災害発生時に生き残ったクラウドを探し出し、自動的にシステム
を復元する。
49
LAN
WAN
Private Cloud
GW
APP DB
GW
企業情報システム
社内LANから接続
利用者
企業情報システムを
自動構築
Public Cloud
APPDB
企業情報システム
災害復旧拠点から接続
利用者
通常時災害時
パターン
リポジトリ
Internet
データを共有する仕組み
災害時には
企業情報システムを
オンデマンドに再構築
GW

 宮城県登米市・慶應大学・TISで実証実験を実施
（2014/11/07）
50
※実証実験の詳細は、CloudConductor公式サイトで公開しているレポートを参照
http://cloudconductor.org/whitepaper/災害時情報共有システムの実証実験.pdf

 実証実験の概要
 システムの復元に要した時間 = 6分53秒
51
時刻経過時間イベント
7:05:50 00:00 災害発生（人為的にNICをダウン）
7:06:05 00:15 CloudConductorによる障害検知
7:06:21 00:31 CloudConductorによるシステム再構築開始
7:12:43 06:53 システム復旧

ライフサイクルごとにクラウドを乗り換えるシステム
 システムのライフサイクルに従い、最適なクラウドへシステムを
乗り換えさせる。
52
LB
APP APP APP
DB (act) DB (sby)
LB
APP APP APP
DB(act) DB(sby)
パターン
LB
APP APP APP
DB (act) DB (sby)
LB
APP APP APP
DB (act) DB (sby)
運用者
クラウドA
システム開発は最安のクラウドAで
サービス開始後は安定のクラウドBへ
ビジネスが軌道に乗ったらプライベートクラウドへ
クラウドB プライベートクラウド
どのクラウドで動作していても
同じようにシステムを利用できる
利用者
データを共有する仕組み

Agenda
1. 今までのシステム構築の課題
4. まとめ
53

まとめ
 インフラ運用を標準化・コード化しOSSツールを活用することで、特定
クラウドに縛られない自働化されたインフラ運用が実現できる。
 そのためには従来のインフラ運用プロセスを見直し、クラウド時代に
適合したアジャイルなインフラ運用プロセスを構築しなければならない。
54
Sunrise on the Floodplains, Wimborne, Dorset by JackPeasePhotography, on Flickr

【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築

【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (9)

Similar to 【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築

Similar to 【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築 (20)

More from cloudconductor

More from cloudconductor (12)

Recently uploaded

Recently uploaded (7)

【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築