Cloud Foundryの仕組み

　前編でも触れたが、Cloud Foundryは以下の4つの特徴を持つ。

• オープンソース（Apache License, Version 2.0）
• 複数の言語、フレームワークに対応
• 複数のデータベース、ミドルウェアに対応
• パブリックPaaS、プライベートPaaSなど、さまざまな利用方法が可能

　この中でも、技術的に関係するのはオープンソースを除いた3点だ。この3点は、図1のような関係にある。

図1　

　言語、フレームワーク、データベース、ミドルウェア、クラウドプロバイダー、それぞれ必要なものを、必要な形態で組み合わせて利用できるのがCloud Foundryの特徴といえる。

　Cloud Foundryを構成する要素をレイヤーごとに分けた場合、図2のようになる。

図2　

　Cloud Foundryが担うのはCF Kernelと呼ばれる、PaaSの機能を提供するレイヤーのみである。IaaSレイヤーの仕様に依存しないという設計思想のため、IaaSレイヤーの構築・運用・監視を行う機能はCloud Foundryには含まれておらず、CF KernelとIaaSレイヤーの間に位置するOrchestratorと呼ばれるレイヤーで行うものとされている。ただし、Cloud Foundryを用いてPaaSを提供する場合、利用するユーザーが認識するのはハードウェアからクライアントまでを含めた全体となる。あくまでも筆者の見解ではあるが、全てのレイヤーを含めて広義のCloud Foundryとも呼べるだろう。

　CF Kernelをさらに細かく見ていくと、図3の要素で構成されている。

図3

　一部のコンポーネントは図に掲載していないが、これらのコンポーネントそれぞれがNATSと呼ばれるメッセージング機構を通じて疎結合で構成され、自律して動作している。

　この中でも特に注目すべきは、DEAとServicesである。DEAはDroplet Execution Agentの略で、ユーザーがデプロイしたアプリケーション（Droplet）を実行させる仕組みのことを指している。つまりJavaやRubyの実行環境は、このDEAの中に構築されているのだ。

　またServicesは、データベースやメッセージングサービス（ここではNATSではなくRabbitMQのような、アプリケーションで利用するサービス）を動かすコンポーネントだ。

　このように疎結合で構成されている利点として、コンポーネントに対する変更が他のコンポーネントに影響を及ぼしにくいという点が挙げられる。例えば事業者が独自にデータベースのサポートを付け加えたい場合、基本的にはServicesへの変更を行うだけで済む。プログラミング言語やフレームワークのサポートを付け加える場合は、DEAに対して変更を行えばよい。実際のケースとして、「Iron Foundry」という、Windowsの.NET FrameworkをサポートしたCloud Foundryのフォークが挙げられる。Cloud FoundryはLinux上での動作を前提としているが、このケースの場合、.NET Frameworkをサポートできるように手を加えたDEAを用いることで対応を行っている。

Cloud Foundryを選ぶメリット

開発者にとってのメリット

　開発者にとってCloud Foundryを選ぶということは、Cloud Foundry上で開発したアプリケーションを動かすということを意味する。それについては、以下の2つのケースが考えられるだろう。

・実運用環境としてCloud Foundryを選ぶケース

　1つは実運用環境としてCloud Foundryを選ぶケースだ。これはCloud Foundryを採用したPaaS上で、実際のサービスを提供していくことになる。

　このケースの場合、まずメリットとしてサーバやネットワークなど、インフラ面での運用を一任できる点が挙げられるだろう。今までは自社で構築・運用するサーバやレンタルサーバ、IaaSなどを用いていたが、アプリケーションが動作するまでの環境構築は自力で行う必要があった。また、利用者の増加に応じてサービスをスケールさせていくには相応のノウハウが必要とされた。Cloud Foundryを採用すれば、環境構築は不要となり運用も一任できる。スケールの面においても、デプロイ時のオプションで動作するインスタンス数を任意に設定することが可能だ。ただし、これらのメリットはCloud Foundryに限らず、他のPaaSでも同様に享受できる。

　Cloud Foundryならではのメリットとしては、やはりCloud Foundryの思想そのものである、ベンダーロックインを防げるという点であろう。PaaSを利用するということは、特定のプラットフォームに依存することを意味する。何らかの理由で利用していたPaaSが停止されることになった場合、当然その上で動くアプリケーションは他のPaaSに移し替える必要が出てくる。しかし、特定のプラットフォームに依存した設計の場合、その移行には困難が伴う。Cloud Foundry向けに作っていれば、仮にそのサービスが停止したとしても、他のCloud Foundryを採用したPaaSに再デプロイするだけでよい。

・開発環境としてCloud Foundryを選ぶケース

　もう1つの選択肢として、開発環境としてCloud Foundryを選ぶケースが考えられる。多人数でアプリケーションを開発する場合、全員に同じ環境をそろえることは無視できないコストを伴う作業となる。複数の案件を同時進行させればなおさらだ。

　前述したようにCloud Foundryは、プログラミング言語にJava、Ruby、PHP、データベースにMySQL、PostgreSQL、MongoDBなど、業界で標準的に使われる技術で構成されている。そのため、一通りの環境があらかじめそろった便利なツールとしてCloud Foundryを使い、運用環境はまた別にするという利用方法も可能だ。この場合、パブリックPaaSを利用してもよいし、プライベートPaaSを利用してもよい。各自が開発機の中にMicro Cloud Foundry（※）を入れてしまえば、ネットワーク接続がない環境でも利用可能だ。

※　Micro Cloud Foundry：無料で提供されている、Cloud Foundryに必要な要素が全て入ったコンパクトな環境。VMware Playerなどで実行できるイメージとして配布されており、起動するだけですぐにCloud Foundry環境を試すことができる。

事業者にとってのメリット

　事業者にとってのCloud Foundryのメリットは、前編でも述べた通り、これまでIaaSを提供してきた事業者が、既存の環境上にCloud Foundryを乗せることでPaaSの提供が可能になるという点だ。また、アプリケーションプラットフォームの開発企業は、自社開発のプラットフォームを追加したCloud Foundryを任意のIaaS上に展開すれば、他との差別化を行った状態でPaaSの提供が可能となる。コストを減らしつつも、新たな付加価値を提供していきたい企業にとってCloud Foundryは有力な選択肢となるだろう。

課題

　Cloud Foundryの今後の課題として、ベンダー間の互換性維持が挙げられる。前述したように、ベンダーが独自に追加・拡張しやすい設計になっているのがCloud Foundryのメリットだが、それはベンダーロックインを防ぐというCloud Foundryの思想と矛盾しかねない危険性をはらんでいる。その思想を生かし続けるためには、各ベンダーがCloud Foundryの共通部分はそのまま残すという認識が必要とされる。

今後の展望

　PaaSを運用していくに当たり必要なOrchestratorについて、2012年4月に「Cloud Foundry BOSH」というツールが発表された。現時点でVMware vSphereおよびAmazon Web Services、OpenStackに対応しており、これらのIaaS上でのCloud Foundryの構築、展開、ライフサイクルマネジメントが行える。

　Cloud Foundryが普及していくための下地がほぼ出来上がりつつあるといえるだろう。