Cloud Foundryの次バージョンでDockerや.NET対応を実現する「Diego」の内部構造は？（前編）第25回PaaS勉強会

2015年7月1日

オープンソースで開発されているPaaS型クラウド基盤ソフトウェアの「Cloud Foundry」は、その内部にコンテナベースの実行環境である「DEA」（Droplet Execution Agent）を搭載しています。

Cloud Foundryの次バージョンとなるCloud Foundry V3では、このDEAに代わる新しい実行環境の「Diego」が登場します。そしてDiegoの登場は単にDEAがDiegoに置き換わるのではなく、Cloud Foundryのアーキテクチャそのものの変革につながっています。

Diegoとは果たしてどのようなものなのでしょうか？ 3月に都内で行われた「第25回 PaaS勉強会」でNTTコミュニケーションズの草間一人氏によって行われたセッション「Cloud FoundryでDockerも.Netも。新コンポーネント Diego入門」の内容を紹介します。

Diegoの登場はアーキテクチャの大変革

草間です。普段はCloud Foundry関連の仕事もしています。

Diegoの前に、現在のCloud Foundryの復習しておきます。

Cloud Foundryには、APIの提供やコントロールを行うCC（Cloud Controller）があって、ユーザーアプリを動かすDEAがあり、リクエストをルーティングするRouterがあって、アプリの死活管理をするHealth Managerがあって、それらのコンポーネントがNATSを通して通信する、これがいまのCloud Foundryです。

参考：PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている？（前編）参考：PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている？（後編）

Diegoというのは、このDEAがGo言語で開発されるので「Diego」なんです。

じゃあDEAがDiegoに置き換えられるだけなのかというとそうではなくて、Diegoの登場はCloud Foundryにとってはじめてのアーキテクチャの大変革なんですね。

でもCloud FoundryはV1からV2のときも大きく変わったではないかと、そう思われるかもしれません。

たしかに僕はCloud Foundryの商用サービスを担当しているので、V2に切り替わるときはメチャクチャ大変でした。APIが新しくなってコンポーネントも一から書き直されたりしましたが、しかしV1からV2でアーキテクチャはあまり変わってないんです。

じゃあDiegoの登場でどう変わるのか？というのを説明していきます。

Diegoは4つのコンポーネントに分かれる

これがDiegoのコンポーネントです。この青い部分がDiegoにあたるところです。

Diegoは大きく4つのコンポーネントに分かれます。

「Cell」はコンテナを動かすためのコンポーネントです。ユーザーがアプリをデプロイすると、Cellの上で起動します。

コンテナの動かし方には、一時的な「Task」と、動かし続ける「LRP」（Long Running Process）があります。

「Brain」はスケジューリングを行うコンポーネントです。これには3つの役割があり、そ「Auctioneer」、「Converger」「Metrics Server」です。

「Auctioneer」は、これまでCloud Controllerがやってきたスケジューリングを行います。アプリをどのVMで動かすか、それを決めることをスケジューリングといいますが、いままではDEAがそれぞれ「4GB空いている」とか「2GBいける」と自己申告し、Cloud Controllerが判断していました。

一方でDiegoはAuctioneerが、「こういうアプリがある」と言ってオークションを開き、Cellがその仕事を競り落とす仕組みになっています。