3. Cloud Foundryのアーキテクチャ
続いてRichardson氏は、Cloud Foundryのアーキテクチャの概要を説明した。Cloud Foundryのプラットフォームはメッセージングによって連携する複数のコンポーネントか構成され、全体像は図3.1のようになっている。
このうち核となるのがCloud Controllerで、アプリケーションの構成管理や、WebサービスAPIの提供などはこのCloud Controllerによって行われる。VMCからの接続もCloud Controllerによって処理されている。DEA（Droplet Execution Agent）というのは、ユーザアプリケーションを動作させるためのエージェントである。アプリケーションはどのDEA上でも実行可能な状態になっており、1つのDEAでいくつのアプリケーションを動作させるかは設定によって選択できる。なお、Dropletというのは、vmc statsコマンドで確認できるインスタンスの実態のことだ。
リクエストのアプリケーションへの振り分けは、RouterとLoad Balancerによって行われる。すべての外部からのHTTPリクエストはRouterを経由し、アプリケーションごとにURLで適切なDEAにルーティングされるとのこと。図3.2は、リクエストハンドリングの流れを示したものである。
Health ManagerはDEAを監視していて、問題が発生した場合にはControllerに通知する。なお、Health Managerが監視しているのはDEAであり、アプリケーション自体の状態は各DEAによって監視されているとのことである。Servicesは、ミドルウェアの機能をサービスとして提供するコンポーネントである。これによりPostgreSQLやMongoDBなどによるストレージ機能が提供されている。
図3.3は、アプリケーションをデプロイする場合の処理の流れを示したものだという。
vmc pushコマンドが実行されたら、まずVMCがフレームワークの検出を行い、Cloud Controllerと通信してアプリケーションのデプロイを開始する。Controllerはフレームワーク用のstagingプラグインを利用して、必要なサービスのDropletを作成する。実際のアプリケーションはDEA上に展開されるので、まずはDEAがアプリケーションを展開可能であるかどうかを確認し、十分なリソースがあればDropletが展開されることになる。DEAは続いてRouterのルーティングテーブルを更新し、アプリケーションをスタートする。
障害に対する自己復旧機能を持っている点は、Cloud Foundryの大きな特徴の一つである。アプリケーションが予期しないエラーで終了した場合には、DEAがその旨のメッセージをブロードキャストする。それに応じて、Routerは対象のアプリケーションへのルーティングを中止し、Health ManagerはCloud Controllerに障害を通知する。通知を受け取ったCloud Controllerは、デプロイメントのプロセスを再度実行することによって、アプリケーションのインスタンスを復帰させる。
DEAそのものの障害はHealth Managerによって監視される。Health ManagerからはDEAに向けて定期的にHeatBeatメッセージが送られており、DEAのクラッシュを自動で検知できるようになっている。クラッシュを検知したHealth Managerは、Cloud Controllerにその旨を通知し、Cloud ControllerはDEAとアプリケーションインスタンスの再機動を実行するという仕組みである。
