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

2014年5月13日

オープンソースで開発されているPaaS基盤ソフトウェア「Cloud Foundry」は、開発元であるVMware(現在はPivotalへ移管)はもちろん、IBMは自社のPaaSであるBlueMixに採用し、またヒューレット・パッカードも新ブランド「HP Helion」で展開するクラウドに採用、日本でもNTTコミュニケーションズがCloudn PaaSに採用するなど、急速に注目度が高まっています。

Publickeyでは2011年10月に開催された「第1回 CloudFoundry輪読会」を基に「PaaS基盤「Cloud Foundry」のアーキテクチャは、どうなっている?」という記事を公開しました。あれから3年半経過した現在、Cloud FoundryはV2へバージョンアップしました。

そして「第18回 Cloud Foundry 輪読会」では、このCloud Foundry V2のアーキテクチャ概要について、NTTコミュニケーションズの草間一人氏が「Cloud Foundryはなぜ動くのか」というタイトルで解説しています。本記事は、その内容をまとめたものです。

Cloud Foundryは、なぜ動くのか

NTTコミュニケーションズでCloudn PaaSの開発や運用をしています。草間(@jacopen)と申します。

今回はCloud Foundry V2の技術的な情報をまとめようとしています。基本的には入門者向けで、深い技術的内容は次回以降にと思っています。では、始めましょう。

まずCloud Foundryにアプリケーションをデプロイしてみます。Cloud Foundry V2ではcfコマンドを使ってデプロイします。

cf push dora

これで、doraというアプリケーションのデプロイが始まります。

fig
fig

いまデプロイが終わったので、Webブラウザでアクセスすると文字が表示されます。

fig

Cloud Foundryに対してcf pushしたら、なにかアプリが動きましたと。

fig

このときCloud Foundryの内部で何が起きているのか、どういう仕組みで動いているのか。このブラックボックスの謎を解いていきましょう

ここでは、Cloud Foudryを外から叩いて中味を推測し、次に各コンポーネントの役割を知り、最後にコンポーネント間の通信がどうなっているか、といったことを話していきます。

Cloud Foundryの内部を探る

cfコマンドにはこういうオプションがあります。

CF_TRACE = true
fig

例えば、あらかじめCF_TRACE=trueを設定しておいて、デプロイしたアプリケーションを削除する「cf delete」コマンドを実行すると、cfコマンドが投げたリクエストや受け取るレスポンスが見えるんですね。

ここではGETのリクエストを投げています。どこに投げているかというと、このapi.107.22.72.200.xip.ioです。

fig

cf pushでも同じように見てみると、api.107.22.72.200.xip.ioと何かやりとりして、最終的にアプリケーションがデプロイされています。

ここまでで分かったのは、どうやらAPIを提供しているようだと。そして最終的にアプリを動かす何かがあるらしいと。

fig

ここでapiのIPアドレスと、アプリケーションdoraのIPアドレスを調べてみましょう。まあURLに書いてあるようなものですが、どちらも同じIPアドレスのところへアクセスしていることが分かります。

fig

つまりどういうことかというと、このIPアドレスを持つコンポーネントがあって、それがAPIだったりアプリケーションだったりと、URLごとにアクセスを分配してくれているのではないかと推測できるわけです。

fig

アプリケーションが死んでも自動で復活する

次はcf scaleというコマンドについて。このコマンドを実行すると、アプリケーションのインスタンスが増えるんですね。

fig

コマンド一発でアプリケーションをスケールさせられます。

このコマンドでアプリケーションのインスタンスを3つに増やして、Webブラウザの画面をリロードしてみます。この画面はアプリケーションの状態を表示しています。

fig

リロードしていくと、インスタンスのポート番号が61030、61029、61028と3つある。つまりインスタンスが3つ立ち上がったのがわかります。

ここから、どうやらアクセスを分けるコンポーネントが、うまいこと3つのインスタンスにアプリを分散しているのではないか、ということが推測されます。

fig

次は、アプリが死ぬとどうなるかです。分かりやすいようにインスタンスを1つに減らしておきます。そしてこのアプリケーションは、/sigterm/KILLというURLにアクセスすると自分自身のプロセスを終了させるという裏機能があります。

さて、アプリが終了したはずですが、もういちどアクセスしてみると復活しています。そしてポート番号が61031になっています。つまりさっきまでのプロセスではなく、新しく生まれたように見えます。

fig

つまり、アプリを死活監視をしている何かがいるのではないかと推測できます。

fig

というわけで、いろいろ推測した結果、Cloud Foundryの中身はこんなふうになっているのではないか、といえます。

fig

実際にそうなっています。ま、結果を知ってたから描けたわけですが(笑)

fig

これら、RouterやCloud Controller、DEA、Health Managerといったコンポーネントが、Cloud Foundryのコアになる部分です。

≫後編に続きます。後編ではコアコンポーネントのそれぞれの働きとCloud Foundry内部の通信について解説します。

Cloud Foundry V2のアーキテクチャ

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

カテゴリ クラウド
タグ  Cloud Foundry , PaaS


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

前の記事
2014年4月の人気記事「MS、C#/Visual Basic次世代コンパイラをオープンソースで」「9インチ以下の画面サイズではWindowsが無料」「Immutable Infrastructure」ほか


カテゴリ



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