クラウドコンピューティング再考<2>|クラウドコンピューティング|ブログ|Computerworld

header_cwr_head_mid_fl_logo

CW_ウルトラバナー_Topics08

CW_ウルトラバナー_Topics04

CW_ウルトラバナー_Topics02

CW_ウルトラバナー_Topics05

CW_ウルトラバナー_Topics06

CW_ウルトラバナー_Topics07

クラウドコンピューティング

クラウドコンピューティング再考<2>

Posted by Cloud BusinessAlliance ( 2010年05月27日 )

前回はNISTによるクラウドコンピューティングの定義から再考してみました。今回は、弊社のLibra(ライブラ)というサービスを開発した経験を交えながら、IaaSに関する要件について考えてみたいと思います。

IaaSの要件

クラウドコンピューティングでは、技術面に関心が向きがちですが、普及ということを考慮すると経済性という視点を持ち、バランスをとることが大切です。やはり、最初のテーマは、やはり規模の経済性を技術的にどう考慮するかがテーマになるでしょう。 規模の経済性は、大量に生産すればするほどコストが下がる仕組みです。その為には、大量に生産する仕組みが必要であり、IaaS に関して言えば大量のサーバを束ねてひとつのリソースプールを構成する仕組みです。ところが、リソースプールの規模が倍になったとき、運用コストはどうなるでしょうか?サーバに関して言えば、大量調達により、安く仕入れることができますが、運用コストは一般にサーバの台数に概ね比例します。そして、この運用コストの内訳のほとんどが、障害対応に関する人件費です。規模の経済性を働かせるには大量に生産する仕組みと変動費の抑制が鍵になります。

巨大なリソースプールを作る

巨大なリソースプールは、単純にサーバを並べるだけでは作れません。大量のサーバ群をコントロールできる単一インターフェースをリソースプールが持っていることが必要です。リソースプールの利用者からすれば、見えているのは、この”単一のインターフェース”だけです。リソースプール化された基盤では、物理的なサーバは完全に隠ぺいされており、その向こうにあるサーバの台数が10 台あるのが100 万台なのかを知るすべはありません。

弊社のサービスである Libra では、リソースプールを構成する為にいくつかのレイヤーを定義しました。土台に、先日CAに買収された米3Tera社のAppLogicというグリッドOSを使っています。これは、ラック 1 本程度のサーバ群を管理する、いわばミニクラウドです。また、複数のミニクラウドをつなげてビッククラウドを作る為に、ALSA(アルサ、AppLogic SOAP API)とAntlia(アントリア)を開発しました。 ALSA には二つの役割があります。ひとつは、API を持たない AppLogic の機能を補完すること。そして、もうひとつは、AppLogic を抽象化することです。ALSAはAppLogic 用ドライバーという顔をもち、これを差し替えることで他の仮想化技術に対応することを可能にします。 Antliaは、複数のミニクラウドを束ねビッククラウドを構成します。Antliaは、前述の”単一のインターフェース”となる API を持ち、ユーザーからのサーバのプロビジョニング等のリクエストを適切なミニクラウドへ割り振ります。

リソースプールを共有する

大量生産したリソースはある特定のユーザだけで使いきれるものではありません。NISTの文書にもありますが、マルチテナントは機能として必須です。 Antlia は、ミニクラウド群のリソースを管理しますが、合わせてリソースプールの利用者に対して提供するリソース量をコントロールする責任を持ちます。この機能は、視点によって意味が1変わってきます。リソースプールの利用者にしてみれば、契約した量に関してはいつでも利用できるということですが、一方、リソースプールの所有者からみると、所有しているリソースプールを切りだして複数のユーザに提供することが可能になるということです。この後者の例としてAmazon があります。Amazon は、巨大なリソースプールを所有しています。Amazon の本業はオンラインショップですが、他方では、余剰リソースを活用してEC2に代表されるAmazon WebServices(AWS)という、もうひとつの事業を運営しています。ITリソースのクラウド化により、従来、コストセンターとして考えられてきたサーバ群の価値に変化が起きつつあります。

自律的な運用を実現する

単一のインターフェースからリソースプールをコントロールできるということ、それはまさに、プログラミング可能な基盤です。基盤がプログラミング可能であれば、障害等の対応は予めプログラミングされた基盤が自律的に対処するので、少ない人員での巨大なリソースプールを運用が可能になります。この機能は、変動費を抑制する為に重要な要素となります。

課題

Libra を開発することによって、いくつかの課題が明確になってきました。最も大きな課題は、ネットワークのコントロールをどうやって実現するのか?ということです。前述のALSA,Antliaを使うことによって仮想マシンのコントロールに関しては土地に縛られることは無くなりましたが、ネットワークをグローバルなスケールで抽象化することには成功していません。近頃大変注目され ている Eucalyptus の場合、全ての仮想マシン間の通信をハブとなる CLC というマシンを経由させることでこの問題を回避していますが、スケーラビリティという観点では問題があるように思います。しかし、課題があるということは、チャンスもあるということです。是非、一緒にチャレンジしてみませんか?

<筆者紹介>

千葉則行(ちばのりゆき)

株式会社エクシード 取締役 CTO

 

 

社会人になってから、一貫してオープンソースを中心とした基盤構築に関わる仕事に携わってきた。

未来については語れるのに、明日については想像すらできないことが目下の悩み。

クラウド・ビジネス・アライアンス) (エクシード

ページの先頭へ戻る