東京証券取引所 株式売買システムのディスク障害による株価情報の配信ができなかったインシデントに関するメモ

公式な社外取締役による調査報告書がありますので、一次情報としてはそれを御覧ください

以降は、上記報告書が出るまでの私的なメモです

2020/10/01に発生した東証のインシデントに関する個人的に気になってたことメモ。適時更新

https://gyazo.com/6e0c104ede0405dc2bdc08a96d432700

タイムライン

2009:

宮原氏 東京証券取引所グループ常務執行役　就任

2012:

売買停止 -> 再開示のトラフィック過負荷インシデント

2013:

宮原氏 日本取引所グループ常務執行役　兼　東京証券取引所常務執行役員

2014:

宮原市 日本取引所グループ専務執行役

2015:

宮原市 日本取引所グループ取締役　兼　東京証券取引所代表取締役社長

2018:

メリルリンチによる大量データ送付による回線パンクインシデント

2020:

宮原氏 日本取引所グループ取締役兼代表執行役グループCo-COO 兼 東京証券取引所代表取締役社長

10/01: 東証インシデント発生

↑に加えて

07:04: 障害検知、障害内容の特定開始、影響範囲特定（07:10, 07:40)

08:00: 注文受け付け開始

08:01: 情報配信がされていないことを証券会社に通知。

08:30: 売買停止の判断

システム回復しなければ売買停止をするのが原則であるため、それに従った

08:40: ロードバランサー遮断

これは、イレギュラーな方法

08:54: 証券会社との接続を強制遮断（売買停止）

09:00: (本来は売買開始の時間)

09:01: 売買停止判断と作業をしたものの、取引は実行されてしまった

11:45: 終日売買停止を公表

16:30: 記者会見

10/05: システム障害に係る（独立社外取締役から構成される）調査委員会の設置について

11/30:

宮原市 日本取引所グループ取締役・代表執行役グループCo-COO、東証代表取締役社長　辞任

ビジネスインパクト

CSの部門の方に聞いたことあるけど、特別窓口をたてるとき1,000~2,000万が飛ぶらしい

売買停止までに受け付けた注文の取り扱い

約定が成立しなかった形でキャンセル扱い。再注文が必要

信用取引や追証については確認中

当日、上場ができなくなった会社は３社あった

10/01は根付かず

09/30の終値をもとにストップ高・安が決定される

特別な取り扱いはしない

情報はHPで出す

障害原因: 共有ディスクでメモリ障害が発生した場合に切替を正常におこなうための設定漏れ/ミス

https://gyazo.com/e9ff8f353eccbebe7020103be5324237

マニュアルの記載と実際の仕様の齟齬が生じた原因は、当該共有ディスク装置のオペレーティングシステムのバージョンアップにより製品仕様が変更された際に、マニュアルの記載が変更されていなかったこと

東証側の調査により、メモリ故障時にFOするための設定値が入ってなかったことが原因とわかっていた。じゃあ、その原因はというと、、、というのが今回のレポート。結果、マニュアルには、メモリ故障時には自動切替がおこなわれると書いてあったけど、実際の仕様とは異なり、そしてその原因はバージョンアップによる変更差分がマニュアルに反映されていなかったということ。

共有ディスクは何を保管するものか

売買関係のパラメタ

ジョブ実行時のパラメタ（例: 売買が始まる前に当日の基準の情報とか、その日における時間の制約など）

売買をおこなう基礎的なデータ

(個人的な重要ポイント）売買に関するポリシーデータ。監視や情報発信のジョブに使われるポリシーデータの参照ができなくなった

売買に直接関係ないデータが、売買そのものに影響を与えてしまった

これ（共有ディスク装置） は 1 号機、2 号機と両現用で運行しておりますので、いわゆるフェイルオーバーという形

で切り替わるはず

共有ディスクがどこにあるものかはわからない。システム概要図にあるデータベースのような気もするが、その場合情報配信GWサーバーとの関連性がないように見える

物理構成が不明ですけど、仮想基盤のデータストアとして共有ディスクを利用してたなら、仮想マシンからデータストアが見えなくなるので、論理的には関係なさそうに見えても、一緒にアボーンしますね

https://gyazo.com/b41ad111725b1b8b9d74048c8b15def6

当日中の売買再開が難しかった理由

売買再開には、（全体）システム再起動が必要だった。が、それはできなかった

過去の２件のインシデントからの「注文の継続受付 + 障害時のヒアリング徹底」対応が災いした

2012: 同じシステムで障害時

東証システム上で売買を停止 -> 発注できなかった注文が証券会社に滞留

売買再開時に証券会社の送信トラフィックが過負荷に

その教訓をうけ、障害時でも注文を受け続けた

(障害時の注文受け付けは、今後も継続される模様)

他回線への切り替えを円滑にできなかった証券会社から売買機会の公平性に関して不満がでた

障害時に、証券会社と状況や対策の聞き取りを徹底するようにした

(聞き取りを徹底するようになったものの、再開のためのルール・基準・手順は未定)

全体システム再起動というスコープでないといけなかったのか?

運用系だけか、注文売買系か、で閉じれなかったのか

当局とは調整していない

ヒアリング結果

再起動を行う場合、投資家や市場参加者に相当の混乱が生じそうだった

その場合、顧客対応と円滑な売買の実施が困難と判断した

障害時から再起動する場合、障害テストも含めて完了とするはずなので、単純に見積もり時間が当日の場に間に合わなかったんじゃないか

個人の経験をベースにして、そこまで大きくないシステムで発生した普通のHW障害でも、大体3~4hr x 1.5（緊急時のバッファ時間）を見積もってたことから考えると、まあ、ちょっと当日中はタイムスケジューリング的にも無理ゲーそう

BCP（contingency plan?）を発動できなかった理由

東証はプライマリとセカンダリDCを用意している。両方とも関東圏にあるので、セカンダリDCは関西に移行する予定である（昨年公表済み）

売買停止が08:57だから、ぎり24時間以内？

ただ、システム全体再起動に失敗して、10/2から再開できていなかったらBCP未達になるので、この判断は結構、ストレスだった様に思える

再発防止策

ネバーストップに加え、レジリエンス（障害回復力）にも重視する策

システム対応と総点検

切替ディスク装置の切替え設定値の修正・総点検

切替手順の確認・整備

切替テスト・訓練

確実に売買停止するための手段の拡充

売買停止できないケースの確認　および　支持方法や運用手順の整備

売買停止できないケースでの、注文受付の開始についても見直しが入りそう

共有ディスク装置を経由しない売買停止機能の開発

市場停止及び再開に係るルール・手順・基準の整備・明確化

今後の主な検討課題

市場停止及び再開に係るルール・手順の整備

コンチプランにおける売買再開基準・運用の明確化

情報発信の拡充

Arrow Headについて

ArrowHead: 株式売買システム。高速かつ可用性の高い(99.9999%)なシステム要件をクリアする。「参加者GWアプリサーバー」「注文管理サーバー」「トレーディングサーバー」から構成される。

https://gyazo.com/15f646a84290ddc6b865ede2996e8816

https://gyazo.com/1d862ccce136396f57fd0684466982a5

証券機能としては、注文系と約定系を並列処理する

https://gyazo.com/355ba2c1ceedde7850224c9771f53ba2

注文処理は証券会社ごとに処理（注文管理サーバー）

約定処理は株式銘柄ごとに処理（トレーディングサーバー）

証券会社から送られた注文を、証券会社別注文キューにいれ、そこから取り出した注文データを、銘柄別キューに入れる

それぞれのノード（サーバー）は、本番系だけでなく、同じ処理を行う待機系を並行動作させている

３ノード構成にしてる（本番x1, 待機x2)

「Preimesoft Server」: ↑を実現するミドルウェア。

データの３重化とデータ同期をするメモリーデータべース機能を提供する

参加者GWアプリ、注文管理アプリ、トレーディングアプリで独立したプロセス間のデータを非同期的に受け渡す

また、書き込み処理（tx）はノード間でメモリー同期を行う

UDPベースだが、独自プロトコルによる信頼性をカバー

メモリなので、ノード障害が発生するとデータが消えちゃうので、本番系 -> 待機系にデータを複製

https://gyazo.com/4e55f659590ce5a37d6ef9262295ed89

東証・JPX vs 富士通

富士通: ハードウェア障害、切替のためのマニュアルの不備、手動切替の準備不足

東証・JPX: 切替マニュアルのテスト、取引再開ができなかった原因

日本の証券マーケットの唯一の組織、それを独占しているのが JPX であり、東証である

この東京マーケットというもの、日本ではほとんど１つしかない証券取引所です。それを独占でマネジメントしている、そういう会社なんだという緊張感。

マーケットというのは、富士通と東証だけでつくっているものではないんですよと。ここには取引参加者がいて、そのもっと先にある投資家という人がいて、その投資や結果によって利益を得ている国なり何なり、全体というオールステークホルダーがいるのだ

問題は Never Stop と言ったときに、ストップしないんだというのが前提になってしまう。そうすると、どうしたって、「いや、待てよ、ストップするかもしれないぞ、そのときにどうするんだ」という次のステージに発想が及ばなくなってしまう

そういう点では、Never Stop というのは、常に機材と東証の関係だけ見ていて、止まってしまったときに大事なプレーヤーは誰かというと、やっぱり取引参加者、そして、投資家、みんなそういう人たちが利害関係人だよねという認識がないと、健全なマーケットは作っていけないのかなと思った

誰か１人が責任を取るとか、そういう問題なのかどうかについては私にはよく分かりません

責任を追及して解任をするとかっていう、そういう話では全くないわけで、自ら辞任をなさるという、そういうご意向だったというふうに聞いております

委員長の久保利弁護士は、発生原因となった機器の問題については「主として富士通の側に原因があった」と指摘

テストをしっかり実施していれば防ぐことができたかもしれず、「東証にも一定程度の責任があった

再開についても「（様々な状況について）事前検討をしっかりしていなかったしルールもなかったのは問題があった」と指摘

再開できる仕組みを作っていきたい

納品後に仕様変更があったにもかかわらず、その認識が富士通になかった。富士通にも責任があると感じているが、機器が変わったときにチェックしておくべきだと指摘されると反論の余地がない

その他

システム障害に関するヒアリングであれば次は確認したい

タイムライン、障害発生ポイント、影響範囲、復旧もふくめた直近の対応、報告態勢、次回の報告タイミング

ユーザーにたいしてどうリスクを抑えるか、市場での被害をどう極小化するか、、、という観点

記者の質問の質について

やっぱり記者は責任の所在を気にするよね　（個人的には間違ってないと思う）

損失の補填については、「原因究明をする」という保留のような回答をしていた

でも、44:57のなぜセカンダリDCに移行しなかった（≒こんち発動しなかったのか）という質問はよかった

同じ人でもそれぞれ質問内容の質がことなってるのはおもしろかった

例: 上のBCPについて聞いたNews Pickの人が、「難しいシステムなので後で教えて下さい」とかいってたり

記者の人は経済的損失やビジネス影響も気にされているので、一定の質問は的を得ているとは思った（ひどい質問もあったけど）

上場できなかったという会社もあり、その場合、資金調達などの市場に一定の遅れがでるというビジネスインパクトはあると思うので、そういう観点の質問はあって然るべきかなっておもった

証券市場は流動性も大事なので。

収益と公益のバランスをとっていく

市場運営の安定な運営がトッププライオリティ

ref