July Tech Festaで発表した資料です。 Cloud Foundry、OpenShift v3、Deis、Flynnを取り上げて、Open PaaSの今と未来について解説しました。

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

2. Kazuto Kusama
@jacopen

3. Cloud Foundryベースの
PaaS開発・運用
しごと

4. 世界を緑色にする仕事
しごと

5. 世界を緑色にする仕事
しごと

6. 個人活動
• PaaS勉強会主宰
• 日本Cloud Foundryグループ
理事

7. 今日の話

8. Open PaaS

9. プロプライエタリPaaS

10. Open PaaS

11. Open PaaS

12. 今回伝えたいこと
• 是非、Open PaaSに興味をもって欲しい
• 今あるOpen PaaSの紹介
• どうOpen PaaSと付き合っていくべきか
• Open PaaSの未来はどうなるか

13. Open PaaSを触ってみよう

15. Cloud Foundry
Cloud Foundry Foundationが開発
(Pivotal, IBM, HP, Intel, NTTなどが参加)
2011年にVMwareがOSSとして公開。その後
Pivotal Software Cloud Foundry Foundationに
移管。

16. 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)

17. DEMO

18. $
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にデプロイ

19. $
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
※デモで話した内容
動きました。かんたん。

20. $
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に切り替えてデプロイ

21. $
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
※デモで話した内容
全く同じようにうごきました

22. $
cf
scale
jtf-­‐php
-­‐i
3
Scaling
app
jtf-­‐php
in
org
erm
/
space
production
as
xxxxx...
OK
※デモで話した内容
スケールアウトも簡単にできます

23. Cloud Foundryのメリット
• たくさんのベンダーがCFを採用
• Open PaaSの理想「アンチベンダーロックイ
ン」が実現されつつある
• Open PaaSでは古参なので、比較的情報が多い
• Eclipse, IntelliJ, Visual StudioなどのIDEサポー
トがある。ツールも豊富

24. Cloud Foundryのデメリット
• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフ
トウェアスタックになりつつある
• NIH症候群の気が・・・

25. Cloud Foundryのデメリット
• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフ
トウェアスタックになりつつある
• NIH症候群の気が・・・
• デプロイが死ぬほど大変

26. Cloud Foundryのデメリット
• デプロイが死ぬほど大変
• 互換性維持のために、合理的とは言い難いソフ
トウェアスタックになりつつある
• NIH症候群の気が・・・
• デプロイが死ぬほど大変
• デプロイが死ぬほど大変

27. は？
は使えないの？

28. 次期バージョン”Diego”で
Docker imageサポート

29. Docker image互換じゃなくて
Dockerが使えるPaaSが欲しい？

31. OpenShift
Red Hatが開発
2011年に発表、2012年にOSSとして公開。
2015年、それまでの仕組み(OpenShift v2)を捨て
去り、Docker PaaSとして生まれ変わった
OpenShift v3を公開。

33. KubernetesをPaaSに
OpenShift v3のコアはKubernetes
Kubernetesの開発にはRed Hatが深く関わってい
る
Kubernetesの概念(Service, Pod, Replication
Controller)をそのまま取り入れている

34. OpenShiftの展開

35. DEMO

36. DEMOしようと思ったけど
失敗(◔⊖◔)

37. http://www.slideshare.net/jacopen/openshift-3dockerpaas
あたりを参考に・・・

38. OpenShiftのメリット
• コアにKubernetesを据えることで、進化が著
しい
• Githubとの連携やwebhookなど、便利な機能
が最初から っている
• Red Hat + Google + その他沢山のベンダーや
開発者によって開発される安心感

39. OpenShiftのデメリット
• Kubernetesの概念が色濃く残っており、PaaS
として使い勝手がいいかどうかは・・・？
• Cloud Foundryほどエコシステムが広がって
いない
• アーキテクチャのリセットはこれで最後・・・
だよね？

40. Kubernetesは分かりづらい！
もっとシンプルなDocker PaaSは無いの？

42. Deis
• Docker + CoreOSをベースとしたPaaS
• 2013年公開。OpDemandが開発。
• 2015年、PaaSベンダーのEngine Yardが
OpDemandを買収

43. DEMO

44. $
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ライクな使い勝手。

45. $
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)
(後略)
※デモで話した内容
簡単

46. $
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でスケールアウト可能。
ただ、ちょっと遅い

47. Deisのメリット
• Herokuライクな使い勝手
• Buildpack, Docker image, Dockerfileなど様々
な仕組みが利用出来る

48. Deisデメリット
• スケジューリングが遅い
• Productionに投入するにはもう少し・・・

49. Flynn

50. Flynn
• Docker PaaS
• 2013年、クラウドファウンディングのスタイ
ルでスタート。現在はPrime Directiveが開発
を主導
• シンプルなHerokuクローン Dokkuの作者が開
発に関与している

51. DEMO

52. $
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のインスパイア)

53. $
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‘∀‘)η

54. $
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でスケールアウト可能。
こちらはかなり速い

55. Flynnのメリット
• シンプル、かつモジュラーでカスタマイズし
やすいアーキテクチャ
• PaaSに必要な要素がFlynn内でほぼ完結して
いる

56. Flynnのデメリット
• CF, OpenShift, Deisに比べると開発の継続力
に一抹の不安
• モジュラーなアーキテクチャは良し、しかし
どこまでメンテナンスし続けられるか

57. アプリのデプロイ方法
cfコマンド git gitocコマンド
webhook

58. アプリのデプロイ方法
buildpack
(docker image)
buildpack
docker image
buildpack
docker image
dockerfile
STI
docker image

59. 前提OS
Ubuntu Ubuntu
CoreOS
RHEL
CentOS

60. コンテナ
Warden Docker DockerDocker

61. By gopher-vector https://github.com/golang-samples/gopher-vector
Ruby + Golang
Golang
Python + Golang
Golang
開発言語

62. 4つのOpen PaaSを比較してみましたが

63. どれもあまり変わらなくね？

64. ✓ gitやCLIツールからデプロイができて
✓ DockerfileやBuildpackのような複数言語を扱う仕組
みが使えて
✓ コマンド一発で起動・停止・スケールアウトが出来て
✓ リクエストルータもあってマルチホストに展開ができ
る

65. 何故どれも似た感じになるのか

66. スケールするWebアプリケーションの
ベストプラクティスがある

67. • 12 Factor appの考え方は極めてシンプルで優れている
• どのPaaSも、12 Factor appを前提に作り込んでいく
• 結果として、どれも使い勝手としては
似たようなものとなる

68. 大規模にスケールする
プラットフォームの作り方も、
だいたい確立している

69. node
node
node
アプリが動く
複数のノード

70. node
node
node
Controller
Scheduler
ノードにアプリを配置する
コントローラ
スケジューラ

71. node
node
node
Controller
Scheduler
Helth
Monitoring
ヘルスチェックの
仕組み

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

73. node
node
node
Controller
Scheduler
Request
Router
MQ
or
KVS
Helth
Monitoring
各コンポーネントを
疎結合に保つための
メッセージキュー
キーバリューストア

74. node
node
node
Controller
Scheduler
Request
Router
MQ
or
KVS
Log
Collector
Metrics
Collector
Helth
Monitoring
ログ・メトリクスの
アグリゲーション

75. +

76. 結果として似たような感じに

77. Open PaaSとの付き合い方

78. Public PaaSの選択肢として

79. 自社サービスの基盤として
Private PaaS構築

80. 自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない？

81. 自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない？
はい、死ぬほど大変です。

82. 自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない？
はい、死ぬほど大変です。
• あんまり自由が利かないんじゃない？

83. 自社サービスの基盤として
Private PaaS構築
• えー、大変じゃない？
はい、死ぬほど大変です。
• あんまり自由が利かないんじゃない？
はい、あんまり利きません

84. でもちょっと待って

85. 皆さん
Dockerは使っていますか？

86. 構成管理ツールは？
Fluentdも使ってますね？

87. 優れた仕組みを積極的に
取り入れていくのは大切

88. でも、だんだんと継ぎ接ぎになりませんか？

89. 1. サービスを開発する
2. 様々な場所に新しい仕組みを取り入れ、効率化を図っていく
3. だんだん規模が大きくなってくる
4. 間に挟まる仕組みも大規模に、複雑になってくる
5. それぞれのアップデートにかかるコストや、引き継ぎにかか
るコストが無視出来なくなってくる
ある種のリスクを抱えている状態

91. 『全部入り』のOpen PaaSを選択肢に

92. • どうやってスケールアウトしよう・・・
• どうやってログ収集しよう・・・
• どうやってリソース監視しよう・・・
• どうやって無停止でアップデートしよう・・・
みんな課題は似たようなもの

93. node
node
node
Controller
Scheduler
Request
Router
MQ
or
KVS
Log
Collector
Metrics
Collector
Helth
Monitoring
きっと自前で作っても似たような仕組みに

94. ダクトテープを投げ捨てよう

95. 仮にOpen PaaSを採用しなかったと
しても、アーキテクチャの参考に

96. デカイ
複雑
コアはk8s
CoreOSの機能
活用しまくり
これ1つで完結

97. Open PaaSの未来

98. や
ぁ

99. 進化し続けるコンテナへの対応

100. 進化し続けるコンテナへの対応

101. Webアプリケーション以外のサポート
• コンテナで動けば、アプリケーション自体は動く
• HTTP/HTTPS以外でどうアクセスできるようにするか

102. TCP Routing
openshift-sdn
Networking v2

103. あらゆるサービスの「ハブ」に
PaaS
IoT mBaaS
DBaaS Bigdata

105. 進化の著しい世界

106. 楽しい!!✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌

107. PaaS勉強会

108. 第27回
7/29

109. PaaS x IoT
Node-RED
勉強会
8/26

110. Questions?