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

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

（2006年09月22日）

企業内に散在する複数台のサーバを統合、集約するサーバ・コンソリデーションに取り組もうとしている企業は多いことだろう。このプロジェクトを成功させるためには、既存の環境とコンソリデーション後の環境に関して、デューデリジェンス（Due Diligence：入念な事前調査・分析）を実施する「計画ステップ」と、サーバ・ベンダーとできるだけ有利な条件で契約するための方法について考える「交渉ステップ」のそれぞれで戦略が必要だ。本稿ではこの両ステップにおけるポイントを解説しよう。

ブラッド・デイ
米国フォレスター・リサーチバイスプレジデント

コンソリデーション・プロジェクトの第1段階となる「計画ステップ」

　サーバ・ベンダーに、自社のサーバ・コンソリデーション・プロジェクトの概要を的確に伝え、条件面などの交渉を行う前のステップとして、まずは慎重かつ綿密なプランニングが必要だ。しかし、筆者が見るかぎり、きちんとデューデリジェンスを実践して、この「計画ステップ」を遂行している企業は少ない。その結果、企業はベンダーに条件や意向を伝えきれず、ベンダーはサーバのパフォーマンスやコンフィギュレーションの最適化、予算について顧客の要望にこたえられないでいる。企業・組織のIT/IS部門は、ベンダーの技術担当者と交渉の席に着く前に、手持ちのITインフラストラクチャにまつわる資産を監査したり、候補としているサーバ製品に対して確固とした選択基準を決めるため、所定のベンチマーク・テストを走らせたりといった作業を行う必要があるのだ。

　これらの作業からなる計画ステップを経て、自社にとって最適な製品やソリューションが選ばれたら、今度は、それらをできるかぎり有利な条件で契約するための「交渉ステップ」に移ることになる。ベンダーとの交渉の席でそれぞれのメンバーが果たす役割を考慮しながら、最良の交渉チームを結成するというわけだ。

　さて、サーバ・コンソリデーションを成功に導くプロジェクト・リーダーというのは、一流の家具職人に似ていると筆者は考える。設計図を描き、材料を仕入れ、測定するといった作業に時間の大半を費やすという点では両者とも同じだからだ。事前にしっかりとした計画を立てておけば、後になってあわてて手直ししたり、余計なコストが発生したりといったことがなくなる。以下で、ぜひ実践していただきたい5つの計画ステップで行うべき作業を解説していこう。

1. 既存のITインフラを構成する資産を目録化し、監査する

　資産目録の作成は、サーバ・コンソリデーションを行う際にあえてやるほどのことではないと思われるかもしれない。だが、まずはこの作業から着手することをお勧めする。資産目録は、サーバ・インフラのどの部分をどう統合すれば、機能性やそのメリットを最大限に高められるかを判断するための目安となるからだ。

　具体的な作業としては、サーバと、各サーバ上で稼働するアプリケーション・ワークロードのロール／アイデンティティ情報、さらに選択したサーバ属性からなる目録を作ることになる。こう書くとそれほど難しい作業には見えないかもしれないが、実際に行うのは容易でなく、自社のIT資産に関し、正確かつ詳細な情報を収集するのにどれだけの時間がかかるかを過小評価している企業が多い。特に、複数の場所にデータセンターと運用管理スタッフを分散させているような大規模企業の場合、作業は困難なものとなる。

　筆者が所属するフォレスター・リサーチでは、企業がIT資産の目録化・監査をもれなく行えるようにするための項目チェックリストを用意している。このうち、サーバに関するリストを図1に示したので、活用していただきたい。

図1：IT資産の目録化・監査のための項目チェックリスト（サーバ編）

2. プロジェクト完了後のサーバ・インフラの予想サイズを割り出す

　このステップでの作業は一般に、パフォーマンス・テスト・ツールが活用される。サーバ・コンソリデーション・プロジェクトで必要とされるサイズ（サーバに搭載されたCPUの処理能力やストレージ・システムの容量など）を正確に見積もるため、実際のアプリケーション・ワークロードのパフォーマンス特性に極力近づけたテスト環境を構築するべきである。

　この作業において、CPUのクロック速度やパイプライン長など、サーバ・アーキテクチャの特定の要素にこだわりすぎるのはよくない。サーバ・コンソリデーション・プロジェクトで評価すべきは、サーバ・インフラ全体における改善であるからだ。サイズの判断は、「Memory-Intensive」などを使ったコンポーネントごとのベンチマーク・ツールや、「TPC-C」に代表される業界団体のベンチマーク・プログラム、そして実運用環境に近い形でアプリケーション・ワークロードをテストできる固有のベンチマーク・ツール（これが最も重要）から算出される結果から総合的に行うことになる。

　続いて、コンソリデーション後に運用するサーバ・マシンのアーキテクチャについて、サーバ・インフラのサイズに関連する要素を中心に検討する。具体的には、AMDのOpteronプロセッサやインテルのEM64T系プロセッサのように、CPUがマルチコア・アーキテクチャを採用しているのか、CPUが複数のスレッドをどう扱うのか、そして、OS固有の機能をチューニングすることでどのような影響が生じるのかといったことが検討される。

　この一連の作業により、例えば、あるベンダーの最新のx64サーバは、他のベンダーの同じCPU数のサーバに比べ、アプリケーション実行時のパフォーマンスが格段に高いといった、自社での実運用時の状況が見えてくるようになる。

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