Webアプリケーションのスケールアウトと死活監視の仕組み：第3回

なぜ「実行可能な Web アプリケーション」を保存しておくのか？

2015年10月27日(火)萱間真人（CTC クラウドイノベーションセンター主任）

リスト

第2回の「Cloud Foundry」見学ツアーでは、Webアプリケーションの配備について、クラウドを制御する「Cloud Controller」を起点に、実行可能な単位に変換する「DEA」や「Warden」が、どのように連携するかの詳細をお伝えしました。今回は、Webアプリケーション配備を踏まえて、Cloud Foundryのスケールアウト（水平拡張）と、Webアプリケーションの死活監視について見学していきましょう。

　それでは見学ツアーの再開です。早速、Cloud Controllerの部屋へ参りましょう。

なぜ「実行可能なWebアプリケーション」を保存しておくのか？

　Cloud Controllerの部屋へ向かう途中で、第2回で訪れたWebアプリケーション配備の過程について振り返っておきます。スケールアウトを解説するにあたり、とても重要なキーワードがありますからね。

　利用者からのWebアプリケーションの配備リクエストは、Cloud Controllerが受け取ります。そのリクエストにはWebアプリケーションそのもの（ソースコードやバイナリ）が含まれています。Cloud Foundryは、このWebアプリケーションを直接実行できるように「ビルドパック」を利用して何かに変換します。

　ここで最初の質問です。「その何かとは何だったでしょうか？」

　みなさんお解りですね。そうです、実行できる単位である「Droplet」です。解らなかった方は、もう一度、第2回の見学ツアーに参加してみてください。

図1：Dropletを作るやりとり
拡大画像表示

　Dropletは、Cloud Controllerからの依頼により、DEAがWarden内で構築する、Cloud Foundry上で実行可能なWebアプリケーションです。図1の最後のフローでDEAは、DropletをCloud Controllerに返却しています。Cloud Controllerは、このDropletを自身に保存します。

　では、次の質問です。「Cloud Controllerは、既に動作しているWebアプリケーションであるDropletを何のために、わざわざ保存しておくのでしょうか？」

　答えは...。おっと、Cloud Controllerの部屋は、もう目の前ですね。

「最適」なDEAの選定とスケールアウト

　Cloud Controllerの部屋に着きました。Cloud Controllerの部屋は、利用者からのリクエストを一手に受け付けるので、いつも賑やかです。多くのリクエストの中からスケールアウトのリクエストを探すのは大変なので、私が今からコマンドラインでスケールアウトのリクエストを出してみます。

　「cf scale -i 10」

　この「10」という数字は、実際に動かすWebアプリケーションの数です。この場合、Webアプリケーションは10並列で稼働することになります。右手前方からやってきたリクエスト、恐らくあれが私のリクエストです。近付いてみましょう。

　Cloud Controllerは、スケールアウトのリクエストを受け取ると、このWebアプリケーションを動作させることができるDEAの選定を開始します。やり方はとてもシンプルです。DEAそれぞれに聞くのです。そして動作させたいWebアプリケーションの情報が記載された依頼書をDEAに渡します（図2）。

図2：DEAの状態確認
拡大画像表示

　DEAは、その内容を確認し、自身で動作させることができるかどうかを判断します。そして、その結果をCloud Controllerに伝えます。こうして、配備可能なDEAを選定したCloud Controllerは、DEAに対してWebアプリケーションの配備リクエストを送信します。

　このフローは第2回で詳細をお伝えしました。ですが1点、大きく異る点があります。そしてこれは、先ほどの質問「Cloud Controllerは既に動作しているWebアプリケーションのDropletを何のために、わざわざ保存しておくのでしょうか？」の答えでもあります。

　みなさんもうお解りですね。そうです、WebアプリケーションをDropletにビルドする処理がなくなるからです。DEAはWebアプリケーションのソースコードやバイナリから新しいDropletをビルドする代わりに、あらかじめビルドされたDropletをCloud Controllerから受け取り（より正確には、Cloud Controllerへ取りに行き）、配備するのです。この処理により、Webアプリケーションの配備までの時間とリソース（CPUやメモリーなど）をより小さくできます。

　WebアプリケーションをDropletへとビルドする処理は、決して速いとは言えません。スケールアウトの要求を受け取ってからWebアプリケーションをDropletにビルドすると、Webアプリケーションの配備に時間がかかってしまいます。また、それぞれのDEAでビルドを開始してしまうと、そのぶんCPUやメモリーのリソースを多く消費してしまいます。

複数の同じWebアプリケーションへのルーティング

　さて、これで複数の同じWebアプリケーションがDEA上で稼働することになりました。これまでは1つのURLに対して1つのWebアプリケーションが割り当てられていました。例えば、「http://myapp.example.com」というURLに対しては、IPアドレス『192.168.101.54』を持つDEAのポート『56324』が対応する」ということです。

　ところが、こうして複数の同じWebアプリケーションが動作してしまうと、1対1の対応ではうまくいきません。そこで必要になるのが、「Router」コンポーネントです。Webアプリケーションを中継する役割を担うために、1つのURLに対し複数の同じWebアプリケーションのIPアドレスとポートをマッピングする機能を持っています。

　この動きの詳細をみるために、Routerの部屋に向かいましょう。

　第2回でお伝えしたとおり、DEAはWebアプリケーションの配備が終わると、Routerに対して「このURLにアクセスされた場合は、このIPアドレスと、このポート番号の組み合わせに転送してください」というルーティングのリクエストを送ります。Routerは、このリクエストの内容に従って、転送先を決定します。

　Routerの部屋に着きました。たくさんのWebアプリケーションへのリクエストが別々のDEAのポートに転送されていきます。では、私が先ほど配備したアプリケーションにリクエストを送るので、よく見ていてください。はい、今到着したリクエストがそれです。リクエストは「192.168.101.54:56324」に転送されました。

　もう1度リクエストしてみましょう。「192.168.101.86:51476」に転送されました。先ほどとは別のDEAですね。このようにRouterは、1つのURLに対して複数のWebアプリケーションが関連付けられると、それらをラウンドロビンで転送する機能を持っています（図3）。そのため、複数の同じWebアプリケーションが配備されても問題なく転送できます。