東京証券取引所
[画像のクリックで拡大表示]

 今週2月2日、東京証券取引所の株式売買システム「arrowhead」に障害が発生し、計300銘柄以上が3時間半にわたって売買できなくなった。arrowheadは、東証が満を持して2010年1月に稼働させたシステムで、旧システムと比べて処理速度が最大で600倍に高速化した。取引に影響を与えるようなトラブルは今回が初めて。

 障害の原因は、株価情報を証券会社などに配信する「情報配信システム」のハードウエア故障だ。信頼性を高めるため、情報配信システムは3重の冗長構成になっているが、故障発生時の切り替えが正常に動作していなかった。

しばしば起こる「冗長構成の機能不全」

 ミッションクリティカルなシステムでは、2重化/3重化の冗長構成にして信頼性を高めるのが一般的だ。しかし、信頼性を高めるはずの冗長構成が意図どおりにうまく機能しないトラブルは珍しくない。

 いくつか例を挙げよう。2011年8月16日、NTTドコモのspモードにトラブルが発生した。原因は、コアネットワークを構成する中継ルーターの故障だった。中継ルーターはもちろん冗長化されていて、故障の後、予備系へすぐ切り替わったのだが、それをきっかけに、それまで接続していたセッションが切断されて新規接続(再接続)になったユーザーがいた。さらに、ほかのユーザーから通常の新規接続要求が重なったことによって、認証サーバーで輻輳が発生したという。

 冗長構成をとる場合、切り替え後に発生し得る状況をよく検討すべき、という教訓を残した。

 2009年2月24日(米国時間)、Gmailで世界的な規模の障害が発生したのを覚えているだろうか。米Googleはデータセンター単位で冗長化する障害対策をとっているが、それを制御するデータセンター用基盤ソフトとGmailの両方に不具合があった。障害が発生したデータセンターから他の複数のデータセンターにユーザーの処理やデータが引き継がれたが、引き継ぎ先のデータセンターで過負荷が同時多発的に発生。Gmailが利用できなくなったという。冗長化の仕組みにもリスクが内在することを示唆している。

 このGmail障害の2週間後、日本では2009年3月9日に気象データの配信システムがダウンした。2台のサーバーによるホットスタンバイ構成だったが、本番系サーバーが故障した後、待機系への切り替えがうまくいかなかった。引き継ぎ情報を格納した制御系ファイルがなぜか壊れていたからだ。このケースも、冗長化の仕組みに問題が隠れていた。

 今回、東証の情報配信システムの障害では、3重化したサーバーのうち1台が故障した。これを知った職員は、診断用ソフトウエアでシステムの状況を解析し、残り2台への切り替えは正常に行われたと判断したが、実際は切り替えに失敗していた。なぜこのような現象が起こったのか。詳しい原因は調査中である。

 なお、参考までに東証で過去に発生した主なシステムトラブルに関する記事を以下にまとめた。また、特番サイト「相次ぐシステム障害」でも多数のトラブル事例を紹介している。この機会に、あなたの会社のシステム障害対策を再点検してみてはどうだろうか。

2008年2月8日、新派生売買システムに障害発生

2008年3月10日、株式売買システムにトラブル

2008年7月22日、派生売買システムに障害

2005年12月8日のみずほ証券誤発注問題