手段を先行させないクラウドの課題解決

クラウド・コンピューティングのユースシナリオ

　「話題のクラウドコンピューティングを導入したいが、一体何に使うのがよいか」、これはクラウドコンピューティング導入に当たって多くの方が一度は悩まれるポイントです。手段が先行し、目的が後追いになるのは本末転倒のように思われますが、革新的な技術の出現に際してよく見られる状況です。

　このような課題に対して、典型的なユースシナリオを体系的にまとめて検討することは有効です。クラウドコンピューティングの場合、2つの軸、すなわちコンサンプション・モデルとワークロードによるマトリックスで考えることで具体的なイメージをつかみやすくなります。

　コンサンプション・モデルとは、クラウド・サービスの利用形態のモデルで、クラウド・サービスと利用者のトポロジーで表されます。

　クラウド・サービスはパブリック・クラウド、プライベート・クラウドに、利用者はエンドユーザーとエンタープライズに分類することで、
「エンドユーザー→パブリック・クラウド」
「エンタープライズ→パブリック・クラウド」
「エンタープライズ→プライベート・クラウド」
「エンタープライズ→パブリック・クラウド←エンタープライズ」
などの意味のある組み合わせを見いだすことができます。

　もう一つの軸であるワークロードとは、クラウドコンピューティングの用途の類型です。

　クラウドコンピューティングの価値の源泉は、「卓越した変化への対応力」であり、特にシステム構成とITリソース要求の変化への対応が重要になります。そのような対応力が効果的である用途の類型として、開発テスト・クラウド、ストレージ・クラウド、デスクトップ・クラウド、ITリソース要求の変動が大きいプロダクション・クラウドなどが挙げられます。

　次に「エンタープライズ→プライベート・クラウド」における典型的なワークロードについて解説します。

開発テスト・クラウド

　開発テストではIT環境の構築、使用、解放が繰り返し行われるため、クラウドコンピューティングの構成変化への対応力が発揮されます。これをクラウドサービスのライフサイクルの中で見ていきましょう（図1参照）。

1）まずIT部門が、開発テストに必要となるさまざまなIT環境のひな型を「サービステンプレート」として定義します。

2）次に、サービス・カタログ・マネジャーが、具体的な開発テスト要件に合うようにサービステンプレートを修正して「サービス・オファリング」を作成し、サービスカタログに登録します。

3）これによってサービス申請者はセルフサービスポータルからサービス・オファリングを見られるようになり、必要なサービス、例えばPCサーバー上のリナックス環境の利用などを申請します。

4）ポータルから入力された申請は承認ワークフローに乗って承認処理が行われ、プロビジョニング・ソフトウエアによってリソースプールから必要なリソースが選ばれ、インスタンス化されます。

5）サービスの利用期間中、システム管理者はITリソースの状況をモニタリングし、課金などに必要となる利用状況をメータリングします。

6）最後に、サービス申請者は不要になったサービスインスタンスを終了し、ITリソースをリソースプールに戻します。

　以上の流れで特徴的なのはセルフサービスポータルの存在です。サービス申請者は自らサービスを選択し、追加のパラメータを指定し、システムに直接利用申請することができます。途中に人手が介在しないため、スピードアップとコストダウンが可能になります。

　また承認ワークフロー、プロビジョニング、モニタリング、メータリングなどが自動的に行われるのは、最初にサービス・テンプレートで必要な手順が設定されているからです。IT部門の役割は、個別のサービス申請への対応からサービステンプレートの定義、開発へとシフトすることになります。