Apr 21
上記がCloudFoundryのアーキテクチャを簡単に表現した図である。Request Router：PaaSの入り口に相当する機能。アプリケーションに対するHTTP要求を全て受け、最も最適なApp Execution Engineにその要求を引き渡す機能を提供する。一種のロードバランサーの様な役割を持っており、各App Execution Engineのアドレスと状態管理、さらにアプリケーションのホストネームについても常に管理をしている。 Cloud Controller：アプリケーションを各々のApp Execution Engineにロードし、稼働を管理する機能。ロードする際には、App Exectution Engineが理解できる、特定のアプリケーションバンドルを作り、必要な数のApp Execution Engineを配置させるのもこの機能の役割。 Application Services：データストレージ等、各種のアプリケーションサービスを提供するサービスのライブラリ。OS的な観点から言えば、ここはデバイスドライバーになる。各サービスは2つのコンポーネントから構成される。具体的には：1)サービスを提供するコンポーネント自体(MySQL, MongoDB,等)と、2)このサービスとアプリケーションを接続する為のCloudFoundryのコンポーネントの2つである。 HealthManager：各アプリケーションの稼働環境を監視し、App Execution Engineがクラッシュした際には、即時に他の場所でアプリケーションを再開できる様に管理する機能を提供する。
個々のアプリケーションレベル：アプリケーションの観点から見て、App Execution Engineの数を幾つ確保してアプリケーションを運用したらいいのかを決め、自動的に、そしてダイナミックに調整する機能。
[#Cloud #クラウド ]CloudFoundryの構造解説、そしてRightScaleとの関係（自動スケーリング）
RightScaleのCTO、Thornsten von Eicken氏のブログに、CloudFoundryの構造が詳しく説明されており、さらに、RightScaleが提供を開始した、CloudFoundryのサーバテンプレートを利用して、CloudFoundryで開発したアプリケーションの自動化が出来る構造を説明している。
CloudFoundryがAzureやGoogleの提供するPaaSと大きく異なる点は次の2点に整理される。
- オープンソースプロジェクト(Apache)としてリリースされているので、導入したいプラットホーム事業社は自由にカスタマイズをしながら運用する事が可能になる。
- 構造が非常にモジュラーになっており、データ処理のコンポーネントと、全体を管理するコンポーネントが分離されている。
＝＝＞この構造は、RightScaleのサービスとして組み込む事が非常に容易な構造であり、分散化された運用がRightScaleの管理下で非常に簡単になる。
CloudFoundryは次のコンポーネントによって構成される。
- App Execution Engine: アプリケーションを実際に動かす実行エンジン。アプリケーションの規模が大きくなれば、このApp Execute Engineの数が増えていく。各App Execution Engineは独立しており、稼働するプラットホームの場所や問わず、一旦動き始めたら、相互で接続し全体としてアプリケーションをサポートする。
- これはRightScaleとして非常に親和性の高い構造で、分散化されたApp Execution EngineをRightScale上で管理し、App Execution Engineの自動的な立ち上げが非常に簡単にできる。
- Request Routerは然程スケーラブルである必要は無い。DNSとの通信が非常に激しいので、あまりインスタンスが多くない方がシステムの安定に繋がる。
- App Execution Engineの数を決定する際に外部からの命令を受けてエンジンの数を増減するインタフェースを持っており、ここがRightScaleのオートスケーリング機能との重要な接点となる。
- RightScaleはこのサービスのレイヤーも充実したサーバテンプレートライブラリを保有しており、そことの連携が可能になる。
これらのコンポーネント間は非常に簡単なメッセージバスによって祖結合されており、双方の通信に加え、それぞれの稼動状態の連絡、新規の場合は通知する機能が実装されている。
このような構造をもったCloudFoundryに対して、ごく自然に、自動スケーリングのニーズが登場するのは容易に理解できる。
今回発表されたCloudFoundryにおいては自動スケーリングの機能はサポートされていないが、上記の構造から分かる通り、その機能を実装するのは比較的簡単である、という事が分かる。
そこにRightScaleの登場、という事になる。
具体的には、サーバテンプレートが既に開発されており、下記のURLにてダウンロードできる様になっている。
このサーバテンプレートを利用することによって、CloudFoundryの基本機能が全て、RightScaleがサポートしている全てのクラウドインフラ上で提供される事になる。
Amazon Web Service（東京リージョンも含む）の上でCloudFoundryが利用できる唯一の方法でもある。
具体的には、自動スケーリングは次の2つの部分で適用できる。
- CloudFoundryのインフラレベル：CloudFoundry全体システムとして、App Execution Engineの稼働数、Request Routerの数、Cloud Controllerの数、各種Serviceのインスタンスの数、等の最適な規模を自動的に調整する方法である。
- これは、CloudFoundryを運用するPaaSオペレータの役割になる。PaaSの運用責任者が、CloudFoundryを構成する各サーバの運転状況を監視し、必要に応じてサーバの増減を行う事によって、安定な稼働状況を確保する仕事である。通常、常に余剰のApp Execution Engineをいくつか稼働させ、迅速に対応させる事ができる。
- このCloudFoundryのサーバコンポーネントのスケーリングの自動化は、RightScaleが比較的簡単に提供することができる。具体的には、CloudFoundry用のサーバアレーを用意し、各サーバの稼働負荷状況を監視しながら自動的にサーバアレーからサーバリソースを自動的に提供する方法をとる。
- こちらは各アプリケーション運用者が行う管理になる。CloudFoundryのモジュラーな構造がうまく作られている為に、外部からのアプリケーション監視、スケーリング操作を行う為の通信が非常にやりやすい、という点が特徴である。
- さらに、CloudFoundryは外部に対してリソースのかなり細かい情報を開示しており、アプリケーション運用者にとっては、非常に感律しやすいインタフェースを提供している。今までのPaaSのベンダには考えられなかった、内部構造の開示は大きく評価すべきである。
RightScaleは、CloudFoundryとの協業戦略は非常にシンプルであり、次の様なサービスを提供する。
- RightScaleはCloudfoundry条のアプリケーションの各サーバの稼働状況を常に監視し、RightScaleのユーザが規定するルールに基づいて、各サーバの稼働規模を自動的に調整し、特定のリソースサーバが必要になった際にはアプリケーションに自動的にあてがい、また、無駄なサーバをシステムプールから自動的に取り除き、全体の運用コストを最適化する機能を提供する事である。
- 本格的なアプリケーション運用になると、CloudFoundry上のアプリだけではなく、PaaSフレームワークの外部の基幹アプリケーションとの連携も当然必要になってくる。これを俗に"Punch Out"と呼ぶが、この際に全体システムインフラ(IaaS)の運用管理の手段としてRightScaleは非常に重要な役割を提供することができる位置にある。
- Punch-Outの事例として次の様なものがある。
- データベースエンジン：メインフレーム上のレガシーDBや、特定のインフラ上で稼働するNoSQL等、データベースは多様なコンフィギュレーションを持っており、それらをAs-Isで使うニーズ
- 負荷分散：Request Routerの前面に別のロードバランサーを実装し、特定のキャッシング機能、外部アプリも含めた負荷分散、等の機能をZeusやSquid等と通して提供する。
- レガシーアプリ全般：例えばビデオエンコーディングのソフト、PDF生成エンジン、等特定のハードウェアで運用されるアプリサービス。
- バックエンドサービスアプリ：テレプォニーサービス、等の特定用途のバックエンドサービスアプリケーションの運用
CloudFoundryが発表されてから、その可能性についての議論が多くされているが、最終的にどれだけのIaaSプラットホームでサポートされるのか、まだ未知数のところがある。オープンソフトウェアベースであるとは言え、CloudFoundryはVMWareの事業戦略の一環に位置づけられる事には間違いなく、政治的な動き、技術的な動き等については注意深く動向を見て行く事が重要になってくる。例えば、CloudFoundryがGoogle App EngineやMicrosoft Azure上で稼働し、開発したアプリケーションがその上で動くかどうかについては、既存のPaaS環境との関係もあり、簡単にYESとは言えない状況ではある。
そういう事情もあり、当面はRightScaleを通してCloudFoundryを利用する等、マルチクラウドをサポートする第3者を経由した利用方法がが重宝されるのではないか、と想像する。
RightScaleを利用することが今現在、Amazon Web Service、他主要クラウド環境上でCloudFoundryを利用できる唯一の方法でもあり、尚かつ、CloudFoundry以外のリソースとの連携を行い、統合的に管理する方法としては、恐らくRightScaleのクラウド管理技術が最も進んでいる、と考える。
また、VMWareはエンタプライズ向けにプライベートクラウド上にCloudFoundryを実装するのは有償で提供する、という事業方針を明確にしている。RightScale上でCloudFoundryで開発したアプリの運用を加え、エンタプライスのプライベートクラウド上のリソースもRightScaleからPunch-Outする様にすれば、わざわざCloudFoundryをエンタプライズのインフラに移植する必要性が小さくなる、とも思われる。
