クラウド基盤では物理リソースは抽象化されるため、使用するサーバは何でも良いのではないかと考えがちだがこれは間違いだ。当たり前の話だが、プライベートクラウド環境は、情報システム部門（バックオフィス）が管理・運用を行う必要性がある。運用性や可用性の担保などを考慮して選定する必要がある

　通常、パブリッククラウドを使用するユーザーは、クラウド事業者のSLA（サービス品質保証）をポイントの1つとして選定するが、情報システム部門は、パブリッククラウドのサービスレベルを考慮するように、ビジネス部門（フロントオフィス）が必要としているSLA、提供したいSLAに応じたハードウェアを選択すべきだ。

　プライベートクラウドの利点として、SLAを柔軟に設定できるということがある。パブリッククラウドにも信頼性、可用性を向上させたエンタープライズレベルのクラウド基盤を提供する事業者も出てきているが、情報システム部門、ビジネス部門がサービスを提供するのに最適なSLAを完全に補完できることは少ない。プライベートクラウドでは、パブリッククラウドとSLAの面からも使い分けができるように、より高いSLA設定や柔軟さを設定できるようにしておいた方がいいだろう。

　サーバは、最もコモディティ化しているコンポーネントの1つだが、各サーバベンダーは、拡張性や管理性、信頼性、サポート品質など細部で違いを出している。必要なサービス・構成に合わせて、大手サーバベンダーやODM（Original Design Manufacturer）ベンダーなどを活用することが求められる。

　主に情報システム部門が検討すべきは、そのサーバの品質、運用のし易さ、TCO（総所有コスト）となる。要求されるサービスレベルとコストの兼ね合いで選定することは既存のオンプレミス環境と変わらない。

　大手サーバベンダーが提供する製品は、やはり品質が一定以上に保たれている。障害が全く発生しないシステムが理想だが、そのようなシステムはまずありえない。サービスレベルを下げたくない、より高品質な基盤を提供したいということであれば、信頼性の高い大手ベンダーのサーバを選定するべきだろう。

　また、クラウド基盤では、サーバ台数が増加する傾向にあるため、管理性も重要なファクターとなる。もちろん、標準的なIPMI（Intelligent Platform Management Interface）を活用したサーバ管理も可能だが、一元的な管理性といった面から見ると大手サーバベンダーが搭載する機能拡張された管理プロセッサや管理ツールの方に一日の長があるといえる。

　監視など既存運用を大きく変えるのは困難だ。既に大手サーバベンダーのサーバを導入しているユーザーであれば、障害監視の仕組みなどベンダーが提供しているツールをそのまま活用できるため、監視運用の仕組みを新たに構築する必要は無い。一方で、サーバ管理・監視の仕組みから基盤検討できるのであれば、独自のツールを持たない代わりに比較的安価なODMベンダーのサーバとOSSの監視ツールのなどを活用することで、全体的なコスト圧縮が可能になるケースもある。

図1　《クリックで拡大》

　次に、プライベートクラウド環境の構築、増強を容易にするプロビジョニングツールの話に移る。プロビジョニングツールの採用の有無もサーバ選定のポイントとなる。

　現時点では、仮想化基盤や物理環境を構築する上でコモディティ化されたツールはなく、大手サーバベンダーから自社サーバのプロビジョニングを行うツールが提供されている。そのため、管理対象が少ない、頻繁なリソース追加が無い場合は、情報システム部門が都度構築することも可能であるため、ツールの無いODMベンダーのサーバでも十分である。だが、規模が大きく、頻繁なリソース追加が必要となる環境では、拡張／縮小に掛かる人的コストや要する期間も考え、プロビジョニングツールのある大手サーバベンダーのサーバを採用するべきである。

ハイパーバイザーの選択肢と現状は

　クラウド環境は、必ずしも仮想化されている必要はないが、集約によるコスト削減やリソース管理の面から、やはり仮想環境を中心に考えていく方がいい。

　現在、主流のハイパーバイザーとしては、「VMware ESXi」「Microsoft Hyper-V」「KVM」などがある。リソースの抽象化層という点では同一の機能を提供しているが、細かい点では機能や制限などがそれぞれ異なるため、実現したいことや用途によって使い分ける必要がある。

　仮想化基盤であれば、異なるハイパーバイザーを個別に管理しても問題はなかったが、プライベートクラウド基盤を構成するためには管理の一元化を行うべきだ。異なる環境を持ってリスク分散を行うことも考慮はすべきだが、運用面から見て機軸となるハイパーバイザーの選定は必要だろう。

　前述の通り、プライベートクラウド基盤のハイパーバイザーとして、VMware、Hyper-V、KVMなどの選択肢があるが、対向のパブリッククラウドも意識して選定しなければならない。

　ハイブリッドクラウドを考慮したプライベートクラウド基盤を構成する上では、使用するパブリッククラウドの仮想化技術も情報としては必要だ。パブリッククラウドの仮想化技術は、一部を除き基本的に正式に公開されていないが、使用している仮想化技術が何であるかは、ハイブリッドクラウド基盤を構成する上で、今後の運用に少なからず影響する。

　1つの例を挙げてみよう。システムの運用状況やサービスの利用状況によって、プライベートクラウドに構成されたサービスをパブリッククラウドに、パブリッククラウドのサービスをプライベートクラウドに移動したいという要望は、必ずといっていいほど発生する。そうなると、いかにサービスを自由に移動しやすい構成にしておくかを考慮しておかなければならない。

　移動したいサービスが仮想マシン単位のレベルなのか、アプリケーション単位のレベルなのかなどによっても異なるが、仮想マシンであれば、特にパブリッククラウドからプライベートクラウドへ回収が可能か、回収方法にどのような手段があるかは事前に考慮に入れておくべきだ。

　ハイブリッドクラウド環境が当たり前になるであろう将来は変わってくるだろうが、現在のパブリッククラウドは、全ての環境へシームレスに仮想マシンの受け渡しが可能なわけでない。仮想マシンレベルの移動を検討するのであれば、現時点では、パブリックとプライベートのハイパーバイザーは合わせておいた方がいいだろう。

図2　《クリックで拡大》

　実際に、オンプレミス環境に多くのユーザーを持つ、VMware、Microsoftなどのベンダーのパブリッククラウドは、プライベート、パブリックに同じハイパーバイザーを採用することで仮想マシンの相互移行を可能とし、自社プライベートクラウド基盤製品と連動した付加価値を付けることに力を注いでいる。

　ただし、シームレスな連係を考えた際には考慮しなければならない問題も多い。クラウド間で仮想マシンを移行するためには、クラウド基盤上の仮想マシンは、他の基盤でも稼働できるように、ネットワーク、ディスク構成などを標準化しておく必要があるからだ。

図3　《クリックで拡大》

　現時点では、仮想化技術が公開されている「VMware vCloud Air」や「Microsoft Azure」もしくは同社の仮想化技術を使用したクラウドサービスが選定しやすく、パブリック／プライベート共に同じ運用方法を使用できることで、パブリック／プライベート間の相互運用性は高くなる。一方で、KVMに関しては、クラウド事業者のAPI次第になっている感は否めない。この辺りは次章でも解説する。

　既に仮想化基盤があるユーザーにとっては、既存の仮想化基盤を活用したクラウド基盤の構築となるため、現時点ではVMware ESX／ESXiを中心として考えることが多くなるだろう。