運用手順の見える化

　次のステップで実施したのが、システム運用手順の見える化だ。従来は運用管理業務の手順やノウハウの多くが属人化していたため、まずはそれらをマニュアル化することから始めた。また、問題が発生した際にいつ誰がどのように対処したかをきちんと記録し、後々手間取らない体制作りも必要だ。これらの実現のために、同社ではITILを導入することにした。

　ITILを採用するからといって、いきなりITIL対応のツールを導入したわけではない。まずは運用管理プロセスの文書化を行い、ルールを決め、それに従った作業をきちんと行うことを徹底したのだ。

　「現場には、それまでドキュメントを書く文化があまりありませんでした。まずはこれを解消し、たとえ時間がかかってもいいから業務プロセスの文書化を行い、そこで定められたルールにきちんと従って作業を行うことを周知徹底しました」（平山氏）

　作業を行う際には申請を行い、作業実施の前に申請内容をみんなでレビューする。それまでは隣の人がどんな作業をしているのかさえ把握できない状況だったが、マニュアル化とレビューのプロセスで属人化を廃し、業務の見える化を実現した。

　さらに、見える化を行って運用管理プロセスを明確に定義できたことで、ITインフラの運用業務をある程度アウトソーシングできるようにもなった。これにより、自社内でのシステム運用からデータセンターへの移行も視野に入れることが可能になった。

ディザスタリカバリの前にやるべきこと

　一連のITインフラ整備を行うに当たり、事業継続性の確保は当初から想定していた。とはいえ、当初の混沌としたITインフラに対し、単に遠隔地バックアップ体制などの災害対策だけを施しても、いざ本当の災害が発生した際にうまくビジネスが継続できる状況にはならないと平山氏は考えた。真の事業継続性を確保するには、一足飛びに目的を達成しようとするのではなく、ステップを順次踏んで対応していく必要があると考えたという。

　まずは、2005年8月からネットワークの冗長化に着手。同年10月からはシングルベンダー・シングルプラットフォームへの移行を開始した。こうしてシンプル化した新たなITシステムを、2006年5月から10月にかけて自社内運用から他社運営の都内データセンターへ移行、順次稼働を開始した。それと並行して、2006年8月からはITILの導入を始め、2007年2月からはインシデント管理および問題・変更管理、2008年7月からはキャパシティー管理と可用性管理の試行を始めた。

ストレージ間コピーによるデータ同期

　データセンターでのITインフラの運用管理がある程度安定化した2007年12月から、ようやくディザスタリカバリの要件検討を始めた。ディザスタリカバリ実現には、さまざまな方法がある。例えば、プライマリサイトでバックアップを取り、それを待機系の遠隔地サイトに送る方法などがある。しかしこうした方法では、いざシステムを復旧する際にそれなりの時間と手間が掛かってしまう。また、マスターデータの更新を待機系に反映させる手間も大きい。

　検討を重ねた結果、遠隔地のサイト間でストレージレベルでのデータ同期を取る方法を採用することにした。この方法であればデータ複製を自動化でき、日常的な運用管理の手間を抑えることができる。

　同社の本番系ローカルサイトでは、ホットスタンバイで冗長化された50台のサーバが稼働している。一方、関西のデータセンターにある待機系リモートサイトは一部の冗長構成以外はシングルサーバ構成とし、ローカルサイトの半分の台数のサーバが稼働している。これらサーバ群に対し、ローカル／リモートサイトで用意されたストレージが、筐体間コピー機能を持った「HP StorageWorks XP20000」（以下、XP20000）だ。

　XP20000を選択した理由は、高レベルでのデータ同期性能やストレージ仮想化機能を利用できる拡張性だった。また、これらの機能を利用する際に運用管理の手間が掛からないことも高く評価した。

　ストレージ容量はローカルサイト側で15Tバイト、リモートサイト側で20Tバイトを確保した。リモートサイト側の容量が大きいのは、将来的にテープによるバックアップを廃し、ディスク内にバックアップすることを想定しているためだ。XP20000のジャーナル方式データコピー機能により、更新データをジャーナル領域にいったん保存してからリモートサイトにコピーする。転送データを平準化できるため、比較的回線帯域が狭くても効率的なデータ複製が可能であり、回線コストも節約できるという。

図1　ノード配置イメージ《クリックで拡大》

　ディザスタリカバリ対策を施した前後で、運用管理コストは従来の1.5倍程度に増加した。XP20000は高性能で信頼性が高いストレージ装置だが、それなりに大きな投資も必要だったのだ。一方で、それまで実施してきたITインフラのシンプル化の効果で、従来のやり方の無駄な部分も明らかになり、その部分の運用コスト削減が別途実現できたという。

　「問題が起きたときのリスクの大きさを想定すれば、高価でも必要なものは導入すべきだという判断になります。ただし、それを決定するのは経営者の仕事です。われわれIT担当者は、導入のメリットとリスク、そしてコストを明らかにして、経営者に判断してもらう材料をきちんと提供する必要があります」（平山氏）

SaaSは究極の災害対策になる

　さらに効率的なディザスタリカバリ実現のために、将来的にはSaaS（Software as a Service）の活用も考えていると平山氏は言う。ITインフラ整備とは別のプロジェクトでコールセンターシステムのリニューアルを行った際、同社はセールスフォース・ドットコムのサービスを導入した。その際、システムの機能をいち早くユーザーに提供したい場合には、SaaSは極めて有効な手法であることを実感したという。また同時に、自前でシステムを持たないことのメリットも大きいと感じた。

　仮に仮想化などの技術を採用してITインフラの運用をある程度自動化・効率化できたとしても、OSやデータベースにパッチを当てるといったメンテナンスの手間はなくならない。これを解消するにはSaaSのような、ITシステムを自社で運用することなく、サービスを受け取るだけの環境に移行すればいい。「ハードウェアの保有から、サービスの利用へ」。この方法は、ある意味では究極の災害対策であるといえよう。

　現時点では、あらゆるシステムをすぐSaaSに移行するのは早計かもしれない。しかし、IT要員のリソースを十分に確保できない中堅・中小規模の企業であれば、災害対策の面からもSaaSの採用を検討する価値があるだろう。

理想像に向け、一歩ずつ進めていく

　災害対策は必要だと認識していてもなかなか踏み出せない人は、今までやってきたことを一度全部捨てて、まずはディザスタリカバリを前提とした理想のシステム像を描いてみるといいだろうと平山氏はアドバイスする。既存のシステムの仕組みを前提にしてしまうと、もともとがディザスタリカバリを考慮していないものなので、さまざまな弊害や作業上の困難が先に見えてしまうのだ。

　「まずは理想の姿を絵にしてみて、そこへたどり着くにはどうすればいいかを考えます。もちろん、すぐに理想像に行き着くことはできないので、段階を踏んで何から始めればいいかを考えればいいでしょう」（平山氏）

　同社のケースでは、将来的なディザスタリカバリ環境構築を思い描きつつも、初めの一歩としてベンダーを統一し、システムを整理することから始めた。着実に、段階を踏んで、一歩ずつ着実に理想のシステム像に近づいていくことが成功の鍵だといえよう。

　その過程で、当初予想しなかった新たな問題も出てくるかもしれない。そうしたときに備え、共に前向きに対処できるような信頼できるパートナーと協力関係を築いておくことも、事業継続という大きな目標を実現する上では重要になるだろうと平山氏は指摘する。