 |
≫ |
|
|
|
なぜHP NonStopサーバは911テロ当日に復旧できたか？
――HP NonStopサーバ災害対策のメカニズムを探る
|
|
|
|
100年以上の歴史を持ち、世界で4番目に大きい商品取引所であるNYBOT（ニューヨーク商品取引所）。コーヒーやココア、砂糖といったいわゆるコモディティを扱う同取引所は、2001年のアメリカ同時多発テロ事件により文字通り「壊滅」し、取引停止を余儀なくされました。しかしNYBOTでは、事前に準備した災害対策プランに基づき、ニューヨーク郊外のロングアイランドに設置されたバックアップ・システムへの移行を直ちに実施。事件当日の午後8時にはすでにバックアップ・システムの稼働準備が整っていたといいます。立会所のスペースや電話回線の不足により実際の取引再開には1週間ほどを要したものの、システム面では災害対策のお手本とも言えるきわめてスムーズな対応を見せました。いわば「アメリカの強さ」を示したこの事例は、NYBOTが1995年から運用を開始したHP NonStopサーバによる災害対策システムのたまものです。
HP NonStopサーバの災害対策は、世界各国の金融機関、通信事業者などで70年代から広く導入されています。とりわけイギリスの金融機関では歴史的にテロ対策のニーズが高く、それに応えるかたちでHP
NonStopサーバの災害対策も完成度を高めてきました。その結果、災害対策としては世界的にもオンリーワンの地位を確立しています。国内でも20年前から都市銀行に導入されているほか、大手コンビニエンスチェーンのPOSシステム、大手家電メーカーの受発注システムなどの災害対策システムを実現しています。
図1は、国内大手コンビニエンスチェーン（以下、CVS）に導入されたHP NonStopサーバによる災害対策システムの構成図です。このCVSでは、元々UNIXサーバで構築されたPOSシステムが運用されていましたが、高負荷時にはセンター側のホストで注文の取りこぼしが発生したり、災害対策が手つかずであったりという課題を抱えていました。そこでHP
NonStopサーバによる災害対策システムを導入し、国内約数千店と取引先約数百社、そして西日本と東日本にデータセンターを置くPOSシステムを新たに構築。負荷分散を実現しつつ業務継続性の確保を実現しました。
では、こうした第一級の災害対策システムは、実際にどのようなアーキテクチャによって実装されているのでしょうか。以下では、その背後のメカニズムにスポットを当てます。 |
|
一般に災害対策システムは、右図の3種類の運用形態のいずれかをとります。
NYBOTでも用いられていたのが、1)の「Active-Standby型」です。この形態では、現用系とほぼ同規模の待機系を遠隔地にも用意します。待機系は通常時には稼働させず、現用系のダウン時に切り替えて使用します。
一方、2)の「Active-Active型（共有式）」では、待機系でも同一の業務を運用します。いずれか片方のダウン時には、もう一方が縮退運転することで肩代わりします。つまり、災害対策と同時に負荷分散も実現するモデルです。このActive-Active型では、双方で同じ業務を運用するため、それぞれのデータをいかに同期させるかがポイントとなります。
最後の3)「Active-Active型（非共有式）」は、2つのシステムで別々の業務を運用し、現用と待機の2つの役割を相互に担う仕組みです。この場合、共有式のようにデータの同期を考慮する必要がないため実装が容易で、かつ資産も有効活用できます。
|
|
いずれの形態においても、災害対策システムの要となるのが、データの「レプリケーション」（コピー）の実現方法です。
1)の「リアルタイム逐次反映型」は、現用系で更新されたデータ内容を、待機系にもリアルタイムに送信します。とはいえ、遠く離れた待機系のデータ更新を確認しながら処理を進める方法（完全同期型）では、高いパフォーマンスは得られません。そこで、現用系へのデータ更新が終わるとアプリケーションは直ちに次の処理に進み、待機系へのデータ更新はバックグラウンドで実行します。この場合、現用と待機の間ではわずかな時間（例えば数秒）のデータ内容のズレが生じますので、待機系に保存されているデータは厳密な意味での最新版ではありません。しかし、災害対策によってアプリケーション性能が損なわれない点がメリットです。
一方、2)の「リアルタイム完全同期型」は、待機系へのデータ更新をアプリケーション側で確認しながら次の処理に進む方法です。1)に比べるとパフォーマンスは低下しますが、現用と待機のデータ整合性を完全に保証でき、障害時の切り替え後にもデータの不整合が起きることはありません。市場取引や決済など、厳格な整合性が求められる用途に適しています。
最後の3)「バッチ更新型」は、例えば1日に数回のバッチ処理により現用から待機へと更新内容をコピーする方法です。3種類のアプローチのうち、ネットワークやシステムのコストをもっとも低く抑えられる方法です。データ更新処理の頻度が少ない用途や、必ずしも最新のデータでなくても大きな問題とならない用途（情報提供サイトなど）に向いています。
このように災害対策システムにおけるレプリケーションは、つねに「パフォーマンス」と「データ整合性」のトレードオフとなります。通常運用時のパフォーマンスを損ねることなく、いかにして業務上求められる整合性を維持するかがポイントです。
|
|
印刷用画面へ
