2005年から約3年がかりでサーバの仮想化・統合化を推進されたユーザ企業様（仮にA社と呼びます）の事例を紹介します。
A社では1990年代まで、メインフレームを中心にシステムを構築・運用し、その後ERP導入によりメインフレームを廃止しました。メインフレーム利用当時から、周辺システムでは、UNIXワークステーションやWindowsサーバによるダウンサイジングが進んでいましたが、基幹システムの移行を契機に、急激にサーバ台数が増加しました。1台のサーバに数システムを同居させるよりも、別のサーバで稼働させたほうが既存システムへの影響がなく安全であり、またハードウェアが安価になってきたことも、サーバ台数増加に拍車をかけたと言えるでしょう。2000年には100台程度だったサーバは、2005年には500台余りに達しました。
サーバ台数は増えても、ハードウェアも含めた新規システム構築への投資額はさほど増加しませんでした。しかし、A社情報子会社に委託しているシステム運用の費用は、サーバ台数に比例する形で増加の一途をたどりました。個別最適なシステムの乱立、異なるアーキテクチャの採用、サーバ間連携の複雑化によって、運用管理が非常に煩雑で非効率になっていたのです。このままではシステム化予算のほとんどを運用費に費やしてしまう恐れがありました。  |  | 図 １ サーバ台数の推移 | 図 ２ 費用の推移 |
2005年、A社情報システム部門は、システム化予算をもっと戦略的IT投資に向けるため、全国の拠点に分散してしまったサーバを統合し、リソース使用効率や運用効率を大幅に改善するプロジェクトに着手しました。
サーバ統合にあたって、まずフェーズ１として、IT資産の棚卸から始めました。ハードウェア・OS・ミドルウェア、ライセンス・保守契約、運用情報など全部で70項目の情報を整理。
2006年、フェーズ2として統合化技術の調査を行い、当時やりたかったことを実現できていた、ひとつの仮想化製品に絞りこみました。可用性向上のしくみ、バックアップ統合のしくみがサービス機能として用意されており、新たに作りこむ必要がないこと、多種OSがサポートされており、特にWindowsNTの延命が可能なこと、などが採用の理由です。
仮想化技術の採用に対し、2つの反対意見がありました。ひとつは「新規技術の導入はリスクが高い。」というもの。これに対しては「仮想化はメインフレームでも実績のある技術であり、それをIAサーバで実現したもの。技術的には十分な実績がある。」として説得しました。
もうひとつの反対意見は「仮想環境を正式にサポートしないパッケージソフトがほとんどなので、結局仮想化統合できないのではないか。」というもの。これに対しては、仮想サーバに移行する予定のパッケージソフトすべての動作検証を行い、問題があれば個別に対策することにしました。
続くフェーズ3で、仮想OSの基本機能の検証、ゲストOSの動作検証、性能検証など、A社ノウハウに基づいた47項目の評価を行い、すべてに亘って問題ないことが確認できました。上記のパッケージソフトの動作確認も、全く問題ありませんでした。
また、同フェーズにおいて、サーバ統合に関する以下5つの標準化方針ドキュメントを作成しました。 表 １ 作成したドキュメント一覧
 これらの方針策定を通じてサーバ統合の思想を具体化かつ明確化し、A社情報システム部門内だけでなく、A社情報子会社とも共有することができました。そして2007年からフェーズ4として統合の実装作業を開始しました。常時性能維持が必要なERPや、ディスクIOやネットワーク負荷の高いシステムは、大型機やブレードサーバで物理統合。その他システムは、基本的に負荷の変動を許容できると判断し、仮想サーバに移行、または新規システムにリプレースしていきました。
最終的に、2009年度までの3年余りをかけて、500台あった既存サーバを105台まで減らしました。新たに設置した物理統合用のサーバ機20台、仮想用サーバ機45台と合わせて170台となりました。仮想用サーバ機45台の上には、開発機や検証機も含めて560の仮想サーバが稼働しています。 
図 ３ 統合によるサーバ台数の推移
仮想化することによって、物理サーバのハードウェア保守切れに際しても、他の仮想サーバへ簡単にシステム移行でき、途切れなくソフトウェアを継続利用できるようになりました。ソフトウェアを長く使い続けることと、システム更新費用が不要となるため、大幅にコストを削減することができました。もしもサーバを単純に更新した場合にかかる、ハードウェア・ソフトウェア・更新作業のコストを簡単に試算すると、仮想化・統合化することによってコストを3分の1以下に抑えることができたことになります。仮想サーバの構築と運用に関する技術習得やルール作りにかかったコストを差し引いても、2分の1に抑えることができました。
A社情報子会社の運用チームも、仮想サーバが増加しても増員せずに問題なく運用ができ助かっています。仮想化することでサーバ構築の手間がかからなくなったことと、高可用性機能により障害対応が減ったことにより、運用効率が大幅に向上したためです。また、仮想化という新しい技術にチャレンジしたことは、運用技術者のモチベーションアップにもつながっています。
A社情報子会社の開発チームも、サーバ構築の申請から完了までのリードタイムが1～2日と大幅に短縮され、大変喜んでいます。もし、新規にハードウェアを調達するところから始めるとしたら、1～2カ月は必要だったからです。
このように、いいことずくめの仮想化、と言いたいところですが、ちょっとしたミスが重大障害につながることもありました。ホストOSに対して誤った操作をしたため、仮想サーバすべてが再起動してしまうとか、新規サーバ構築中に別の本番稼動中サーバにインストールをしてしまうなどの人的障害です。これまではサーバ1台だけにとどまっていた障害が、統合化された範囲全体に影響するようになり、運用管理者の人的ミスのリスクが高くなっています。
このため、A社情報子会社の運用チームは、作業手順書の見直しや、作業前レビューの徹底、運用チーム内の役割分担の変更など、運用プロセス全体にわたる改善を続けてきました。その結果、1年で人的障害の発生回数は半減し、その後も年々減少しています。また、2007年から本格的に開始したインシデント管理も徐々に定着してきました。障害を、起こしてしまった事故を片づけ反省するという暗いイメージで捉えるのではなく、これまで気付かなかったミスの入り込む余地を見つけ、改善と成長の機会を得られたと前向きに捉えることができるようになりました。
サーバ仮想化・統合化は、2009年度でほぼ計画どおり達成しました。A社では、今後のITインフラの課題として、「ストレージ仮想化によるデータ最適配置」「仮想化による安価な災害対策サイトの構築」「パブリッククラウドの有効活用」「運用管理の自動化」などに取り組んでいく予定です。
*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。 | 
