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

Transcript

• 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/