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

14,226 views

Published on

APC勉強会 #18で発表した資料です。
http://8a1-apc.connpass.com/event/13592/

ブラックボックス化されていて、普段見ることができないPaaSの中身を、OSSのPaaSであるCloud Foundryを題材に解説します。

Published in: Technology
0 Comments
91 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,226
On SlideShare
0
From Embeds
0
Number of Embeds
885
Actions
Shares
0
Downloads
257
Comments
0
Likes
91
Embeds 0
No embeds

No notes for slide

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

  1. 1. Cloud Foundryで学ぶ
 PaaSのしくみ講座
  2. 2. 日本Cloud Foundryグループ Kazuto Kusama @jacopen
  3. 3. 日本Cloud Foundryグループ #cfgrjp
  4. 4. PaaS
  5. 5. 1. コードを書く 2. PaaSにデプロイ 3. 動作! すごく簡単 PaaS
  6. 6. 1. コードを書く 2. PaaSにデプロイ 3. 動作! PaaS わかる わかる え、どうやったの?
  7. 7. 1. コードを書く 2. PaaSにデプロイ 3. 動作! PaaS わかる わかる え、どうやったの? 4. スケールアウト ???
  8. 8. PaaSが便利なのは分かる インフラを知らなくとも使える でも、ブラックボックスなのは嫌だ
  9. 9. 今回の目的 • ブラックボックスに思われがちな、PaaSの中身を理解して貰う ことで、不安を解いてもらいたい • Cloud Foundryだけでなく、どのPaaSにも共通して利用できる 知識を身につける
  10. 10. PaaS上の
 アプリの動作を 見てみる PaaS上の アプリの一生を 追ってみる PaaSを支える 仕組みを学ぶ 321
  11. 11. 教材: Cloud Foundry • オープンソースのPaaSなので、
 誰でも仕組みを追える • 多くのベンダーが採用
 (IBM, HP, NTT Comなど) • ユーザーが機能を拡張できる、Heroku 互換のBuildpackを採用している
  12. 12. PaaS上の
 アプリの動作を 見てみる1
  13. 13. 例えば、PHPアプリを構築するとき • Apache/Nginxをインストール • PHP(mod_php/php-fpm)をインストール • 必要に応じてpeclやpearをインストール
  14. 14. 例えば、Rubyアプリを構築するとき • Rubyをインストール • bundle install • (Railsなら) rake assets:precompile • (Railsなら) rake db:migrate
  15. 15. DEMO
  16. 16. ※DEMOで話した内容 皆さんが普段Apache+PHPの環境を作りたいと思ったとき たぶんこんな感じでapt-getでインストールすると思います。 するとほら、こんな感じでApacheのプロセスが起動するわけですね。
  17. 17. ※DEMOで話した内容 じゃあRubyのアプリの場合はどうか。 ここにSinatraのアプリを用意しましたので、まずは定番のbundle installですね。 その後に起動します。
  18. 18. ※DEMOで話した内容 すると、こんな感じで起動するわけです。 ここまでは、皆さんが見慣れた光景ですよね。
  19. 19. Server OS Apache PHP (mod_php/php-fpm) Application Server OS Ruby WEBrick Application サーバー OS ミドルウェア アプリケーション 手動で構築したときのソフトウェアスタック
  20. 20. では、PaaSの場合は?
  21. 21. DEMO
  22. 22. ※DEMOで話した内容 PaaSの場合、中身はどうなるんでしょう。 今回、自前のCloud Foundry環境を用意したので、まずはSinatraアプリを デプロイしてみます。
  23. 23. ※DEMOで話した内容 デプロイ出来たので、実際にPaaS環境の中に入って、どんな感じにアプリが 上がっているか見てみましょうか。 Rubyのプロセスが上がっているのが分かりますよね。さっきと殆ど同じという ことが分かるでしょう。
  24. 24. ※DEMOで話した内容 次にPHPアプリをデプロイしてみました。 httpd となっていますが、さっき手動で上げたときのapache2のバイナリの 名前が違うだけです。単純にApacheのプロセスが上がっているだけ、 と言うことです。 つまり、皆さんが普段自前で組んでる環境も、PaaSで組まれる環境も、 中身は殆ど同じ、というわけです。
  25. 25. Server OS Apache PHP (mod_php/php-fpm) Application Server OS Ruby WEBrick Application サーバー OS ミドルウェア アプリケーション PaaS上のソフトウェアスタック
  26. 26. PaaSであっても
 アプリが動く仕組みは一緒 ポイント①
  27. 27. PaaS上の アプリの一生を 追ってみる2
  28. 28. Server OS Apache PHP /usr/sbin/apache2 /etc/apache2/ … /usr/bin/php5 /etc/php5/ … apt-get yum source… 手動で構築する時 • aptやyumなどの
 パッケージマネージャ • ソースからコンパイル • どちらの場合も、
 サーバーの特定の場所 にランタイムが配置さ れる
  29. 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. 30. DEMO
  31. 31. ※DEMOで話した内容 さっき上げたアプリをもう一度見てみましょうか。 /home/vcap/app∼の下に、何かコンフィグがあるようですね。見てみましょうか あれ、おかしいですね。/home/vcapに居るはずなのに、そもそもappなんて ディレクトリが存在しないように見えます。
  32. 32. ※DEMOで話した内容 Rubyの場合も、/home/vcap/app配下のファイルを読んでいるようですが、 やはりPaaS環境上に、そんなファイルは存在しないように見えます。 どういうことでしょうか。
  33. 33. ※DEMOで話した内容 ここで皆さんに覚えておいて欲しいのが、コンテナという仕組みです。 この後説明しますが、アプリはコンテナの中で動いています。実際にアプリの コンテナの中に入ってみますね。 コンテナの中で、Rubyプロセスが上がっているのが確認出来ます。 ファイルはどうでしょうか。
  34. 34. ※DEMOで話した内容 はい、確かにファイルが存在することが確認出来ました。 これはさっきアップロードした、Sinatraアプリですね。 bin/ の中を見てみると、rubyやgemなど、実行に必要なバイナリが既に 設置されていることが分かります。実際にRubyバイナリを実行して、 バージョン情報を見てみましょうか。
  35. 35. ※DEMOで話した内容 では、PHPアプリのほうを見てみましょうか。 こちらも/home/vcap/app が存在しますね。ここで重要なのは、さっきのRubyと 同じパスなのにも関わらず、設置してあるファイルは全く別物ということです。 アプリケーションに応じて、必要なものが、適切に設置してあるわけです。
  36. 36. ✓ PaaSの実行環境では、アプリごとにコンテナが作られ、
 マルチテナントで動いている ✓ コンテナの中には、実行に必要なバイナリが全て含まれている ✓ その他実行に必要な作業も全て実施済(Rubyのbundle installなど) Photo by Enokson https://www.flickr.com/photos/vblibrary/4385390248/
  37. 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. 38. コンテナ技術 • Cloud Foundryの場合、Wardenという 独自のコンテナ機構を使っている • HerokuはLXCを利用 • 最近はDockerが流行り いずれもLinuxのcgroupsやnamespaceと いう機能を活用しており、得られる
 メリットは似通っている Photo by Dirk Dallas https://www.flickr.com/photos/dirkdallas/
  39. 39. コンテナによるメリット • 異なる環境をアプリに提供出来る • JavaならJava、RubyならRuby • アプリ同士を隔離出来る • セキュリティの担保、リソースの制限 • 素早く立ち上げることがきる • VMを使うと数分、コンテナなら数秒 Photo by Dirk Dallas https://www.flickr.com/photos/dirkdallas/
  40. 40. Application Application Application Application Server OS Apache Ruby 2.1.4 Ruby 1.9.3-p551 Java7 php-fpm Tomcat このコンテナイメージは、 誰が、いつ用意したのか?
  41. 41. Buildpack
  42. 42. Buildpack • Herokuによって作られた、任意の言語 やフレームワークを扱えるようにする 仕組み • Cloud FoundryもBuildpackを利用可能 Photo by cgc76 https://www.flickr.com/photos/cgc76/10620451574
  43. 43. Buildpack • Ruby • PHP • Java • Python • Go • Node • etc…
  44. 44. Buildpackの3フェーズ 1. Detect 2. Compile 3. Release Buildpackには、必ずこの3スクリプトが
 含まれている
  45. 45. 1. Detect 2. Compile 3. Release Buildpackの実行条件に合致するかを チェックするスクリプト。 合致したら0を、合致しなければ1を返 す。
  46. 46. 1. Detect 2. Compile 3. Release composer.jsonがあるか (無ければ次へ) .phpのファイルがあるか (無ければ次へ) $WEBDIRがあるか PHP Buildpackの場合
  47. 47. 1. Detect 2. Compile 3. Release 実行環境を構築するスクリプト
  48. 48. 1. Detect 2. Compile 3. Release Ruby Buildpackの場合 1. Gemfileから指定Rubyバージョンを
 確認して、バイナリをダウンロード 2. フレームワークを確認(Rails?Sinatra?) 3. bundle install 4. rake assets:precompile(Railsの場合)
  49. 49. 1. Detect 2. Compile 3. Release 実行に必要な環境変数などの情報を出力 (今回は説明は割愛)
  50. 50. つまりBuildpackとは • コードがどういう言語で書かれている か検出する • その言語向けの環境を構築する Photo by cgc76 https://www.flickr.com/photos/cgc76/10620451574
  51. 51. ここまでの復習を兼ねて
 一連の流れで考えてみよう
  52. 52. 1. ユーザーがアプリをプッシュ
  53. 53. 2. Cloud Foundryがアプリを受け取る Insi Ruby buildpack Java buildpack PHP buildpack PH
  54. 54. 3. アプリに対し、内蔵のBuildpackのdetect
  スクリプトを順次実行 Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  55. 55. 4. detectでマッチしたBuildpackの
  compileスクリプトを実行 Inside PaaS Java buildpack PHP buildpack PHP buildpack
  56. 56. 5. ランタイムもアプリも含まれた  実行環境一式が出来上がる Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  57. 57. 6. Cloud Foundryの実行ノードで  アプリを起動  (このとき、コンテナで動く) aaS
  58. 58. Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  59. 59. Buildpackの適用を中心とした、 アプリの準備作業を「ステージング」と呼ぶ Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  60. 60. PaaSへの「デプロイ」は「アップロード」
 「ステージング」「実行」の3フェーズで構成される Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  61. 61. これまで手動で行ってきたインストール作業を
 コードから自動判別して行っているに過ぎない Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  62. 62. スケールアウトの仕組み
  63. 63. DEMO
  64. 64. ※DEMOで話した内容 Cloud Foundryでは、コマンド一発でアプリケーションのインスタンス数を 増やすことができます。それも一瞬で。実際に試してみましょうか。 一瞬で起動しましたね。手動でサーバーをスケールアウトするのと比べると、 数百倍、数千倍速いですね。これはどういう仕組みなんでしょうか。 ←だいたい数秒
  65. 65. スケールアウト • コマンド一発で、たくさんのインスタ ンスを展開出来る • しかも速い
  66. 66. Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack ・ ・ ・ buildpackをたくさん実行? 時間がかかるし、負荷も高そう
  67. 67. Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack Dropletと言う形で、保存しています Droplet
  68. 68. Cloud Controller DEA (Droplet Execution Agent)
  69. 69. Ruby buildpack Java buildpack PHP buildpack PH アップロードを受け取るのは、CCの仕事
  70. 70. Ruby buildpack Java buildpack PHP buildpack PHP buildpack CCからDEAに、ステージングの依頼
  71. 71. PHP buildpack DEAは成果物(Droplet)を返す。CCはそれを保存。
  72. 72. CCはDropletを各DEAに配布して実行を依頼する
  73. 73. スケールアウト時は、ステージングは行わず
 Dropletの配布のみで済む
  74. 74. PaaSを支える 仕組みを学ぶ 3
  75. 75. appA appA appAappBappB Internet ? アプリは複数台に跨がっ ているだけでなく、関係 ないアプリと同居してい るという状態。 目的のアプリにどうやっ てアクセスすればよいか。
  76. 76. リクエストルーティング
  77. 77. Router
  78. 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. 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. 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. 81. appA appA appAappBappB 実際にリクエストが来たら、 リストを元にアクセスを分 配 ♪ appA.example.com
  82. 82. ✓ Cloud FoundryのRouterは、アプリへのリクエストを解釈して正 しい場所に転送する、L7のリクエストルーター ✓ Routerが利用する情報は、各DEAからもたらされる ✓ 一般的に使われる、L3の「ルーター」とは異なるので注意 Photo by Enokson https://www.flickr.com/photos/vblibrary/4385390248/
  83. 83. メッセージングバス
  84. 84. appA appA appAappBappB 負荷が高くなっても対応できるよう、Routerは複数台で負荷 分散できるようになっている。
  85. 85. appA appA appAappBappB ところで、先ほど「DEAはRouterに通知する」と表現した。
 つまり、Routerの数が増えると、通知数も増えてしまう? Router数 x DEA数=通知数・・・
  86. 86. appA appA appAappBappB もちろん、そうはならない。メッセージのやり取りは、
 NATSというPub-Sub型メッセージングバスを通じて行う NATS
  87. 87. Publish-Subscribeモデル • メッセージの送信側(Publisher) と受信 側(Subscriber)が存在 • Publisherはトピックを付けてメッセー ジを送信する。どれだけのSubscriber が居るかは関知しない。 • Subscriberは、指定しているトピック のメッセージを自動的に受信する Publisher Subscriber
  88. 88. Publish-Subscribeモデル Subscribe ENL ENL RES Subscribe ENL and RES Subscribe RES NATS Publish Publish
  89. 89. appA appA appAappBappB Subscribe router.register Publish router.register {“uris”:[“appA.example.com”],”host”:"192.168.10.2","port":35155} NATS
  90. 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. 91. NATS • NATSを通じて疎結合に構成されている • どこに何が存在するか、各コンポーネ ントが把握しておく必要が無い(NATS のアドレスさえ分かっていればいい) • そのため、柔軟にコンポーネントの追 加・削除が行える
  92. 92. 死活監視
  93. 93. appA appA appAappBappB 運用していると、必ず障害は起こる ぬるぽ ソフトウェアのバグで アプリがクラッシュ ハードウェア障害で DEAホストがダウン
  94. 94. Health Manager
  95. 95. appA appB アプリのクラッシュ時 ぬるぽ NATS Σ appB DEAがアプリのクラッシュを検出
  96. 96. appA appB アプリのクラッシュ時 ぬるぽ NATS Publish droplet.exited Subscribe droplet.exited appB dropletが終了した旨をpublish。
 HMはそれをsubscribeしている
  97. 97. appA appB アプリのクラッシュ時 NATS Publish hm9000.start appB Subscribe hm9000.start HMはCCにクラッシュしたアプリを 再度上げるよう通知
  98. 98. appA appB アプリのクラッシュ時 NATS appB Publish dea.start Subscribe dea.start CCはDEAにアプリの立ち上げ メッセージを通知
  99. 99. appA appB アプリのクラッシュ時 NATS appB appA アプリが復旧する
  100. 100. appA appB ホストのクラッシュ時 NATS appB DEAは普段から、heartbeatを定期的にpublishしている Publish dea.heartbeat Running appA, appB Publish dea.heartbeat Running appB Subscribe dea.heartbeat
  101. 101. appA appB ホストのクラッシュ時 NATS appB ホストがクラッシュした場合、heartbeatが来なくなるので HMはクラッシュに気づく Publish dea.heartbeat Running appB ?
  102. 102. appA appB ホストのクラッシュ時 NATS appB 足りなくなった分を増やすよう通知 Publish hm9000.start Subscribe hm9000.start
  103. 103. appA appB ホストのクラッシュ時 NATS appB アプリが復旧する appA appB Publish dea.start Subscribe dea.start
  104. 104. まとめ
  105. 105. ユーザーが書いたコードは
  106. 106. PaaS上でよしなに実行される PaaS
  107. 107. アプリ自体は、ごく一般的な仕組みで動いている OS Runtime Framework
  108. 108. その裏には、多くの人に便利なサービスを
 提供できるよう、考え抜かれた仕掛けが存在する Inside PaaS Ruby buildpack Java buildpack PHP buildpack PHP buildpack
  109. 109. Cloud Controllerはユーザーからのリクエストを 受け取り
  110. 110. Buildpackにより実行可能なDropletが作成され Ruby buildpack Java buildpack PHP buildpack
  111. 111. DropletはCCのコントロールにより、
 素早くDEA上で実行される
  112. 112. Routerはアプリがどこで動いていても
 適切なアクセス手段を提供する
  113. 113. アプリはDEAとHealth Managerにより
 監視され、問題が起きてもすぐに復旧される
  114. 114. 全てのコンポーネントはNATSにより疎結合に
 結ばれており、柔軟に構築ができる NATS
  115. 115. これがPaaSの仕組み
  116. 116. もちろん、PaaSに必要なものは他にもある • ユーザーの管理・認証・認可 • ログの管理 • メトリクスの管理 • 課金 • Web GUI • データベース等のサービス これらの話は、またの機会に。
  117. 117. おまけ: これからのPaaS
  118. 118. 最近のトレンド
  119. 119. OpenShift DockerベースのPaaSが増えつつあるDeis Flynn
  120. 120. Cloud Foundryも、
 次期アーキテクチャ”Diego”で
 Dockerに対応する予定 Diego
  121. 121. Diegoでは、NATSではなく
 CoreOSが開発するetcdを利用する
 (現在も一部にはetcdを使っている)
  122. 122. 今後もPaaSは変わりつづけるけれど • Buildpack <=> Dockerfile • Droplet <=> Docker image • NATS <=> etcd と置き換えて考えることも出来る(同一ではないけど)
 新しい仕組みを取り入れたからといって、
 これまでの知識が無駄になるわけではない
  123. 123. 日本Cloud Foundryグループ #cfgrjp
  124. 124. PaaS勉強会 #paasjp http://paas.connpass.com/
  125. 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/

×