東京証券取引所 2020年機器の故障からの終日の売買停止

二重化した共有ディスク装置の1号機でメモリが壊れ、2号機への自動の切り替えが働かなかった。切り替えの設定値の意味がマニュアルと実機で違い、その壊れ方を試す試験も無かった。売買を止める手段はどれも同じ装置に頼っており、ネットワークを切って止めたため、装置が戻った後も当日中に再開できなかった。

攻撃ではなく、機器の故障から始まった障害です。2020年11月30日の日本取引所グループの独立社外取締役による調査委員会の報告書、同日の金融庁の業務改善命令、2021年3月25日の東京証券取引所の再発防止策検討協議会の報告書に沿って書いています。設定値は2020年10月4日に直され、10月5日から正しい値で動いています[1]。売買の停止と再開の決まりは2021年4月から順に実施されました[4]。2026年11月時点の公開資料で書いています。

要点

故障したのは共有ディスク装置 NAS の1号機のメモリカード。耐用年数内の偶発の故障で、調査委員会はこの点で東証の対応に問題を認めていない。
切り替えの設定「オンパニック」を False にしていた。マニュアルでは False でも15秒後の引き継ぎは働くとされたが、採用した機種では、故障の通知を先に受けると引き継ぎ自体が働かない仕様に変わっていた。
本番の前の試験は生存監視の通信を切る形だけで、装置本体が機能停止を知らせる形を試していなかった。
通常の売買停止、市場停止、緊急用の売買停止の3つが、どれも壊れた NAS のファイルを使っていた。ロードバランサを切って止めたため、約定が内部に残り、再開の道が塞がれた。
注文を受けたまま止めた後に再開する手順も、システムを立ち上げ直して再開する試験も無かった。直しは、切り替えの検証、停止の手段の独立、停止と再開の決まりと訓練の3つ。

何が起きたか

図1 2020年10月1日の朝の流れ

日時	公表資料の内容
2015年9月	2代目の arrowhead が稼働。NAS の設定値 False を引き継ぐ。この時期の NAS では、False のときの動きが既に変わっていた[1]
2019年11月	3代目の arrowhead が稼働。設定値 False を踏襲。同じ月に富士通は NAS の供給元から訂正版のマニュアルを受け取っていた[1]
2020年10月1日 7時4分	NAS 1号機のアクセス異常を示すメッセージを大量に検知。7時10分、売買監理と運用管理の画面の一部にログインできなくなる[1]
7時37分	障害対策本部を設置[1]
8時	注文の受付が通常どおり始まる[1]
8時16分から9時23分	1号機の強制の電源断、2号機への遷移、ポートの閉塞、富士通から渡されたコマンドを順に試し、どれも切り替えに至らない[1]
8時36分	全銘柄の売買を立会の開始から止めると決め、通知。通常の売買停止、市場停止、緊急用の売買停止はどれも実行できなかった[1]
8時54分、8時56分	arrowhead と立会外の ToSTNeT の前のロードバランサを遮断。相場情報の遮断は9時をまたぎ、9時から約1分、約定の情報が配信された。9時11分にその約定は無効と通知[1]
9時26分	コマンドに追加の指定を付けて強制の切り替えに成功[1]
11時、11時45分	臨時のリスク管理委員会を経て終日の売買停止を決め、11時45分に公表[1]
10月1日 22時	故障したメモリを載せたマザーボードの交換が終わる。10月2日の売買は問題なく終わった[1]
10月4日、5日	本番のオンパニックを True に直し、10月5日から正しい設定値で稼働[1]
11月30日	調査委員会の報告書。金融庁が東証と日本取引所グループに業務改善命令[1][2][3]
2021年3月25日	再発防止策検討協議会の報告書。売買停止の方針、取引所による注文の取消し、再立ち上げによる再開、再開の基準を4月から順に実施[4]

起きた仕組み

切り替わらなかった理由

図2 設定値 False の意味の食い違いと、当日の動き

NAS の自動の切り替えには、生存監視の応答が途絶えて15秒後に引き継ぐ標準の方式と、相手から機能停止の通知を受けて即時に引き継ぐ方式がある。東証の要件定義は、機器の故障でも30秒以内に切り替えを終えることを求めていた[1]。

供給元は、初代の稼働中に作り始めた機種で False のときの動きを変え、初期値を False から True に変えた。仕様書には初期値の変更だけが書かれ、動きの変更は書かれなかった。富士通の製品の担当は初期値の True だけを実機で確かめ、False は書面で確かめた。2015年時点のマニュアルの記載は東証の認識と同じで、東証も詳細設計書のレビューで誤りに気付けなかった[1]。

当日は、1号機が2号機へ故障の通知を送った後に生存監視が途絶えたため、即時と標準のどちらの引き継ぎも働かなかった。2代目の稼働中は問題が出なかったため、設定は3代目でも引き継がれていた[1]。

架空の二重化の設定。名前と値は本物ではない

# storage-ha.conf  架空の例
takeover.on_panic = false
# 手元の文書: 即時の引き継ぎだけを止める。15秒後の引き継ぎは常に働く
# 実機の動き: 通知を先に受けたら、15秒後の引き継ぎも止まる
# 確かめ方: 文書でなく、この値のまま本体の機能停止を注入して切り替わるかを見る

試験の抜け

壊れ方	2号機が受け取るもの	False のときの実際	本番の前の試験
1号機との通信が切れる	生存監視の応答の途絶	15秒後に引き継ぐ	した
1号機の本体が機能停止する	故障の通知、続いて途絶	引き継がない	しなかった

東証と富士通は、False でも本体の機能停止で引き継ぐと考えていたため、生存監視の通信を切る試験で業務が続いたことをもって、故障時の引き継ぎの設計が全体として正しいとした。調査委員会は、本体の機能停止を再現する試験をしていれば設定の不備に気付けた可能性があるとし、この点で東証にも一定の責任があったとした[1]。

止める手段が同じ装置に頼っていた

図3 売買を止める手段の依存と、再開が塞がれた理由

複数のサーバーで使うファイルは、設計の効率とデータの一元性のため、できる限り NAS で一元管理されていた。売買停止の手段は通常の手段が使えない場合に備えて複数用意されていたが、緊急用の売買停止も、対象の銘柄を指定するファイルを NAS に置く作りだった[1]。予備の手段が主の手段と同じ部品に頼れば、その部品が止まったときに両方とも止まる。調査委員会は、緊急用の売買停止は、いかなる事態でも確実に実行できる構成にしておくべきだったとした[1]。

ロードバランサの遮断は約定の処理を止めないため、8時54分までの注文で約定が生まれ、その通知が内部に残った。ネットワークを戻せば無効の約定の通知が取引参加者に届く。arrowhead を立ち上げ直せば注文と約定は消えるが、取引参加者の側は発注済みの注文を抱えたままになる。立ち上げ直して再開する手順は、取引参加者と合意も試験もされていなかった。聞き取りで再発注できると答えた参加者の売買代金のシェアは約38%で、コンティンジェンシー・プランの50%に届かない見込みだった[1]。

止まらない、だけを目標にした結果

調査委員会は、Never Stop の標語を強調しすぎ、障害の日も8時の受付と9時の開始を絶対のものとして対処したため、回復後の再開ができなかったのは本末転倒だとした[1]。金融庁も、Never Stop に比べてレジリエンス、つまり障害からの回復力の取り組みが遅れていたと指摘した[2]。

どこで止められたか

図4 障害が終日の停止に広がった5段と、それぞれで止める仕組み

段	この件で公表資料にあること	直しとして示されたこと
2 切り替わらず	仕様とマニュアルの相違で、故障時に別系統へ切り替わらない設定になっていたことを、東証も委託先も把握していなかった[2]	全設定値を要求仕様と製品の動きに照らして総点検し、出荷前の実機の検証と違う値は実機で確かめる。機器の仕様変更の確認の手順を委託先も含めて見直す[1][2]
3 戻せない	自動の切り替えが働かない場合の対処のコマンドの準備が不十分だった[1]	切り替えが不調のときの手順を新設し、機器の状態ごとの対応を一覧にする。NAS の切り替えの試験と訓練を続ける[1]
4 止められず	3つの停止の手段が、どれも故障した機器の正常な稼働を前提にしていた[2]	NAS を経由しない売買停止を開発する。1つの機器の故障や機能の不全で停止の指示が効かなくなる所がないか、依存の関係を全体で点検する[1][2]
5 再開できず	障害時に注文の受付を止める決まり、受け付けた注文の扱い、再開の決まりが無く、参加者の側の試験と訓練も無かった[2]	影響が読めないときは注文を受けずに止める。取引所が注文を取り消せることを規則にする。再立ち上げによる再開の手順と、再開の基準を決め、参加者と訓練する[4]

2 切り替わらず。文書でなく動きで確かめる

二重化は、切り替えが働いて初めて意味を持つ。設定値の意味を文書で確かめても、文書が実機と違えば何も分からない。富士通の管理規定は初期値だけを実機で確かめ、それ以外の値は仕様書の整合で確かめる決まりだった[1]。初期値から外した値は、作り手が試していない動きに入る。本番で使う値のまま、想定する壊れ方の1つずつを実際に起こして確かめる。確かめ方の段は AIの出力を確かめるの3段目、実物で確かめる、と同じ考え方である。

3 戻せない。働かない場合の手順

強制の切り替えは、富士通の製品の担当から渡されたコマンドに追加の指定を付けて9時26分に成功した[1]。自動の切り替えが働かない場合を前もって想定し、そのコマンドを手順に書き、試しておけば、2時間余りの手探りは要らなかった。調査委員会は、他社でも二重化の切り替えが働かず大規模な障害になった例が報じられていることを挙げ、手動の切り替えの準備が不十分だったとした[1]。

4 止められず。停止の道を独立させる

止める仕組みは、止めたい原因と同じ部品に頼ってはならない。失敗したときにどちらに倒れるかの設計は A10 例外的な状況への不適切な対応にある。売買の停止は、障害のときに確実に閉じる側へ倒すための機能であり、その機能自体が障害で止まれば、失敗した時に開いたのと同じになる。

5 再開できず。止めた後の道を決めておく

再発防止策検討協議会は、影響が読めないときは注文を受けずに止める方針、止める手段の優先の順、取引所による注文の取消し、再立ち上げによる再開、再開には参加者の売買代金のシェアで概ね5割、個人投資家のシェアで概ね3割、参加者の数で概ね5社を基準とすること、再開の前に最低15分の注文受付と立会の時間を取ること、を決めた[4]。立ち上げ直して再開したときの注文と約定の扱いは、取引所の側でも公表されている[5]。止めた後の手順が決まっていて初めて、止める判断を早くできる。

守り方

根本の直し

冗長化の切り替えは、本番で使う設定値のまま、想定する壊れ方の1つずつを注入して確かめる。通信の途絶だけでなく、本体の機能停止、応答の遅れ、部分の故障も試す[1]。
初期値から外した設定は、作り手が試していない動きとして扱い、実機で確かめる。機器や部品の仕様が変わったときに、何を確かめ直すかの手順を委託先も含めて決める[1][2]。
止める、切り離す、戻す、の制御の道を、止めたい原因になる部品から独立させる。1つの部品の故障で、主の手段と予備の手段が同時に止まらないかを依存の図で点検する[2]。A10 例外的な状況への不適切な対応

緩和の策

自動の切り替えが働かない場合の強制の切り替えの手順を、機器の状態ごとに書き、訓練で使う[1]。
止めるかどうかの判断の期限を決めておく。何時までに戻らなければ止める、影響が読めなければ受け付けない、のように[1][4]。
止めた後に再開する手順を、つながる相手と合意し、合同で試す。立ち上げ直して状態を消す再開も、1つの手段として試しておく[4]。
障害のときに何を、どの頻度で、どこへ出すかを決めておく[4]。記録と警告は A09 セキュリティログとアラートの不備にある。

参照

システム障害に係る独立社外取締役による調査委員会の報告書について日本取引所グループ、2020年11月30日。調査報告書を含む
株式会社東京証券取引所及び株式会社日本取引所グループに対する行政処分について金融庁、2020年11月30日
システム障害に係る業務改善命令及び責任の所在の明確化について日本取引所グループ、2020年11月30日
再発防止策検討協議会報告書東京証券取引所、2021年3月25日
売買システム再立ち上げによる売買再開日本取引所グループ

東京証券取引所 2020年 機器の故障からの終日の売買停止

要点