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

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.ﬂickr.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.ﬂickr.com/photos/dirkdallas/

39. コンテナによるメリット • 異なる環境をアプリに提供出来る • JavaならJava、RubyならRuby • アプリ同士を隔離出来る • セキュリティの担保、リソースの制限 • 素早く立ち上げることがきる • VMを使うと数分、コンテナなら数秒 Photo by Dirk Dallas https://www.ﬂickr.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.ﬂickr.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. Gemﬁleから指定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.ﬂickr.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.ﬂickr.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 <=> Dockerﬁle • 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/

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

Similar to Cloud Foundryで学ぶ、PaaSのしくみ講座 (20)

More from Kazuto Kusama (20)

Recently uploaded (20)