サーバ・コンソリデーションの「計画ステップ」と「交渉ステップ」

綿密な計画を立てたのち、ベンダーから有利な契約条件を引き出す

（2006年09月22日）

3. 仮想化技術を利用する

　サーバ（CPU）仮想化は、サーバ・コンソリデーションの効果をいっそう引き立たせるスパイスのような技術と言ってよいだろう。この技術を使う主なメリットには、ハードウェア・コストの削減、システムの応答性と柔軟性の改善、そして、システム運用管理にかかる負荷およびコストの抑制がある。

　このステップでは、昔ながらのハードウェア・パーティショニングから、IBMの「マイクロパーティショニング」のようなLPAR（論理パーティショニング）に至るまでの、さまざまな粒度のサーバ仮想化技術について調査し、自社のプロジェクトにはどの技術がふさわしいのかを検討していただきたい。仮想化技術の採用には次のようなメリットがある。

■TCO（総所有コスト）の削減

　仮想化がもたらす最も明らかなメリットは、物理リソースの利用率を高められることだ。ITインフラにおいて、仮想化の導入とコンソリデーションが共に進めば、ハードウェアの設置スペースや電源、空調など、データセンターで日々消費するさまざまなリソースの削減にも貢献できるはずだ。

■システムの応答性、柔軟性の改善

　仮想化されたリソースは、ビジネス・ニーズや必要なサービス・レベルの変化に応じて動的に移動、変更できるようになる。

■システム運用管理負荷／コストの削減

　仮想化によって、管理するサーバの台数が減るだけでなく、日常的な管理作業負荷とコストが軽減される。例えば、パッチング、初期システム、ソフトウェアの導入、システム監視、マシン・メンテナンス、チューニングおよびアップグレード・プランニングなどの作業とそれぞれにかかるコストである。

4. 初期コストをもれなく算出する

　サーバ・コンソリデーション・プロジェクトでは、サーバのみならず、その周辺インフラ、つまりストレージやネットワークの拡張／アップグレード、追加の必要があるソフトウェア・ライセンス・コスト、テスト環境などへの投資も必要になってくる。これらは必ず初期コストとして計算に入れておくべきだ。

　プロジェクトにかかるコストを抑えたいのであれば、より少ない台数の、より高性能なサーバ上でアプリケーションを走らせることが目標になる。とはいえ、アプリケーションを既存のプラットフォームから別のプラットフォームに移すには、当然、相応のコストがかかることになる。そこで、以下の点を踏まえて、コンソリデーション・プロジェクトの初期コストを算出することをお勧めする。

■ベンダーの製品ロードマップのチェック

　ハードウェアの購入コストやアップグレード・コストは幅が広い。そのため、サーバ・ベンダー各社の製品ロードマップのチェックは必須である。例えば、ベンダーがアーキテクチャを刷新した新しいサーバ・ブランドを投入するような時期にアップグレードを行うとなると、サーバのみならず、ストレージやネットワーク・デバイスまでハードウェアを総入れ替えしなくてはならないケースも出てくる。だが、サーバ・アーキテクチャが同一であれば、最初はメモリの増設から始め、CPUやI/Oモジュールの追加やアップグレードといった具合にデバイスを選択的にアップグレードすることができる。

■ソフトウェア・アップデートとライセンス契約の把握

　コンソリデーションにより、新バージョンのOSや新リリースのアプリケーションなど、ソフトウェアのアップデートの必要が生じ、当然コストがかかってくる。アップデートに伴い、サポート契約の再交渉が必要になるケースだと、コストはさらに上昇する。

　結局のところ、これがコスト評価の最も難しい部分なのである。コストは、例えば、サーバのベンダーやブランドは何か／追加料金なしで現行のライセンスを新規のサーバに適用できるか／アプリケーションがサーバのパーティションや仮想マシン（VM）上で稼働している場合、ライセンス体系がどう変わってくるか、といった複数の可変要素で決まるからだ。

■追加コストの想定

　テスト運用段階で追加のコストが発生する可能性もある。サーバ・コンソリデーションに限らず、ITプロジェクトでは、技術的な不具合や未知のユーザー・ニーズなどを洗い出すために、極力本番稼働に近いテスト運用を実施するのが普通だ。その際、ベンダーによっては、実機を無料もしくは破格の値段で貸し出してくれるところもあるが、契約内容自体はあくまでプロジェクトのテスト運用に限定したものである。同様に、カットオーバーの前後にベンダーのプロフェッショナル・サービス担当スタッフが出向いて行ってくれるサポートについても、無料サービスというわけではない。

　したがって、初期コストの見積もりには、テスト運用でかかるコスト（ベンダーに支払う料金と自社スタッフの人件費を含む）をきちんと盛り込んでおく必要がある。

5. 自社ITインフラの「ライフサイクル・コスト」を試算する

　計画ステップの仕上げは、サーバ・マシンの導入と運用管理、そして漸増的な変更コストを含む包括的なライフサイクル・コストの試算である。これは、次の交渉ステップにおいて、サーバ・ベンダーとの「交渉ツール」の1つとして用いられることになる。

　一般に、IT/IS部門では、3年から5年ごとに、すべてのサーバを“オーバーホール”する作業の必要が生じる。フォレスターが提唱する、運用管理ライフサイクルを通じたサーバ所有コスト・モデル「C3」（図2）は、コストのあらゆる内訳と、それらが3～5年のライフサイクルのどこで発生するかを突き止めるうえで役立つはずだ。

　C3モデルは、サーバ、ストレージ、ネットワーク、OSおよびシステム・ソフトウェア、アプリケーションなどの各コンポーネントから、運用管理スタッフ（常勤スタッフとコントラクター）、ハードウェアの設置スペース、電源、空調などの設備まで、自社ITインフラにかかわるあらゆるコストが対象となる。なお、筆者がこれまで多くの顧客企業を見てきた中では、以下に示す3段階のコストのうち、「取得コスト」と「継続的運用コスト」の2段階のコストまではきちんと見積もるが、3つ目の「インクリメンタルな変更コスト」を見過ごしている企業がほとんどであった。

図2：フォレスター・リサーチが提唱するC3コスト・モデルの記入シートの例

■取得コスト

　取得コストは、製品やサービスの購入時にかかる1度限りの初期コストを指す。ベンダーがその製品やサービスを顧客企業の環境にインストールする前に支払われるコストである。

■継続的運用コスト

　スタッフの給与やベンダーに支払われるメンテナンス料などの継続的運用コストは、毎月、隔月もしくは毎年発生し、製品やサービスを利用しているかぎり続く。

■インクリメンタルな変更コスト

　3～5年のライフサイクル・コストに含めて考えるべき、ハードウェアのアップグレードやソフトウェアのバージョンアップなどに要するコスト。ベンダー自身も2年後のアップグレード時にユーザーにいくら請求するか決めているわけではないので、これらのコストを定量化するのが難しく、ほとんどの企業は無視しがちだ。また、上位機種への買い換えや下取りのオプションを用意しているベンダーもあり、そうなるとインクリメンタルな変更コストを見積もるという作業はますます困難なものとなる。

　さらに、次期サーバにアップグレードするときの査定額が一定のパーセンテージに基づいて定められていても、顧客の交渉に応じてくれるベンダーも存在する。フォレスターとしては、そのベンダーの過去のリリース頻度と契約規模の平均拡大率、もしくは平均縮小率を参考に、あらかじめアップグレードの予算を組んでおくことを顧客に勧めている。

前のページへ < ｜1｜2｜3｜ > 次のページへ