PaaS基盤「Cloud Foundry」のアーキテクチャは、どうなっている?

2011年10月21日

先週、Cloud Foundryのソースコードを読もうという「第1回 CloudFoundry輪読会」が開催され、参加してきました。

Cloud FoundryはVMwareからリリースされたオープンソースのPaaS基板ソフトウェア(および同名のVMwareによるクラウドサービス)で、IaaSに依存せず、VMwareのvSphereやAmazonクラウドなど複数のクラウドに対応するのが特徴です。また、Java、Pythonなど複数の言語、MySQLやPostgreSQLなど複数のデータベースをサポートしており、囲い込みをしない「Open PaaS」を指向しています。

同種のPaaS基盤はRed HatからOpenShiftが登場してきており、IaaS非依存、複数言語対応、複数データベース対応のオープンなPaaSという新しいトレンドを作りつつあります。

この新しいPaaS基盤がどのような仕組みになっているのか、これまで情報がほとんどなかった中でこのCloud Foundry輪読会はその情報を得る貴重な機会でした。輪読会の内容からポイントになるところを、記事として紹介したいと思います。

(追記:Cloud Foundry V2のアーキテクチャについては、記事「PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている?(前編)」をご参照ください)

CloudFoundryの全体構成

  • CF kernel(Cloud Foundry Kernel)とOrchestatorを分割して設計することで、IaaSには依存しないようになっている。
  • CF Kernel(=Cloud Foundryカーネル)の部分を「Cloud Foundry」と呼ぶ。
  • Orchesratorは、CF KernelをIaaS上に構築し、運用、監視する部分で、ここはCloud Foundryには含まれない。
fig

CF Kernelを作る上での方向性

  • MTTR(Mean Time To Recovery)を高める。障害をより早く検知し、より早く直すこととする。
  • 自律システムで、故障に対して自動復旧できること、保持する設定情報を最小限にする。
  • PaaSとその上で動くアプリケーションの双方がスケールアウトすること
  • Single Point of Failureがないこと(ただし後述のように現在はまだ残っている)
  • 上記を達成した上で、できるだけシンプルにする

基本デザインとパターン

  • イベントドリブン
  • 非同期
  • ノンブロッキングI/O
  • すべてのコンポーネントは疎結合であること
  • メッセージングによるやりとりを基盤とする

カーネルコンポーネント

  • すべてのコンポーネントを動的に発見できること
  • つまり、コンポーネントをデータベースに登録する必要がない
  • 自動登録によって管理コストを低減し、IaaSとPaaSの分割を実現
  • すべてのコンポーネントを1つのOS上で動かすことも、複数のOS上に分割して動かすこともできる(前者がMicro Cloud Foundry、後者はプロダクション向けのCloud Foundry)

カーネルコンポーネントの種類

  • CloudController
    構成管理、制御コントローラー
  • Router
    名前はRouterでインターネットのルーターと紛らわしいが別物。URLロードバランサー
  • DEA(Droplet Execution Agent)
    ユーザーアプリケーションを動かすエージェント
  • HealthManager
    監視機構
  • Messaging System
    コンポーネント間のメッセージング処理基盤
fig

CloudController

  • Cloud Foundryの全コンポーネントへの状態変更命令はすべてCloudControllerを経由して行う
  • アプリケーションのデプロイ、スタート、ストップなどもすべてCloud Foundryが実施
  • Cloud Contollerが、アプリケーションの言語/フレームワークなどを判別し、必要なスタートアップファイルとともにDEAに実行指令を出す
  • CloudControllerはRails3で開発された
  • CloudControllerに対するユーザークライアントをVMC(VMware Cloud CLI)と呼ぶ

DEA

  • DEAは、すべてのユーザーアプリケーションの実行を司る
  • すべてのアプリケーションは、どのDEAでも実行できる
  • Cloud ControllerがDEAへアプリケーションの実行を指令するときに、アプリケーションが利用するリソース量の制約をシェルの「ulimitコマンド」でかけている

Router

  • カーネルコンポーネントを含むすべての外部からのHTTP通信はRouterを経由
  • アプリケーション毎に下段のDEAにURLでルーティングをする。URLロードバランサーとして動作する
  • ルーティング情報は動き出したらオンメモリで保持

HealtManager

  • HealtManagerはDEA上のアプリケーションの状態監視
  • ただしDEAにHeartbeatを出しているだけで、直接アプリケーションの状態を見るのはDEA
  • 異常を検知した場合はCloudControllerに対して修復依頼メッセージを出す

Services/Massaging

  • Servicesは、ミドルウェアレイヤのサービス(おもにデータベース)のデプロイおよびアプリケーションへのbind(自動設定)を提供している
  • 現在対応しているのはMongoDB、MySQL、Neo4j、PostgreSQL、RabbitMQ、Redis。今後さらに増えていく可能性が高い。

  • Messagingの部分は「NATS」と呼ばれる(理由は…?)

Cloud Foundryのマルチノードへの展開

VCAPはCloud Foundryの本体。CF Kernel部分のソースコード

fig

複数のノードに分散してコンポーネントをインストールできるため、スケーラビリティや可用性に適したシステム構築が可能。

ただし、CFカーネルからは下のレイヤに対して(つまりOrchestratorレイヤ)に対して、インスタンスの増減の指令を出す機能はないので、あらかじめマニュアルで最初から複数ノードにデプロイしておく必要がある。

Q&Aなど

──── 動作環境はLinuxのみと考えていいのか?

Linux/UNIXで、Windowsは対応していない。

──── CF KernelとOrchestratorレイヤの連係はないと説明があったが、つまりPaaSレイヤからIaaSレイヤに対してインスタンスの増加や減少といった要求はそもそも出せないということか?

イエス。いまはあらかじめマニュアルでIaaSレイヤにデプロイするだけ。Orchestrationレイヤはいまのところない。(新野注:たぶんVMwareが将来、製品としてリリースするCloud Foundryでは、IaaSとなるvSphereと連係がとれるようになるのでしょう)。

──── HealthManagerやCloudControllerはSPOFにならないのか?

HealthManagerは落ちても直接の運用の支障にはならない、ただしNATS(Messagingのこと)は、ここが死んだらだめだと思っているので、いま対応を作りかけのようだ。CloudControllerに関してはRailsのアプリなので、これのSPOF対策はRailsアプリとしてデプロイ側でいまはやらなければならないレベルのようだ。

──── Messaging(NATS)は、なぜ独自のものを作ったのか? RabbitMQをサポートしているのなら、なぜそれを使わなかったのか?

シニアアーキテクトの人によると、小さいのがほしかった、余計な機能を持たせたくなかったとのこと。

参照資料

輪読会で説明に使われたスライドです。

Node on CloudFoundry :: 2011

このエントリーをはてなブックマークに追加
follow us in feedly




カテゴリ

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本