「実例」に見る意外な落とし穴：ディザスタリカバリで強い企業を作る（3/3 ページ）

[村上智，ITmedia]

●同期／非同期の選択とデータロストのシミュレーション

　ソリューション導入に当たり、まず、データレプリケーションの手法について検討が行われた。

　ローカルサイトのストレージに書き込みが発生した際、書き込みイメージが遠隔サイトのストレージに転送されたことを保障してから「データ書き込み完了」とする同期転送モードと、ローカルサイトのストレージにデータの書き込みが完了した時点で、遠隔サイトへの転送状況にかかわらず「データ書き込み完了」とする非同期転送モードのどちらを選ぶかが焦点となった。

　同期転送の場合、データロストは発生しない。ただし、ネットワーク遅延時間や回線容量が大きな足かせとなる。一方非同期転送は、ネットワーク遅延時間や回線容量に同期転送ほどの考慮を行わなくてよい半面、常にデータロストの可能性を考慮しておく必要がある。

　この事例では、サイト間の距離が1万キロ以上あり、ネットワーク遅延時間が200ミリ秒というレベルだったため、最終的に非同期モードが選択された。ネットワーク遅延時間が200ミリ秒ということは、どんな小さな書き込みトランザクションでも、同期転送モードの場合は、都度200ミリ秒待たされるということである。これでは、ほとんどのアプリケーションはまともに動作しない。

　非同期転送を選択した後の課題は、可能な限り数多くのシナリオを想定して、データロストのパターンを考察することである。「どのような場合に、どれだけのデータロストが発生し、それを小さくするには、何をすればよいのか」という課題と常に向き合うことになった。

　その過程で筆者が用いたのは、長期にわたって採取した、顧客システムの「単位時間当たりの書き込みトランザクション量」の推移である。これと、転送可能なネットワーク帯域および選択したデータレプリケーションの転送アーキテクチャーとを照らし合わせ、顧客が納得できるリカバリシナリオを作り上げた。

　そこから先は、シナリオを実現するシステムの構築であったが、被災時のシミュレーションを机上、テスト機を問わず実施し、そこで得たエッセンスをシステムに実装していくといった手法を実施した。

　やや細かな話になるが、この時のシステム実装で得た教訓の1つに、パラメータチューニングの重要性がある。

　取り扱うソリューションに左右されるかと思うが、自由度の高いソリューションほど、各種バッファなどのパラメータ調整が可能なものが多い。この時に用いたソリューションもその傾向が強かった。

　このケースではシステム要件をクリアすべく、幾度にもわたってパラメータの調整を実施し、ベターな値を見出すに至った。ここで大きかったのは、システム本運用後、状況によっては再度の調整が必要になるとのリスクを事前に説明し、エンドユーザーの理解が得られたことだ。

　トランザクション量の振る舞いについては事前に十分かつ慎重に検討したものの、ビジネスの変化によって予測し得ない状態になる可能性もあるため、こういった考慮は必要不可欠だ。事実、本運用後もシステムアセスメントを得て、何度かパラメータ変更を実施している。

●運用フェーズ移行時のテストの重要性

　システムの構築完了の後に待っていたのは、運用の手順をまとめ、顧客にそのノウハウをトランスファーする作業であった。どんなに素晴らしいソリューションを導入しても、オペレーションの中に属人性が少しでも残っていれば、前述したケースと似たトラブルが必ず発生する。

　それらを回避するために必要なのは、繰り返しとなるが、可能な限り（本来ならばいっさいの排除がベストではあるが）属人性を排除した運用マニュアルと、本番環境を用いた徹底した運用テスト（サイトの切替演習、切替後のサイト運用など）である。

　このシステムの場合、こうした部分は十分に対策、実施することができた。また、ソフトウェアベースのソリューションを用いることで、ハードウェアに依存しない、可能な限り属人性を排除した方式設計を行うことができたのも、運用フェーズでのオペレーター教育の成功につながったと考察している。

　以上、2回に分けてストレージのディザスタリカバリを考慮するうえでの注意点について述べさせてもらった。地震、集中豪雨、台風などの天災や予期しない広域停電など、ディザスタリカバリを考慮しなければいけないビジネスシーンは確かに増えてきている。一連のエッセンスが読者のディザスタリカバリプラン作成の糧となれば幸いだ。