Cloud Foundry構成概要 111018
•
16 recomendaciones•12,320 vistas
第1回CloudFoundry輪読会 CloudFoundry構成概要 http://blog.udcp.net
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Cloud Foundry構成概要 111018
Similar a Cloud Foundry構成概要 111018 (20)
Último
Último (9)
Cloud Foundry構成概要 111018
- 1. CloudFoundry アーキテクチャガイド 2011/10/18(火) 第1回 CloudFoundry輪読会 @u1
- 2. 自己紹介 — 名前: Yuichi Uemura — twitter: @u1 — web: http://blog.udcp.net — 本職 ◦ IaaS基盤のサービス開発 – VMware vSphere使って作ってます ◦ ここ1年は、、、 – AzureやOffice365といったMicrosoftのサービスと連携させる サービスの開発 — なぜCloudFoundryやっているか？ ◦ Azureやっていて、PaaS基盤の仕組みに興味を持っ たので触ってます
- 3. 本資料の位置づけ — CloudFoundryを作った@derekcollision氏 が2012年9月のOSCON2011の発表資料 (http://www.slideshare.net/derekcollison/oscon-2011)を ベースとしています
- 4. アジェンダ 1. CloudFoundryの設計思想 2. CloudFoundryの各種コンポーネント説明
- 6. CloudFoundryが目指しているところ • アプリケーションとサービスを動かす基盤を提供する • 利用者にとってベストな選択と機会を提供する • シンプルでかつ速いインフラ
- 7. CloudFoundryを作る上での方向性 — KernelとOrchestratorを分割して設計する ◦ Layered on top of IaaS – IaaSレイヤーの上で動き、IaaSには依存しないシステム – VMware vSphere以外でも動く事 — Kernel ◦ Core PaaS System – ここをCloudFoundryと呼ぶ — Orchestrator ◦ KernelをIaaS上に構築、運用、監視する部分は CloudFoundryに含まない – Kernelとは疎結合に作れるようにする – 各事業者、利用者側でここは腕の見せ所
- 9. CF Kernelを作る上での基本的な方向性 — MTTRを高める事を意識する事 ◦ より早く検知し、より早く直す事に特化する – MTTR(Mean Time To Recovery) – MTBF(Mean Time Between Failures) — 自律システムである事 ◦ 故障に対して自動復旧出来る ◦ 保持する・設定する設定情報を最小限にする — PaaSとその上で動くアプリの双方がスケールアウト出来る事 — SPOF(Single Point of Failure)が無い事 — 上記を達成した上で、出来る限りシンプルにアーキテクチャを保ち続 ける
- 10. Basic Design — Event-Driven — Asynchronous — Non-blocking IO — Independent, Idempotent — Message Passing — Eventually Consistent
- 11. Basic Pattern — All componentes loosely couples ◦ 疎結合である事 — Messaging as foundation ◦ メッセージングによるやりとりを基盤とする — JSON payload
- 12. Kernel Components — 全てのComponentを動的に発見出来る事 ◦ ComponentをDBに登録する必要は無い ◦ 自動登録、管理コストの低減、IaaSとPaaSの分割 — 任意のサイズでComponentを実行出来る ◦ 全てのComponentを1つのOS上で動かす事も出来る – MicroCloudFoundry ◦ 複数のOS上に分割することも出来る – Production向けのCloudFoundry
- 13. Kernel Components — CloudController ◦ 構成管理、制御コントローラー — Router ◦ URLロードバランサー — DEA ◦ Droplet Execution Agent ◦ ユーザーアプリを動かすエージェント — HealthManager ◦ 監視機構 — Messaging System ◦ コンポーネント間のメッセージ処理
- 17. 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
- 19. 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の状態の監視も実施している
- 20. DEA 2 — 実装 ◦ Ruby FiberとEventMachineが使える事が必須 ◦ CloudControllerで各言語、フレームワーク毎のstartupファイル を作成し、そのファイルをDEAから実行する – この際に利用するリソース量の制約をかけている – 新しい言語、フレームワークに対応させる場合はstartupファイルの生成ロ ジックに手を入れればok ◦ フレームワーク毎のstartupスクリプトの生成は/vcap/staging/ lib/vcap/staging/pluginの中に記載
- 23. 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対応はここに仕込む)
- 25. 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 を再起動させる
- 27. 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
- 28. Services 2 — 実装 ◦ なぜかservicesだけソースコードツリーがvcapでなく て、vcap-servicesな事に注意 ◦ CloudControllerからの命令はREST UIで待ち受けて いる。ちなみにgatewayの基礎はsinatraで書かれて いる
- 30. Messaging — NATS — 後述のセッションで詳しく@hamaknが話し ます — https://github.com/derekcollison/nats ◦ ここだけcloudfoundryチームではなく、 derekcollison氏のみによる管理
- 31. おしまい