ひしめき合う
Open PaaSを徹底解剖!
PaaSの今と未来
Kazuto Kusama
@jacopen
Cloud Foundryベースの
PaaS開発・運用
しごと
世界を緑色にする仕事
しごと
世界を緑色にする仕事
しごと
個人活動
• PaaS勉強会主宰
• 日本Cloud Foundryグループ

理事
今日の話
Open PaaS
プロプライエタリPaaS
Open PaaS
Open PaaS
今回伝えたいこと
• 是非、Open PaaSに興味をもって欲しい
• 今あるOpen PaaSの紹介
• どうOpen PaaSと付き合っていくべきか
• Open PaaSの未来はどうなるか
Open PaaSを触ってみよう
Cloud Foundry
Cloud Foundry Foundationが開発

(Pivotal, IBM, HP, Intel, NTTなどが参加)
2011年にVMwareがOSSとして公開。その後
Pivotal Software Cloud Foundry Foundationに
移管。
Cloud Foundryを採用したサービス
Public PaaS Private PaaS
Pivotal (Pivotal Web Services)
IBM (Bluemix)
NTT Communications (Cloudn
PaaS)
Fujitsu (K5)
Pivotal (Pivotal CF)
HP (Helion Development Platform)
Active State (Stackato)
DEMO
$	
  ls	
  
index.php	
  info.php	
  
$cf	
  push	
  jft-­‐php	
  
Creating	
  app	
  jft-­‐php	
  in	
  org	
  cln100021251	
  /	
  space	
  production	
  as	
  xxxxx...	
  
OK	
  
Creating	
  route	
  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com...	
  
OK	
  
Binding	
  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com	
  to	
  jft-­‐php...	
  
OK	
  
Uploading	
  jft-­‐php...	
  
Uploading	
  app	
  files	
  from:	
  /Users/jacopen/Project/jacopen/jtf/php	
  
Uploading	
  1.7K,	
  2	
  files	
  
Done	
  uploading	
  
OK	
  
(中略)	
  
	
  	
  	
  	
  	
  state	
  	
  	
  	
  	
  since	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  cpu	
  	
  	
  	
  memory	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  disk	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  details	
  
#0	
  	
  	
  running	
  	
  	
  2015-­‐07-­‐26	
  02:07:26	
  PM	
  	
  	
  0.0%	
  	
  	
  14.5M	
  of	
  256M	
  	
  	
  34.1M	
  of	
  2G	
  
※デモで話した内容
シンプルなPHPアプリをCloudn
PaaSにデプロイ
$	
  ls	
  
index.php	
  info.php	
  
$cf	
  push	
  jft-­‐php	
  
Creating	
  app	
  jft-­‐php	
  in	
  org	
  cln100021251	
  /	
  space	
  production	
  as	
  xxxxx...	
  
OK	
  
Creating	
  route	
  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com...	
  
OK	
  
Binding	
  jft-­‐php.paas.jp-­‐e1.cloudn-­‐service.com	
  to	
  jft-­‐php...	
  
OK	
  
Uploading	
  jft-­‐php...	
  
Uploading	
  app	
  files	
  from:	
  /Users/jacopen/Project/jacopen/jtf/php	
  
Uploading	
  1.7K,	
  2	
  files	
  
Done	
  uploading	
  
OK	
  
(中略)	
  
	
  	
  	
  	
  	
  state	
  	
  	
  	
  	
  since	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  cpu	
  	
  	
  	
  memory	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  disk	
  	
  	
  	
  	
  	
  	
  	
  	
  	
  details	
  
#0	
  	
  	
  running	
  	
  	
  2015-­‐07-­‐26	
  02:07:26	
  PM	
  	
  	
  0.0%	
  	
  	
  14.5M	
  of	
  256M	
  	
  	
  34.1M	
  of	
  2G	
  
※デモで話した内容
動きました。かんたん。
$	
  cf	
  api	
  https://api.ng.bluemix.net	
  
Setting	
  api	
  endpoint	
  to	
  https://api.ng.bluemix.net...	
  
OK	
  
API	
  endpoint:	
  	
  	
  https://api.ng.bluemix.net	
  (API	
  version:	
  2.27.0)	
  
Not	
  logged	
  in.	
  Use	
  'cf	
  login'	
  to	
  log	
  in.	
  
$	
  cf	
  login	
  
API	
  endpoint:	
  https://api.ng.bluemix.net	
  
(中略)	
  
$	
  cf	
  push	
  jtf-­‐php	
  
Creating	
  app	
  jtf-­‐php	
  in	
  org	
  erm	
  /	
  space	
  production	
  as	
  xxxxx...	
  
OK	
  
※デモで話した内容
全く同じコマンドで、向き先をBluemixに切り替えてデプロイ
$	
  cf	
  api	
  https://api.ng.bluemix.net	
  
Setting	
  api	
  endpoint	
  to	
  https://api.ng.bluemix.net...	
  
OK	
  
API	
  endpoint:	
  	
  	
  https://api.ng.bluemix.net	
  (API	
  version:	
  2.27.0)	
  
Not	
  logged	
  in.	
  Use	
  'cf	
  login'	
  to	
  log	
  in.	
  
$	
  cf	
  login	
  
API	
  endpoint:	
  https://api.ng.bluemix.net	
  
(中略)	
  
$	
  cf	
  push	
  jtf-­‐php	
  
Creating	
  app	
  jtf-­‐php	
  in	
  org	
  erm	
  /	
  space	
  production	
  as	
  xxxxx...	
  
OK	
  
※デモで話した内容
全く同じようにうごきました
$	
  cf	
  scale	
  jtf-­‐php	
  -­‐i	
  3	
  
Scaling	
  app	
  jtf-­‐php	
  in	
  org	
  erm	
  /	
  space	
  production	
  as	
  xxxxx...	
  
OK	
  
※デモで話した内容
スケールアウトも簡単にできます
Cloud Foundryのメリット
• たくさんのベンダーがCFを採用
• Open PaaSの理想「アンチベンダーロックイ
ン」が実現されつつある
• Open PaaSでは古参なので、比較的情報が多い
• Eclipse, IntelliJ, Visual StudioなどのIDEサポー
トがある。ツールも豊富
Cloud Foundryのデメリット
• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフ
トウェアスタックになりつつある
• NIH症候群の気が・・・
Cloud Foundryのデメリット
• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフ
トウェアスタックになりつつある
• NIH症候群の気が・・・
• デプロイが死ぬほど大変
Cloud Foundryのデメリット
• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフ
トウェアスタックになりつつある
• NIH症候群の気が・・・
• デプロイが死ぬほど大変
• デプロイが死ぬほど大変
は?
は使えないの?
次期バージョン”Diego”で

Docker imageサポート
Docker image互換じゃなくて
Dockerが使えるPaaSが欲しい?
OpenShift
Red Hatが開発
2011年に発表、2012年にOSSとして公開。
2015年、それまでの仕組み(OpenShift v2)を捨て
去り、Docker PaaSとして生まれ変わった
OpenShift v3を公開。
KubernetesをPaaSに
OpenShift v3のコアはKubernetes
Kubernetesの開発にはRed Hatが深く関わってい
る
Kubernetesの概念(Service, Pod, Replication
Controller)をそのまま取り入れている
OpenShiftの展開
DEMO
DEMOしようと思ったけど

失敗(◔⊖◔)
http://www.slideshare.net/jacopen/openshift-3dockerpaas
あたりを参考に・・・
OpenShiftのメリット
• コアにKubernetesを据えることで、進化が著
しい
• Githubとの連携やwebhookなど、便利な機能
が最初から っている
• Red Hat + Google + その他沢山のベンダーや
開発者によって開発される安心感
OpenShiftのデメリット
• Kubernetesの概念が色濃く残っており、PaaS
として使い勝手がいいかどうかは・・・?
• Cloud Foundryほどエコシステムが広がって
いない
• アーキテクチャのリセットはこれで最後・・・
だよね?
Kubernetesは分かりづらい!
もっとシンプルなDocker PaaSは無いの?
Deis
• Docker + CoreOSをベースとしたPaaS
• 2013年公開。OpDemandが開発。
• 2015年、PaaSベンダーのEngine Yardが
OpDemandを買収
DEMO
$	
  deis	
  create	
  
Creating	
  application...	
  done,	
  created	
  sanest-­‐odometer	
  
Git	
  remote	
  deis	
  added	
  
$	
  git	
  remote	
  show	
  
deis	
  
origin	
  
$	
  git	
  push	
  deis	
  master	
  
Counting	
  objects:	
  9,	
  done.	
  
Delta	
  compression	
  using	
  up	
  to	
  4	
  threads.	
  
Compressing	
  objects:	
  100%	
  (5/5),	
  done.	
  
Writing	
  objects:	
  100%	
  (9/9),	
  1.04	
  KiB	
  |	
  0	
  bytes/s,	
  done.	
  
Total	
  9	
  (delta	
  1),	
  reused	
  0	
  (delta	
  0)	
  
(後略)
※デモで話した内容
deis createすると、deisにアプリが作られると同時に
gitにremoteリポジトリが追加される
あとは git push deis masterすればデプロイされる、
Herokuライクな使い勝手。
$	
  deis	
  create	
  
Creating	
  application...	
  done,	
  created	
  sanest-­‐odometer	
  
Git	
  remote	
  deis	
  added	
  
$	
  git	
  remote	
  show	
  
deis	
  
origin	
  
$	
  git	
  push	
  deis	
  master	
  
Counting	
  objects:	
  9,	
  done.	
  
Delta	
  compression	
  using	
  up	
  to	
  4	
  threads.	
  
Compressing	
  objects:	
  100%	
  (5/5),	
  done.	
  
Writing	
  objects:	
  100%	
  (9/9),	
  1.04	
  KiB	
  |	
  0	
  bytes/s,	
  done.	
  
Total	
  9	
  (delta	
  1),	
  reused	
  0	
  (delta	
  0)	
  
(後略)
※デモで話した内容
簡単
$	
  deis	
  scale	
  web=5	
  
Scaling	
  processes...	
  but	
  first,	
  coffee!	
  
done	
  in	
  12s	
  
===	
  unisex-­‐newsreel	
  Processes	
  
-­‐-­‐-­‐	
  web:	
  
web.1	
  up	
  (v2)	
  
web.2	
  up	
  (v2)	
  
web.3	
  up	
  (v2)	
  
web.4	
  up	
  (v2)	
  
web.5	
  up	
  (v2)	
  
※デモで話した内容
deis scaleでスケールアウト可能。
ただ、ちょっと遅い
Deisのメリット
• Herokuライクな使い勝手
• Buildpack, Docker image, Dockerfileなど様々
な仕組みが利用出来る
Deisデメリット
• スケジューリングが遅い
• Productionに投入するにはもう少し・・・
Flynn
Flynn
• Docker PaaS
• 2013年、クラウドファウンディングのスタイ
ルでスタート。現在はPrime Directiveが開発
を主導
• シンプルなHerokuクローン Dokkuの作者が開
発に関与している
DEMO
$	
  flynn	
  create	
  
Created	
  coyotes-­‐rebuff-­‐richards	
  
$	
  git	
  remote	
  show	
  
deis	
  
flynn	
  
origin	
  
$	
  git	
  push	
  flynn	
  master	
  
Counting	
  objects:	
  9,	
  done.	
  
Delta	
  compression	
  using	
  up	
  to	
  4	
  threads.	
  
Compressing	
  objects:	
  100%	
  (5/5),	
  done.	
  
Writing	
  objects:	
  100%	
  (9/9),	
  1.04	
  KiB	
  |	
  0	
  bytes/s,	
  done.	
  
Total	
  9	
  (delta	
  1),	
  reused	
  0	
  (delta	
  0)	
  
-­‐-­‐-­‐-­‐-­‐>	
  Building	
  coyotes-­‐rebuff-­‐richards...	
  
-­‐-­‐-­‐-­‐-­‐>	
  PHP	
  app	
  detected	
  
(後略)	
  
※デモで話した内容
flynn createでアプリ作成とリモートリポジトリ追加
git push flynn masterでデプロイ。
deisと驚くほど一緒 (まあ、Herokuのインスパイア)
$	
  flynn	
  create	
  
Created	
  coyotes-­‐rebuff-­‐richards	
  
$	
  git	
  remote	
  show	
  
deis	
  
flynn	
  
origin	
  
$	
  git	
  push	
  flynn	
  master	
  
Counting	
  objects:	
  9,	
  done.	
  
Delta	
  compression	
  using	
  up	
  to	
  4	
  threads.	
  
Compressing	
  objects:	
  100%	
  (5/5),	
  done.	
  
Writing	
  objects:	
  100%	
  (9/9),	
  1.04	
  KiB	
  |	
  0	
  bytes/s,	
  done.	
  
Total	
  9	
  (delta	
  1),	
  reused	
  0	
  (delta	
  0)	
  
-­‐-­‐-­‐-­‐-­‐>	
  Building	
  coyotes-­‐rebuff-­‐richards...	
  
-­‐-­‐-­‐-­‐-­‐>	
  PHP	
  app	
  detected	
  
(後略)	
  
※デモで話した内容
(n‘∀‘)η
$	
  flynn	
  scale	
  web=5	
  
scaling	
  web:	
  3=>5	
  
14:32:04.554	
  ==>	
  web	
  flynn-­‐6e60228c3fa54933acc30401b9a30a4d	
  starting	
  
14:32:04.747	
  ==>	
  web	
  flynn-­‐397fba6e68cf4206bb8c28328a843427	
  starting	
  
14:32:05.215	
  ==>	
  web	
  flynn-­‐397fba6e68cf4206bb8c28328a843427	
  up	
  
14:32:06.344	
  ==>	
  web	
  flynn-­‐6e60228c3fa54933acc30401b9a30a4d	
  up	
  
scale	
  completed	
  in	
  2.252653272s	
  
※デモで話した内容
flynn scaleでスケールアウト可能。
こちらはかなり速い
Flynnのメリット
• シンプル、かつモジュラーでカスタマイズし
やすいアーキテクチャ
• PaaSに必要な要素がFlynn内でほぼ完結して
いる
Flynnのデメリット
• CF, OpenShift, Deisに比べると開発の継続力
に一抹の不安
• モジュラーなアーキテクチャは良し、しかし
どこまでメンテナンスし続けられるか
アプリのデプロイ方法
cfコマンド git gitocコマンド
webhook
アプリのデプロイ方法
buildpack
(docker image)
buildpack
docker image
buildpack
docker image
dockerfile
STI
docker image
前提OS
Ubuntu Ubuntu
CoreOS
RHEL
CentOS
コンテナ
Warden Docker DockerDocker
By gopher-vector https://github.com/golang-samples/gopher-vector
Ruby + Golang
Golang
Python + Golang
Golang
開発言語
4つのOpen PaaSを比較してみましたが
どれもあまり変わらなくね?
✓ gitやCLIツールからデプロイができて
✓ DockerfileやBuildpackのような複数言語を扱う仕組
みが使えて
✓ コマンド一発で起動・停止・スケールアウトが出来て
✓ リクエストルータもあってマルチホストに展開ができ
る
何故どれも似た感じになるのか
スケールするWebアプリケーションの
ベストプラクティスがある
• 12 Factor appの考え方は極めてシンプルで優れている
• どのPaaSも、12 Factor appを前提に作り込んでいく
• 結果として、どれも使い勝手としては

似たようなものとなる
大規模にスケールする
プラットフォームの作り方も、
だいたい確立している
node
node
node
アプリが動く
複数のノード
node
node
node
Controller
Scheduler
ノードにアプリを配置する
コントローラ
スケジューラ
node
node
node
Controller
Scheduler
Helth
Monitoring
ヘルスチェックの
仕組み
node
node
node
Controller
Scheduler
Request

Router
Helth
Monitoring
アプリへのアクセス
をルーティングする
リクエストルータ
node
node
node
Controller
Scheduler
Request

Router
MQ
or
KVS
Helth
Monitoring
各コンポーネントを
疎結合に保つための
メッセージキュー

キーバリューストア
node
node
node
Controller
Scheduler
Request

Router
MQ
or
KVS
Log
Collector
Metrics
Collector
Helth
Monitoring
ログ・メトリクスの
アグリゲーション
+
結果として似たような感じに
Open PaaSとの付き合い方
Public PaaSの選択肢として
自社サービスの基盤として
Private PaaS構築
自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない?
自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない?
 はい、死ぬほど大変です。
自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない?
 はい、死ぬほど大変です。
• あんまり自由が利かないんじゃない?
自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない?
 はい、死ぬほど大変です。
• あんまり自由が利かないんじゃない?
 はい、あんまり利きません
でもちょっと待って
皆さん
Dockerは使っていますか?
構成管理ツールは?
Fluentdも使ってますね?
優れた仕組みを積極的に

取り入れていくのは大切
でも、だんだんと継ぎ接ぎになりませんか?
1. サービスを開発する
2. 様々な場所に新しい仕組みを取り入れ、効率化を図っていく
3. だんだん規模が大きくなってくる
4. 間に挟まる仕組みも大規模に、複雑になってくる
5. それぞれのアップデートにかかるコストや、引き継ぎにかか
るコストが無視出来なくなってくる
ある種のリスクを抱えている状態
『全部入り』のOpen PaaSを選択肢に
• どうやってスケールアウトしよう・・・
• どうやってログ収集しよう・・・
• どうやってリソース監視しよう・・・
• どうやって無停止でアップデートしよう・・・
みんな課題は似たようなもの
node
node
node
Controller
Scheduler
Request

Router
MQ
or
KVS
Log
Collector
Metrics
Collector
Helth
Monitoring
きっと自前で作っても似たような仕組みに
ダクトテープを投げ捨てよう
仮にOpen PaaSを採用しなかったと
しても、アーキテクチャの参考に
デカイ
複雑
コアはk8s
CoreOSの機能
活用しまくり
これ1つで完結
Open PaaSの未来
や
ぁ
進化し続けるコンテナへの対応
進化し続けるコンテナへの対応
Webアプリケーション以外のサポート
• コンテナで動けば、アプリケーション自体は動く
• HTTP/HTTPS以外でどうアクセスできるようにするか
TCP Routing
openshift-sdn
Networking v2
あらゆるサービスの「ハブ」に
PaaS
IoT mBaaS
DBaaS Bigdata
進化の著しい世界
楽しい!!✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌
PaaS勉強会
第27回
7/29
PaaS x IoT
Node-RED
勉強会
8/26
Questions?

ひしめき合うOpen PaaSを徹底解剖! PaaSの今と未来