クラウドコンピューティングの重要な形態として、IaaSサービスは様々なオープンソースや商用のクラウドプラットフォームソリューションで利用可能です。本稿では、オープンソースのIaaSクラウドプラットフォームを利用してパブリッククラウドやプライベートクラウドの管理プラットフォームを開発するという視点に基づき、Eucalyptus、OpenNebula、CloudStack、OpenStackなどのオープンソースのIaaSクラウドプラットフォームを紹介し、比較します。
AWSが提供する成功するクラウドプラットフォームの特徴
AWSは、現在最も成功しているクラウドコンピューティングプラットフォームであり、そのシステムアーキテクチャ***は、Webサービスインタフェース、サービス***位置へのすべてのものを介してオープンなデータと機能によって特徴付けられ、SOAアーキテクチャを介して、システムが疎結合を達成するようにします。
AWSは、アクセスレイヤー、共通サービスレイヤー、PaaSレイヤーサービス、IaaSレイヤーサービスという複数のコンポーネントから構成されるWebサービススタックを提供します。ユーザーアプリケーションは、IaaSの基本ITリソース、PaaS、共通サービスをアプリケーションアーキテクチャのコンポーネントとして利用し、独自のサービスを構築します。まとめると、AWSエコシステムにおけるシステムアーキテクチャの核となる考え方は、SOA、レイヤリング、サービスの組み合わせです。
プライベートクラウドの要件
AWSのようなパブリック・クラウド・プラットフォームに加え、プライベート・クラウドやハイブリッド・クラウドもIaaSの重要な形態です。通常、企業はプライベート・クラウド・プラットフォームに対していくつかの要件を持っています。
- コンピューティング・バーチャル・テクノロジーの多様な選択肢。
- ストレージ技術/デバイスの多様なサポート。
- ネットワーク技術/デバイスの複数サポート。
- 複数のAPIに対応
最初の3つの要件は、基本的に同じ機能とインターフェイスを外部に示すために、基礎となる特定のテクノロジー/デバイスの違いを遮蔽するIaaSプラットフォームを求めています。これは一般的に、抽象的なフレームワークとプラグイン設計によって実現されます。さらに、コンピュート仮想化、ネットワーキング、ストレージの各テクノロジーが自己完結型であるという事実に基づき、アーキテクチャ全体の設計では、コンピュート仮想化、ネットワーキング、ストレージを3つの独立したサブシステムまたはサービスとして考える必要があります。
つまり、さまざまなAPIやアクセス方法を提供するためのAPIまたはアクセスレイヤー、IaaSサービスを外部に提供するための基礎となるサービスを統合するコア仮想化管理レイヤー、そして技術の違いをシールドするためのコンピュート／ストレージ／ネットワークサービスレイヤーです。
技術チームの開発要件
小規模な技術チームはエリート主義で、全員が全体の設計に参加できます。大規模なチームはピラミッド構造になっており、全体の設計に参加できるのは数人だけで、大多数の人は能力や責任に応じて個々の機能やモジュールにしかアクセスできません。
この2つのタイプのチームの要求を満たすためには、クラウドプラットフォームの全体的なソフトウェアアーキテクチャは、コンポーネント、モジュール、サービスの組み合わせによってシステム全体を構成する疎結合である必要があります。同時に、コンポーネント、モジュール、サービスは、小規模なチームが独立してメンテナンスを行い、独立した設計、開発、進化を容易にするために、凝集性が必要です。
さらに、クラウドプラットフォームは、サービス間で再利用できる基本的な共有コンポーネントを提供することを検討する必要があります。再利用可能なコンポーネントの代表的なものは、データベースORM、メッセージング、サーバーサイド・インフラストラクチャ・フレームワーク、構成管理システム、ロギング・システム、エラー位置特定システムなどです。多くの大規模なチームは、これらの基礎となる共有サービスを統合し、ドメイン記述言語によって基礎となるフレームワークコードの生成を自動化することで、開発者が特定のサービス実装や主要技術の研究に集中できるようにしています。
クラウドプラットフォームの紹介と比較
以下は、4つのオープンソースIaaSクラウドプラットフォームを、レイヤー化、コンポーネント化、SOAによるシステムの疎結合化、フレームワーク・プラグイン設計によるコンポーネントサービス、開発プラットフォームの観点から比較したものです。
ユーカリ
Eucalyptusは、AWSのクローン化を試みた最初のオープンソースIaaSクラウドプラットフォームの1つで、全体的なアーキテクチャは図1の左半分に示されています。 Eucalyptusは、クラウドコントローラ、Walrus、クラスタコントローラ、ストレージコントローラ、ノードコントローラで構成され、これらが互いに連携して必要なクラウドサービスを提供します。各コンポーネントはWS-SecurityをサポートするSOAPメッセージを使用して安全に通信し、EucalyptusはAWS準拠のSOAPとQueryインターフェースを外部に提供しますが、それ以外のAPIは提供しません。
図1 EucalyptusシステムアーキテクチャとCLC論理アーキテクチャ
レイヤリングの観点から見ると、EucalyptusにはAPIレイヤがなく、CLCがグローバルリソース管理レイヤ、クラスタサービスが基盤となるリソース管理レイヤとなっています。CLC、CC、NCの3層構造は、ソフトウェアアーキテクチャのレベルではレイヤリングではなく、より大規模なクラスタを管理するための工学的アプローチと見なすしかありません。
コンポーネントサービスの観点から見ると、コンピュートサービスとストレージサービスはクラスタごとに独立したサービスとして設計されており、ネットワークは依然としてコンピュートサービスの一部です。Eucalyptusはコード実装ではネットワーク部分を独立して実装していますが、全体的な設計は独立したサービスに従って設計されておらず、全体的な設計は十分に切り離されていません。
CLCはEucalyptusの中核であり、仮想マシン制御、ストレージボリューム管理、ネットワークリソース管理、イメージ管理、スナップショット管理、キーペア管理、メタデータ管理などのサービスモジュールを含みます。図1の右半分に示すように、オープンソースのESB Muleがすべてのサービスをオーケストレーションし、Eucalyptusサービスを通じてEC2とEBSのサービスを外部に提供します。ご覧のように、SOAレベルではEucalyptusの方が優れた仕事をしています。しかし、ESB技術の敷居は高く、設計者や開発者の要件も高い。同時に、Eucalyptusはごく限られた場所でしかプラグインをサポートしていないため、抽象化フレームワークとプラグインの全体的な設計はあまり行われていません。
開発プラットフォームの観点から見ると、Eucalyptusの主な開発言語はJavaとC言語です。CLCはオープンソースのESB Muleをコアオーケストレーションサービスとして採用し、斬新なアーキテクチャを採用していますが、CCとNCはAxis/CをベースとしたApache +CGIのソフトウェアアーキテクチャを採用してWebサービスを実現しています。全体として、Eucalyptusはプラットフォーム化の流れを発展させていません。
オープンネビュラ
OpenNebulaはReservoirプロジェクトの一部であり、2005年にEuropean Research Councilによって立ち上げられたVirtual Infrastructure and Cloud Computing Initiativeの仮想化管理レイヤのオープンソース実装です。
OpenNebulaはインターフェース層、コア層、ドライバ層の3つの層に明確に分かれています。インターフェイス層はネイティブのXML-RPCインターフェイスを提供し、EC2、OCCI、OpenNebula Cloud APIといった様々なAPIを実装し、ユーザに様々な選択肢を提供します。
OpenNebulaコアのコアレイヤーは、統合フックプラグイン管理、リクエスト管理、VMライフサイクル管理、ハイパーバイザー管理、ネットワークリソース管理、ストレージリソース管理、およびその他のコア機能を提供します。
レイヤは、仮想化ソフトウェアや物理インフラストラクチャと相互作用するさまざまなドライバで構成されるドライバ・レイヤです。図2のドライバ層には、DataStoreやNetworkManagerなどの複数のドライバが描かれていないことに注意してください。モニタリングやユーザインターフェイスのようなフロントエンドモジュールも図2には描かれていません。OpenNebulaがレイヤリングとフレームワーク＋プラグインの設計の両方で良い仕事をしていることは明らかです。
図2 OpenNebulaのシステムアーキテクチャ
OpenNebulaでは、ONEではコンピュート、ストレージ、ネットワークがそれぞれ独立したモジュールとなっており、リソーススケジューリングも分離され、requirementsとmatcherによる複数のオプションポリシーとリソースクォータ管理をサポートし、さらにスケジューリングエンジンHaizerをサポートすることで、リースの高度なリソーススケジューリング機能を提供しています。
OpenNebulaがSOA設計を採用していないこと、コンピュート、ストレージ、ネットワークを別々のコンポーネントとして設計していないこと、十分なデカップリングを行っていないことは明らかです。OpenNebulaは、Libvirtが提供するインタフェースを利用して、リモートからコンピュートノードの仮想化制御コマンドを呼び出していることは注目に値します。このエージェントレス設計は、システムのインストールとデプロイの段階でソフトウェアのインストールと設定作業を削減するため、設計上のハイライトです。
開発プラットフォームの観点から、OpenNebulaはコアONEの実装にC++を採用し、特定の機能を実装するためにRubyで開発された様々なドライバを使用しています。システム全体のコアコンポーネントは1つだけなので、開発プラットフォームについてはほとんど手が入っていません。
クラウドスタック
CloudStackはCloud.comによって開発され、Citrixによって買収され、Apache Foundationに寄稿されたオープンソースのIaaSソフトウェアです。ブリティッシュ・テレコム、日本電信電話、韓国テレコムなど、世界中のパブリッククラウドにIaaSプラットフォーム技術を提供しています。
図3の左半分はCloudStackの全体的なアーキテクチャを示しており、Dashboard/CLIレイヤー、CLoudStack API、コアエンジンレイヤー、コンピュート/ネットワーク/ストレージコントローラーレイヤーがあり、典型的なレイヤードアーキテクチャです。具体的には、CloudStackはネイティブのカスタムAPIを提供し、クラウドブリッジを通じてAWS互換のAPIもサポートしています。
図 3 CloudStack システム・アーキテクチャと管理サーバー・アーキテクチャ
OpenNebulaと同様、CloudStack自体もSOA設計を採用しておらず、またコンピュート／ストレージ／ネットワーク部分とコアエンジンを分離していないため、疎結合やコンポーネント設計の面でさらなる強化が必要です。
ClousStackは、開発プラットフォームの観点から、API、管理サーバ、エージェントをJavaで開発し、ランタイムはTomcatのServerletとしてデプロイしています。 また、ネットワークやシステム管理に関連する部分の開発にはPythonを多用しています。特筆すべきは、CloudStackのコードには、通信、データ管理、イベント管理、タスク管理、プラグイン管理など、開発プラットフォームの基本構成をカバーする独立したJavaコードベースが含まれていることです。
オープンスタック
OpenStackは、オープンソースのIaaSクラウドプラットフォームとしてはまだ2年目の新参者ですが、***コミュニティとエコシステムがあり、クラウド開発のために多くの企業や開発者が周りに集まっています。図4は、***がリリースしたEssexの論理アーキテクチャを示しています。
図 4 OpenStack Essex の論理アーキテクチャ
OpenStackの全体的なアーキテクチャは3つのレイヤーに分かれており、トップレイヤーはアプリケーションと管理ポータル、API、その他のアクセスレイヤー、コアレイヤーはコンピュートサービス、ストレージサービス、ネットワークサービス、3番目のレイヤーは共有サービス、そして現在はアカウント権限管理サービスとイメージサービスです。このうち、QuantumとcinderはOpenStackのインキュベーション・プロジェクトで、****がコア・サービスに追加されました。
Essexと以前のバージョンでは、ストレージのEBSはNova-Volumeと結合され、ネットワークサービスはNova-Networkと結びついていました。開発中のFolsomリリースでは、EBSとNetworkはNovaとは別のサービスになっており、NovaはAPI経由で新しいcinderとQuantumサービスを呼び出します。ご覧の通り、OpenStackはSOAとサービス指向コンポーネントを切り離すという素晴らしい仕事をしています。
Novaは、APIサーバー、Nova -スケジューラ、Nova -コンピュート、Nova -ボリュームとNova -ネットワークなど、いくつかの部分が含まれています。同時に、ノヴァは、スケジューラなどのプラグインは、プラグインの異なるハイパーバイザー、ネットワークとボリュームの一部の使用をサポートするために、新しいスケジューリングアルゴリズムを開発するためにサポートするフレームワークやプラグインの多くを採用している技術や機器の異なるベンダーをサポートするために。cinderやQuantumなどのサービスも、Novaと同様の全体的なアーキテクチャとプラグイン設計を採用しています。
開発プラットフォームの観点から見ると、OpenStack は良い仕事をしています。第二に、すべてのサービスが、サーバサイドのアプリケーションには WSGI、データベースの ORM には SQLAlchemy、設定ファイルの解析とロギングには同じコンポーネントなど、似たようなソフトウェアアーキテクチャと内部実装技術を使っています。OpenStackをベースにしているため、開発者は複数のコンポーネントの開発に簡単に参加することができます。
合成と比較
前節では、レイヤリング、SOA、コンポーネント化、デカップリング、開発プラットフォームの観点から、各IaaSオープンソースクラウドプラットフォームについて説明しました。
表1の比較から、すべてのオープンソースIaaSクラウドプラットフォームは、レイヤリングにおいてより良い仕事をしていることがわかります。SOA/コンポーネント化/デカップリングの面では、OpenStackとEucalyptusが有利です。フレームワークとプラグインの設計の面では、Eucalyptusが劣っていることを除いて、他のプラットフォームは非常に良い設計をしています。OpenStackの開発プラットフォームは良い仕事をしています***、CloudStackは2位です。バランスとしては、OpenStackのデザインは現在****で、EucalyptusとCloudStackは2番手です。
表1 IaaSオープンソース・クラウド・プラットフォームの比較
実際の要求設計との比較
実際の要件を使って、4つのオープンソースIaaSプラットフォームが開発サポートの面でどのように機能するかを見てみましょう。この要件はプライベート・クラウドのシナリオに由来しており、クラウド・プラットフォームは異なるユーザーからのリソース要求に優先順位を付けて処理し、各状態のタスク数をカウントするなどのタスク管理機能を提供する必要があります。
一つはタスクの統一的なスケジューリングをどのように管理するか、もう一つはタスクの状態遷移に関する情報の収集です。
OpenNebulaとOpenStackはそれぞれ独立したスケジューラコンポーネントを提供し、スケジューラを拡張するプラグイン機構をサポートしています。Eucalyptusの内部プロセスは主にMuleバスによって駆動され、新しいモジュールを追加するにはコアプロセスのコードを修正する必要があります。これに対して、OpenStackとOpenNebulaの実装は、既存システムへの影響が最も少ない。
タスクの状態遷移情報については、システムの複数の部分に情報が分散しているため、状態遷移をメッセージでタスク管理/統計を担当するモジュールに送り、統一的に処理する設計になっています。この点で、メッセージバスを備えたOpenStackと、Muleを備えたEucalyptusには明らかな優位性があります。全体として、OpenStackはセカンダリ開発をしっかりサポートしてくれます。
テクノロジーを超えて
上記の比較は、主に設計の面で、OpenStackが大きな優位性を持っています。しかし、他の点では
Eucalyptusは、AWSエコシステムのプライベートクラウド市場をリードしています；
CloudStackは、パブリッククラウドの展開後の商用顧客の数が多い後、その機能は、Apacheのオープンソースプロジェクトになった後、その疎結合の設計も議題にされている、キャッチアップの傾向の設計、安定して成熟している傾向があります；
OpenStackの現状は、機能が未完成であること、商用サポートが不十分であることが挙げられ、基盤化された後も現在の開発トレンドを維持できるかどうかも、我々にとって大きな関心事です。実際にクラウドプラットフォームを選択する過程では、機能やシステムのアーキテクチャ・設計、将来的な発展性などを自分たちの視点で検討する必要があります。
