ひしめき合うOpen PaaSを徹底解剖！ 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, Dockerﬁleなど様々な仕組みが利用出来る

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 (後略) ※デモで話した内容 ﬂynn createでアプリ作成とリモートリポジトリ追加 git push ﬂynn 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 ※デモで話した内容 ﬂynn 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 dockerﬁle 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ツールからデプロイができて ✓ Dockerﬁleや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 ログ・メトリクスのアグリゲーション

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?

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

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

Recommended

More Related Content

What's hot

What's hot(20)

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

Similar to ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来(20)

More from Kazuto Kusama

More from Kazuto Kusama(18)

Recently uploaded

Recently uploaded(13)

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