PaaS基盤「Cloud Foundry V2」内部で使われるBuildpack、Wardenコンテナの仕組みとは?(後編)

2014年6月9日

オープンソースで開発されているPaaS基盤ソフトウェア「Cloud Foundry」では、HerokuのBuildpackやコンテナ技術のWardenなどが内部で使われ、柔軟なPaaSの機能を実現しています。

以前の記事「PaaS基盤「Cloud Foundry V2」のアーキテクチャは、どうなっている?」の続編として、さらに詳しいCloud Foundryの仕組みを、5月23日に開催された「第19回 PaaS 勉強会(旧称:Cloud Foundry 輪読会)」のNTTコミュニケーションズ 草間一人氏のセッションを基に紹介します。

本記事は前編中編後編に分かれています。いまお読みの記事は後編です。

アプリを動かすコンテナ、Wardenの仕組み

ユーザーのアプリケーション、DropletはWarden(ウォードン)コンテナの中で実行されます。アプリケーションが終了するとコンテナごと捨てられます。

Wardenはもともとアプリケーションの実行用に作られたのですが、現在ではStaging処理にも使われています。

なぜWardenコンテナをアプリケーションの実行に使うのかというと、マルチテナントを実現する際に、ほかのアプリケーションからの影響を受けないように、などの理由があります。

fig

DEAの中身は2つのプロセスに分かれています。Cloud Controllerと会話をするdeanextというプロセスと、Warden serverです。deanextが「このアプリをWardenコンテナで動かしてよ」とwarden serverに依頼すると、warden serverがそれを自分の子プロセスとして立ち上げるわけです。

fig

Wardenというのは、warden serverとwarden clientとwarden protocolというプロトコル、そしてwshdと呼ばれるコンテナに必要なC言語で書かれたプログラムから構成されています。

Wardenが利用する技術は、Namespacesによる空間の分離、CPUやメモリの制限のためのcgroupsなどです。

fig

つまりWardenは、LXCだったりDockerなどとだいたい同じものなのです。

fig

なぜWardenなのか。LXCやDockerではないのか?

で、このあたりの話をするとよく聞かれるのが、なぜWardenなのか、と。なぜLXCじゃないのか、Dockerじゃないのか、ということです。これから説明するのはCloud Foundryチームの言い分です。

実は初期のCloud FoundryはLXCを使って実装されていましたが、LXCはもともとLinuxを前提に作られています。Cloud Foundryは将来的にWindowsなどもサポートしていきたいという考えがあって、マルチプラットフォームに対応できる仕組みにしたかったから、という理由が1つ。

もう1つは、LXCがCloud Foundryuの要求に対して過剰性能だったというもの。Cloud Foundryでやりかったのはアプリケーションをくるんで動かしたかっただけなので、リッチな機能はいらず、C言語で1000行以下で見通しのいいシンプルな仕組みが欲しかったため、Wardenを作ったと。

fig

Dockerに対しては、Dockerが1コンテナ1プロセスが前提のため、Cloud Foundryの仕組みに合わないこと、Dockerのコンテナを作成後に制限を動的にコントロールできないのが理由だと言われています。

fig

まあCloud Foundry v2を作るときにはまだDockerがなかったので、いまDockerを使っていないのは仕方がないという気もします。

一方で、僕のつっこみとしては、Dockerの1コンテナ1プロセスの前提はSupervisorを使えば手間はかかるけどできるよね、とか、動的に制限がコントロールできないというのは、そもそもCloud Foundryにそんな機能ないよとか、とも思います。

HerokuはBuildpackで記述してLXCで稼働しています。Cloud FoundryはBuildpackで記述してWardenで稼働します。最近はやりのDockerでやろうとするとDockerfileで記述してDockerで稼働です。

fig

個人的な意見では、最終的に実現されるものは一緒ですよと。Dockerはいま流行しているし、WardenよりDockerのほうがよいのではという意見もありますが、実現されるのが同じなら単純に置き換えるのにそれほど意味がないのでは、とも思います。

ただ、DockerfileよりもBuildpackのほうがいろいろできて書きやすいかなという気もしますが、Dockerイメージを突くってイメージ丸ごとアップロードする方法もあるので、そういうのをやってみたいなという気もします。

fig

公開されているスライド「Cloud Foundry V2を、もうちょっと深掘りしよう

Cloud Foundry V2のアーキテクチャ

Tags: クラウド Cloud Foundry PaaS

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





タグクラウド

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準

アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

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

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

最新記事10本