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

ひしめき合う 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症候群の気が・・・




• デプロイが死ぬほど大変






は？

は使えないの？

次期バージョン”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 git ocコマンド

webhook

アプリのデプロイ方法

buildpack (docker image)

buildpack docker image

buildpack docker image

dockerfile

STI docker image

前提OS

Ubuntu Ubuntu CoreOS RHEL

CentOS

コンテナ

Warden Docker Docker Docker

By gopher-vector https://github.com/golang-samples/gopher-vector

Ruby + Golang

Golang

Python + Golang

Golang

開発言語

https://github.com/golang-samples/gopher-vector

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


Helth Monitoring

ヘルスチェックの仕組み

node

node

node


RequestRouter

Helth Monitoring

アプリへのアクセスをルーティングするリクエストルータ

node

node

node


RequestRouter

MQ or

KVS

Helth Monitoring

各コンポーネントを疎結合に保つためのメッセージキューキーバリューストア

node

node

node


RequestRouter

MQ or

KVS

Log Collector

Metrics Collector

Helth Monitoring

ログ・メトリクスのアグリゲーション

+

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

Open PaaSとの付き合い方

Public PaaSの選択肢として

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

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


⇒　はい、死ぬほど大変です。



• あんまり自由が利かないんじゃない？



• あんまり自由が利かないんじゃない？

⇒　はい、あんまり利きません

でもちょっと待って

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

構成管理ツールは？

Fluentdも使ってますね？

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

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

1. サービスを開発する

2. 様々な場所に新しい仕組みを取り入れ、効率化を図っていく

3. だんだん規模が大きくなってくる

4. 間に挟まる仕組みも大規模に、複雑になってくる

5. それぞれのアップデートにかかるコストや、引き継ぎにかかるコストが無視出来なくなってくる

ある種のリスクを抱えている状態

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

• どうやってスケールアウトしよう・・・

• どうやってログ収集しよう・・・

• どうやってリソース監視しよう・・・

• どうやって無停止でアップデートしよう・・・

みんな課題は似たようなもの

node

node

node


RequestRouter

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?

Technology

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