ここ数年に限っても、大規模な災害や事故が世界中で発生しており、罹災した企業が莫大な損害を被ることもしばしばだ。このような災害等の原因でシステムがダウンした際には、一刻も早く事業を再開させないと、ライン停止による直接的な被害のみならず、ライバル企業に取引先を奪われてしまう可能性すらある。そこで注目を集めるようになったのが、事業継続計画(BCP)や災害復旧(DR)だ。しかし、回線トラブルなど一時的な現象からも、迅速なビジネス再開が求められる。
東京に本社を置く半導体メーカーのP社は、災害や事故によって基幹システムがダメージを受けることで、企業活動がストップしてしまうリスクを懸念していた。そこで同社では、災害発生時に短時間で事業を再開させるため、基幹システムにリモート・レプリケーションツールを導入している。これは、本社のプライマリサイトと遠隔地に設置した災害対策サイトをネットワーク(WAN)でつなぎ、常にデータの同期を取るものだ。しかし販売管理、生産管理、在庫管理、CRM等の業務アプリケーションは、OSやハードウェア、導入時期などがすべて異なるため、レプリケーションも別々に行わざるを得なかった。
ほとんどの場合、業務アプリケーションは単独で運用されることはなく、各データ間には必ず相関関係が存在する。仮に販売管理システムが先にダウンし、後から在庫管理システムが停止したとすると、レプリケーションデータにはタイムラグが生じてしまう。つまりP社の現在のシステムでは、せっかくリモートサイト側で事業を再開したとしても、出庫履歴が残っているのに売上が計上されていない、といったトラブルが起こり得るのだ。正しいデータを判断し、整合性をもって迅速にシステム再開するのは至難の業だ。
このように、業務アプリケーションの再開に際しては、同期の取れたすべてのデータが揃っている必要がある。複数のシステムが情報を共有する環境において、データの整合性をいかに保つかがP社のクリアすべき課題であった。

P社はまず、レプリケーションの手段を見直すことにした。今はアプリケーションごとバラバラに取得しているレプリケーションポイントを、すべて同じタイミングで取得するようにすれば、データの整合性を保つことができる。そこで、ストレージベースのレプリケーションツールをいくつか検討した結果、EMCが提供しているハイエンドストレージと災害対策ソフトウェア、そしてそのオプション機能「コンシステンシー・グループ」を利用することにした。
災害対策ソフトウェアは、アプリケーションに及ぼす影響を最小限に抑えながら、本番サイトのデータを災害対策サイトに複製する。これにより、RPO(復旧時点)とRTO(復旧時間)を短縮し、システム停止後わずか数分で業務データを復旧させることが可能だ。そしてこの「コンシステンシー・グループ」機能を追加すれば、複数のシステムやアプリケーション間のデータでも常に整合性が取れたデータを取得できるので、本番用サイトと災害対策サイトの間でレプリケーションの整合性が保証されるのだ。
P社では、それぞれ稼動している販売管理、生産管理、在庫管理、CRM等の業務アプリケーション用ストレージに、上記のレプリケーションツールと「コンシステンシー・グループ」機能を導入し、相互に依存性のあるアプリケーションデータの整合性を取ることにした。ここで仮に販売管理システムをストレージA、生産管理システムをストレージB、在庫管理システムをストレージCとすると、レプリケーションツールがA、B、Cそれぞれの整合性を取るように「コンシステンシー・グループ」を作って災害対策サイトのストレージに書き込む。もし、各アプリケーション間のリンクに障害が発生したとき、すなわちコンシステンシー・グループ内のデータが1つでも災害対策サイトに届かないと、グループすべてのリモート・レプリケーションが中断される。これにより災害対策サイトには常に整合性の取れたデータが残るというわけだ。
こうしてP社は整合性が取れたレプリケーションデータの取得が可能となり、迅速なビジネス再開と事業継続性をより確実なものにしたのである。
