写真●記者会見に臨む鈴木義伯常務取締役CIO(中央)
写真●記者会見に臨む鈴木義伯常務取締役CIO(中央)
[画像のクリックで拡大表示]

 3月10日に東京証券取引所の株式売買システムで障害が発生し、午前9時から午後1時まで2銘柄が売買できなかった問題(関連記事1関連記事2)で、東証は同日午後5時から緊急の記者会見を開いた。鈴木義伯常務取締役CIO(最高情報責任者)は、「データベースのデッドロックが引き金だった」と説明した(写真)。

 デッドロックが発生したのは午前8時59分43秒から44秒にかけて。午前の取引が始まる午前9時の直前だ。複数銘柄の注文を1つにまとめた「バスケット取引」のトランザクションと、同注文に含まれる一部銘柄の訂正注文のトランザクションとの間で起こった。

 2つのトランザクションが、それぞれどのようなデータベースをロックしたまま放さなかったのかについては公表を避けたが、注文データを格納するデータベースと、バスケット取引のデータを格納するデータベースの2つだったとみられる。

 オンラインでデータベースを更新するトランザクションを実装する場合、複数のトランザクションによるデータの2重更新を避けるため、更新処理が完了(コミット)するまで、更新対象のデータを占有(ロック)する。ロックがかかっているデータは、他のトランザクションからの更新はできない。2つのトランザクションが、それぞれ別々のデータをロックした状態で、お互いがロック中のデータにアクセスすると、ともにロック待ちになったまま動かなくなる。この状態をデッドロックと呼ぶ。

 デッドロックが発生した場合、後から起動したトランザクションを強制的に終了させて先行するトランザクションを優先的に完了させるのが一般的だ。後発のトランザクションは、一定時間が経過した後で再起動(リトライ)する。東証の売買システムでも、同様のルールで「後発の訂正トランザクションをリトライさせた」(鈴木CIO)。だが、先行のトランザクションが終了しないまま、デッドロックが再び発生して、またリトライを繰り返すという事象が起きた。

 リトライが続きシステムに無駄な負荷がかかるのを防ぐため、東証の売買システムでは、リトライする回数の上限を100回と定めている。今回は、この上限を超えたために訂正のトランザクションが異常終了した。

 正常に処理できなかった訂正注文の中に、アルプス電気と名古屋鉄道の2銘柄が含まれていたため、これら2銘柄が売買停止となった。システムで処理できなかった訂正注文については、午後1時の売買再開までに運用で対処した。

 鈴木CIOは、「デッドロックの発生自体は想定しており、リトライのロジックにも問題がなかった」と説明した上で、「リトライが繰り返されるのは想定外の事象だ」と明かす。後発のトランザクションをリトライしたのにどうして正常に処理されなかったのは、「詳細を調査中」(同)と話すにとどめた。東証は今夜中に再発防止の対策を講じ、明朝までにシステムの修正とテストを終える考え。

 東証の株式売買システムは2000年5月の稼働。富士通製メインフレームで動作している。アプリケーションの開発ベンダーは富士通。デッドロックを検知するトランザクション制御ソフトは、富士通製「AIM」を使っている可能性が高い。