現場の視点で見る災害対策（3）：WAN回線の設計とリハーサル：ディザスタリカバリで強い企業を作る（4/4 ページ）

[小川晋平，ITmedia]

●最悪のケースから想定する

　リハーサルの際にはいくつかの災害ケースを想定することになる。このとき注意すべきは「最悪のシナリオから考えるべき」ということだ。というのも往々にして、実際の災害時は、想定していないようなケースこそ起こるものだからだ。

　例えば、フェイルオーバーの意思決定を行う人を定義し、さらにエスカレーション順位を3位まで決めていたとしよう。しかしリハーサルに当たっては、災害発生後、DRサイト側からその3名ともに連絡がつかない、という事態を想定して訓練を行うべきだ。

　このような場合の解決策としては、どんな可能性が考えられるだろうか？　例えば、「DRサイト側で持つチェックリストを元に、あるしきい値を超えた場合には自動的にフェイルオーバーを行う」といった取り決めをあらかじめ行っておくのも1つの手だ。逆に、フェイルオーバー意思決定者に連絡がつくまで、とにかくDRサイト側は「待つ」という方法もある。そのどちらか、あるいは別の方法かも含め、自社ではどのように意志決定するのかを決定する必要がある。

　いずれにしても、意思決定者に連絡がつくという「想定内の事態」だけでリハーサルしていても効果は薄い。まず「誰にも連絡がつかない」という最悪のケースから訓練を始め、それよりもましなケースを順に考えていくという方向でリハーサルを実施すると効果的である。

●リハーサルのための人員配置は行わない

　災害の際、DRサイト側でフェイルオーバー作業を行える人員はどのくらいいるだろう？　これは、実際に運用上集まってこられるメンバーであり、その人数にはおのずと上限があるはずだ。リハーサルのとおりに段取りよく集まる可能性のほうが低いと考えるべきだろう。

　例えば、東京で災害が起こった場合、フェイルオーバー時に大阪側のDRサイトに集まることができるのは、普段から大阪にいるSEである。したがって、リハーサルを行うからといって、東京のSEを何人かわざわざ応援で大阪に呼び、リハーサル時間を短縮しても意味がない。リハーサルのためのリハーサルに終わるだけだ。

　この場合、大阪側のSEが足りなくてRTOを満たせないのであれば、RTOの設定を見直すか、より多くのSEを配置する、あるいはうまくアウトソーシングを活用するといった対策をとる必要がある。

●外向けのサービスまで停止しない

　リハーサルの実施は、自社内にはアナウンスできても、取引先などの他社にまでアナウンスをすることは難しい。不特定多数のユーザー向けに提供しているサービスについてはさらに困難だ。

　停止すべきでない代表的なサービスとしては、電子メールと外部に公開しているWebシステムが挙げられる。電子メールについては、インターネット側から自社に配送されたメールはインターネットゲートウェイで受信し、そこから不達エラーを発生させないようにメールサーバの設定を変更し、queueに溜めておく。

　外部に公開しているWebシステムについては、もともとアウトソーシングしている企業が多いため問題になることは少ないだろう。しかし、もしプライマリサイト内でWebサーバを自力で設置、運用している場合は、インターネットコネクティビティは生かしたまま、http/httpsのみプライマリサイトで提供するといった工夫が必要だ。

●フェイルオーバーテスト後の確認

　フェイルオーバーに関するテストを行った後には、DRサイト側にきちんとサービスが移行し、提供できているかどうか確認する必要がある。DRサイト内での稼働確認は当然だが、その他の拠点からも同様に、サービスが提供されているか確認をする必要がある。

　このときの確認拠点としては、本社などの大規模な拠点とレイヤ3以下の構成が異なる代表的な拠点を選定すべきだ。例えば、WAN回線品目の異なる拠点、DRサイトと異なるDHCPサーバを利用している拠点などがその例である。

●通常時のDRサイト運用／監視訓練

　プライマリサイトが通常稼働するのはすばらしいことだが、こうした平常時、DRサイト側で何の作業も行わないと、オペレータの運用の勘所が損なわれる。そのため、通常時からDRサイト側からプライマリサイトのサーバを監視し、アラートが上がった場合はどういう手順書にひも付いて対応するのかということを訓練しておくとよい。

　DRサイト側からプライマリサイトを監視することによって、平常時のサービスレベルの向上が期待できるほか、有事の際には、大量のアラートがDRサイト側で上がり、「何か普段とは違うこと」が起こっていると分かる。これこそが、フェイルオーバーの意思決定に至るプロセス開始のトリガーになる。

●運用定例会の重要性

　プライマリサイト側でシステムの運用改善を行い、手順書の見直しや設定変更によるシステムバックアップをとった場合には、DRサイトでもその情報を捕捉し、対応する必要がある。そのため、運用定例会などを開き、常日ごろからプライマリサイト側の運用者とDRサイト側の運用者が情報を共有しておくことが非常に重要だ。

●トリアージの見直し

　実際にリハーサルを行ってみると、優先度の高いシステムと優先度の低いシステムの差がはっきりと分かる。本来、災害対策の対象となるシステムは優先度が高いものであるはずだが、実際にリハーサルを行い、限定してサービスを立ち上げてみると、「このシステムのほうがもっと重要だ」「こちらはそれほど重要でもない」といった要望が明確に見えてくる。

　いったんは優先度が低いとして災害対策対象から外したシステムであっても、リハーサルを通じて対象範囲を見直したり、逆に対象から外すといったことは十分にあり得る。このあたりは自社のニーズに基づいて柔軟に対応したい。