Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CloudFoundry アーキテクチャガイド	 2011/10/18(火)第1回 CloudFoundry輪読会@u1
自己紹介—    名前: Yuichi Uemura	—    twitter: @u1	—    web: http://blog.udcp.net	—    本職	      ◦  IaaS基盤のサービス開発	        – ...
本資料の位置づけ—  CloudFoundryを作った@derekcollision氏 が2012年9月のOSCON2011の発表資料 (http://www.slideshare.net/derekcollison/oscon-2011)を...
アジェンダ1.    CloudFoundryの設計思想	2.    CloudFoundryの各種コンポーネント説明
1.  CloudFoundryの設計思想
CloudFoundryが目指しているところ•    アプリケーションとサービスを動かす基盤を提供する	•    利用者にとってベストな選択と機会を提供する	•    シンプルでかつ速いインフラ
CloudFoundryを作る上での方向性—    KernelとOrchestratorを分割して設計する	      ◦  Layered on top of IaaS	        –  IaaSレイヤーの上で動き、IaaSには依存...
この部分がCloudFoundryの範囲 Orchestratorレイ ヤーは含まない
CF  Kernelを作る上での基本的な方向性—    MTTRを高める事を意識する事	      ◦  より早く検知し、より早く直す事に特化する	        –  MTTR(Mean Time To Recovery)	       ...
Basic  Design—  Event-Driven	—  Asynchronous	—  Non-blocking  IO	—  Independent, Idempotent	—  Message Passing	—  Ev...
Basic  Pattern—    All componentes loosely couples	      ◦  疎結合である事	—    Messaging as foundation	      ◦  メッセージングによるやりとり...
Kernel  Components—    全てのComponentを動的に発見出来る事	      ◦  ComponentをDBに登録する必要は無い	      ◦  自動登録、管理コストの低減、IaaSとPaaSの分割	—    任...
Kernel  Components—  CloudController	  ◦  構成管理、制御コントローラー	—  Router	  ◦  URLロードバランサー	—  DEA	  ◦  Droplet Execution Agent...
2.  CloudFoundryの各種コンポーネント説明
CloudController—    https://github.com/cloudfoundry/vcap/tree/master/cloud_controller	—    機能	      ◦  開発者がCF上のアプリの状態を確認...
DEA  1—    https://github.com/cloudfoundry/vcap/tree/master/dea	—    機能	      ◦  全ての"ユーザー"のAppの実行を司る	      ◦  全てのAppはどのD...
DEA  2—    実装	      ◦  Ruby FiberとEventMachineが使える事が必須	      ◦  CloudControllerで各言語、フレームワーク毎のstartupファイル         を作成し、そのフ...
DEAからAPP起動部分のコードhttps://github.com/cloudfoundry/vcap/blob/master/dea/lib/dea/agent.rb
Router—    https://github.com/cloudfoundry/vcap/tree/master/router	—    機能	      ◦  全ての外部からのHTTPの通信はRouterを経由	        –...
HealthManager—    https://github.com/cloudfoundry/vcap/tree/master/health_manager	—    機能	      ◦  DEA上のAppの状態を監視	      ...
Services  1—    https://github.com/cloudfoundry/vcap-services	—    機能	      ◦  ミドルウェアレイヤーのサービスのDeploy及びAppへ         のbin...
Services  2—  実装	  ◦  なぜかservicesだけソースコードツリーがvcapでなく     て、vcap-servicesな事に注意	  ◦  CloudControllerからの命令はREST UIで待ち受けて    ...
Messaging—  NATS	—  後述のセッションで詳しく@hamaknが話し  ます	—  https://github.com/derekcollison/nats	  ◦  ここだけcloudfoundryチームではなく、  ...
おしまい
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Cloud Foundry構成概要 111018
Upcoming SlideShare
Loading in …5
×

Cloud Foundry構成概要 111018

25,492 views

Published on

第1回CloudFoundry輪読会
CloudFoundry構成概要
http://blog.udcp.net

Published in: Technology

Cloud Foundry構成概要 111018

  1. 1. CloudFoundry アーキテクチャガイド 2011/10/18(火)第1回 CloudFoundry輪読会@u1
  2. 2. 自己紹介—  名前: Yuichi Uemura —  twitter: @u1 —  web: http://blog.udcp.net —  本職 ◦  IaaS基盤のサービス開発 –  VMware vSphere使って作ってます ◦  ここ1年は、、、 –  AzureやOffice365といったMicrosoftのサービスと連携させる サービスの開発 —  なぜCloudFoundryやっているか? ◦  Azureやっていて、PaaS基盤の仕組みに興味を持っ たので触ってます
  3. 3. 本資料の位置づけ—  CloudFoundryを作った@derekcollision氏 が2012年9月のOSCON2011の発表資料 (http://www.slideshare.net/derekcollison/oscon-2011)を ベースとしています
  4. 4. アジェンダ1.  CloudFoundryの設計思想 2.  CloudFoundryの各種コンポーネント説明
  5. 5. 1.  CloudFoundryの設計思想
  6. 6. CloudFoundryが目指しているところ•  アプリケーションとサービスを動かす基盤を提供する •  利用者にとってベストな選択と機会を提供する •  シンプルでかつ速いインフラ
  7. 7. CloudFoundryを作る上での方向性—  KernelとOrchestratorを分割して設計する ◦  Layered on top of IaaS –  IaaSレイヤーの上で動き、IaaSには依存しないシステム –  VMware vSphere以外でも動く事 —  Kernel ◦  Core PaaS System –  ここをCloudFoundryと呼ぶ —  Orchestrator ◦  KernelをIaaS上に構築、運用、監視する部分は CloudFoundryに含まない –  Kernelとは疎結合に作れるようにする –  各事業者、利用者側でここは腕の見せ所
  8. 8. この部分がCloudFoundryの範囲 Orchestratorレイ ヤーは含まない
  9. 9. CF  Kernelを作る上での基本的な方向性—  MTTRを高める事を意識する事 ◦  より早く検知し、より早く直す事に特化する –  MTTR(Mean Time To Recovery) –  MTBF(Mean Time Between Failures) —  自律システムである事 ◦  故障に対して自動復旧出来る ◦  保持する・設定する設定情報を最小限にする —  PaaSとその上で動くアプリの双方がスケールアウト出来る事 —  SPOF(Single Point of Failure)が無い事 —  上記を達成した上で、出来る限りシンプルにアーキテクチャを保ち続 ける
  10. 10. Basic  Design—  Event-Driven —  Asynchronous —  Non-blocking IO —  Independent, Idempotent —  Message Passing —  Eventually Consistent
  11. 11. Basic  Pattern—  All componentes loosely couples ◦  疎結合である事 —  Messaging as foundation ◦  メッセージングによるやりとりを基盤とする —  JSON payload
  12. 12. Kernel  Components—  全てのComponentを動的に発見出来る事 ◦  ComponentをDBに登録する必要は無い ◦  自動登録、管理コストの低減、IaaSとPaaSの分割 —  任意のサイズでComponentを実行出来る ◦  全てのComponentを1つのOS上で動かす事も出来る –  MicroCloudFoundry ◦  複数のOS上に分割することも出来る –  Production向けのCloudFoundry
  13. 13. Kernel  Components—  CloudController ◦  構成管理、制御コントローラー —  Router ◦  URLロードバランサー —  DEA ◦  Droplet Execution Agent ◦  ユーザーアプリを動かすエージェント —  HealthManager ◦  監視機構 —  Messaging System ◦  コンポーネント間のメッセージ処理
  14. 14. 2.  CloudFoundryの各種コンポーネント説明
  15. 15. CloudController—  https://github.com/cloudfoundry/vcap/tree/master/cloud_controller —  機能 ◦  開発者がCF上のアプリの状態を確認、設定を行う際の入 り口 ◦  CloudFoundryの全コンポーネントへの状態変更命令は全 てCloudControllerを経由して行う –  AppのDeployは元より明示的なStart/Stop等も全て実施 —  実装 ◦  Rails3(現バージョンは3.0.5で動作)で書かれている ◦  外部向けにREST APIを保持 –  使えるAPIはroutes.rbを見れば分かる ◦  CloudControllerに対するユーザークライアントを VMC( VMware Cloud CLI)と呼ぶ –  https://github.com/cloudfoundry/vmc
  16. 16. DEA  1—  https://github.com/cloudfoundry/vcap/tree/master/dea —  機能 ◦  全ての"ユーザー"のAppの実行を司る ◦  全てのAppはどのDEAでも実行可能な状態になる ◦  1つのDEA上で1つのAppを動かすか、N個のAppを動かすかは 選択可能 –  極小のVMで1OS 1DEA 1APPで動かすべきか(Single Tenant)、極 大のVMで1OS 1DEA NAPPで動かすべきか(Multi Tenant)はインフ ラ側の設計指針に大きく影響する –  Herokuのアプローチは後者 ◦  動かしているAppの状態の監視も実施している
  17. 17. DEA  2—  実装 ◦  Ruby FiberとEventMachineが使える事が必須 ◦  CloudControllerで各言語、フレームワーク毎のstartupファイル を作成し、そのファイルをDEAから実行する –  この際に利用するリソース量の制約をかけている –  新しい言語、フレームワークに対応させる場合はstartupファイルの生成ロ ジックに手を入れればok ◦  フレームワーク毎のstartupスクリプトの生成は/vcap/staging/ lib/vcap/staging/pluginの中に記載
  18. 18. DEAからAPP起動部分のコードhttps://github.com/cloudfoundry/vcap/blob/master/dea/lib/dea/agent.rb
  19. 19. Router—  https://github.com/cloudfoundry/vcap/tree/master/router —  機能 ◦  全ての外部からのHTTPの通信はRouterを経由 –  APP向けの通信だけでなく、CloudControllerへのアプリケーションDeploy命 令などもRouterを経由する ◦  アプリケーション毎に下段のDEAにURLでルーティングをする –  URL LoadBalancerとして動作 ◦  DEAからリアルタイムにルーティングテーブルのアップデート情報が来 る –  ルーティング情報は動き出したらオンメモリで保持 –  Router再起動時にはCloudControllerから情報を転送し、ルーティングテーブ ルを構成する —  実装 ◦  EventMachineによる非同期処理により、大量のセッション情報を取り 扱っている –  Routerの前段にNginxが仕込まれてる(SSL対応はここに仕込む)
  20. 20. HealthManager—  https://github.com/cloudfoundry/vcap/tree/master/health_manager —  機能 ◦  DEA上のAppの状態を監視 –  DEAに対してHeartbeat Messageを定期的に飛ばしている –  App自体の状態を見ているのはDEA側 –  DEAとHealthManagerは分割しておいておくのが望ましい —  実装 ◦  異常を検知した場合はCloudControllerに対して修復 依頼メッセージを出す –  自分自身に状態遷移を起こす権限は保持していない –  例) DEAが動いているOSがDownした場合、別のDEAで該当APP を再起動させる
  21. 21. Services  1—  https://github.com/cloudfoundry/vcap-services —  機能 ◦  ミドルウェアレイヤーのサービスのDeploy及びAppへ のbind(自動設定)を提供している ◦  2つの役割、GatewayとNodeで構成されている –  Node上でユーザーが利用するミドルウェアが動作し、 Gateway側でNodeに対してDeployをする構成 –  DEAとCloudControllerの関係に近い ◦  現状対応しているServicesは以下 –  mongodb、mysql、neo4j、postgresql(vpostgre)、rabbitmq、 redis –  大きく分けるとRDBとKVSの2種。ただし今後は増えていく可 能性が高い –  vblobなるサービスも。。。README.mdしか無いけどw
  22. 22. Services  2—  実装 ◦  なぜかservicesだけソースコードツリーがvcapでなく て、vcap-servicesな事に注意 ◦  CloudControllerからの命令はREST UIで待ち受けて いる。ちなみにgatewayの基礎はsinatraで書かれて いる
  23. 23. Messaging—  NATS —  後述のセッションで詳しく@hamaknが話し ます —  https://github.com/derekcollison/nats ◦  ここだけcloudfoundryチームではなく、 derekcollison氏のみによる管理
  24. 24. おしまい

×