Upload
uemura-yuichi
View
19.850
Download
2
Embed Size (px)
DESCRIPTION
第1回CloudFoundry輪読会 CloudFoundry構成概要 http://blog.udcp.net
Citation preview
CloudFoundry アーキテクチャガイド 2011/10/18(火) 第1回 CloudFoundry輪読会 @u1
自己紹介
� 名前: Yuichi Uemura � twitter: @u1 � web: http://blog.udcp.net
� 本職 ◦ IaaS基盤のサービス開発 � VMware vSphere使って作ってます
◦ ここ1年は、、、 � AzureやOffice365といったMicrosoftのサービスと連携させる
サービスの開発
� なぜCloudFoundryやっているか? ◦ Azureやっていて、PaaS基盤の仕組みに興味を持っ
たので触ってます
本資料の位置づけ
� 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には依存しないシステム
� VMware vSphere以外でも動く事
� Kernel ◦ Core PaaS System
� ここをCloudFoundryと呼ぶ
� Orchestrator ◦ KernelをIaaS上に構築、運用、監視する部分は
CloudFoundryに含まない
� Kernelとは疎結合に作れるようにする
� 各事業者、利用者側でここは腕の見せ所
この部分がCloudFoundryの範囲
Orchestratorレイヤーは含まない
CF Kernelを作る上での基本的な方向性
� MTTRを高める事を意識する事
◦ より早く検知し、より早く直す事に特化する � MTTR(Mean Time To Recovery)
� MTBF(Mean Time Between Failures)
� 自律システムである事
◦ 故障に対して自動復旧出来る
◦ 保持する・設定する設定情報を最小限にする
� PaaSとその上で動くアプリの双方がスケールアウト出来る事
� SPOF(Single Point of Failure)が無い事
� 上記を達成した上で、出来る限りシンプルにアーキテクチャを保ち続ける
Basic Design
� Event-Driven
� Asynchronous
� Non-blocking IO
� Independent, Idempotent
� Message Passing
� Eventually Consistent
Basic Pattern
� All componentes loosely couples ◦ 疎結合である事
� Messaging as foundation
◦ メッセージングによるやりとりを基盤とする
� JSON payload
Kernel Components
� 全てのComponentを動的に発見出来る事 ◦ ComponentをDBに登録する必要は無い
◦ 自動登録、管理コストの低減、IaaSとPaaSの分割
� 任意のサイズでComponentを実行出来る
◦ 全てのComponentを1つのOS上で動かす事も出来る � MicroCloudFoundry
◦ 複数のOS上に分割することも出来る � Production向けのCloudFoundry
Kernel Components
� CloudController ◦ 構成管理、制御コントローラー
� Router ◦ URLロードバランサー
� DEA ◦ Droplet Execution Agent
◦ ユーザーアプリを動かすエージェント
� HealthManager ◦ 監視機構
� Messaging System ◦ コンポーネント間のメッセージ処理
2. CloudFoundryの各種コンポーネント説明
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
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の状態の監視も実施している
DEA 2
� 実装 ◦ Ruby FiberとEventMachineが使える事が必須
◦ CloudControllerで各言語、フレームワーク毎のstartupファイルを作成し、そのファイルをDEAから実行する � この際に利用するリソース量の制約をかけている
� 新しい言語、フレームワークに対応させる場合はstartupファイルの生成ロジックに手を入れればok
◦ フレームワーク毎のstartupスクリプトの生成は/vcap/staging/lib/vcap/staging/pluginの中に記載
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を経由
� APP向けの通信だけでなく、CloudControllerへのアプリケーションDeploy命令などもRouterを経由する
◦ アプリケーション毎に下段のDEAにURLでルーティングをする
� URL LoadBalancerとして動作
◦ DEAからリアルタイムにルーティングテーブルのアップデート情報が来る
� ルーティング情報は動き出したらオンメモリで保持
� Router再起動時にはCloudControllerから情報を転送し、ルーティングテーブルを構成する
� 実装 ◦ EventMachineによる非同期処理により、大量のセッション情報を取り
扱っている
� Routerの前段にNginxが仕込まれてる(SSL対応はここに仕込む)
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を再起動させる
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
Services 2
� 実装 ◦ なぜかservicesだけソースコードツリーがvcapでなく
て、vcap-servicesな事に注意
◦ CloudControllerからの命令はREST UIで待ち受けている。ちなみにgatewayの基礎はsinatraで書かれている
Messaging
� NATS
� 後述のセッションで詳しく@hamaknが話します
� https://github.com/derekcollison/nats
◦ ここだけcloudfoundryチームではなく、derekcollison氏のみによる管理
おしまい