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

オープンソースで開発されているPaaS基盤ソフトウェア「Cloud Foundry」は、開発元であるVMware（現在はPivotalへ移管）はもちろん、IBMは自社のPaaSであるBlueMixに採用し、またヒューレット・パッカードも新ブランド「HP Helion」で展開するクラウドに採用、日本でもNTTコミュニケーションズがCloudⁿ 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というアプリケーションのデプロイが始まります。

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

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

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

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

Cloud Foundryの内部を探る

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

CF_TRACE = true

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud Foundry V2のアーキテクチャ

• PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている？（前編）
• PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている？（後編）
• PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは？（前編）
• PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは？（中編）
• PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは？（後編）