Cloud FoundryがRuby「で」作られたクラウドだった件
最近PaaSが次々と出てきています。特にNode.jsが動くと喧伝するプラットフォームは大量に出てきていて、そろそろガベージコレクションが走っていい頃合じゃないかと思うほどです。
Rubyist的にPaaSの注目株は、VMwareがオープンソース（Apache 2.0）のプロジェクトとして提供している「Cloud Foundry」でしょう。現在、Cloud FoundryではJavaのSpring、RubyではRailsとSinatra、JavaScriptではNode.jsをサポートしていて、Erlang、PHP、Scala、Pythonなども動いているようです。ストレージ（メッセージングサービス）としては、MySQLやMongoDB、KVSのRedis、Memcache、RabbitMQなどがサポートされていて、ソケットでつながるものなら何でも対応できるということです。
Cloud Foundryはサービス名でもドメイン名でもあり、VMwareの有償ホスティング（.com）と、オープンソースのプロジェクト（.org）の2つがあります。いずれもまだベータ版です。
Cloud Foundryが注目である理由は、いくつかあると思います。RubyやRails「が」動くクラウドというだけではなく、クラウド自体がRuby「で」作られていることが1つ。もう1つは最初から言語VMを抽象化して扱う仕組みを作り込んであること、そしてこれをオープンソース・プロジェクトとして推進していることなどでしょう。オープン・ソースなので、手元のノートPCやサーバ上にクラウド（PaaSのコントローラー）と同じコードを持ってきて開発環境やプライベートクラウドを作ることもできる、ということです。VMware Playerなどで簡単に動かせるバイナリイメージの「Micro Cloud」も用意するようです。
Cloud FoundryがRubyで作られたクラウドといっても、それぞれの言語のVM自体は各言語のものを使いますし、下はUbuntu（Linux）ですから（Windows上で稼動させる予定は今はないそうです）、Cloud Foundryのことを「Rubyで作られたクラウド」と呼ぶのが正確かどうかは分かりません。ただ、アプリの管理やルーティング管理、言語VMの制御は、複数のRubyアプリ、Railsアプリの集合であるVCAP（VMware’s Cloud Application Platform）として実装されていて、結構驚くべきものがあると思います。ちなみに各コンポーネントはメッセージバスで接続されていますが、そこで使われているプロトコルは何とPubSubです。VMwareはEMC傘下で、EMCといえばエンタープライズなIT企業の典型だと思いますが、Cloud Foundryを見ていると、とても“エンタープライズ・クラス”という感じがしません。良い意味で。
各アプリのデプロイは、やはりRubyで書かれた「VMC」（VMware Cloud CLI）というコマンドラインツールで行えるようです。例えば、「vmc push [appname]」でアプリの作成、URLのマッピング、スタートなどができ、「vmc instances
ちょっとVCAPの中を見てみると、こんな感じです。例えば、デプロイ環境の管理をするDEA（deploy environment agent）の設定ファイル（dea.yaml）をのぞくと、
などと書いてあります。宣言的に言語処理系を追加するAPIがあるということですね。RSpecのほうからagentの設定項目を引っ張り出してみると、
などとなっていて、メモリ割り当て量や監視のインターバルは、DEAで設定できそうなことが分かります。
マルチテナント、マルチVM、マルチユーザー、マルチアプリというクラウドサービスの根幹となるのは、その名もズバリ、「クラウド・コントローラー」というRailsアプリです。例えば、WebアプリそのものであるAppモデル、「vcap/cloud_contorller/apps/models/app.rb」を覗いてみると、先頭のほうは、こんな感じです。
意外に普通っぽいRailsアプリという印象ですが、Frameworksにopt_rebarやliftとあるのが妙な感じです。ほかの共同開発者と関連付けられていたりもするのが興味深いです。同様に、account_capacity.rbをのぞくと、ユーザーごとのプランの違いによるメモリ容量の違いなんかも書かれてあって、PaaSのサービスの実体そのものという感じがあります。
大規模アプリケーションやエンタープライズアプリケーションではRubyは使えない、スケールしないという声が根強くありますが、Cloud Foundyの中を見ると、全くそんなのどこ吹く風という感じです。HTTPリクエストに対してはEventMachineやFiberをヘビーに使っているようです。
Cloud FoundryはHerokuの抽象度をさらに高めたような感があります。作り始めたタイミングの違いかもしれませんが、Herokuがアプリのディスパッチ処理にはErlangベースのシステムを使っている一方、Cloud FoundryはピュアRubyというのも興味深いところです。
●Cloud FoundryはクラウドのLinuxカーネルだ
Engine Yardを退職してCloud Foundryプロジェクトの立ち上げに関わっているEzra Zygmuntowiczさんのインタビューを見ると、
Cloud Foundry is “the Linux kernel for the cloud.”
と言っています。Cloud FoundryはクラウドにとってのLinuxカーネルだということですが、その心は、Linuxが異なるアーキテクチャのCPUを抽象化したように、クラウドの違いを抽象化するものだ、ということです。
Cloud FoundryプラットフォームのコードごとAmazon EC2上など、ほかのインフラ上に持っていけば、自分だけのPaaSを持てるというメリットは、他のPaaSにない特徴です。元々PaaSが台頭した理由が、インフラの維持・管理に手間やコストがかかりすぎるとが大きいと考えると、ちょっと逆戻りのような気もしますが、現在のPaaSがブラックボックスであることを考えると、注目すべき揺り戻しのようにも思えます。