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には含まれない。

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
コンポーネント間のメッセージング処理基盤

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部分のソースコード

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

ただし、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をサポートしているのなら、なぜそれを使わなかったのか？

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