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関連の仕事もしています。

fig

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

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

fig

参考:PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている?(前編) 参考:PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている?(後編)

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

fig

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

fig

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

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

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

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

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

fig

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

fig

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

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

fig

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

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

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

fig

なぜこの仕組みがいいのか? どんなメリットがあるかは、詳しくは数学的な根拠があるそうなのですが、そこまで詳しくは調べられていないので、どなたかの説明を期待します。

「Converger」は、何かのはずみでコンポーネントが死んだりアプリのインスタンスが足りなくなったときに、増やすためのオークションを要求します。また、なんらかの理由でインスタンスが多ければとめるためのオークションも要求します。V2までのHealth Managerに近い感じです。

BBSは各コンポーネントの情報を集約します。これはetcdそのものです。DiegoのコンポーネントはV2で使われていたNATSではなく、etcdで情報をやりとりします。

「Receptor」はAPIを提供するコンポーネントです。Cloud Foundryに詳しい人は、なるほどいままでのCloud ControllerがDiegoではReceptorになるのか、と思われるかもしれませんが、違います。

Receptorが提供するAPIは、TaskのCRUD、Long Running ProcessのCRUD、Cellのリストを返す、これだけです。

Receptorの役割は、APIでTaskやLRPのリクエストを受け付けて、Diegoのクラスタ内に展開する。また、アプリ作成や削除のリクエストであれば、オークションにかける。というもので、PaaSとしてのAPIは提供しません。

Kubernetesに似てる?

Diegoを構成する主なこれらのコンポーネントを、マルチノードで組むとこうなります。

fig

BBSを中心に、ReceptorやBrainがCellと通信をします。

これを見て、僕はKubernetesに似てるなと思いました。スケジューラとランナーがetcdを通して疎結合し、連係するのは似てるなと。

fig

違うところはスケジューリングの仕組みと、コンテナがDockerではなくGardenであることですね。

Kubernetesに似ているということは、Diego単体でも動くか? 答えはイエスです。DiegoはCloud Foundryのフルセットがなくとも、単体で動きます。Diegoを単体で動かすためにLatticeというのが提供されています。

Latticeを触ってみたところ、Kubernetesほど機能は充実していませんがシンプルで直感的なので、これはなかなかいい仕組みだと思いました。

参考:Lattice深掘り話 - SlideShare

≫後半に続きます。後半では、本題となるDiegoのDocker対応と.NET対応について説明しています。

関連記事

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

タグ : Cloud Foundry , PaaS



≫次の記事
Cloud Foundryの次バージョンでDockerや.NET対応を実現する「Diego」の内部構造は?(後編) 第25回PaaS勉強会
≪前の記事
VirtualBox 5.0リリース間近、RC2が登場。準仮想化でWindowsやLinuxの性能向上、USB 3.0対応など

カテゴリ



Blogger in Chief

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

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



新着記事 10本


PR - Books


fig

fig

fig