Cloud Foundry構成概要 111018

23,373 views
23,763 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. おしまい

×