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氏のみによる管理

おしまい