2.3クラウドの設計

・拡張性

スモール・スタートで開始して後からリソースを拡張していく場合もあると思いますが、クラウド基盤として拡張性をどこまで持たせるのかは決めておく必要があります。同時に、クラウド基盤のライフサイクル・モデルおよび関連するライフサイクル・コストについての評価を実施しておく必要があります。

・サービス・レベル

顧客視点で語られることの多いサービス・レベルは、以下の2種類が関連します。

• （A）収容システムから見て利用者へ提供するサービスのレベル。
• （B）クラウド基盤側から見て収容システムへ提供するサービスのレベル。

一般に、顧客に提供するサービス・レベルの中でシステムによって実現する部分は一部ですが、（B）によって（A）を実現するため、（A）＜＝（B）である必要があります。また、共通で利用する基盤を提供するため、クラウド基盤のサービス・レベルは、収容システムの中で最も厳しいサービス・レベルを満たすことが求められます。

・KPIの設定

要件定義工程で、プライベート・クラウドに関する評価項目を設定しておくことが重要です。顧客視点のサービス・レベルの設定も重要ですが、目標数値や内部管理用の指標を決めておき、ステーク・ホルダー（特に経営層）にコミットしておくことが重要です。

2.3クラウドの設計

ここでは、クラウド基盤の設計に関して説明します。個別の要件となるため収容システムの移植については割愛します。

2.3.1 クラウド基盤OSSの選択

OSSのクラウド管理基盤は、仮想マシンの管理機能、リソース管理機能、ネットワーク管理機能、ユーザー管理機能、アクセス制御機能などを提供しています。必要な機能を満たすOSSを選択します。なお、クラウド基盤OSSの紹介については次回の連載記事を予定しています。

2.3.2 アーキテクチャの設計

クラウドの実装設計は、利用するOSSの、クラウド基盤のアーキテクチャにあわせる必要があります。

図2にプライベート・クラウドの構成例を示します。

ラック1、2本程度の小規模のクラウド基盤であれば、クラウド・コントローラを一式設置するだけで制御することができます。それ以上の規模になる場合には、複数コントローラで負荷分散するように設計をすることが必要です。

現在公開されているOSSのクラウド基盤でHA構成までサポートされているものはほとんどありませんので、複数のOSSを組み合わせて自前で実装するか、エンタープライズ版を導入するなどの方法が考えられます。

実装にあたっては、OSSのサポートしている範囲と、その実績（安定性）なども考慮して全体のアーキテクチャを設計することが必要となります。