サーバーを統合しようとする企業が増えている。2000年問題を機に多くの企業がシステムを抜本的に見直して約5年。「2003年あたりから徐々にサーバー統合を実施する企業が登場し始め，ここに来て本格化している」（あるサーバー・メーカー）。多数のサーバーが散在し，予想を超える運用管理コストの増加につながった。この問題を解決するために，ハードウエアのリプレースに合わせ，多数のサーバーをまとめていく。これが，このところのサーバー統合の流れだ。
2000年当時と比較して，ハードウエアの性能は飛躍的に向上している。複数のサーバーを一つにまとめる能力は持っている。「仮にサーバーの統合をしなくても，サーバー機をリプレースするだけでも効果を見込める」（あるサーバー・メーカー）。ハードウエアをリースで調達しているような場合など，価格性能比の大幅な向上により運用コストを圧縮しつつ，サービス・レベルも高められる。これに統合することによるメリットを加えれば，サーバー統合に目が集まるのも当然だ。
ところがサーバーの進化は，必ずしも性能の向上などのメリットだけを提供するわけではない。稼働するOSやミドルウエア，ひいては業務アプリケーションに影響を与え，これがサーバー統合を難しくする。特に，中期的な計画に基づいてシステムを構築していこうとする場面で，それは色濃く表れる。そうした例をいくつか見てみよう。
「今のRDBMSが使えなくなるかも・・・」
釣具店のフランチャイズ・チェーンを運営するA社は，これから既存システムの改修を行う計画だ。POSデータをリアルタイムに送受信することで，頻繁に動く商品の流れを正確につかむのが目的だ。A社では，店内のキオスク端末でチェーン店全ての在庫を検索できるシステムを導入している。主な商品についてはユーザーが自分で在庫を確認できる。このシステムを有効に活用するためには，商品の動きをリアルタイムに追跡する必要がある。
基本的には処理性能の高いサーバー機の導入や，WAN回線の見直しにより，トランザクションやトラフィックの増大に対処していくことになると考えているが，問題はRDBMSだ。主としてシステム基盤，それも企業インフラに近い部分の増強で対応するつもりだが，データベースまでは踏み込みたくない。
現在はOracle 8i Databaseを利用しており，A社のシステム部門では「イントラネットでの利用に限られるので，バージョンアップするつもりはない」という。バージョンアップのメリットを今のところはあまり感じていないからだ。ところが，システム見直しの相談を受けているベンダーは「Oracle 8iとなると，OSもハードウエアも新しいサーバー機で動作するかどうか，確信が持てない。この点は頭が痛い」と懸念している。
「せっかく作った標準仕様が無効になる」
B社は，データベース・サーバーの統合を進めている。同社では，業務の必要に合わせてシステム化を果たしてきた関係で，大きく6種類のシステムを並立させている。それぞれが，Webサーバー，アプリケーション・サーバー，データベース・サーバーを持つ3層構造のシステムである。いずれもデータベース・サーバーを冗長化しており，「各システムで“眠っている”バックアップ機に目をつぶっていられなくなった」（B社のシステム担当者）。そこで，DBサーバーの統合に着手した。
向こう3年間の中期計画として，まずは6システムのうち半数のDBサーバーを統合する。DBサーバーを共有することにより，DBサーバーを標準化できた。アプリケーションはこの標準仕様に則ってDBサーバーと接続する。これが，今後，アプリケーションを標準化していくための基礎となる。
ただし，B社のシステム担当者は社内システムの標準化に着手できた達成感とともに，心配も口にする。「次のDBサーバー統合のときに，今のサーバー機は代替わりしている可能性が高い。そのとき，今のOSのまま統合はできないかもしれない」。OSが変われば，DBサーバーもアプリケーションも標準仕様に手を加えざるを得ない。せっかく作った標準仕様をまた作り直さなければならないかもしれない。同社としての標準仕様とロードマップは描けたが，期待するほどには有効に働かない可能性があることも分かってしまったのだ。
「同じハードウエアを供給してくれると保証してくれた」
C社は，全国に展開する各拠点にホスト・コンピュータを配置してきた。1990年代初頭からシステム化に取り組んできたため，その経緯からなかなか抜け出せなかった。ところがここに来て，さらに拠点を拡大していく計画が持ち上がり，「つぎはぎだらけで拡張の余地がなくなったホストは捨てて，オープン化せざるを得ないと判断した」（C社のシステム部長）。
各拠点に分散していた業務システムをデータ・センターに集約し，ブレード・サーバーに統合した。拠点間で業務の差がほとんどなく，処理量が異なるだけということから，最初の設計時にそれぞれの拠点がどれだけのブレードを必要とするかは読みやすい。しかも，その設計を今後の新拠点にもそのまま利用できる。このことから，増設が容易なブレード・サーバーの導入に踏み切った。
しかし，これだけならば“よく言われるブレード・サーバーの利点”に過ぎない。同社がブレードに踏み切ったのには，もう一つ大きな理由があった。それは「サーバー・メーカーが今後3年間程度ならば，同一仕様，同一アーキテクチャのハードウエアを供給してくれると，内々にではあるが約束してくれたから」（C社のシステム構築を担当したベンダー）である。
サーバー仕様が変わっては，当初の設計が通用しなくなる。メーカーが公式に「何年間，同じサーバーを供給し続ける」と具体的に宣言する例はほとんどない。そこに非公式ながら「今後3年は大丈夫」という保証が得られた。もしかすると，ブレード・サーバーそのものを評価したというよりもむしろ，同じハードウエアの供給を保証されたのがブレード・サーバーだった，という側面の方が強いのかもしれない。
サーバー統合には計画性が必要とはいうものの・・・
CPUはもちろん，チップセットも次々と新しいアーキテクチャに則った製品が登場してくる。当然，サーバー・メーカーは新しいハードウエアへの対応を進めていく。進化したハードウエアが計画的なIT投資，基盤整備の邪魔をする。もちろん，技術の進歩を否定するつもりはない。どこまでも進化し続けてほしい。しかし，あらゆる場面で誰もが進化を享受できるとは限らない。進化することが時として邪魔になることがあるのも現実だ。
では，そんなことは気にせずに，そのときそのときで必要な統合を手がければいいじゃないか，とも思えるかもしれない。しかし現実には「サーバーが増えるペースの方が早過ぎて，安易な統合計画では結果として台数は増えているという事態になりかねない」（あるサーバー・メーカー）。採用されるアーキテクチャが増えるほど，運用コストは上がっていく。それだけに，システム基盤であるハードウエアの整備は全社的に，計画的に進める方が統合の効果は期待できる。それゆえ，じっくりと時間をかけて進めざるを得ない。すると，技術の進歩がその計画を邪魔をする。
この矛盾は構造的に避けられない性格のもの。うまい解決策は簡単には見つからないかもしれない。筆者自身も，申し訳ないが今のところは「こうすればいいと思います」と言えるような案を持つには至っていない。今後，2007年問題が目前に控えており，ハードウエアの刷新まで踏み込まざるを得ないケースは増えていくだろう。こうした矛盾を解決するうまい方法をなるべく早い段階で見つけ，地道にレポートしていきたい・・・。と，500MHzのPentium IIIのPCで調べものをしつつ，もう新しいソフトウエアも見かけなくなったMac OS 8.6でこの原稿を書きながら，そんなことを考えている。
