USの調査会社META Group(http://www.metagroup.com)のレポートに
興味深いモノがありました。TCO削減に有効な手段とされているサーバー
統合(Server Consolidation)ですが、注意しておくべき落とし穴として
「Server Consolidation: Five Vender Myths」と題してまとめています。
・NT3.5環境と最新のUnix環境を比較するのはフェアでない。Windowsプラット
フォームのままバージョンアップすることも有効なTCO削減手段の一つである。
・複数台のサーバーを一台のハイエンドサーバーに統合することで運用管理が
楽になるように見えるが、実際には各サービス毎に運用管理が必要なので手間
は変わらない。ハイエンドサーバーへまとめるメリットがあるのは大規模データ
ベースシステムくらいではないか。
・OSを単一ベンダーに統一することは過度のベンダー依存を引き起こし、コスト面
の交渉時に不利な要素となるので避けた方が良い
・サーバーの仮想化を使い、単一物理サーバーに複数のサービスを立ち上げる方が
TCO削減に有利なように見えるが、管理ツールのコストが高くなりがちである。
同じことは複数のブレードサーバーを一つの筐体にまとめることでも実現でき、
この方が管理ツールコストの選択や配備に融通が効きやすい。
・既にMicrosoftのOSやOffice製品を利用しているユーザーが同社製品から完全
に離れることは実質的には困難であるし、コスト削減にはあまり寄与しない。
といったようなことが述べられています。確かにいずれも経営層から見れば魅力的
なTCO削減手段ではあるけれども、よくよく積算してみると返ってコスト高になって
しまいそうなトピックではないかと思います。
あらためて感じたのはTCO削減という話題において「運用管理ツール」の位置付けが
とても重要になってきているということです。単一ベンダーに限定されないオープン系
のシステムにおいては種々雑多なシステムを如何に統一的に管理するかという点が最も
重要だということかと思います。
IBMはEclipse Hyadesプロジェクトなどと協調してログフォーマットの統一や
インストール手順・各種設定手順の統一といった取り組みを始めています。
Microsoftのそれに相当する取り組みはDSIということになるでしょうか。
いずれにしても運用管理における標準化の試みは既に始まっているので、
それらの動向は常に意識しておく必要がありそうです。
当たり前のことではありますが、アプリケーションを開発する立場としてはロギング
や設定ファイルなどは独自実装を避け、開発言語もしくは開発プラットフォームで
標準的に用意された手段を用い、尚且ついつでも取り替えが可能なようにしておくことが
これらの動きに対する大切な備えだということかと思います。
とは言っても、ロギングや設定ファイルはどうしても後回しになってしまって
実装がいい加減になってしまいがちです。機能要件だけではなく、これらの
仕組みも設計段階できちんと整理して織り込んでおくことが大切ですね。
