クラウドコンピューティング環境では、ユーザーが自分で何が欲しいかを選定するセルフサービスポータルシステムが必要になります。そのポータルシステムを利用することで、サーバー、ストレージ、ネットワークなどを最適な組み合わせで提供できなければなりません。

 ここでは、セルフサービスポータルシステムと、それと連動してITリソースを割り当てるシステムを合わせて「サービスマネジメントシステム」と呼びます。図1に示したのはサービスマネジメントシステムの一例で、「IBM Tivoli Service Automation Manager」のアーキテクチャーを示してします。

図1●サービスマネジメントシステムのアーキテクチャーの一例(IBM TivSAM)
図1●サービスマネジメントシステムのアーキテクチャーの一例(IBM TivSAM)

 クラウドコンピューティングは、動的な資源を自動構成する「プロビジョニング(=サービスのオートメーション)」を中心として、それを支えるオペレーション支援機能群と従量課金を基本とした、注文から提供までのサービスマネジメントシステムが必要となります。

 コンテンツプロバイダーはサービスを開発し、サービスを登録します。登録するサービスの内容は、基本サービスやオプション類などで、ユーザーのカスタマイズ範囲を特定するのが特徴です。

クラウドコンピューティングのサービスライフサイクル

 クラウドコンピューティング環境では、サービスとして提供するIT環境の構築と同時に、サービス全体のライフサイクルを考えておくことは重要です。ここではクラウドコンピューティング環境のサービス全体のライフサイクルを次のような要素で考えます(図2)。[サービス定義]→[オファリング]→[サービス申請作成]→[プロダクション]→[サービス終了]。

図2●クラウドコンピューティングで重要なサービスライフサイクル
[画像のクリックで拡大表示]

 サービス定義においては、ライフサイクルを通じて利用者や管理者などのクラウド環境の利用者に主眼をおいたユースケース(使い方)を定義する必要があります。そこでは、利用者の利用状況、要件を分析して必要とされる機能要件と非機能要件(SLAや容量など)を定義します。

 そのほか、セルフサービスポータル上で利用部門がどのような機能が利用可能で、どのような非機能要件が果たされているのかが明らかになる必要があります。利用部門における利用イメージが作り出しやすくなっていなくてはなりません。つまり、サービス利用者にとってのメリットが容易に判断できるということです。サービス移行後のシステム管理の要件についても同様に定義します。

 これまでのITインフラストラクチャーの運用設計は「何を管理するのか」という視点が強調されていました。それに対して、クラウドコンピューティング環境のサービス定義の設計においては、利用者と同様に管理者も主要な登場人物(アクター)として定義し、「どのように管理するのか」というユースケースが重要になってきます。こうすることで管理機能をシステム設計に組み込み、サービスの質を設計段階で織り込んでおくことができます。

 サービスのテンプレートは複数の利用部門に公開されますので、機能要件/非機能要件の明確な定義やユースケースの共有などが重要になってきます。ITインフラストラクチャーのサービス全体を一つの系(システム)としてとらえたアーキテクチャー(基本構造)が明示されることが重要になります。