APC勉強会 #18で発表した資料です。 http://8a1-apc.connpass.com/event/13592/ ブラックボックス化されていて、普段見ることができないPaaSの中身を、OSSのPaaSであるCloud Foundryを題材に解説します。

1. Cloud Foundryで学ぶ
PaaSのしくみ講座

2. 日本Cloud Foundryグループ
Kazuto Kusama
@jacopen

3. 日本Cloud Foundryグループ
#cfgrjp

4. PaaS

5. 1. コードを書く 2. PaaSにデプロイ 3. 動作！
すごく簡単
PaaS

6. 1. コードを書く 2. PaaSにデプロイ 3. 動作！
PaaS
わかる わかる え、どうやったの？

7. 1. コードを書く 2. PaaSにデプロイ 3. 動作！
PaaS
わかる わかる え、どうやったの？
4. スケールアウト
？？？

8. PaaSが便利なのは分かる
インフラを知らなくとも使える
でも、ブラックボックスなのは嫌だ

9. 今回の目的
• ブラックボックスに思われがちな、PaaSの中身を理解して貰う
ことで、不安を解いてもらいたい
• Cloud Foundryだけでなく、どのPaaSにも共通して利用できる
知識を身につける

10. PaaS上の
アプリの動作を
見てみる
PaaS上の
アプリの一生を
追ってみる
PaaSを支える
仕組みを学ぶ
321

11. 教材: Cloud Foundry
• オープンソースのPaaSなので、
誰でも仕組みを追える
• 多くのベンダーが採用
(IBM, HP, NTT Comなど)
• ユーザーが機能を拡張できる、Heroku
互換のBuildpackを採用している

12. PaaS上の
アプリの動作を
見てみる1

13. 例えば、PHPアプリを構築するとき
• Apache/Nginxをインストール
• PHP(mod_php/php-fpm)をインストール
• 必要に応じてpeclやpearをインストール

14. 例えば、Rubyアプリを構築するとき
• Rubyをインストール
• bundle install
• (Railsなら) rake assets:precompile
• (Railsなら) rake db:migrate

15. DEMO

16. ※DEMOで話した内容
皆さんが普段Apache+PHPの環境を作りたいと思ったとき
たぶんこんな感じでapt-getでインストールすると思います。
するとほら、こんな感じでApacheのプロセスが起動するわけですね。

17. ※DEMOで話した内容
じゃあRubyのアプリの場合はどうか。
ここにSinatraのアプリを用意しましたので、まずは定番のbundle installですね。
その後に起動します。

18. ※DEMOで話した内容
すると、こんな感じで起動するわけです。
ここまでは、皆さんが見慣れた光景ですよね。

19. Server
OS
Apache
PHP (mod_php/php-fpm)
Application
Server
OS
Ruby
WEBrick
Application
サーバー
OS
ミドルウェア
アプリケーション
手動で構築したときのソフトウェアスタック

20. では、PaaSの場合は？

21. DEMO

22. ※DEMOで話した内容
PaaSの場合、中身はどうなるんでしょう。
今回、自前のCloud Foundry環境を用意したので、まずはSinatraアプリを
デプロイしてみます。

23. ※DEMOで話した内容
デプロイ出来たので、実際にPaaS環境の中に入って、どんな感じにアプリが
上がっているか見てみましょうか。
Rubyのプロセスが上がっているのが分かりますよね。さっきと殆ど同じという
ことが分かるでしょう。

24. ※DEMOで話した内容
次にPHPアプリをデプロイしてみました。
httpd となっていますが、さっき手動で上げたときのapache2のバイナリの
名前が違うだけです。単純にApacheのプロセスが上がっているだけ、
と言うことです。
つまり、皆さんが普段自前で組んでる環境も、PaaSで組まれる環境も、
中身は殆ど同じ、というわけです。

25. Server
OS
Apache
PHP (mod_php/php-fpm)
Application
Server
OS
Ruby
WEBrick
Application
サーバー
OS
ミドルウェア
アプリケーション
PaaS上のソフトウェアスタック

26. PaaSであっても
アプリが動く仕組みは一緒
ポイント①

27. PaaS上の
アプリの一生を
追ってみる2

28. Server
OS
Apache PHP
/usr/sbin/apache2
/etc/apache2/
…
/usr/bin/php5
/etc/php5/
…
apt-get
yum
source…
手動で構築する時
• aptやyumなどの
パッケージマネージャ
• ソースからコンパイル
• どちらの場合も、
サーバーの特定の場所
にランタイムが配置さ
れる

29. Server
OS
?
6u45
7u79
8u45
5.4.39
5.5.23
5.6.7
1.9.3-p551
2.1.6
2.2.2
PaaSの場合
• 様々な言語、それも
様々なバージョンに
対応しなければいけない
• どこにどう
インストールされている
のだろう？

30. DEMO

31. ※DEMOで話した内容
さっき上げたアプリをもう一度見てみましょうか。
/home/vcap/app∼の下に、何かコンフィグがあるようですね。見てみましょうか
あれ、おかしいですね。/home/vcapに居るはずなのに、そもそもappなんて
ディレクトリが存在しないように見えます。

32. ※DEMOで話した内容
Rubyの場合も、/home/vcap/app配下のファイルを読んでいるようですが、
やはりPaaS環境上に、そんなファイルは存在しないように見えます。
どういうことでしょうか。

33. ※DEMOで話した内容
ここで皆さんに覚えておいて欲しいのが、コンテナという仕組みです。
この後説明しますが、アプリはコンテナの中で動いています。実際にアプリの
コンテナの中に入ってみますね。
コンテナの中で、Rubyプロセスが上がっているのが確認出来ます。
ファイルはどうでしょうか。

34. ※DEMOで話した内容
はい、確かにファイルが存在することが確認出来ました。
これはさっきアップロードした、Sinatraアプリですね。
bin/ の中を見てみると、rubyやgemなど、実行に必要なバイナリが既に
設置されていることが分かります。実際にRubyバイナリを実行して、
バージョン情報を見てみましょうか。

35. ※DEMOで話した内容
では、PHPアプリのほうを見てみましょうか。
こちらも/home/vcap/app が存在しますね。ここで重要なのは、さっきのRubyと
同じパスなのにも関わらず、設置してあるファイルは全く別物ということです。
アプリケーションに応じて、必要なものが、適切に設置してあるわけです。

36. ✓ PaaSの実行環境では、アプリごとにコンテナが作られ、
マルチテナントで動いている
✓ コンテナの中には、実行に必要なバイナリが全て含まれている
✓ その他実行に必要な作業も全て実施済(Rubyのbundle installなど)
Photo by Enokson https://www.flickr.com/photos/vblibrary/4385390248/

37. Server
OS
Apache
Ruby 2.1.4 Ruby 1.9.3-p551 Java7
php-fpm
Tomcat
app A app B app C app D
それぞれがコンテナ
Application
Application Application
Application

38. コンテナ技術
• Cloud Foundryの場合、Wardenという
独自のコンテナ機構を使っている
• HerokuはLXCを利用
• 最近はDockerが流行り
いずれもLinuxのcgroupsやnamespaceと
いう機能を活用しており、得られる
メリットは似通っている
Photo by Dirk Dallas https://www.flickr.com/photos/dirkdallas/

39. コンテナによるメリット
• 異なる環境をアプリに提供出来る
• JavaならJava、RubyならRuby
• アプリ同士を隔離出来る
• セキュリティの担保、リソースの制限
• 素早く立ち上げることがきる
• VMを使うと数分、コンテナなら数秒
Photo by Dirk Dallas https://www.flickr.com/photos/dirkdallas/

40. Application
Application Application
Application
Server
OS
Apache
Ruby 2.1.4 Ruby 1.9.3-p551 Java7
php-fpm
Tomcat
このコンテナイメージは、
誰が、いつ用意したのか？

41. Buildpack

42. Buildpack
• Herokuによって作られた、任意の言語
やフレームワークを扱えるようにする
仕組み
• Cloud FoundryもBuildpackを利用可能
Photo by cgc76 https://www.flickr.com/photos/cgc76/10620451574

43. Buildpack
• Ruby
• PHP
• Java
• Python
• Go
• Node
• etc…

44. Buildpackの3フェーズ
1. Detect
2. Compile
3. Release Buildpackには、必ずこの3スクリプトが
含まれている

45. 1. Detect
2. Compile
3. Release
Buildpackの実行条件に合致するかを
チェックするスクリプト。
合致したら0を、合致しなければ1を返
す。

46. 1. Detect
2. Compile
3. Release
composer.jsonがあるか
(無ければ次へ)
.phpのファイルがあるか
(無ければ次へ)
$WEBDIRがあるか
PHP Buildpackの場合

47. 1. Detect
2. Compile
3. Release
実行環境を構築するスクリプト

48. 1. Detect
2. Compile
3. Release
Ruby Buildpackの場合
1. Gemfileから指定Rubyバージョンを
確認して、バイナリをダウンロード
2. フレームワークを確認(Rails?Sinatra?)
3. bundle install
4. rake assets:precompile(Railsの場合)

49. 1. Detect
2. Compile
3. Release
実行に必要な環境変数などの情報を出力
(今回は説明は割愛)

50. つまりBuildpackとは
• コードがどういう言語で書かれている
か検出する
• その言語向けの環境を構築する
Photo by cgc76 https://www.flickr.com/photos/cgc76/10620451574

51. ここまでの復習を兼ねて
一連の流れで考えてみよう

52. 1. ユーザーがアプリをプッシュ

53. 2. Cloud Foundryがアプリを受け取る Insi
Ruby buildpack
Java buildpack
PHP buildpack
PH

54. 3. アプリに対し、内蔵のBuildpackのdetect
スクリプトを順次実行
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

55. 4. detectでマッチしたBuildpackの
compileスクリプトを実行
Inside PaaS
Java buildpack
PHP buildpack
PHP buildpack

56. 5. ランタイムもアプリも含まれた
実行環境一式が出来上がる
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

57. 6. Cloud Foundryの実行ノードで
アプリを起動
(このとき、コンテナで動く)
aaS

58. Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

59. Buildpackの適用を中心とした、
アプリの準備作業を「ステージング」と呼ぶ
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

60. PaaSへの「デプロイ」は「アップロード」
「ステージング」「実行」の3フェーズで構成される
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

61. これまで手動で行ってきたインストール作業を
コードから自動判別して行っているに過ぎない
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

62. スケールアウトの仕組み

63. DEMO

64. ※DEMOで話した内容
Cloud Foundryでは、コマンド一発でアプリケーションのインスタンス数を
増やすことができます。それも一瞬で。実際に試してみましょうか。
一瞬で起動しましたね。手動でサーバーをスケールアウトするのと比べると、
数百倍、数千倍速いですね。これはどういう仕組みなんでしょうか。
←だいたい数秒

65. スケールアウト
• コマンド一発で、たくさんのインスタ
ンスを展開出来る
• しかも速い

66. Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
・
・
・
buildpackをたくさん実行？
時間がかかるし、負荷も高そう

67. Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
Dropletと言う形で、保存しています
Droplet

68. Cloud Controller DEA
(Droplet Execution Agent)

69. Ruby buildpack
Java buildpack
PHP buildpack
PH
アップロードを受け取るのは、CCの仕事

70. Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack
CCからDEAに、ステージングの依頼

71. PHP buildpack
DEAは成果物(Droplet)を返す。CCはそれを保存。

72. CCはDropletを各DEAに配布して実行を依頼する

73. スケールアウト時は、ステージングは行わず
Dropletの配布のみで済む

74. PaaSを支える
仕組みを学ぶ
3

75. appA appA appAappBappB
Internet
?
アプリは複数台に跨がっ
ているだけでなく、関係
ないアプリと同居してい
るという状態。
目的のアプリにどうやっ
てアクセスすればよいか。

76. リクエストルーティング

77. Router

78. appA appA appAappBappB
appA.example.comは192.168.10.2:52341で上がってます
appB.example.comは192.168.10.2:52313で上がってます
各DEAは、自分の持つ
アプリのポートとIPアドレ
ス、URLをRouterに通知

79. appA appA appAappBappB
appA.example.comは192.168.10.4:64341で上がってます
appA.example.comは192.168.10.5:23591で上がってます
各DEAは、自分の持つ
アプリのポートとIPアドレ
ス、URLをRouterに通知

80. appA appA appAappBappB
これで、Routerは
どこのIPのどのPortに、
どのアプリが動いているか
知ることが出来る
appA.example.com 192.168.10.4:64341
192.168.10.5:23591
192.168.10.2:52341
appB.example.com 192.168.10.3:32563
192.168.10.2:52313

81. appA appA appAappBappB
実際にリクエストが来たら、
リストを元にアクセスを分
配
♪
appA.example.com

82. ✓ Cloud FoundryのRouterは、アプリへのリクエストを解釈して正
しい場所に転送する、L7のリクエストルーター
✓ Routerが利用する情報は、各DEAからもたらされる
✓ 一般的に使われる、L3の「ルーター」とは異なるので注意
Photo by Enokson https://www.flickr.com/photos/vblibrary/4385390248/

83. メッセージングバス

84. appA appA appAappBappB
負荷が高くなっても対応できるよう、Routerは複数台で負荷
分散できるようになっている。

85. appA appA appAappBappB
ところで、先ほど「DEAはRouterに通知する」と表現した。
つまり、Routerの数が増えると、通知数も増えてしまう？
Router数 x DEA数=通知数・・・

86. appA appA appAappBappB
もちろん、そうはならない。メッセージのやり取りは、
NATSというPub-Sub型メッセージングバスを通じて行う
NATS

87. Publish-Subscribeモデル
• メッセージの送信側(Publisher) と受信
側(Subscriber)が存在
• Publisherはトピックを付けてメッセー
ジを送信する。どれだけのSubscriber
が居るかは関知しない。
• Subscriberは、指定しているトピック
のメッセージを自動的に受信する
Publisher Subscriber

88. Publish-Subscribeモデル
Subscribe ENL
ENL
RES
Subscribe ENL and RES
Subscribe RES
NATS
Publish
Publish

89. appA appA appAappBappB
Subscribe
router.register
Publish
router.register
{“uris”:[“appA.example.com”],”host”:"192.168.10.2","port":35155}
NATS

90. appA appA appAappBappB
Subscribe
router.register
Publish
router.register
NATS
Publish
dea.start
Subscribe
staging.start
Subscribe
dea.start
Subscribe
dea.advertise
Publish
dea.advertise
CC-DEA間もNATS

91. NATS
• NATSを通じて疎結合に構成されている
• どこに何が存在するか、各コンポーネ
ントが把握しておく必要が無い(NATS
のアドレスさえ分かっていればいい)
• そのため、柔軟にコンポーネントの追
加・削除が行える

92. 死活監視

93. appA appA appAappBappB
運用していると、必ず障害は起こる
ぬるぽ
ソフトウェアのバグで
アプリがクラッシュ
ハードウェア障害で
DEAホストがダウン

94. Health Manager

95. appA appB
アプリのクラッシュ時
ぬるぽ
NATS
Σ
appB
DEAがアプリのクラッシュを検出

96. appA appB
アプリのクラッシュ時
ぬるぽ
NATS
Publish
droplet.exited
Subscribe
droplet.exited
appB
dropletが終了した旨をpublish。
HMはそれをsubscribeしている

97. appA appB
アプリのクラッシュ時
NATS
Publish
hm9000.start
appB
Subscribe
hm9000.start
HMはCCにクラッシュしたアプリを
再度上げるよう通知

98. appA appB
アプリのクラッシュ時
NATS
appB
Publish
dea.start
Subscribe
dea.start
CCはDEAにアプリの立ち上げ
メッセージを通知

99. appA appB
アプリのクラッシュ時
NATS
appB appA
アプリが復旧する

100. appA appB
ホストのクラッシュ時
NATS
appB
DEAは普段から、heartbeatを定期的にpublishしている
Publish
dea.heartbeat
Running appA, appB
Publish
dea.heartbeat
Running appB
Subscribe
dea.heartbeat

101. appA appB
ホストのクラッシュ時
NATS
appB
ホストがクラッシュした場合、heartbeatが来なくなるので
HMはクラッシュに気づく
Publish
dea.heartbeat
Running appB
?

102. appA appB
ホストのクラッシュ時
NATS
appB
足りなくなった分を増やすよう通知
Publish
hm9000.start
Subscribe
hm9000.start

103. appA appB
ホストのクラッシュ時
NATS
appB
アプリが復旧する
appA
appB
Publish
dea.start
Subscribe
dea.start

104. まとめ

105. ユーザーが書いたコードは

106. PaaS上でよしなに実行される
PaaS

107. アプリ自体は、ごく一般的な仕組みで動いている
OS
Runtime
Framework

108. その裏には、多くの人に便利なサービスを
提供できるよう、考え抜かれた仕掛けが存在する
Inside PaaS
Ruby buildpack
Java buildpack
PHP buildpack
PHP buildpack

109. Cloud Controllerはユーザーからのリクエストを
受け取り

110. Buildpackにより実行可能なDropletが作成され
Ruby buildpack
Java buildpack
PHP buildpack

111. DropletはCCのコントロールにより、
素早くDEA上で実行される

112. Routerはアプリがどこで動いていても
適切なアクセス手段を提供する

113. アプリはDEAとHealth Managerにより
監視され、問題が起きてもすぐに復旧される

114. 全てのコンポーネントはNATSにより疎結合に
結ばれており、柔軟に構築ができる
NATS

115. これがPaaSの仕組み

116. もちろん、PaaSに必要なものは他にもある
• ユーザーの管理・認証・認可
• ログの管理
• メトリクスの管理
• 課金
• Web GUI
• データベース等のサービス
これらの話は、またの機会に。

117. おまけ: これからのPaaS

118. 最近のトレンド

119. OpenShift
DockerベースのPaaSが増えつつあるDeis
Flynn

120. Cloud Foundryも、
次期アーキテクチャ”Diego”で
Dockerに対応する予定
Diego

121. Diegoでは、NATSではなく
CoreOSが開発するetcdを利用する
(現在も一部にはetcdを使っている)

122. 今後もPaaSは変わりつづけるけれど
• Buildpack <=> Dockerfile
• Droplet <=> Docker image
• NATS <=> etcd
と置き換えて考えることも出来る(同一ではないけど)
新しい仕組みを取り入れたからといって、
これまでの知識が無駄になるわけではない

123. 日本Cloud Foundryグループ
#cfgrjp

124. PaaS勉強会
#paasjp http://paas.connpass.com/

125. 参考情報
• はじめてのCF Buildpack http://www.slideshare.net/jacopen/cf-buildpack
• Cloud Foundryは何故動くのか http://www.slideshare.net/jacopen/cloud-foundry-33851040
• Cloud Foundry V2を、もうちょっと深掘りしよう http://www.slideshare.net/jacopen/c-fv2
• 日本Cloud Foundryグループ http://cloudfoundry.gr.jp/
• PaaS勉強会 http://paas.connpass.com/