ディザスタ・リカバリの迷路を解く

複雑な状況の中、自社にとってのベスト・プランにたどり着くためには

（2008年01月08日）

災害時でもビジネスを継続するためには、ディザスタ・リカバリ（災害復旧）として、バックアップ・サイトの構築が不可欠である。特に近年、企業はITシステムの停止による甚大な損失を目の当たりにして、ディザスタ・リカバリを重く受け止めるようになってきた。しかし、サーバ仮想化に代表される新技術が、企業のIT環境を効率化する一方で、システムの複雑化を招いている側面もある。そのため、自社に合ったディザスタ・リカバリ体制を整えることは容易ではないのが現状である。本稿では、実際に企業がどのようにディザスタ・リカバリを講じているのか、実例を交えて解説する。

Gary Anthes
Computerworld米国版

複雑さをきわめる今日のディザスタ・リカバリ計画

　昔はよかった。ITマネジャーにとってディザスタ・リカバリ（災害復旧）計画の立案は、さほど難しい仕事ではなかったからだ。毎晩、あるいは週末ごとに、メインフレームのデータをテープ・ストレージへバックアップすれば済んでいた。

　几帳面な性格なら、テープをオフサイトへ移したり、不測の事態を想定して別のデータセンターを立ち上げたりしたかもしれないが、それで十分だった。ディザスタ・リカバリ・テストを実施するにしても、テープを取り寄せ、データを正確に読み取れるかどうかをチェックするだけであった。

　しかし、コンピュータの分散化やネットワーク化、異なるハードウェア・システムの混在、さまざまなOSの利用、仮想化技術の導入など、ITシステムを取り巻く環境はここ数年で複雑さを増している。そのため、現在、ディザスタ・リカバリ計画を立案・テストすることは、さまざまな要素が絡み合い、非常に困難である。IT管理者が毎晩安心してベットに向かうことは、ほとんど不可能になりつつある。

　こうした状況に対応するため、さまざまな方法を企業は模索するようになった。例えば、一部の企業では、緊急時にCPUリソースをすばやく移転できるディザスタ・リカバリ・ホット・サイトの運営を外部パートナーに委託している。しかし、最近では、リカバリ・サイトの外部委託を止め、社内で対応するべきだと考える企業が増加してきている。

　マサチューセッツ工科大学（MIT）のCIO、ジェリー・グロチョウ（Jerry Grochow）氏は、ディザスタ・リカバリの問題点を次のように説明する。「あるアプリケーションを利用するために必要な機器の数を調べてみると、10台以上もあった。しかし、そういったことは別に珍しくもない。SAPアプリケーションのプログラマーに、『復旧するにはどのマシンが必要か』と聞いても、おそらく明確な答えは返ってこないだろう。なぜなら、認証サーバが稼働しなければ、ユーザーはログオンさえできないという事実をプログラマーは知らないし、そのサーバが別のデータセンターにあることも知らないからだ」

　もはや企業のIT資産は、IT部門でコントロールしきれなくなってきた。Grochow氏は以前、証券会社に勤めていたが、その会社では外部の契約業者40社からさまざまなデータが自動的に送られてきていた。金融機関などではこのような外部機関との接続が100件を超えるところもある。「自動的に送られてくるデータが複雑に絡み合っている場合、どのようにデータ処理アプリケーションをリカバリすればよいというのか」と、同氏はシステムの高度化がもたらすディザスタ・リカバリの難しさを指摘している。

システムが高度化しアウトソーシングが困難に

　ウィスコンシン州グリーンベイのトラック輸送会社、Schneider Nationalは、以前、ディザスタ・リカバリ・ホット・サイトを提供するサービス・プロバイダーと契約していた。しかし、最近、自社で2つ目となるデータセンターをディザスタ・リカバリ・サイトとして構築した。

　Schneiderの技術サービス担当バイスプレジデントであるポール・ミューラー（Paul Mueller）氏は、「システムが複雑になればなるほど、プロバイダーが提供するホット・サイトでの復旧は困難になる」と語る。

　Schneiderが運用していたシステム環境をアウトソーシングにより再現することは難しく、そのため同社が実施していた半期ごとのディザスタ・リカバリ・テストでは、必ずしも満足のいく結果を得られなかったという。「テストを実施すると、テープが修正されていないといった問題が毎回発生した。リストアできるかどうかは、ハードウェアやOSの構成などに常に左右された」とMueller氏は語る。

　Mueller氏によれば、新しいデータセンターの構築には莫大なコストを費やしたが、その分満足のいく施設を構築できたという。2カ所のデータセンターは、冗長化された光ファイバ回線や電話システムで結ばれ、メインフレームの相互バックアップが行われる。「われわれは、顧客をサポートするサプライチェーンや当社のIT環境に対し、リスクを勘案して大規模な投資を決断したが、その方向性に間違いはなかった」（Mueller氏）

　Schneiderの投資はデータセンターの構築だけにとどまらず、コンサルタントの助けを借りて、70人のマネジャーと一部の有力顧客にインタビューを行った。それにより、システム停止を引き起こす条件や時間ごとの推定損失額、各マネジャーが目指すリカバリ・タイムを把握することができたという。

　「それらをアセスメント文書にまとめ、データセンターがダウンしたときのダメージがどれほどの規模かを示せれば、非常に説得力を持った情報となる」とMueller氏は述べている。

　アリゾナ州テンペのSonora Quest LaboratoriesのCIO、ボブ・ドウド（Bob Dowd）氏は、ディザスタ・リカバリとして完全に冗長化したホット・サイトを構築する余裕はないが、災害回避のための対策はいくつか講じていると語る。同社は、夜間に患者2万人の医療検査を行い、翌朝、医師へ検査結果を届けている。このような高度に自動化されたプロセスにおいて、長時間にわたってシステムが停止すれば、ビジネスに甚大な被害が出ることは容易に想像できる。

　「われわれはコンピュータ・ルームを強化し、可能な限り冗長性を高めた。たとえ1つのノードがダウンしても、瞬時に別のノードがフェールオーバする」とDowd氏。テンペのデータセンターは、冗長ディスクと2つのネットワーク・コアを持ち、単一障害点がない。加えて、1日2回のバックアップを実行し、1回目はサーバへ、2回目はテープに格納してオフサイトへ送っている。

　それでもDowd氏は、データセンターがフェニックス空港の滑走路の突端近くに立地することを懸念している。しなしながら同氏は、安全性を確保しつつ、安価な方法でリモート・サイトへのバックアップを実現する手法を考案している。

　テンペでは、研究用システムのテスト環境にデータセンターの一部を割り当てているが、実質的にそれは本番環境をスケール・ダウンした環境と同じである。それをアリゾナ州ツーソンのラボに移動すれば、テンペのバックアップ・サイトとして利用することが可能になるという。「あくまで事業を支援するバックアップ・サイトという位置づけであるため、必ずしも頻繁にアップグレードする必要はない」とDowd氏は説明している。