Sun Cloud API：十分なシンプルさを実現しているか？

作者 Boris Lublinsky , 翻訳者 編集部 投稿日 2009年4月4日

セクション

運用/インフラ,

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

SOA ,

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

タグ

Sun Microsystems

 

William Vambenepe氏による新しい投稿(リンク)は、データセンター自動化メカニズムにおいて、柔軟性を犠牲にしてでもシンプル性がどれほど強く求められているかを 物語っている。これは、SunによるSun Cloudイニチアチブ(リンク)の発表に端を発する。同氏の意見は以下のとおりだ。

Sun APIは非常にシンプルで、作者たちはその事実を誇りに思っています。実際、彼らは不必要な複雑さを回避したことに満足してしかるべきです。ただ一部、（少なくとも現時点では）必要となる複雑さも排除してしまったと思われます。

Sun Cloudの基盤は、リソースモデル(リンク)およびこれらリソースへのアクセスやその操作用のAPIだ。Sun Cloudが定義するリソースモデルはCloudリソースを中心に構築されており、Cloudリソースとは、クラウド内でアクセス可能なすべてのリソース のユーザービューで、クラウド自体およびそのコンポーネントへのアクセスを提供するものである。クラウドは1つ以上の仮想データセンター（VDC： Virtual Data Center）を含むことができ、これは単独の仮想データセンター内で利用可能なリソースのユーザービューに値する。VDCに含まれるのは、インター フェースを介して特定のVMに付加することができる一連のパブリックアドレス（公にアクセス可能な静的インターネットプロトコル（IP）アドレス）、クラ スタ（VMのグループ）、VNet（共通の機能でグループ化する目的で分けられたリソース）、およびボリューム（この情報へのアクセスに使用する同じ信用 証明によってアクセスされる可能性があるリモートWebDAVボリューム）である。ボリューム内容のポイントインタイムの描写は、スナップショットによっ て定義される。先ほど説明したように、クラスタには、仮想マシン（VM：Virtual Machine）（クラスタに関連する仮想コンピュータで、特定のVMのスナップショットを示すバックアップによって定義された状態）および仮想ネット ワーク（VNet：Virtual Network）（VMに関連するインターフェースが接続される可能性のある仮想プライベートネットワーク）が含まれる。インターフェースは、特定のVM に関連するネットワークインターフェースカード（NIC）を意味し、VNet（仮想プライベートネットワーク）またはパブリックアドレス（インターネット からアクセス可能な静的パプリックIPアドレス）のどちらかへの（このVMからの）IP接続の記録を残す。

Tim Bray氏の投稿(リンク)によると、Sunクラスタ向けに提供されたAPIは以下のとおりである。

（このAPIは）ストレージ、計算、およびネットワーキングサービスの統一ビューです。これはVDCの概念を中心に構築されており、ネットワーク、サー バーのクラスタ、パブリックIPアドレス、およびストレージサービスを含みます。考え方としては、非常に大がかりで意欲的な何かを構築するための管理上、 操作上のハンドルを実現するためのものです。VDCの概念はまことに巧妙で、いずれは、本格的なあらゆるクラウドAPIにおいて必要となってくるものだと 思います。

根底において、インターフェースはHTTPベースで、REST対応となるべく熱心な試みが行われています。サーバー、ネットワーク、仮想データセン ターなどのリソースはすべてJSON対応です。（中略）このインターフェースは、「サーバーの起動」や「スナップショットの保存」など、リソースの CRUD以上のことを実行します。つまり、昔ながらのREST設計パターンではあまり詳しく説明してくれない類のことです。その仕組みの例を挙げると、 サーバーの代表が一連の「コントローラ」URIを含み、これらのうちの1つに対するPOSTがサーバーのリブートなどの動作を実行するためのリクエストを 構成します。

下位レベルのRESTの上位には、どちらかといえばHTTPメッセージングを扱いたくない人向けのライブラリセットがあり、これはJava、 Ruby、Pythonを問わず利用可能です。その上位には、古典的なUnixテキスト行の代わりにJSONを出力する以外、シェルスクリプティングに適 したコマンドラインのインターフェースが存在します。

最後に、Web GUIが用意されており、いろいろなものをドラッグ＆ドロップすることでVDCを構築できます。これはすばらしいデモウェアで、人々が急な通知で通信に よって手早くアドホックなサーバー配備を実現するためにこれを使用している姿が目に浮かびます。しかし、私の確信では、これらのドラッグ＆ドロップ操作に は非常に手間がかかり、それよりはサーバー配備をスクリプト作成したくなるに違いありません。

Vambenepe氏は、このシンプルな階層モデルに基づくAPIが実際のデータセンターの複雑性を体現できるかどうか疑問に思っている。

今日のデータセンターを見てください。データセンターに含まれるすべてのネットワーク接続された機器、ストレージ、サーバー、ハイパーバイザー、オペレー ティングシステム、およびインフラストラクチャサービスのインベントリを作成するのです。これら一切のリソースの構成設定すべてを考えてみてください（こ れらは信頼性と一貫性を備えた完全なCMDBで表されるように、もっとも捕らえどころがない物体です）。このデータセンターに、公開するすべてのコント ロールとAPIを追加してみてください。たとえアプリケーション層を考慮しなくても、大量のデータになります。これは、Sun Cloud API内のモデルが表現できる内容よりも桁違いに大きいものです。私たちは、この（CMDBモデルとSun Cloudモデル間の）ギャップに目を向け、分析すべきです。これらはなぜこれほどかけ離れているのでしょうか。理想的なデータセンター自動化および仮想 化モデルはどれほど規模の大きいものなのでしょうか。

同氏はこう提案している。

「全知のCMDBモデル」と「Sun Cloudモデル」間に存在する理想的な場所は、徐々に複雑になっていく何層かをはさんだ中間あたりにあります。もちろん、今までのところ、これらは離れていて、「中間あたり」とは現実逃避に過ぎません。

Sun Cloud(リンク)は、クラウド作成者とユーザーが使用できるAPIセットである。このシンプルなリソースセットとAPIがクラウドの構築や使用に十分であることが証明されるか、より複雑なAPIセットが必要となるかどうかは、やがて明らかになるだろう。

 

原文はこちらです：http://www.infoq.com/news/2009/03/SunCloud

• 次へ >