現場の視点で見る災害対策（2）：DRサイトの実現方式と設計上のポイント：ディザスタリカバリで強い企業を作る（4/5 ページ）

[小川晋平，ITmedia]

DRサイトの縮退設計

●縮退系サイジング用負荷テスト

　Active-Standby構成の場合、通常時はDRサイト側のシステムは利用しない。したがって、DRサイトとプライマリサイトのシステムが必ずしも同じハードウェアスペックである必要はない。プライマリサイトが被災した際には、サービススペックが落ちることを許容する空気ができていると想定できるからだ。そのため、企業の社内向けシステムであれば、DRサイト側では縮退したシステム構成をとることが一般的である。

　もちろん、社外向けのサービスの場合は話が別だ。可用性を低下させることがあってもレスポンスが悪くなるほど縮退させるわけにはいかない。したがって、サービスの特性に基づいて縮退構成を考える必要がある。

　しばしば実施される縮退の手段としては、

ハードウェア台数の削減

ハードウェアスペックの低下

機能の限定

がある。このうちどれを選択するか考える際に最初に行うべきことは、災害時に低下するサービススペックの定義である。「ユーザーのレスポンスタイムは2倍になってもよい」「想定する同時アクセス数を6割で見積もってよい」「プライマリサイトの可用性は99.9％だがDRサイトは95％でよい」「20種類ある提供機能のうち、災害時は主要なもの5つに限定する」といった具合だ。

図4●DRサイトにおける縮退サービスの考え方

　これらの指標を明確にした上で、まず机上でDRサイトにおける縮退系サイジングを行う。その上でテスト環境を構築し、チューニングや台数の増減を行いながら負荷テストを複数回実施する。この結果を受けて縮退系の設計を見直し、サービスレベルとの整合性を図るといった作業が必要になる。

　ここにも注意が必要なポイントがある。机上でシステム縮退のサイジングを行い、サービスレベルを落としていくと、どんどんシステムが貧弱になっていく。机上の計算だけでは、有事の際には動かないシステムができてしまう可能性がある。しかし、有事の際に動かないシステムにはそもそも意味がない。縮退によって浮くコストがあるならば、負荷テストくらいはできるであろう。この手間だけは絶対に惜しむべきではない。

●縮退時の工夫

• スナップショットボリュームのGB単価低減

　DRサイト側のストレージでスナップショットを取るという実装は多い。このスナップショット領域だが、高いパフォーマンスや信頼性が求められるプライマリボリュームと同じGB（ギガバイト）単価のディスクを使う必要性はなく、単価の低減が可能である。同時にILMの実装を考えることで、GB単価を下げる工夫を加えるべきだ。

• 空メールボックスでの復旧の有用性

　電子メールシステムを復旧する場合を考えてみよう。プライマリサイト側で提供しているメールボックスを完全に復旧させる必要はあるだろうか？　電子メールの場合、迅速な復旧が求められる（＝RTOは短時間）一方で、比較的長いRPOが許容されると思われる。

　メールサーバにメールを残さない設定とし、クライアントPCにPOP3で取り込んでいる構成を考えてみよう。仮に災害が発生したとしても、メールというサービスの復旧を最優先するのであれば、メールボックスが空の状態で簡単に復旧させることができる。メールそのもののデータがどうしても必要ならば、例えば1日に1回メールボックスをバックアップし、そのテープを外部の保管業者に送る仕組みとしていれば、時間は掛かるものの災害発生1日前までのデータを後から復旧させることができる。

　このように一種の「割り切り」を行うことで、レプリケーションを行う必要がなくなり、WAN回線の使用帯域やレプリケーション用の設備コストを大幅に削減することができるというわけだ。

　筆者個人の印象では、「1人当たりのメールの流量が多い顧客はレプリケーションを求める」「1人当たりのメールの流量が少ない顧客は空メールボックスの復旧を望む」傾向にある。このあたりは、皆さんの会社や団体の実情に合わせて方式を決定してほしい。