データベース・サーバーやバックボーン・ルーターなど24時間365日の可用性を求められるシステムは通常冗長構成が取られている。もともとTCP/IPネットワークも,回線交換通信網に比べ高伝送効率を図るというよりは網内拠点障害に強い通信網を作ることを目的としていた。

 電話交換網やインターネットのような大規模システムにおいては当然二重化程度ではなく,三重,四重の冗長構成が取られており,その実装や試験,検査などに膨大な人材と費用を投入して運用されている。しかし,中小規模のプライベート・システムにそれほどの時間と費用を掛けるのは現実的ではなく,一般的な冗長構成とは二重化のことであろう。ただ,二重化構成の作り方や運用の仕方によっては,大きな被害を被ることがあることを知っておきたい。

アクティブ・スタンバイに注意

 二重化構成には,フルタイム・デュアルとアクティブ・スタンバイがある。フルタイム・デュアルとは実冗長系とも呼ばれ,同じ処理をする二つの独立したシステムが稼働率50%未満で相互排他的に同時稼働している。どちらか一方がフェールしても,片方の処理キャパシティ内で継続稼働させるというモデルである。信頼性,可用性に優れているが高度な技術的実装が要求されるため,システムが高価になり,また運用技術的にも難しい。

 一方,半二重であるアクティブ・スタンバイ形式は切替冗長系といい,通常運転時にはアクティブ側だけが有効化され,スタンバイ側は無効化されている。アクティブ側に障害があった場合にのみスタンバイ側に処理を引き継ぎ,継続した稼働状態を提供するものである。比較的単純な技術によって実現され,システム・コスト,運用コストとも安価でフルタイム・デュアルに比べ導入が容易である。稼働システムの切り替わりに数十秒から数分の停止時間が発生するという問題もあるが,構築運用がし易く,また実績も多いため,メーカーやSI事業者のSEはこの構成を推奨している。

 しかし,このアクティブ・スタンバイ・システムには大きな危険が潜在する。

復帰するときが危険

 通常,アクティブ・スタンバイ・システムの導入試験や検査では,アクティブ側が完全に停止した場合,予定通りスタンバイ側に処理が引き継がれるかどうかのテストは十分に行なわれるが,アクティブ側が不安定な場合の動作検証は省略されがちなのである。

 しかし,現実にはシステムが瞬間的にダウンしてすぐに復帰したり,異常な挙動を示すがしばらくするとまた元に戻ったりという不安定な状況はよくある現象である。二つのシステムがそれぞれ排他的に動作しているフルタイム・デュアルであれば,片方に問題があってもシステム全体としてはそれほど大きな問題とはならない。

 一方,アクティブ・スタンバイのように完全に稼働,非稼働が切り替わるシステムは,プライマリがダウンと復帰を繰り返すことにより,処理がプライマリとスタンバイを行ったり来たりするようになる(発振現象)。さらに,切り替わりの周期がプライマリのダウンと復帰の周期と一致すると,ネットワークにパケットが大量にあふれ出るという「パケットストーム」を引き起こすことがある(共振現象,)。

図●共振現象
図●共振現象

 その結果,それぞれのシステムが異常な過負荷に陥ってしまう。そのシステムが全体に対して中核的な役割を担っている場合には,周辺のシステムに対して2次障害を引き起こすことにもなる。

三つのポイントで検査,評価しよう

 従って,アクティブ・スタンバイ・システムでは,一度アクティブ側がダウンし,スタンバイ側に処理を引き継いだ後でアクティブ側が再び復旧して来た場合,自動的に処理をアクティブ側に戻すというというような設定をしてはいけない。一度ダウンした系がたとえ自動的に復活してきたとしても,手動で再アクティブ化するような運用をすべきである。これはデータベース・システムだけではなくバックボーン・ルーター,エッジ・スイッチも同様である。

 特にルーターやスイッチのようなネットワーク機器の場合,メモリーの一部に障害が発生したり,過負荷を検知したりするとシステムを強制的にリブートさせてしまう製品が多い。メモリー障害でリブートし,再び立ち上がった後,同じメモリーに読み書きした時点で,またシステムをリブートさせるという繰り返し現象が発生してしまう。

 システムが障害検知をして自律的にリブートした場合であっても,オペレータの処理を介在せずに機能が有効になるような運用は避けなければならない。特にバックボーンに近いネットワーク機器をVRRP(Virtual Router Redundancy Protocol)によって冗長構成している場合,VRRPノード間で発振現象が発生すると,ネットワーク全体にパケット・ストームを引き起こす可能性があるため非常に危険である。

 冗長構成のシステムを検査,評価する場合には,以下のポイントに注意しよう。

  • アクティブ系がダウンした場合,安全にスタンバイ系に処理が引き継がれるか?
  • ダウンしたアクティブ系が自動的に復活してきた場合,スタンバイ系から自動的に処理を引き戻さないか?
  • ダウンしたアクティブ系が新たにスタンバイ系として立ち上がった後,現状のアクティブ系(もともとスタンバイ系)がダウンした場合,安全に処理が元のアクティブ系に引き戻されるか?

 稼働スケジュールのギリギリにシステムがセットアップされるとなかなか上記のようなテストに時間を割くことは難しいかもしれない。しかし,たとえ稼働スケジュールを遅らせてでも,この観点でのテストや検査は行っておきたい。こういったテストをせずにそのシステムによるサービスを開始し,ここで説明したようなパケットストームが発生した場合,その被害,損害は計り知れない。

 また,十分なテストや検査,評価を行い,その結果,予定通りに切り替わり動作が行われたとしても安心してはいけない。トラブル,障害とは,常に予想しなかった個所や状況の下で発生する。システムの運用は機器の機能や性能だけに頼るのではなく,稼働状況や障害時の動作状況をオペレータの目と耳と手で確認すべきなのである。そのような運用の姿勢が,最も安定したシステムの可用性を生み出すということを忘れてはならない。


伊勢 幸一
ライブドア 執行役員 ネットワーク事業部 技術担当
 本来の専門は機械工学。機械系メーカー,オープンシステム系ベンチャーSI事業者を経て,1996年にスクウェア(現スクウェア・エニックス)に入社。その後,スクウェアUSAへ出向し,ハリウッド映画製作に参加。2000年に帰任し,PlayOnlineプロジェクトを立ち上げる。2005年,独立してスタジオ・ファリストを設立後,ライブドアに入社。技術担当執行役員を務め,現在に至る