ITマネジメントレベルの向上

一般的にサーバ統合はコストダウンの手法として語られることもありますが、私たちにとってサーバ統合の重要な目的は事業継続・災害対策でした。
バックアップとリストアを確実に実施できるようにするための手段としてサーバ統合に取り組んだ、当社の事例をご紹介します。

［その1］サーバが60台以上もあった

全社的な事業継続の取り組みがスタートした頃、社内システムのサーバは60台を超えていました。この60台超のサーバは、その時々の異なる考え方で構築されており、OSやミドルウェアの構成だけでなくバックアップの方法もバラバラでした。
稼動する多数の業務システムやアプリケーションは、それぞれ必要とされたタイミングにその都度構築するということを繰り返していたという過去からの経緯がありました。

また、当社は2001年にNEC系販社5社を統合し再スタートしたという生い立ちの中で、短期間に5社バラバラの業務システムを統合しなければならなかった経緯もあり、過去からの混沌を長期間引きずっていました。

［その2］システム復旧方法が統一されていなかった

これらバラバラの社内システムは運用や管理も大変でした。
特に災害対策を考えた場合、60超のサーバのリストアやシステム復旧の方法が異なっていたため、限られたサーバ運用要員が全てのシステムの復旧方法を熟知するのは困難でした。
したがって、大規模な災害が発生したときに本当に社内システムの復旧は可能なのかという不安を抱えていました。

事業継続を支えるサーバ環境を実現するうえで、私たちが検討した時のポイントは二つあります。

災害発生時のシステム復旧に対する要件を明確にすること

システム復旧の要件を明確にすることは重要です。
むやみに高い要件やサービスレベルを目標にすると指数関数的に設備投資に必要な費用が増加します。

まずRPO（目標復旧時点）を何分・何時間・何日にするのかを明確にする必要があります。
システム復旧時には被災直前の状態に復旧したいとなると、距離の離れた複数の場所でシステムを稼動させ、データを常に同期させる等の方法を考えることになります。
これは、高価なハイエンドのストレージ製品によるリアルタイムの遠隔レプリケーション機能やデータベース製品の高価なオプションの導入などが必要になります。

次にRTO（目標復旧時間）を何分・何時間・何日にするのかを明確にする必要があります。
大規模災害が発生してもシステム停止は極力回避したいとなると、RPOを短くするのと同様の方式だけでなく、自動切り替えのための遠隔クラスタや分散処理など、さらに高額なシステムを導入することになります。災害発生時にどれだけの時間のシステム停止が許されるかの検討が必要です。
もちろん、それが必要な業務にはそれに見合うシステムを導入する必要がありますが、合意形成できずに要求がどんどんエスカレーションし、結果、本当に必要かどうか疑わしい最高レベルのシステムを導入するというのは避けるべきです。
システム停止時の事業への影響度により経営判断が必要になる場面です。

技術的に高度になりすぎないこと

技術的に高度になりすぎないことも重要です。要件の明確化はシステムの初期導入費を抑えるために必要ですが、採用する技術の選択は維持・運用費を適正なレベル抑えるために必要な検討事項です。

最先端の高度な技術の導入は技術者にとっては魅力的かもしれませんが、運用にも高度なスキルが必要となりがちです。
運用要員に高いスキルを求めることは教育コストの上昇や人件費の上昇等の問題にもつながり、現実的でなくなる危険性があります。
また、復旧手順が複雑になってしまい、いざというときに復旧できなくなる危険性もあります。

ただし最先端の製品の中にはシンプルに高度な機能が使えるものもありますので、運用性を十分に検討して判断する必要があります。

先に検討した災害発生時のシステム復旧に対する要件を満たすために実施した対策は、以下の二つが柱となっています。
特にサーバ統合は、採用する技術によって、以降の運用の成否を決める重要な対策でした。

データセンターへの設置・集約

まず私たちは、データセンターへのサーバ設置は必須であると判断しました。
耐震設備、防火設備、電源設備が充実したデータセンターにサーバを設置すれば、一般的なオフィスビルにサーバを設置するよりも災害対策のレベルアップを図ることができます。
多少の災害では被災によるダメージをほとんど受けずに済みます。

アプリケーション設計最適化と仮想化によるサーバ統合

サーバ環境を二系統に分割

何度かのアプリケーション設計最適化によるサーバ統合と仮想化技術によるサーバ統合を経て、大きく分けて二系統のサーバ環境を構築しました。

• 基幹系システム用

  OS、ミドルウェアの構成、アプリケーション設計を統一した自社開発アプリケーションを稼動

• 社内ポータル等の 情報系システム用

  VMwareにより、少ない物理サーバで多数の業務システム別の仮想サーバを稼動

基幹系サーバを29台→9台に集約

サーバがたくさんあるということは、被災時のシステムの復旧作業もそれだけ大変ということです。
全てのサーバのシステム復旧手順が整備されていても、災害時に限られた社員しか出社できない状況においては、いつシステム復旧作業が完了できるのか先が見えない話になってしまいます。

まず取り組んだのは、基幹系システムのバックアップやリカバリ方法を統一するためのサーバ統合です。
自社開発アプリケーションで構成される基幹システムにおいては、同じサーバ環境でそれぞれのアプリケーションが動作できるよう、OSやデータベース等のミドルウェアの統一とアプリケーション設計の最適化に取り組みました。
これにより、基幹系システムは29台のサーバを9台に集約し、バックアップ方式も一方式に集約しました。

情報系サーバは仮想化で対応

次に取り組んだのは、既成のパッケージソフトで業務システムを構築している情報系システムのサーバ統合です。
自社開発アプリケーションと違い、既成のパッケージソフトでは前提となる環境は決められているので、自社の都合でOSやミドルウェア等のサーバ環境を変更して統一することは困難です。

情報系システムのサーバ統合を検討していた頃は、仮想化システムの運用機能も充実してきており、本番環境への導入も現実的になっていました。
サーバを仮想化してしまえば、パッケージソフト別にOSもミドルウェアも異なる仮想サーバを一つの物理サーバで稼動させることもできますし、仮想化システムのバックアップ機能を使えばバックアップの方式も統一できます。

これまでの説明のように、今は大きく分けて二系統のサーバ環境を運用しています。
一系統目は基幹系システム用のサーバ環境、二系統目は社内ポータル等の情報系システム用のサーバ環境です。
この二系統のサーバ環境は一つのバックアップストレージを共有しています。

二ヶ所でバックアップデータを保管

バックアップストレージはNEC製のiStorage HSという重複排除による高圧縮機能とレプリケーション機能をもつストレージです。
これは、高圧縮機能とレプリケーション機能の組み合わせにより、少ないネットワーク帯域で遠隔地へのバックアップデータのレプリケーションを可能とする製品です。 ここで重要なのは、災害対策として二ヶ所でバックアップデータの保管を行っている点です。

この仕組みにより、本番サイトの被災によりサーバ環境が全損しても災害発生の1日前の状態に社内システムのデータが復元できるようになり、全社的な事業継続への取り組みの中で決定した目標や要件を実現することができました。

これまでの説明のように、私たちは社内システムの事業継続・災害対策の取り組みを行いました。
また、アプリケーションの動作環境を統一することによるサーバ統合、VMwareによる仮想化サーバ統合を体験してきました。

特に仮想化は災害対策だけでなく、システム開発や運用を楽にする副次的なメリットもたくさん享受しています。以下に一例を挙げます。

• 複数の仮想サーバを丸ごと評価環境に再現させることにより、本番環境とほとんど同じ環境で機能検証や手順検証を行うことが可能
• 突然高負荷になった仮想サーバに、一時的にCPUやメモリを多く割り当てたることが可能

事業継続を含めこれから社内システムを見直す方々には、要件・技術・コストを高度にバランスさせた、自社にとって最適のインフラを手に入れて頂きたいと願っております。
また、お客様へ私たちからも「最適」を提供させていただきたいと考えています。

本コラムに関連するコンサルティングサービス

• ITマネジメントレベル簡易診断
  IT部門が取り組むべき課題を見つけて、マネジメントのレベルアップを支援します。